Planning
Figure 2 illustrates the primary tasks accomplished during the Planning Phase.
.gif)
Figure 2. Planning Phase activities
On This Page
.gif){kind=icon}
Roles and Responsibilities
Installing Deployment Workbench
Adding Operating Systems
Adding Device Drivers
Adding Updates
Adding Language Packs
Choosing an Image Strategy
Milestone: Build Lab Created
Roles and Responsibilities
All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 3 lists those roles and defines the focus areas for each role cluster. See Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx for more information about MSF Team Model role clusters.
Table 3. Roles and Responsibilities During the Planning Phase
Role |
Focus |
|---|---|
Product Management |
|
Program Management |
|
Development |
|
Test |
|
User Experience |
|
Release Management |
|
Installing Deployment Workbench
The Computer Imaging System feature team uses Deployment Workbench to create distribution shares and develop disk images. The first step in the preparation process is to install Deployment Workbench on the build server, which is the server that holds the source files (scripts, batch files, Windows media, device drivers, and applications) used as part of the scripted build process.
Use a desktop, laptop, or server-class computer as the build server. It may be (but does not have to be) in a domain. The build server can be running Windows Vista, Windows XP, or Windows Server 2003. If the computer is running a server operating system, it can be a stand-alone server, a member server, or a domain controller. The solution cannot be installed and run on an x64 edition of Windows, however.
The Getting Started Guide includes step-by-step instructions for installing BDD 2007, including Deployment Workbench and the Windows AIK. It also describes the folders that BDD 2007 creates in %PROGRAMFILES% and in the distribution share it creates. In contrast to earlier versions of BDD, folders need not be manually shared—Deployment Workbench creates the necessary shares automatically when deployment points are created. “Appendix A: Starting Deployment Workbench,” describes how to start Deployment Workbench and introduces its organization.
Tip Organizations can brand the Deployment Workbench and the Windows Deployment Wizard. For example, they can change the text displayed in the title bar of Deployment Workbench or change any of the text displayed by Windows Deployment Wizard. For more information, see “Appendix H: Branding BDD 2007.”
Adding Operating Systems
All Windows Vista editions are included in a single image file, Install.wim, which is in the Sources folder on the distribution media. For more information about the Windows Vista distribution media and Install.wim, see the Windows Automated Installation Kit User’s Guide. To build images based on Windows Vista, the Computer Imaging System feature team must add the Windows Vista media to the BDD 2007 distribution share. See “Operating Systems” in “Appendix B: Configuring the Distribution Share” in this guide for instructions that describe how to add an operating system to a distribution share.
In addition to adding Windows Vista media to the distribution share, the Computer Imaging System feature team can add Windows Vista images from Windows DS to the distribution share. When the team adds a Windows DS image to the distribution share, BDD 2007 uses the image file from the Windows DS server. There are two requirements for doing this. First, the team must specify an image catalog to use when adding the image from Windows DS, because an image catalog cannot be created from a Windows DS image. Second, the team must copy to C:\Program Files\BDD 2007\bin the following files from the \sources directory on the Windows Vista media(copy from media that matches the platform, x86 or x64, on which BDD 2007 is installed):
Wdsclientapi.dll
Wdscsl.dll
Wdsimage.dll
Note Before adding an image from Windows DS to Deployment Workbench, the Computer Imaging System feature team must add a matching platform image directly to the distribution share. BDD 2007 uses the setup files from the image in Deployment Workbench to install images from Windows DS. For example, before adding an x86 Windows Vista image from Windows DS to Deployment Workbench, add x86 Windows Vista media to the distribution share.
Note When adding images from Windows DS to a BDD 2007 deployment server running an x64 edition of Windows, install update 925404. This update is available through PSS. Windows Server 2003 R2 also includes it.
Note A catalog (.clg) is a binary file that describes the components and settings in a Windows image. Servicing a Windows Vista image requires a catalog. For example, when using Windows SIM to create an answer file for a Windows Vista image, Windows SIM first creates a catalog that describes the image’s contents. Likewise, Deployment Workbench catalogs the images added to the distribution share. For more information about catalog files, see the section “Understanding Windows Image Files and Catalog Files” in the Windows AIK.
Adding Windows XP Professional to the distribution share is similar to adding Windows Vista. Use the same wizard for both. For Windows XP Professional, BDD 2007 still supports the $OEM$ folder structure. If the Computer Imaging System feature team created an operating system–specific $OEM$ folder, the team can use that folder by storing it in the following locations of the distribution share (BDD 2007 searches the folders in the following order):
Control\Build\$OEM$, where Build is the ID of the build with which to associate the $OEM$ folder structure.
Operating Systems\Destination, where Destination is the name of the operating system with which to associate the $OEM$ folder structure.
$OEM$, which is at the root of the distribution share.
If the team is adding Windows XP Tablet PC Edition to the distribution share, copy the entire contents of the CD number 2 Components directory to the Operating Systems\Destination folder of the distribution share, where Destination is the name of the operating system. BDD 2007 detects the deployment of Windows XP Tablet PC Edition based on the product key and automatically copy CD number 2 to the destination computer.
Note The article “Deploying Windows XP Tablet PC Edition 2005” at https://www.microsoft.com/technet/prodtechnol/winxppro/deploy/sitpcdep.mspx describes how to create a single image for deploying Windows XP Professional and Windows XP Tablet PC Edition 2005. The steps that this article describes require customization of the Sysprep folder.
If the Windows XP Professional media does not contain SP2, create a slipstreamed version by integrating SP2 with the media. See “How to integrate Windows XP Service Pack 2 files into the Windows XP installation folder” at https://support.microsoft.com/default.aspx/kb/900871 for more information.
Sysprep
The Windows AIK, which comes with BDD 2007, includes the latest Sysprep tools for Windows Vista. Therefore, the Computer Imaging System feature team does not need to add any other tools to create custom Windows Vista images.
For Windows XP Professional, BDD 2007 copies the correct version of Sysprep from Deploy.cab, which is in the distribution media’s Support\Tools folder. BDD 2007 looks for Deploy.cab in Operating Systems\Destination\Support\Tools, where Destination is the name of the operating system, in the distribution share.
If a custom $OEM$ folder structure associated with the build the team is creating already includes Sysprep, BDD 2007 will use that version of Sysprep instead. For example, copy Factory.exe, Sysprep.exe, and Setupcl.exe to Operating Systems\Destination\$OEM$\$1\Sysprep.
Windows PE
The Windows AIK includes the correct version of Windows PE for deploying Windows Vista and Windows XP Professional by using LTI deployment and creating custom operating system images. Zero Touch Installation (ZTI) deployment requires Windows PE 2005. For more information about loading the correct version of Windows PE for ZTI deployment, see the Zero Touch Installation Guide. The Computer Imaging System feature team does not need to add Windows PE media to create custom operating system images.
Adding Device Drivers
Depending on the type of computers in the environment and the hardware they contain, the Computer Imaging System feature team requires software from the hardware vendors to make the system fully functional. Some of this software is provided on a CD-ROM or DVD-ROM by the hardware manufacturer, but other software must be downloaded from the Internet.
This solution ships with example configurations for Woodgrove National Bank. The files described in the Client Build Requirements job aid need to be downloaded, extracted, and added to the distribution share to ensure that all the hardware models defined for Woodgrove National Bank work correctly. See “Out-of-Box Drivers” in “Appendix B: Configuring the Distribution Share” for instructions that describe how to add device drivers to a distribution share.
For the latest versions of the files required by Woodgrove National Bank, see the manufacturers’ Web sites:
Dell at https://support.dell.com
Toshiba at https://pcsupport.toshiba.com
Motion Computing at https://www.motioncomputing.com/support
Device drivers run as part of the operating system and have unrestricted access to the entire computer. As a result, it’s important to deploy device drivers from known and trusted sources only. In some cases, however, required device drivers might not be signed by the vendor. In those cases, the Computer Imaging System feature team can self-sign device drivers for deployment after verifying the device drivers’ functionality and stability. Self-signing device drivers have additional benefits. First, standard users cannot install device drivers without assistance from an administrator. Self-signing device drivers allows these users to install approved device drivers without requiring assistance while maintaining security at the same time. As well, the user experience is improved, because Windows Vista installs signed, staged device drivers automatically when the user installs the device. For more information about self-signing device drivers, see “Step-by-Step Guide to Device Driver Signing and Staging” at https://www.microsoft.com/technet/WindowsVista/library/ops/4bbbeaa0-f7d6-4816-8a3a-43242d71d536.mspx?mfr=true.
With BDD 2007, team members can group device drivers. When they add a device driver by using Deployment Workbench, they can create groups and associate the device driver with any of those groups. Then, they can associate a device driver group with each build they create in the distribution share. They can also specify device driver groups during deployment, as the Configuration Reference describes.
Note No drivers are required to run Windows Vista in a Microsoft Virtual PC 2007 virtual machine (VM), but installing the latest version of the Microsoft Virtual PC Additions improves performance. The Computer Imaging System feature team can run Windows XP in a Microsoft Virtual PC 2004 VM with no additional device drivers. An updated version of the Additions is included in Virtual PC 2004 SP1 that improves Windows XP SP2 performance.
Adding Updates
When developing an image, take care to ensure that all critical security updates are included in the image so that computers deployed with the image are as up-to-date as possible. Use different approaches to perform these updates (when using BDD 2007, the first method is recommended):
Download the security updates from the Microsoft Web site; then install them as part of the image build process.
Benefits. The process is relatively easy to perform; additional fixes can be added by placing the downloaded updates and adding it to the distribution share.
Drawbacks. The image is vulnerable before the updates are installed and the computer is restarted, providing an opportunity for vulnerabilities to be exploited; the application process can be time-consuming. However, building images in a closed lab environment mitigates this risk.
Use Microsoft Windows Server Update Services (WSUS) or Microsoft Systems Management Server (SMS) 2003 to install the security update post deployment.
Benefits. The process is easy to perform and picks up new updates as soon as they are approved.
Drawbacks. The image is vulnerable before the updates are installed and the computer is restarted, providing an opportunity for vulnerabilities to be exploited; the application process can be time-consuming.
Drawbacks specific to SMS 2003. Depending on the SMS server configuration, it may take an hour or more before all updates are applied; having the SMS 2003 client included in the image and communicating with a specific SMS site may result in all computers built from the image communicating with only that same site.
Download the security updates from the Microsoft Web site, and then integrate them into the Windows installation source before beginning the unattended build process.
Benefits. The image is protected at all times from known security exploits, and the image-build process completes faster because all security updates are installed before building the image.
Drawbacks. Integrating the security updates takes some effort. It may not be obvious which updates can be integrated; some need to be installed as part of the unattended build process.
Download the required Windows security updates from the Microsoft Windows Update Web site at https://v4.windowsupdate.microsoft.com/catalog/en/default.asp. Use this site to query for and download the updates rather than install them. After connection to the Web site, click the Find updates for Microsoft Windows operating systems link. Select the appropriate operating system to update; then, click Search. On the next Web page, select the Critical Updates and Service Packs link from the results list. Add the required updates to the download basket, and then download them to a temporary location.
Windows Vista Updates
Microsoft provides Windows Vista operating system updates as packages. Packages include service packs, security updates, and other operating system changes. Use Deployment Workbench to add updates to the OS Packages item of the distribution share. BDD 2007 will install these packages during deployment. See “Appendix B: Configuring the Distribution Share” for instructions on adding updates to the OS Packages item in the distribution share.
Windows XP Updates
Add Windows XP Professional updates as applications, and then add a task to the task sequence that installs the update. “Appendix B: Configuring the Distribution Share” describes how to add applications to the distribution share. “Appendix D: Editing the Task Sequence” describes how to add application installs to the task sequence. For security updates, create a subgroup called Security Updates in the State Restore group, and add security updates to it. Doing so installs security updates automatically, keeps them organized, and gives control over the installation order. To prevent users from seeing security updates in the applications list during deployment, deselect the Enable this application check box in the Application Properties dialog box, where Application is the name of the update added to the distribution share.
For more information about command-line options available for installing Windows XP Professional SP2 updates, see “The Guide for Installing and Deploying Updates for Microsoft Windows XP Service Pack 2” at https://www.microsoft.com/technet/prodtechnol/winxppro/deploy/hfdeploy.mspx.
Optionally, integrate each update into Windows XP Professional as described by Microsoft Knowledge Base article 828930 at https://support.microsoft.com/kb/828930. All updates released for Windows XP Professional SP2 include the /integrate option described in the article. Most Windows XP Professional core fixes can be integrated, but those to other components (such as Windows Internet Explorer®, Windows Script Host (WSH), Microsoft Windows Messenger, or others) may not. Do not include updates integrated into Windows XP in the task sequence.
Adding Language Packs
Language packs enable a multilingual Windows environment. Windows Vista is language-neutral, and all language and locale resources are added to Windows Vista through language packs (Lp.cab files). By adding one or more language packs to Windows Vista, the Computer Imaging System feature team can enable those languages when installing the operating system. As a result, the Computer Imaging System feature team can deploy the same Windows Vista image to regions with different language and locale settings, reducing development and deployment time.
The following provide additional information about language packs in Windows Vista:
See the section “Running the Windows Deployment Wizard” in the Lite Touch Installation Guide for instructions on installing language packs during deployment.
See the Configuration Reference for the properties to configure for installing language packs automatically.
See “Manage Language Packs for Windows” in the Windows Automated Installation Kit User’s Guide for more information about Windows Vista language packs.
See “Packages” in “Appendix B: Configuring the Distribution Share” to learn how to add language packs to a BDD 2007 distribution share.
If the team is installing Windows XP Multilingual User Interface (MUI) language packs, add each language pack as an application to the distribution share. Then, install the language pack as part of the build’s task sequence, or allow the user to choose a language pack during deployment. “Appendix B: Configuring the Distribution Share” describes how to add applications to the distribution share. “Appendix D: Editing the Task Sequence” describes how to add application installs to the task sequence. For language packs, create a subgroup called Language Packs in the State Restore group, and add language packs to it. Doing so installs language packs automatically, keeps them organized, and provides control over the installation order. To prevent users from seeing language packs in the applications list during deployment, clear the Enable this application check box in the Application Properties dialog box, where Application is the name of the language pack added to the distribution share.
Choosing an Image Strategy
Most organizations share a common goal: Create a corporate-standard desktop configuration that is based on a common image for each operating system version. Organizations want to apply a common image to any computer in any region at any time, and then customize that image quickly to provide services to users.
In reality, most organizations build and maintain many images—sometimes up to 100 images. By making technical and support compromises, making disciplined hardware purchases, and using advanced scripting techniques, some organizations have reduced the number of images they maintain to approximately three or fewer. These organizations tend to have the sophisticated software-distribution infrastructures necessary to deploy applications—often before first use—and keep them updated.
The following list describes costs associated with building, maintaining, and deploying disk images:
Development costs. Development costs include creating a well-engineered image to lower future support costs and improve security and reliability. They also include creating a predictable work environment for maximum productivity but balanced against flexibility. Higher levels of automation lower development cost.
Test costs. Test costs include testing time and labor costs for the standard image and applications that might reside inside it and those applied after deployment. Test costs also include the development time required to stabilize disk images.
Storage costs. Storage costs include storage of the distribution points, disk images, migration data, and backup images. Storage costs can be significant depending on the number of disk images, number of computers in each deployment run, and so on.
Network costs. Network costs include moving disk images to distribution points and to computers. The disk-imaging technologies that Microsoft provides do not support multicasting, and so network costs scale linearly with the number of distribution points that must be replicated and the number of computers in the deployment project.
As the size of image files increases, costs increase. Large images have more updating, testing, distribution, network, and storage costs associate with them. While team members update only a small portion of the image, the Computer Imaging System feature team must distribute the entire file.
Note Windows Vista does not require a separate image for each type of hardware abstraction layer (HAL). However, Windows Vista can be installed only on ACPI-compliant computers.
Thick Image
Thick images are monolithic images that contain core applications, language packs, and other files. Part of the image development process is installing core applications and language packs prior to capturing the disk image. To date, most organizations that use disk imaging to deploy operating systems are building thick images.
The advantage of thick images is simplicity. The organization creates a disk image that contains core applications and language packs and thus performs a single step to deploy the disk image and core applications to the destination computer with language support for all destination locales. Also, thick images can be less costly to develop, as advanced scripting techniques are not often required to build them. In fact, thick images can be built through BDD 2007 with little or no scripting work. Last, in thick images, core applications and language packs are available on first start.
The disadvantages of thick images are maintenance, storage, and network costs. For example, updating a thick image with a new version of an application or language packs requires rebuilding, retesting, and redistributing the image. If the Computer Imaging System feature team chooses to build thick images that include core applications and language packs, they should install them during the disk-imaging process.
Thin Image
A key to reducing image count, size, and cost is compromise. The more the Computer Imaging System feature team puts in an image, the less common and larger that image becomes. Big images are less attractive to deploy over a network, more difficult to update regularly, more difficult to test, and more expensive to store. By compromising on what the team includes in images, the team reduces the number of images maintained and their size—ideally, the Computer Imaging System feature team builds and maintains a single, worldwide image that is customized after deployment.
Thin images contain few if any core applications or language packs. The Computer Imaging System feature team installs applications and language packs separately from the disk image. Installing the applications and language packs separately typically takes more time at the computer and possibly more total bytes transferred over the network, but the transfer is spread out over a longer period of time. The team can mitigate the network transfer time by using trickle-down technology that many software distribution infrastructures provide, such as Background Intelligent Transfer Service (BITS).
Thin images have many advantages. First, they cost less to build, maintain, and test. Second, network and storage costs associate with the disk image are lower, because the image file is physically smaller. The primary disadvantage of thin images is they can be more complex to develop initially; but this drawback is offset by a reduction in the costs of building successive images. Deploying applications and language packs outside the disk image often requires scripting and a software distribution infrastructure. Another disadvantage of thin images is that core applications and language packs are not available on first start—a possible requirement in high-security scenarios.
If the Computer Imaging System feature team chooses to build thin images that do not include applications or language packs, the organization should have a systems management infrastructure, such as SMS 2003, in place to deploy applications and language packs. To use a thin image strategy, the Computer Imaging System feature team will use this infrastructure to deploy applications and language packs after installing the thin image.
Hybrid Image
Hybrid images mix thin and thick image strategies. In a hybrid image, the disk image is configured to install applications and language packs on first run, giving the illusion of a thick image but installing the applications and language packs from a network source. Hybrid images have most of the advantages of thin images. However, they are not as complex to develop and do not require a software distribution infrastructure. They do require longer installation times, however, which can raise initial deployment costs.
An alterative is to build one-off thick images from a thin image. The team begins by building a reference thin image. Then, after the thin image is tested, the team adds core applications and language packs, captures them, tests them, and distributes a thick image based on the thin image. Testing of the thick image is minimized, because the imaging process is essentially the same as a regular deployment. Be wary of applications that are not compatible with the disk-imaging process, however.
If the Computer Imaging System feature team chooses to build hybrid images, it will store applications and language packs on the network but include the commands to install them when the team deploys the disk image. This process is different from installing the applications and language packs in the disk image. The Computer Imaging System feature team is deferring installations that would typically occur during the disk imaging process to the image deployment process. Also, if the organization has a systems management infrastructure in place, the team will likely use it to install supplemental applications and language packs after deployment.
Milestone: Build Lab Created
At this point, the development lab environment has been prepared. (See Table 4.)
Table 4. Deliverables for the Build Lab Created Milestone
Deliverable ID |
Description |
|---|---|
Development Image Server Ready |
The imaging server in the development lab is now ready for building prototype computer images and has been approved by the project manager. |
The primary emphasis of the Development Role Cluster during the Planning Phase has been to configure the lab environment and make it operational, install the imaging system, and collect all needed drivers and media.
Download
Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007
Update Notifications
Sign up to learn about updates and new releases
Feedback