Administration Guide Business Desktop Deployment 2007
Version 2.0 April 5, 2007 Prepared for:
University of Iowa
Prepared by:
Admin Guide
BDD 2007
Document Information
Document Name: File Name: Last Saved: BDD 2007 administration guide UofI BDD 2007 Administration Guide v2.0.doc January 9, 2009
Document Revision History
Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 1.5 2.0 Date 2/13/07 2/15/07 2/19/07 2/21/07 2/22/07 2/27/07 3/12/07 3/14/07 3/15/07 3/20/07 4/4/07 4/5/07 Updated By LRS LRS LRS LRS LRS LRS LRS LRS LRS LRS LRS LRS Description of Changes Initial document creation Document Content Document Content Document Content Document Content Document Content Document Content Document Content Content Finalization Content Revision Content Edit for final delivery Document Finalized for delivery
UofI
Page 2 of 52
Admin Guide
BDD 2007
Table of Contents
1. 2. INTRODUCTION ...............................................................................................................................................5 GETTING STARTED WITH BDD 2007 ..........................................................................................................7 2.1. BDD 2007 SYSTEM REQUIREMENTS ..............................................................................................................7 2.2. INSTALL BDD 2007 ........................................................................................................................................8 2.3. CHECKING FOR BDD 2007 UPDATES ..............................................................................................................9 2.4. BDD 2007 NAMING CONVENTIONS ................................................................................................................9 2.5. BDD 2007 FOLDER STRUCTURE................................................................................................................... 10 2.5.1. BDD 2007 Storage Sizing .................................................................................................................... 11 2.5.2. BDD 2007Access Control .................................................................................................................... 12 3. THE DEPLOYMENT WORKBENCH ........................................................................................................... 14 3.1. OS SOURCE MEDIA ...................................................................................................................................... 14 3.2. APPLICATIONS .............................................................................................................................................. 15 3.3. OS PACKAGES (VISTA) ................................................................................................................................. 17 3.4. DRIVERS ....................................................................................................................................................... 18 3.5. BUILDS ......................................................................................................................................................... 19 3.5.1. Create a build from the OS source media ............................................................................................ 20 3.6. DEPLOYMENT POINTS ................................................................................................................................... 20 3.6.1. Create a Lab Deployment Point .......................................................................................................... 21 3.7. WINPE ......................................................................................................................................................... 21 4. CAPTURING AN IMAGE ............................................................................................................................... 22 4.1. 4.2. 4.3. 4.4. 4.5. 5. CAPTURING A ―REFERENCE‖ IMAGE ............................................................................................................. 24 CAPTURING AN OSD/ZTI ―REFERENCE‖ IMAGE ........................................................................................... 25 UPDATING THE REFERENCE IMAGE .............................................................................................................. 27 IMPORTING AN LTI CAPTURED .WIM ............................................................................................................. 27 IMPORTING AN OSD/ZTI CAPTURED .WIM.................................................................................................... 28
PREPARING TO DEPLOY IMAGES ............................................................................................................ 29 5.1. CREATING A NETWORK DEPLOYMENT POINT ............................................................................................... 29 5.2. CREATING AN OSD/ZTI DEPLOYMENT POINT .............................................................................................. 30 5.2.1. Prerequisite Configuration .................................................................................................................. 30 5.2.2. Create and Configure the OSD/ZTI deployment point ........................................................................ 30 5.2.3. Install the SMS Admin Console and OSD feature pack ....................................................................... 32 5.2.4. Update the SMS OSD WinPE .............................................................................................................. 33 5.2.5. Ensure the SMS client has access to resources .................................................................................... 34 5.3. CONFIGURING SMS OSD FOR ZTI ............................................................................................................... 35 5.3.1. Updating files in BDD and SMS .......................................................................................................... 37
6.
DEPLOYING AN IMAGE ............................................................................................................................... 37 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. LITE TOUCH DEPLOYMENT – NEW COMPUTER ............................................................................................. 39 LITE TOUCH DEPLOYMENT – REFRESH COMPUTER ...................................................................................... 40 LITE TOUCH DEPLOYMENT – REPLACE COMPUTER ...................................................................................... 41 LITE TOUCH DEPLOYMENT – UPGRADE COMPUTER ..................................................................................... 41 ZERO TOUCH DEPLOYMENT – REFRESH COMPUTER..................................................................................... 41 ZERO TOUCH DEPLOYMENT – NEW COMPUTER ........................................................................................... 41 ZERO TOUCH DEPLOYMENT – REPLACE COMPUTER .................................................................................... 41 ALTERNATE DEPLOYMENT METHODS .......................................................................................................... 42
7.
CUSTOMIZING DEPLOYMENT .................................................................................................................. 42 7.1. 7.2. BOOTSTRAP.INI ............................................................................................................................................ 42 CUSTOMSETTINGS.INI................................................................................................................................... 43
UofI
Page 3 of 52
Admin Guide
BDD 2007
7.2.1. Sections ................................................................................................................................................ 43 7.2.2. Properties ............................................................................................................................................ 44 7.2.3. Settings................................................................................................................................................. 45 7.3. CUSTOM SETTINGS DATABASE ..................................................................................................................... 45 7.4. GROUPING COMPUTERS ................................................................................................................................ 47 7.5. TASK SEQUENCER ........................................................................................................................................ 48 8. RELATED TOOLS ........................................................................................................................................... 50 8.1. USMT 3.0 .................................................................................................................................................... 50 8.1.1. Customizing the USMT XML control files ........................................................................................... 50 8.2. WINDOWS SYSTEM IMAGE MANAGER .......................................................................................................... 51 8.3. IMAGEX........................................................................................................................................................ 52
UofI
Page 4 of 52
Admin Guide
BDD 2007
1. Introduction
When planning the effort to deploy Windows Vista, countless scenarios can have a direct impact on the solution. Likewise, there are a number of tools that can be leveraged to deploy Vista. The list of tools includes but is not limited to Windows Deployment Services (WDS), ImageX, WinPE, BDD 2007, SMS OSD, and third-party imaging suites like Ghost. Some of these tools are probably familiar, while some have only been available since the early releases of Vista. BDD 2007 is the focus of this document, BDD 2007 is a combination of WAIK (ImageX, SIM, and USMT), SMS OSD, and the BDD 2007 components, which include Scripts, Configuration files, Configuration database, Environment variables, and Log files. BDD 2007 is a Solution Accelerator created by Microsoft to assist with the deployment of Windows Vista. The solution provides for Lite Touch and Zero Touch deployment methodologies. BDD 2007 is a combination of tools and scripts bundled together to support a variety of desktop deployment scenarios. Properly leveraging these tools allows for imaging the operating system and any core applications that may be considered part of a standard desktop. At the core of BDD 2007 is the Deployment Workbench. This tool is modular and allows for each component of the image to be managed independently. The advantage of leveraging the deployment workbench is that it allows the process to be captured in a maintainable / repeatable way. The deployment workbench allows you to customize the OS, incorporate drivers and updates, customize builds, create WinPE images, and capture OS images. This document will guide you through the initial deployment and configuration of BDD 2007, including: the initial install, the first time in the BDD 2007 deployment workbench, capturing an image and deploying images. Integration into SMS will also be covered when appropriate. The diagram on the following page details the logical flow of the BDD 2007 solution. It begins in the Deployment workbench, where operating systems, applications, OS packages, and drivers are added. From this base of resources Builds and Deployment Points are created. Builds and Deployment Points are used to tailor the way the operating system is deployed and in the case of deployment points, affects the way the end user interacts with the deployment wizard. When using the lab deployment point, an LTI capture deployment can be performed, which essentially allows for a capture of an image. This capture generates a .wim file, which can be imported into the deployment workbench as an operating system, turned into a build, and then leveraged with a deployment point (Network, OSD, or Media). Alternatively, the image could be deployed directly through SMS OSD, ImageX, or WDS. When deployed through BDD, a network, Media, or OSD/ZTI deployment point is used to deliver the OS to the machine. These deployments are either Lite Touch (LTI) or Zero Touch (ZTI). A Lite Touch leverages a BDD deployment along with WinPE media generated by BDD to deploy the OS. On the other hand, ZTI leverages SMS OSD to pull in the necessary files from BDD and then leverages technology available in SMS OSD to deploy the OS as an advertisement.
UofI
Page 5 of 52
Admin Guide
BDD 2007
Operating System
Applications OS Packages Drivers
Build
No
Capture?
Yes
Network Media ZTI Deployment Point
Lab Deployment Point
No
LTI?
Yes
LTI Capture Deployment
ZTI (SMS) Deployment
LTI Deployment No LTI? Yes
OSD Capture
LTI Capture
Windows Setup WinPE Offline Servicing Specialize OOBE
.wim
.wim
OSD (SMS) Deployment
ImageX Deployment
WDS Deployment
Diagram 1: BDD deployment and capture logical flow
UofI
Page 6 of 52
Admin Guide
BDD 2007
2. Getting Started with BDD 2007
Getting started with BDD 2007 will include verifying / installing the prerequisite components, ensuring the necessary Windows infrastructure exists, installing BDD 2007, and understanding the initial configuration. The following section describes the BDD 2007 system requirements. Server software requirements apply to computers on which BDD 2007 will be installed and used. Client software requirements apply to computers on which the deployment scripts will be run to install the Windows operating system.
2.1. BDD 2007 System Requirements
Supported Operating Systems: Windows Server 2003; Windows Vista; Windows XP; Windows XP 64bit; Windows XP Service Pack 1; Windows XP Service Pack 2 Note: The following prerequisites, the BDD 2007 tool itself, and the additional components can be found on the following share: \\iowa.uiowa.edu\shared\NTAdmin\Vista\Deployment Tools alternatively the direct link to the respective Microsoft downloads are provided below. Business Desktop Deployment 2007 (BDD 2007) Solution Accelerator o http://www.microsoft.com/downloads/details.aspx?FamilyID=13f05be2-fd0e-4620-8ca61aad6fc54741&DisplayLang=en
BDD 2007 Prerequisites o Windows Installer 3.1 o http://www.microsoft.com/downloads/details.aspx?FamilyID=889482fc-5f564a38-b838-de776fd4138c&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-43624b0d-8edd-aab15c5e04f5&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=95e24c87-873248d5-8689-ab826e7b8fdf&DisplayLang=en
Microsoft .NET Framework 2.0
o
Microsoft Word or a Word reader (required to view the documentation)
o
MMC 3.0 is required to run the Workbench and view the documentation on Windows Server 2003 and Windows XP. Note: MMC 3.0 is included in Microsoft Windows Server 2003 R2 and in Windows Vista. http://www.microsoft.com/downloads/info.aspx?na=22&p=1&SrcDisplayLang= en&SrcCategoryId=&SrcFamilyId=&u=%2fdownloads%2fdetails.aspx%3fFamil yID%3d4c84f80b-908d-4b5d-8aa8-27b962566d9f%26DisplayLang%3den http://www.microsoft.com/downloads/details.aspx?FamilyID=c717d943-7e4b4622-86eb-95a22b832caa&DisplayLang=en
o
Windows Script Host (WSH) 5.6
The tools portion of BDD relies on several Windows Vista deployment tools. After installation of the BDD.msi and start-up of the BDD Workbench, the Workbench will enable the user to choose to automatically download and install the following additional components:
UofI
Page 7 of 52
Admin Guide
BDD 2007
o
Windows Automated Installation Kit http://www.microsoft.com/downloads/details.aspx?FamilyID=c7d4bc6d-15f34284-9123-679830d629f2&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b58147b0-b45e-492dd6da2971&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=799ab28c-691b4b36-b7ad-6c604be4c595&DisplayLang=en http://www.microsoft.com/downloads/details.aspx?FamilyID=993c0bcf-3bcf4009-be21-27e85e1857b1&DisplayLang=en
o
Application Compatibility Toolkit 5.0
o
User State Migration Tool 3.0
o
MSXML 6.0
Infrastructure Requirements include: Active Directory DHCP DNS (recommended) WDS (recommended) SMS 2003 with SP2 (for ZTI / OSD)
Supported Clients (for deployment) include: Vista Business Vista Enterprise Vista Ultimate Windows XP Professional Windows XP Tablet PC Edition
2.2. Install BDD 2007
This section of the document details the steps necessary to install BDD 2007. In this scenario, BDD 2007 is being installed on a Windows Server 2003 member server. The reason a server OS is assumed is because having a robust system that is fault tolerant and has the space necessary to support the data generated by the deployment process is important. The following assumes that BDD 2007 is being installed on Windows Server 2003 with SP1; however, BDD 2007 can be installed on any of the supported operating systems listed above. The first step is to install the prerequisites required by the BDD 2007 tool, then BDD 2007 itself can be installed, finally the additional tools/components required by BDD 2007 can be installed. Note: The prerequisites, the BDD 2007 tool, and the additional components can be installed from the share \\iowa.uiowa.edu\shared\NTAdmin\Vista\Deployment Tools, from the direct download link above, or from within the deployment workbench itself (additional components only).
UofI
Page 8 of 52
Admin Guide
BDD 2007
1. Install the prerequisites with the installation defaults a. Install .NET Framework 2.0 b. Install MMC 3.0 c. Install MSXML 6.0 2. Install BDD 2007 with the installation defaults 3. Install the additional components with the installation defaults a. Install the Windows Automated Installation Kit (WAIK) b. Install USMT 3.0 (User State Migration Tool) Note: A bug exists in which BDD 2007 is unable to install the Microsoft Windows User State Migration Tool (USMT) 3.0 on computers silently during deployment. Until this issue is resolved in USMT 3.0, perform the following steps for the x86 version of USMT 3.0 to repackage the files into a cabinet file from which BDD 2007 can extract USMT 3.0. i. Copy C:\program files\BDD 2007\samples\USMT30_x86.ddf to C:\ ii. From the command prompt, change directory to C:\ and run makecab.exe /F USMT30_x86.ddf. iii. Copy the usmt30_x86.cab file to Distribution$\Scripts or Distribution$\Tools\x86 Note: The deployment tools scan the tools folder and the scripts folder during a deployment, a good practice is to use the scripts folder since it is always scanned. Note: This cab file includes files necessary to run USMT as well as the XM L control files. These control files can later be edited to customize the USMT functionality; the cab file can then be recreated and redeployed. This process is expanded on in the USMT section later in this document.
2.3. Checking for BDD 2007 Updates
The components leveraged by the BDD 2007 tool can be updated by Microsoft, because of this fact; Microsoft provides a built-in way to check for updated components from within the deployment workbench. The following steps detail this process. In the Deployment Workbench, under Information Center, click Components – In the Actions pane, click Check for Updates When the wizard starts, select check the internet for updates If there are updated or additional applications available, the components list will reflect any changes
2.4. BDD 2007 Naming Conventions
In the Deployment Workbench, most of the resources (Operating Systems, Applications, OS Packages, Drivers, Builds, and Deployment points) you will be working with will require a name. In some cases the name or ID assigned to the resource cannot be changed, for example Build ID, once it is designated. This table outlines the naming conventions that could be used in the BDD 2007 environment.
UofI
Page 9 of 52
Admin Guide Object Type Operating Systems Naming Convention OS: 1 - 2 chars Edition: 1 – 3 chars Description: 3 chars Type: 2 - 4 chars Version: 2 chars Publisher Name Version N/A – populated on import Name is editable, but will be populated on import Group Description Examples VEAPPLTIv1.wim VECUSOSDv1.wim VEOSOLTIv1.wim VEOSOOSDv1.wim Microsoft Office 2007 Adobe Reader 8.0 Symantec Antivirus 10.2 ITS SMS Prestage N/A N/A All Drivers GX620 GX270 Dell HP VEOSO VECOR VECORCUS Department OS Configuration Migdata Compback Miglogs Table 1: BDD naming conventions
BDD 2007
Applications
OS Packages Drivers Driver Groups
Builds (ID/Name)
OS Name:2 - 4 chars Description: 2 - 4 chars Type: 2 - 4 chars Purpose Purpose
Deployment Points Folders/Shares
2.5. BDD 2007 Folder Structure
By default on the machine where BDD 2007 is installed, in addition to the files placed in the C:\Program Files\BDD 2007 folder, a default folder structure is created. This default folder structure is nested under a hidden share ―Distribution$‖ (this folder does not become a hidden share until the Lab deployment point is created). This default share has the following structure, most of which can be mapped back to the deployment workbench GUI: Distribution$ o o $OEM$ – used to store files and folders to be copied to the destination computer to be used by setup, support for Windows XP Professional, and to add additional drivers Applications – when importing an application with source files, the source files will be copied to this location.
UofI
Page 10 of 52
Admin Guide
BDD 2007
o o o
Boot – contains the Lite Touch WinPE .iso and .wim that support the lab deployment point Captures – a place to store captured images (WIM files) Control – At the root are the control files for the lab deployment point and the applications, builds, drivers, and packages metadata xml files. This folder also contains subfolders for each build and for each deployment point, the control files for each respective build (TS.xml and Unattend.xml) and deployment point (Bootstrap.ini and CustomSettings.ini) are maintained in these folders Operating Systems – when importing an operating system from source media, a captured image (WIM file), or WDS, the files will be copied to this location. Out-of-Box Drivers – when importing drivers, the needed files will be copied to this location Packages – when adding Vista security updates, service packs, and language packs, the needed files will be copied to this location. Scripts – Contains the scripts (LTIxxxx.vbs, ZTIxxxx.vbs) used throughout the deployment process. Tools – Contains the tools (BDDRun, bootsect, imagex) used throughout the deployment process.
o o o o o
In addition to this default folder structure, some folders will need to be created to host the network deployment points used for deploying images and to support user state migration data, computer backup data, and log file data. Two primary concerns in creating these additional shares are how to allow for proper storage sizing and how to allow appropriate access control. The following describes a sample folder structure: Deployment o o o o o o MigData CompBack Logs DeployPoint1 DeployPoint2 DeployPoint3
Note: ITS will provide space on a member server that departments will be able to use to host their Data and Deployment Points.
2.5.1.
BDD 2007 Storage Sizing
In Regards to USMT Data planning, the following methods can be used to estimate storage requirements: Run Scanstate.exe (USMT) with the /p command option to estimate the size of the user state migration data. The /p command option estimates the disk space requirements without actually performing the migration. View the size of the contents of the folders in the user profile. Randomly sample targeted computers to determine an average amount of storage required to back up the user state
UofI
Page 11 of 52
Admin Guide
BDD 2007
migration. Note: there may be several profiles (user name folders) on each target computer, so include each profile to be migrated. Another factor is how long the user state migration data must be stored. At a minimum, store the user state migration data until the deployment has been verified to be successful. This way in the event that the deployment fails it is possible to roll back the configuration. After successful deployment and verification of data availability, the USMT data can be deleted. Calculate the storage requirements for user state migration data by multiplying the size of the user migration state by the number of simultaneous computers being upgraded (size of migration × number of simultaneous computers). As for computer backup data, an optional step in the deployment process for the Refresh Computer and Upgrade Computer scenarios is to perform a backup of the target computer before deploying the target operating system. The purpose of this backup is for recovery of user state migration data. A computer backup can be captured to either: Local drives on the target computer Network shared folders
The backup process in BDD 2007 leverages the Imagex.exe tool. The backup process creates an image of the disk volume where the user state migration data is stored. For planning purposes, you can estimate the computer backup storage requirements for a single computer by performing the following steps: Run the Refresh Computer and Upgrade Computer scenario processes in the test lab to determine the size of the backup file. Determine how long the backup file needs to be persisted.
Calculate the storage requirements for computer backup by multiplying the size of the backup file for one computer times the number of computers being deployed simultaneously by using the Refresh Computer and Upgrade Computer scenarios.
2.5.2.
BDD 2007Access Control
In addition to the shared folders created for USMT data, computer backup data, and log data, the BDD 2007 scripts that run during deployment may require access to other resources. These resources include BDD 2007 deployment point shares, application shares, and database servers. Access is granted to these shares and other resources for the credentials specified in the: UserID, UserPassword, and UserDomain properties (in CustomSettings.ini) Windows Deployment Wizard (During an LTI deployment)
Grant access to the following resources: BDD 2007 deployment points. Configure access to the deployment point created in Deployment Workbench. Any resources accessed by using the ZTIConnect.wsf script. Configure access to resources that are referenced by using the ZTIConnect.wsf script. Any resources on application or database servers. Configure access to applications or databases that are accessed through the SQLServer, SQLShare, and Database properties.
UofI
Page 12 of 52
Admin Guide
BDD 2007
Note: Other connections to the same servers, such as Named Pipes and Remote Procedure Call (RPC), use the same credentials listed above. Use the ZTIConnect.wsf script to establish these connections. Once the appropriate storage space has been allocated and the additional shares created, access to these shares should be secured. The primary goal is to ensure that unauthorized users are unable to access information gathered through the deployment process. Only the target computer creating this information should have access to these folders. The permissions set in these steps allow a target computer to connect to the appropriate share and create a new folder in which to store user state information or logs, respectively. The folder permissions prevent other users or computers from accessing the data stored in the folder. 1. Start Windows Explorer, and navigate to SharedFolder. 2. Right-click SharedFolder (where SharedFolder is one of the shared folders listed in Table 21), and then click Properties. 3. On the Security tab, click Advanced. 4. On the Permissions tab, clear the Allow inheritable permissions from the parent to propagate to this object and all child objects check box. 5. When the Remove when prompted to either Copy or Remove the permission entries that were previously applied from the parent message box appears, click Remove. 6. On the Permissions tab, click Add. 7. In the Enter the object name to select text box, type Domain Computers, and then click OK. 8. This action allows domain computers to create subfolders. 9. On the Permission Entry for SharedFolder dialog box, in the Apply onto list, select This folder only 10. On the Permission Entry for SharedFolder dialog box, in the Permissions list, select Allow for the Create Folders/Append Data permission, and then click OK. Repeat steps 6–9, substituting Domain Users for Domain Computers. 11. On the Permissions tab, click Add. 12. In the Enter the object name to select text box, type CREATOR OWNER, and then click OK. 13. This action allows domain computers and domain users to access the subfolders they create. 14. On the Permission Entry for SharedFolder dialog box, in the Apply onto list, select Subfolders and files only. 15. On the Permission Entry for SharedFolder dialog box, in the Permissions list, select Allow for the Full Control permission, and then click Repeat steps 11–15 for each group that will receive access.
UofI
Page 13 of 52
Admin Guide
BDD 2007
3. The Deployment Workbench
The deployment workbench is an MMC 3.0 based interface that allows a technician to work with images and the resources associated with them. Some of the primary tasks in the Deployment Workbench include adding operating systems, applications, drivers, and OS update packages to be leveraged during the capture and deployment of OS images. The first time in the deployment workbench, the technician will need to perform the following tasks. Some of these steps will be covered in detail later in this section. For the time being, it is important to understand that before moving into any type of production deployment, a lab deployment point must be created to facilitate the creation and capture of ―reference‖ images. These reference images can then be leveraged with a network or OSD/ZTI deployment type. 1. Import operating system source media 2. Create a build from the OS source media 3. Create a Lab deployment point – this step is critical to all deployment methods (LTI, ZTI, OSD) 4. Use the Lab deployment point to capture a ―reference‖ or ―master‖ image 5. Import the captured image 6. Create a build from the captured image 7. Create a deployment point (Network, OSD/ZTI) for production deployment When the deployment team adds operating systems, applications, operating system packages, and out-ofbox device drivers to the distribution share, the team is storing the source files in the distribution share folder specified during BDD 2007 installation. The default is D:\Distribution, where D is the volume with the most available space. The team associates these stored items with builds later in the configuration process. In the distribution share’s Control folder, Deployment Workbench stores metadata about operating systems, applications, operating system packages, and out-of-box device drivers in the following files:
Applications.xml – Contains metadata about applications in the distribution share Drivers.xml – Contains metadata about device drivers in the distribution share OperatingSystems.xml – Contains metadata about operating systems in the distribution share Packages.xml – Contains metadata about operating system packages in the distribution share
3.1. OS Source Media
One of the first steps to be completed when working in the deployment workbench will be to import the OS source media. This process is taking the Vista (DVD) or XP (CD) and copying those source files from the optical media to the BDD 2007 distribution share. One thing to note is that all Windows Vista editions are included in a single image file, Install.wim, which is in the Sources folder on the distribution media. The exception to this is Vista Enterprise, when importing from a Vista Enterprise DVD, only the Vista Enterprise Edition will be imported. Although this is a basic step, it is essential. In order to build images based on Windows Vista, the Windows Vista media must be added to the BDD 2007 distribution share. One piece of data that is made available by importing the Vista source media is a catalog. 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
UofI
Page 14 of 52
Admin Guide
BDD 2007
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. Note: When an operating system is deleted from Deployment Workbench, it is also removed from the Operating Systems folder in the distribution share. In other words, removing an operating system from Deployment Workbench also removes it from the file system. Perform the following steps to import the Vista source media into the deployment workbench On the technician machine, insert a Vista DVD or capture a Vista .iso In the Deployment Workbench, expand the Distribution node, right-click on the Operating Systems node, and select New (or click New from the Actions pane) In the New Os Wizard: o o o Full set of source files Source directory: :\ or :\ Destination directory name: Windows Vista ―Edition Name‖ Source
These same steps would be used to import the Windows XP source media.
3.2. Applications
The primary reason for importing applications is to include those core applications that are common to most computers in the organization as a part of the ―default‖ build. Those applications that are not considered core applications will typically be deployed through some other means such as SMS application deployment. How applications are deployed to the desktop depends on a number of factures, including: what applications infrastructure is in place, what applications are considered core applications, and which imaging strategy has been selected. The three imaging strategies detailed by Microsoft are explained in the following: Thick image – Install applications to the build being used to create disk images. Team members can install applications by using the Windows Deployment Wizard, or they can add applications to the task sequence. Thin image – Application deployment likely occurs outside of operating system deployment, probably using a systems-management infrastructure such as SMS 2003. Hybrid image – Some applications are installed to the build being used to create reference images, in addition some applications are possibly installed using a tool like SMS.
When adding an application to the distribution share, the deployment workbench can install the application from its original network location, or it can copy the application source files to the distribution share. In either case, the commands for installing the application in silent mode and to suppress rebooting must be included. It is also important to ensure that each application has a unique name otherwise; users will see multiple applications with the same name, each of which installs a different application (during a Lite Touch installation). Important: Do not allow an application to restart the computer. BDD 2007 must control restarts or the task sequence will fail. Use the command-line property REBOOT=REALLYSUPPRESS to prevent some Windows Installer–based applications from restarting. To cause BDD 2007 to restart the computer after installing an application, select the Reboot the computer after installing this application check box in the Application Properties dialog box of Deployment Workbench.
UofI
Page 15 of 52
Admin Guide
BDD 2007
Note: When an application is deleted from Deployment Workbench, it is also removed from the Applications folder in the distribution share. In other words, removing an application from Deployment Workbench also removes it from the file system. Once an application has been added to the distribution share, it can be installed in one of two ways: During the task sequence – Application installations added to the task sequence—the sequence of tasks that occur during installation to prepare, install, and configure the build on the destination computer—occur when BDD 2007 executes the task sequence on the destination computer. If an application will be installed as a part of the task sequence, the applications should be disabled by clearing the Enable this application check box. During Deployment – During the interview, the Windows Deployment Wizard prompts the installer with a list of applications that are available for installation. The installer can then choose which applications to install (if that screen has not been hidden). Typically, applications added to the deployment workbench would be installed as a part of the deployment wizard when the technician is creating reference images.
Although core applications are typically included in the deployment to automate the installation, if the application does not support silent installation, it is possible to insert configuration that would cause the process to pause and therefore allow the technician to manually install applications and make additional manual configurations. Two basic methods can be used to achieve this: Task Sequencer – Simple reminders of where certain applications should be installed can be inserted into the task sequence. When the system reaches this part of the build, it stops; the technician can manually install the application, respond to the prompt, and then allow the system to continue processing. Notepad – Add a new item as an application but the application "install" is actually just having notepad open a text file. In the file, list out the procedures to complete any manual customizations, then when the technician has finished and closes notepad, the system continues processing and finishes the capture. The following command and working environment can be used to setup notepad as a ―application‖:
Command: Working Directory: c:\windows\notepad.exe tasklist.txt .\Applications\ManualTasks
Note: Applications are processed or deployed in the order that they appear (top to bottom) in the Deployment Workbench, which is in turn represented in the applications.xml file. When adding applications like the Notepad customization, it is important to have this application run last. This can be achieved by leveraging the dependencies tab on the application properties, by editing the applications.xml file found in ―C:\Distribution\Control‖ or by removing the application and adding it back into the Deployment workbench so that it is placed at the bottom of the list. Use the following steps to import applications into the deployment workbench. In the Deployment Workbench, expand the Distribution node, right-click on the Applications node, and select New (or Click New from the Actions pane) In the New Application Wizard: o o o Application with source files (i.e. local source) or Application without source files on the network (i.e. SMS package source location) Publisher: Application name:
UofI
Page 16 of 52
Admin Guide
BDD 2007
o o o o o o o
Version: Language: English Platform: x86 platform ONLY! Source Directory: Specify the name of the directory that should be created: Pub App Version Command Line: application.exe /q /c:‖msiexec /I application.msi /qn‖ Working directory: .\Applications\Publisher App Name Version\
Note: Test your command line options and working directories from the command line before including the applications in a deployment.
3.3. OS Packages (Vista)
A part of maintaining a reference image is including the most recent updates available. This effort serves to increase the security of the image at deployment time and to reduce the resources required to patch new deployments. OS packages for Vista (updates, service packs, and language packs) can be added to the deployment workbench using the new package wizard in the OS packages node. Like applications, there are a number of different ways updates can be deployed. The recommended practice is to include updates in the image so that computers deployed with the image are as up-to-date as possible. The following details the different options available for deploying updates: Download the security updates from the Microsoft Web site; then install them as part of the image build process. This process is relatively easy to perform, additional updates are added to the distribution share and deployed as a part of the image Use Microsoft Windows Server Update Services (WSUS) or Microsoft Systems Management Server (SMS) 2003 to install the security update post deployment. Again, this process is relatively easy to perform, however the image is vulnerable until the software update tool identifies and patches the system. Download the security updates from the Microsoft Web site, and then integrate them into the Windows installation source before beginning the unattended build process. This process would likely take the most effort and may require testing to determine which updates can be deployed in this manner, however this would be the most secure method of deployment
With past efforts of deploying the Windows desktop operating system, the question had been raised if the ―reference‖ image should be continuously updated or if new deployments could be patched after the fact. Vista addresses this question by introducing the ability to patch an image offline. BDD 2007 can leverage Vista’s ability to be patched offline and can patch a Vista install immediately after an image is deployed and still in the Windows PE phase of deployment. This way a reference image does not need to be updated only to add operating system updates. Due to the way the ―ztipatches.wsf‖ script functions by default, the following line of code must be commented out in the script (which can be found in Distribution\Scripts): ―fLangCanContinue = FALSE‖ Eventually the process of integrating updates into an image should include leveraging the Microsoft update catalog to download all relevant updates. However, at the time of this writing, this site is
UofI
Page 17 of 52
Admin Guide
BDD 2007
unavailable. The site is scheduled to be available in April 2007, once it is available, technicians will be able to perform the following tasks. Download the required Windows security updates from the Microsoft Windows Update Web site at http://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. Once downloaded, the OS packages can be added to the deployment workbench.
Until the downloads are available through the Windows Update catalog, the updates can be obtained by deploying a new Vista OS, letting the updates download and install, and then reviewing the update history and using the details provided there to download the respective .msu file. Once the updates are downloaded, you will need to extract the .cab from the .msu. However, the new MSU format does not support the old /x type switches to extract the content. It also cannot be run on a pre-Vista OS. To extract the content from an MSU file, you need to use the Expand command that is part of Vista. Note that the Expand command from earlier versions of Windows is different and will not work. Use the following command: ―expand PatchName.msu /f:*.cab c:\temp\‖ Note: ITS will maintain a Vista Update Cabs folder that will contain the most recent versions of the expanded .cab OS update files used by the BDD 2007 tool. (\\iowa.uiowa.edu\shared\NTAdmin\Vista\Deployment Tools\Vista Update Cabs) Perform the following steps to import OS packages Download updates and perform the steps to extract the .cab o http://test.catalog.update.microsoft.com/v7/site/Home.aspx
In the Deployment Workbench, expand the Distribution node, right-click OS packages and click New (or click New from the Actions pane) Browse to the expanded .cab Click Add
3.4. Drivers
Depending on the type of computers in the environment and the hardware they contain, the desktop deployment team may require software from the hardware vendors to make the system fully functional. Some of this software may be provided on a CD-ROM or DVD-ROM by the hardware manufacturer, but other software may need to be downloaded from the Internet. For the latest versions of the files required by different PC vendors, see the manufacturers’ web sites: Dell at http://support.dell.com HP at http://www.hp.com/support IBM at http://www.ibm.com/pc/support
UofI
Page 18 of 52
Admin Guide
BDD 2007
Toshiba at http://pcsupport.toshiba.com
With BDD 2007, the deployment team can group device drivers. When a device driver is added by using Deployment Workbench, groups can be created and the device driver can then be associated with any of those groups. A driver group is a logical grouping of one or more drivers defined in the Out-of-Box Drivers node in Deployment Workbench. Device driver groups can then be associated with each build created in the distribution share. A build will only include those device driver groups that have been associated in the deployment workbench. Device driver groups can also be exposed to the user during the deployment interview. Note: When a device driver is deleted from Deployment Workbench, it is also removed from the Out-ofBox Drivers folder in the distribution share. In other words, removing a device driver from Deployment Workbench also removes it from the file system. Note: ITS will maintain an updated driver share. \\itsnt129.iowa.uiowa.edu\Drivers Perform the following steps to import device drivers. Locate or download drivers In the Deployment Workbench, expand the Distribution node, right-click on the Out-of-Box Drivers node, and select New (or click New from the Actions pane) Add the drivers in D:\Setup\Drivers to the repository Browse to the driver source directory Click Add
3.5. Builds
After defining and populating the distribution folders as necessary with Vista and application source files, you use the Builds node of the BDD Workbench to define the details of the installation of specific builds. A build can be defined as a collection of details about a specific installation of Windows Vista, including the particular version or SKU of Windows Vista as well as specific commands and actions to customize the deployment for a specific purpose. You can have one master build or many builds as needed to support the specific needs of the organization. Essentially, a build binds operating system source files with a configuration. Builds include: Operating system – An operating system or custom image to use for the build Unattended setup answer file (Unattend.xml) – An answer file that describes how to install and configure the operating system on the destination computer. For example, the answer file can contain a product key, organization name, and information necessary to join the computer to a domain Task sequence (TS.xml) – Each build has a default task sequence. This sequence can be optionally customized
At a minimum, one build will typically be created for each operating system added to the deployment workbench. Creating a build provides a way to control the installation through the ability to edit the build’s unattend.xml file; in addition, the build provides a way to control the deployment process as a whole through the ability to edit the task sequence (ts.xml). With this understanding, it should start to become clear how a build provides a way to tailor an OS for a specific deployment. For example the unattend.xml file can be edited to add registry keys, tweak the UI, turn features on or off, and so on.
UofI
Page 19 of 52
Admin Guide
BDD 2007
Likewise, custom actions can be added to the task sequence to partition a drive, install an application, or perform other tasks. Note: While a build’s name and comments can be changed later, a build’s ID cannot. Before creating builds, create a naming scheme for use in creating build IDs that will provide meaningful information about each build. Volume license customers, such as the University of Iowa, deploying Windows Vista to 25 computers or more should select the ―Do not use a product key when installing‖ option. Customers deploying Windows XP Professional or using Windows Vista Multiple Activation Keys (MAKs) should select the ―Use the specified product key‖ option, and then type a product key in the Product Key box.
3.5.1.
Create a build from the OS source media
In the Deployment Workbench, right-click on the Builds node, and select New (or click New from the Actions pane) In the New Build Wizard: o o o o o o o o o Build ID: Build name: Build comment: Operating System Image: ProductKey: FullName: Organization: Internet Explorer home page: Administrator Password and confirm Password:
Perform the following steps to create a build from OS source media.
3.6. Deployment Points
In BDD 2007, a deployment point is essentially a share that contains the resources (operating systems, builds, drivers, OS packages, applications) used during an operating system deployment. The first deployment point created in the Deployment Workbench is the ―Lab‖ deployment point. This deployment point is unique in that there is only one and that it references all of the resources in the distribution share. Until the Lab deployment point is created, the Distribution folder BDD 2007 installs the initial resources into is not a share. The process of creating the Lab deployment point shares the folder. The other deployment point types are described in the following bullet points. BDD 2007 supports four types of deployment points: Lab – This is a basic, single-server deployment point. This deployment point references all the content in the distribution share. When building custom ―reference‖ or ―master‖ images for use with Network, Media, and OSD deployment points the deployment team will use a lab deployment point. Network – This is a subset of the distribution share that can be replicated to many servers based on the organization’s requirements. Multiple network deployment points can be created as
UofI
Page 20 of 52
Admin Guide
BDD 2007
needed. The team can choose the builds, images, device drivers, updates, and applications that are associated with a given network deployment point. Media – This is a subset of the distribution share that can be put on a DVD, Universal Serial Bus (USB) flash disk, etc… to perform stand-alone, potentially network-disconnected deployments. The media created using this method can contain applications as well as the Vista install media, and provides great flexibility when installing from physical media. OSD – This is a copy of all the scripts, tools, and other files necessary to properly configure custom actions in the Microsoft SMS Operating System Deployment (OSD) Feature Pack for performing a ZTI deployment. The images, applications, and device drivers are part of this replica. OSD deployment points can only be used to deploy images created by the SMS 2003 Image Capture Wizard CD.
3.6.1.
Create a Lab Deployment Point
In the Deployment Workbench, right-click on the Deployment Points node, and select New or click New from the Actions pane In the New Deployment Point Wizard: o o o o o o o o Lab or single-server deployment (default) Deployment point name: LAB Allow user to select additional application on Upgrade (default) Ask if an image should be captured (default) Do Not Allow the user to set Administrator Password (Default) Do Not Allow user for specifying product key (default) Share name: Distribution$ (default) Do not capture user state data
Perform the following steps to create a Lab Deployment Point.
In the Deployment Workbench, right-click the LAB Deployment Point and select Properties On the Rules tab o o Verify CustomSettings.ini Verify BootStrap.ini
In the Deployment Workbench, right-click the LAB Deployment Point and select Update Note: The update process will take at least 5 - 10 minutes.
3.7. WinPE
Windows Pre-Installation Environment (Windows PE) is a minimal operating system designed to prepare a computer for Windows installation. It can be used to start a computer with no operating system, to partition and format hard drives, and to copy disk images or initiate Windows Setup from a network share. Windows PE 2.0 is the latest release based on the Microsoft Windows Vista operating system.
UofI
Page 21 of 52
Admin Guide
BDD 2007
The Deployment Workbench creates Windows PE boot images that it configures to connect to the deploy point and install a specified build. These WinPE images are used during deployment for new computer scenarios and to build reference images. For each deployment point, the deployment team can create .wim and .iso Windows PE image files that automatically connect to the deployment point and begin the installation. During the process, BDD 2007 allows the user to choose which build to install from the deployment point. BDD 2007 requires the Windows AIK, which in turn comes with Windows PE. No additional files are necessary to create Windows PE images for BDD 2007. Deployment Workbench automatically customizes Windows PE .wim files when a deployment point is updated (through a full update). Optionally, the deployment point can be configured to generate the following Windows PE images: LTI flat bootable ISO image LTI bootable RAM disk ISO image Generic flat bootable ISO image Generic bootable RAM disk ISO image
When a deployment point is updated, Deployment Workbench generates the Windows PE .wim image and other optional ISO images. It stores these images in the distribution share’s Boot folder for the lab deployment point and in the deployment point’s boot folder for other deployment points. Windows PE does not need to be manually customized to add network interface card (NIC) device drivers to it. The Deployment Workbench automatically adds NIC device drivers to the Windows PE images that are added to the distribution share. Optionally, video and system device drivers can be added from the distribution share to the Windows PE images. After the deployment team has updated the deployment point and generated Windows PE images, the Windows PE ISO images can be burned to CDs or DVDs by using most commercial CD-burning software. Optionally, the.wim image file can be added to Windows DS. Note: The same platform edition (x86 or x64) of Windows PE must be used to start computers for installing each platform edition of Windows. In other words, the deployment team must start destination computers using the x86 edition of Windows PE to install the x86 edition of Windows Vista. Likewise, the team must use the x64 edition of Windows PE to install the x64 edition of Windows Vista. If mismatched editions are used, team members might see an error indicating that the image is for a different type of computer.
4. Capturing an Image
The process of capturing an image is essentially a Lite Touch type deployment from the ―Lab‖ deployment point that ends with the Windows Deployment Wizard capturing an image of the destination computer. When creating a Lab deployment point, the Deployment Workbench provides the option of prompting to capture an image, be sure to select this option. When the Lab deployment point is used to install a build on a destination computer, once the deployment wizard interview is complete, the deployment wizard will: deploy the OS with the options specified during the interview, sysprep the machine, and capture the image to a .wim file. Capturing an image for deployment using OSD/ZTI is similar to capturing an image for deployment using LTI. However, the SMS 2003 Image Capture Wizard CD is used to capture the image instead of allowing Windows Deployment Wizard to capture the image. Like the LTI capture, the lab deployment point is used to create a ZTI/OSD capture, the deployment wizard interview is completed. The deployment wizard
UofI
Page 22 of 52
Admin Guide
BDD 2007
then: deploys the OS with the options specified in the interview, copies files need to prepare the image for sysprep, and then stops at a logged in administrator desktop. At this point, the SMS Image Capture CD is used to run the image capture wizard. The image capture wizard runs sysprep on the machine and will then shutdown the machine. The next step is to boot from the SMS Image Capture CD, which will boot into WinPE and capture the image to a .wim. Note: Disable antivirus programs on the lab computer before capturing an image of the lab computer’s disk. Antivirus programs can interfere with the configuration of the image and installation of applications during deployment. After deployment, enable the antivirus program. Test the interaction of antivirus programs with BDD 2007. In reality, anytime you are creating or possibly updating a reference image. So, let us start by defining what a reference image is. A reference image is the base image that contains the configuration, applications, updates, and drivers that are relevant to a majority if not all of the desktops in the organization. Depending on things like image strategy, core application base, technology available, and general standardization, the ability to create a single reference machine may be limited; however, it is always a goal. In operating systems prior to Windows Vista, there was a dependency on the machines HAL that required multiple ―reference‖ images to be maintained. Vista has eliminated this dependency and will likely only require multiple reference images when the environment it is being deployed into dictates this course. The process of capturing a reference image includes the configuration to customize the image according to standards, policies, and desired look / feel. There are really three primary ways the desktop can be configured before being captured as a ―reference‖ image, the following details these three methods: Scripts – Scripts can be written to configure the machine either through registry modification, built in functions and calls or other means. Once these scripts are developed, they can be added to the deployment workbench as applications (applications that should only be available to the Lab deployment point). These applications would then be available during the deployment wizard interview and could function as a reusable checklist for ensuring the reference machine is configured as expected. Unattend.xml – The unattend.xml is the Vista answer file. This file can be edited as a flat file with a tool like notepad, or it can be modified using the Windows System Image Manager (SIM) tool. The SIM tool allows the technician to link the file to a valid Vista catalog, which provides a list of the components that can be added to the file. Once the file is modified, it can be verified and saved through the tool. The unattend.xml file offers many options to configure the machine, however there may be some configuration that can only be tweaked through a script or manual intervention. Manual configuration – Manual configuration means interacting with the machine and configuring settings manually through the desktop GUI. When performing a ZTI/OSD capture, there is a default pause in the process before the image capture CD is run, this pause would allow a technician to configure the desktop as necessary and then capture the image. In order to perform this manual configuration as a part of the LTI capture, the process must be paused either by using the task sequencer or the notepad solution detailed earlier in this document. Editing the “default” profile – Editing the ―default‖ profile is slightly different for LTI and ZTI and cannot be done at all for an OSD only deployment (because there is no post-capture build created in the deployment workbench). With LTI, you need to leverage the notepad application described earlier in this document to stop the Vista install at a point where you can make your changes to the signed in administrator profile. With ZTI, the process stops naturally at the logged in administrator profile so that the technician can run the OSD capture CD. In either case, once the admin profile is configured the capture can proceed and that captured .wim turned brought
UofI
Page 23 of 52
Admin Guide
BDD 2007
into BDD as an Operating System and then turned into a Build. At the build level, you have the opportunity to edit the unattend.xml answer file. Edit the answer file with Windows System Image Manager so that in the Specialize pass under Windows-Shell-Setup set CopyProfile to True. This will allow the administrator profile you configured to be copied up as the ―default‖ profile before setup completes and deletes it.
4.1. Capturing a “reference” Image
Capturing an image with BDD 2007 is a Lite Touch Deployment that ends with an image capture. The Lite Touch Deployment process relies upon an interview wizard used for the Refresh and Upgrade Scenarios. To capture a reference image, you must start a lab computer using the Windows PE bootable images you generate by updating the ―lab‖ deployment point. You can start the Windows PE bootable images in two ways. First, you can burn the ISO images that BDD 2007 generates when you update a deployment point to a CD. These ISO image files are in the \Boot folder of the distribution point (\\servername\Distribution$\Boot). Second, you can add the LiteTouchPE_x86.wim or LiteTouchPE_x64.wim image files to the Boot Images node of a Windows DS server. The .wim image files are in the \Boot folder of the distribution point (\\servername\Distribution$\Boot). Perform the following tasks to capture a reference image. On the machine running the deployment workbench (hosting the distribution share), burn the D:\Distribution\Boot\LiteTouchPE_x86.iso file to CD Note: this is the Lab deployment point WinPE iso On the reference machine, boot to the CD created in the previous step In the deployment wizard: o o Keyboard Layout: United States Specify credentials for connecting to the distribution share: o o o o o o o o User name: Password: Domain:
Computer name: (Doesn’t matter when performing a capture) Join a workgroup: Workgroup (you must join a workgroup to capture) Specify whether to restore user data: Do not restore user data and settings Select an operating system image to install: Windows Vista Enterprise Source Locale Selection: English (United States) Time Zone: Select one or more applications to install: Any core applications as appropriate Specify whether to capture an image: Capture an image of this computer Location: \\TechnicianMachine\Distribution$\Captures File name:
o
Review the Details before clicking Begin.
UofI
Page 24 of 52
Admin Guide
BDD 2007
After clicking Begin, the task sequence starts by partitioning and formatting the hard disk. Next, it installs and configures the build, installs any specified applications, runs Sysprep to prepare the computer for imaging, and restarts the computer in Windows PE to capture the image. BDD stores the captured image in the Captures folder of the distribution share. After capturing the image, you can add it to the deployment workbench as an available operating system image.
4.2. Capturing an OSD/ZTI “reference” Image
As mentioned previously, the process of capturing a ZTI / OSD reference image is very similar to capturing an LTI image. The primary difference is that the SMS client, a way to stop the SMS service, and a way to delete the SMS client certificate must be available as applications during the deployment interview. Once these applications are included, the SMS Image Capture CD can be used to initiate a capture. The first difference between an LTI capture and an OSD/ZTI capture is that you need to add the SMS client, a way to stop the SMS service, and delete the SMS client certificate. In the Deployment Workbench, add the SMS client install and pre-stage: In the Deployment Workbench, expand the Distribution node, right-click on the Applications node, and select New (or Click New from the Actions pane) In the New Application Wizard: o o o o o o o Application without source files or elsewhere on the network Publisher: Microsoft Application name: SMS 2003 Advanced Client Version: SP2 Language: English Platform: x86 Platform Only Command Line: ccmsetup.exe /useronly /source:\\itsnt129.iowa.uiowa.edu\Srcfiles\smsclient /mp:itsnt129.iowa.uiowa.edu SMSSITECODE=UI1 SMSCACHESIZE=1000 Working directory: \\itsnt129.iowa.uiowa.edu\srcfiles\smsclient
o
Right-click on the Applications node, and select New (or Click New from the Actions pane) In the New Application Wizard: o o o o o o o o Application without source files or elsewhere on the network Publisher: ITS Application name: SMS 2003 Client Pre-Stage Version: 1.1 Language: English Platform: x86 Platform Only Command Line: cscript PrepSMSClient.vbs //B Working directory: \\itsnt129.iowa.uiowa.edu\srcfiles\smsclient
On the reference machine:
UofI Page 25 of 52
Admin Guide
BDD 2007
If you have not already done so, on the machine running the deployment workbench (hosting the distribution share), burn the D:\Distribution\Boot\LiteTouchPE_x86.iso file to CD Note: this is the Lab deployment point WinPE iso
On the reference machine, boot to the CD created in the previous step In the deployment wizard: o o Keyboard Layout: United States Specify credentials for connecting to the distribution share: o o o o o o o User name: Password: Domain:
Computer name: (Doesn’t matter when performing a capture) Join a workgroup: Workgroup (you must join a workgroup to capture) Specify whether to restore user data: Do not restore user data and settings Select an operating system image to install: Windows Vista Enterprise Source Locale Selection: English (United States) Time Zone: Select one or more applications to install in addition to the following required applications: SMS 2003 Advanced Client SMS 2003 Client Pre-Stage Any core applications as appropriate Location: \\TechnicianMachine\Distribution$\Captures File name:
o
Specify whether to capture an image: Prepare to capture the image (using OSD)
o
Review the Details before clicking Begin.
After installing the base Vista operating system and any applications, the deployment wizard will prepare for capture. To perform the capture, do the following: Insert the OSD Capture CD, if it does not prompt with autorun, start the OSD Image Capture Wizard (OSDICW.EXE) o o o o o o Name the image: Store the image: \\bddserver\share\captures share Connect as: domain\account that has permissions to above share Local admin password: Sysprep options: leave as default (-oobe -generalize) Enter: Comments, created by, and version indicator (date is a good option for version)
The OSD Image capture wizard will run and then shutdown the computer
UofI
Page 26 of 52
Admin Guide
BDD 2007
Boot to SMS OSD capture CD, the system boots into WinPE and captures an image as a .wim Note: If you have to restart the machine for any reason before this point, you will need to manually delete the SMS certificate
4.3. Updating the Reference Image
Updating reference images will include two primary efforts, deciding how to add the change (scripts, unattend.xml, or manually) and how to document the change. There is no predetermined best way to perform either of these tasks. Some changes to the image will only be available through one configuration method. The best idea will be to stick to one primary method and only use the others as necessary. As for documentation, whenever the base image is modified, this information should be recorded in order to track changes and to help in troubleshooting should issues occur. A document that captures version, changes (additions, subtractions, etc…), and any other information that is considered relevant would be beneficial.
4.4. Importing an LTI captured .wim
Once an image has been captured leveraging the BDD Lab deployment point, that .wim file is located in the captures folder on the distribution share. In order for this image to be used with BDD, it must be imported into the deployment workbench as a new operating system. Once the .wim image file is imported as an OS, it can be used to create a build and then be associated with one or more deployment points. Note: When importing a captured .wim as a new operating system, it is important to import the Vista setup files in addition to the image file. This is important because the setup files found on the Vista source media must be available with at least one build associated with any given deployment point. Perform the following steps to import a .wim captured through the LTI process. In the Deployment Workbench, expand the Distribution node, right-click on the Operating Systems node, and select New or click New from the Actions pane In the New Os Wizard: o o o o Select operating system image (WIM) file Source file: D:\Distribution\Captures\VistaCap.wim Optionally, Move the files to the distribution share instead of copying them Copy Windows Vista Setup files from the specified path (this can be either the source media that was imported into the deployment workbench or the Vista DVD. Destination directory name:
Once a captured .wim is imported as an operating system, it is useless in regards to being used in an actual deployment until it has been associated with a build. Perform the following steps to create a new build. In the Deployment Workbench, right-click on the Builds node, and select New or click New from the Actions pane In the New Build Wizard: o Build ID:
UofI
Page 27 of 52
Admin Guide
BDD 2007
o o o o o o o o
Build name: Build comment: Operating System Image: ProductKey: Do not specify a product key at this time Organization: FullName: Internet Explorer home page: Administrator Password and confirm Password:
4.5. Importing an OSD/ZTI captured .wim
Perform the following steps to import a .wim captured through the LTI process. In the Deployment Workbench, expand the Distribution node, right-click on the Operating Systems node, and select New (or click New from the Actions pane ) In the New Os Wizard: o o o Select Custom Image File Source file: D:\Distribution\Captures\VistaCap.wim Optionally, Move the files to the distribution share instead of copying them Destination directory name:
Again, a captured .wim must be associated with a build in order to be leveraged with an OSD/ZTI deployment point. Perform the following steps to create a new build. In the Deployment Workbench, right-click on the Builds node, and select New or click New from the Actions pane In the New Build Wizard: o o o o o o o o o Build ID: Build name: Build comment: Operating System Image: ProductKey: Do not specify a product key at this time Organization: FullName: Internet Explorer home page: Administrator Password and confirm Password:
UofI
Page 28 of 52
Admin Guide
BDD 2007
5. Preparing to Deploy Images
The process of preparing to deploy images to customer workstations includes setting up a deployment point (network, media, or ZTI), associating deployment resources (builds, applications, and drivers) with the deployment point, and customizing the deployment control files (customsettings.ini, bootstrap.ini). Whereas a distribution share contains the files necessary to install and configure a build on a destination computer, a deployment point defines a subset of those files and how to connect to them. For example, the distribution share might contain multiple operating systems and hundreds of applications. A deployment point defines which of those files to distribute and how to access them through a network connection or removable media. The following sections cover how to create the Network and ZTI deployment points.
5.1. Creating a Network Deployment Point
If you will be using ITS resources to host your network deployment point - go to \\itsnt129.iowa.uiowa.edu\DeploymentPoints and create a folder to house the deployment point, send a request to ITS-SPA-ECM@UIOWA.edu to create a share of the folder you created. If you are using itsnt129, create a network deployment point; use these example settings as a guide: Server: itsnt129.iowa.uiowa.edu Share: UI_Base Path: \\itsnt129.iowa.uiowa.edu\DeploymentPoints\sharename
Perform the following steps to create a Network Deployment Point. In the Deployment Workbench, right-click on the Deployment Points node, and select New or click New from the Actions pane In the New Deployment Point Wizard: o o o o o o o o o Separate deployment share Deployment point name: Allow user to select additional application on Upgrade: Checked (default) Allow the user to set Administrator Password: Unchecked (default) Allow the user to specify a product key: Unchecked (default) Server name: Share name: Match deployment point name Path for share: User data defaults:
In the Deployment Workbench, right-click the new Deployment Point and select Properties On the Rules tab o Edit CustomSettings.ini to: Load state and Scan state arguments Hide deployment wizard pages
UofI
Page 29 of 52
Admin Guide
BDD 2007
o
Provide default values for deployment questions Specify the DeploymentRoot property
Edit BootStrap.ini
In the Deployment Workbench, right-click the new Deployment Point and select Update Note: The full update process populates all of the deployment resources (builds, applications, drivers, control files, etc…) into the deployment share, in addition the WinPE .iso images are generated. The update process will take at least 5 - 10 minutes.
5.2. Creating an OSD/ZTI Deployment Point
Deploying images by leveraging the ZTI deployment method involves some additional configuration because of the interaction between SMS and BDD.
5.2.1.
Prerequisite Configuration
The prerequisite configuration includes adding WinPE 2005 and Windows Server 2003 SP1 source media to the distribution share. Customizing Windows PE 2005 for use by ZTI requires certain files from this operating system. Add the WinPE 2005 source media: o o In the Deployment Workbench, expand the Distribution node, right-click on the Operating Systems node, and select New or click New from the Actions pane In the New Os Wizard: Full set of source files Source directory: :\ or :\ (an iso-drive would be used by mounting the WinPE2005.iso file and then accessing it) Note: the WinPE 2005 .iso can be found at \\itsnt129\iowa.uiowa.edu\shared\NTAdmin\vista\deployment tools\deployment team o o Destination directory name: Windows PE 2005
Add the Windows Server 2003 SP1 source media In the Deployment Workbench, expand the Distribution node, right-click on the Operating Systems node, and select New or click New from the Actions pane In the New Os Wizard: Full set of source files Source directory: :\ or :\ Note: the Windows Server 2003 SP1 .iso can be found at \\itsnt129\iowa.uiowa.edu\shared\NTAdmin\vista\deployment tools\deployment team Destination directory name: Windows Server 2003 Enterprise Edition SP1
5.2.2.
Create and Configure the OSD/ZTI deployment point
Perform the following steps to create a ZTI deployment point.
UofI
Page 30 of 52
Admin Guide
BDD 2007
In the Deployment Workbench, Right-click on the Deployment Points node, and select New o o o o o o o o o Type: SMS 2003 OSD Name: Server name: Share name: Path: Specify user data defaults: Click Create Specify where to obtain SMS 2003 OSD files: C:\SMSADMIN\OSD Click OK to the warning
Perform the following steps to configure the OSD/ZTI deployment point Right-click the ZTI deployment point and select properties On the Rules tab Note: ITS has provided a template customsettings.ini file, which can be found at: the contents of this file can be copied and pasted into the Rules tab of the deployment point or you can use the following settings: o Edit customsettings.ini (populate as much as possible) [Settings] Priority=Default [Default] OSInstall=Y ScanStateArgs=/v:5 /o /c LoadStateArgs=/v:5 /c /lac UserDataLocation=AUTO [SMS] SQLServer=smsserver Database=SMS_"SiteCode" Table=v_Program Parameters=PackageID, Programname SQLSHARE=sharename On the Builds tab o Ensure the Windows Vista Enterprise OSD build is the only one checked Note: The BuildID of the Build selected will used as subfolder name in the D:\ZTI folder.
UofI
Page 31 of 52
Admin Guide
BDD 2007
On the Windows PE tab o o o o Windows PE source: Windows PE 2005 Windows Source: Windows Server 2003 SP1 Ensure include network drivers is checked Optionally add a custom bitmap image to be included in the generated WinPE iso
Right-click the ZTI deployment point and select Update Note: The update process generates a Generic_OSD_x86.iso file by combining the WinPE 2005 and Windows Server 2003 SP1 source media. The full update process populates all of the deployment resources (builds, applications, drivers, control files, etc…) into the deployment share, in addition the WinPE .iso images are generated. The update process will take at least 5 - 10 minutes.
5.2.3.
Install the SMS Admin Console and OSD feature pack
If you do not have the SMS administrator console and the SMS OSD feature pack update installed, you will need to install them locally on your BDD machine in order to complete the following tasks. To install the SMS administrator console: For a new installation, run: o o \\itsnt129.iowa.uiowa.edu\support\SMS 2003 SP2 AdminConsole New Install.cmd
For upgrades, run: \\itsnt129.iowa.uiowa.edu\support\SMS 2003 SP2 AdminConsole New Upgrade.cmd
After installing the SMS administrator console, certain firewall exceptions are required for the console to work properly. The following Port and Program exceptions must be added to the Windows Firewall Settings on the SMS Admin Console systems: Port 135 TCP (RPC) Unsecapp.exe (WMI) Statview.exe (Message Status Viewer)
Install the SMS OS Deployment Feature Pack on any SMS 2003 SP1 Administrator console computer intended to provide operating system deployment functionality. Before installing the OS Deployment Feature Pack, close the SMS Administrator console. Note: SMS 2003 SP1must be installed on all site servers to support the SMS 2003 OSD Feature Pack. In addition, the SMS Administrator Console supplied with SMS 2003 SP1 must be used. To install the SMS OSD Feature Pack: 1. Double-click the file OSDeployment_setup.exe located at \\itsnt129\support\Feature Packs\SMS2003 OSD Feature Pack Update. This executable file calls the OSDeployment.msi file, which runs the setup wizard. 2. Click Next. 3. Read the license agreement. If you choose to accept the license agreement, select I accept the license agreement, and click Next.
UofI
Page 32 of 52
Admin Guide
BDD 2007
4. Click Next on the Installation page to start the installation process and view the progress window. 5. On the Setup Complete page, click Finish. You do not need to provide special configuration information during or after feature pack setup. If you encounter a problem during feature pack installation, examine these log files in the SMS\Logs folder for error messages: OSDeploymentsetup.log OSDeploymentmsi.log
After installing the OSD Feature Pack, an Image Packages folder appears in your SMS Administrator console.
5.2.4.
Update the SMS OSD WinPE
The version of WinPE that the SMS OSD Feature Pack creates cannot be customized and does not include Windows Management Instrumentation (WMI). Without WMI support in WinPE, the ZTI scripts will not be able to discover attributes such as HAL type, asset tag, serial number, make, model, or universally unique identifier (UUID). A customized WinPE image can be created using the deployment workbench or a manual process. Although using the Generic_OSD_x86.iso generated by the Deployment Workbench is the recommended approach, we have seen issues when using the Generic_OSD_x86.iso file in testing. It may be necessary to modify the WinPE 2005 source manually and then update the SMS OSD WinPE from the manually updated source. The effort of manually updating the WinPE 2005 source includes adding network drivers, updating Winbom.ini, and modifying the splash screen. To manually update the WinPE 2005 source: Perform the following steps on the WinPE 2005 source files that were imported into the deployment workbench Add additional Network driver support o o Copy b57win32.inf from the Broadcom driver directory to C:\Distribution\Operating Systems\Windows PE 2005\I386\INF Copy b57xp32.sys from the Broadcom driver directory to C:\Distribution\Operating Systems\Windows PE 2005\I386\SYSTEM32\DRIVERS, click yes to replace the existing file
Make the appropriate modifications to Winbom.ini, perform the following steps: o o o o Open the Winbom.ini file at the root of the WinPE 2005 source in Notepad. In the [WinPE] section, add a new line, and then type Quiet=Yes. Save the file, and then close Notepad. Copy the Winbom.ini file to the I386 and I386\System32 directories in the WinPE 2005 source. Copy a customized bitmap ―winpe.bmp‖ (800 x600) into the following directories: C:\Distribution\Operating Systems\Windows PE 2005\I386\System32
Update the WinPE splash screen o
UofI
Page 33 of 52
Admin Guide
BDD 2007
C:\Distribution\Operating Systems\Windows PE 2005\WINPE
Perform the following tasks to update the WinPE 2005 media used by the SMS OSD feature pack. In the SMS Administrator Console, right-click Image Packages, point to All Tasks, and then click Update Windows PE Click Next to the welcome Browse to the Path (you may have to type the path in manually) of the WinPE 2005 source C:\Distribution\Operating Systems\Windows PE 2005 Click Finish In SMS, Update Image package source – Right-click the OS Image, select All Tasks, Update Operating System Package Files In SMS, Update distribution points – Right-click the OS Image, select All Tasks, Update Distribution Points
Note: Only if it is determined that the Generic_OSD_x86.iso file generated by the Deployment Workbench is functional should you perform the following steps instead of the manual method described above. To import the customized WinPE image into the SMS 2003 OSD Feature Pack, you need to provide access to the contents of the Generic_OSD_x86.iso file. The Update Windows PE wizard in the SMS OSD Feature Pack needs to copy the contents of the .iso file to create a .wim file that can be used by the SMS OSD Feature Pack. To provide the SMS OSD Update Windows PE wizard access to the contents of the Windows PE .iso file, do one of the following: Burn the contents of the .iso file to a CD. Mount the .iso file using a tool that has the ability to mount .iso files as a local drive.
Perform the following tasks to update the WinPE 2005 media used by the SMS OSD feature pack. In the SMS Administrator Console, right-click Image Packages, point to All Tasks, and then click Update Windows PE Click Next to the welcome Browse or type in the Path and of the Windows PE .iso file, Generic_OSD_x86.iso Click Finish In SMS, Update Image package source – Right-click the OS Image, select All Tasks, Update Operating System Package Files In SMS, Update distribution points – Right-click the OS Image, select All Tasks, Update Distribution Points
5.2.5.
Ensure the SMS client has access to resources
If you are using the ITS shares, the following configuration has been completed for you already. During the deployment to the target computers, the SMS client connects to the distribution point shares and shared folders. Ensure there are accounts within SMS for use by the SMS client when accessing these resources. After configuring the SMS client access account(s), create additional
UofI
Page 34 of 52
Admin Guide
BDD 2007
shared folders in which to store the user state migration data, computer backup data, and the deployment logs. After creating the additional shared folders, configure the appropriate shared folder permissions. Ensure that unauthorized users are unable to access user state migration information and the deployment logs. Only the target computer creating the user state migration information and the deployment logs should have access to these folders.
5.3. Configuring SMS OSD for ZTI
The Operating System Deployment (OSD) Feature Pack Update adds new functionality to SMS 2003. This new functionality provides SMS 2003 with the ability to perform tasks such as computer imaging, state migration, and mass deployment. The SMS OSD image deployment process includes Actions and Phases. Action – A command performed during one of the phases of the OS Deployment process. These can be custom actions, where you define the command line and all parameters relating to it, or standard actions, where most of the details are already known to SMS. Phase – There are six phases implemented by the OS Deployment Feature Pack for the image deployment process: o o o o o o Validation – makes sure that an OS deployment can or should be performed. State Capture – captures the user state information Pre-install – prepares the computer for the installation of a new image (e.g. partitioning or formatting) Install – the OS image file (WIM file) is placed on the machine Post-Install – after the OS is up and running, additional configuration can be performed. State Restore – the user state backed up in the ―State capture‖ phase is restored, before any users log on.
Note: During each of these phases (except for the Install phase), one or more actions can be defined and executed. The first step in configuring SMS OSD for a ZTI deployment is to create an Image Package from the SMS Administrator Console based off the OSD Deployment Point that was previously created from the Workbench. In the SMS Administrator Console: Right-click Image Packages, select New Operating System Image Package In the New Operating System Image Package Wizard: o o o o o Name: ID – Vista Enterprise OS only – ZTI Image file: C:\distribution$\operatingsystems\veosoosdv1\veosoosdv1.wim Create a departmental folder to store your OSD package source Source: \\itsnt129.iowa.uiowa.edu\OSD\ Click OK to the update DP's warning
UofI
Page 35 of 52
Admin Guide
BDD 2007
Under the Image Package you just created, Right-click the programs node, select New Operating System program In the New OS program wizard: o o o o o o o o Name: ID – Vista Enterprise OS only – ZTI, click Next Product Key: Product key not required License mode: (doesn’t matter, leave at default), click Next Domain: Account: Uncheck create a random password for the local administrator, click Next Click Finish Click OK to the update DP's warning
With the programs node selected, in the details pane, Right-click the "OS Install" program, select properties o o On the General tab - Enter a descriptive comment On the User Notification tab o o Set the Department Use a custom .rtf notification Set the postpone to a past date to eliminate the ability to postpone Always assign the client to the UI1 SMS site For each phase add custom action Name: ZTI - "phase name" Command line: zerotouhcinstallation.vbs Note: By including the ―/debug:true‖ the ―C:\MININT‖ folder will be retained during the cleanup phase. The switch is useful when you are debugging the initial process, but likely would not be included in a production run. Files: All files from ZTI$\VISTAEEZTI (scripts, configs, etc…) Important: this step only needs to be performed for one phase. Also, you will need to change to All files *.* in the open browse window Note: As a part of this process, the USMT30_x86.cab file that contains the USMT bits and USMT control files necessary to execute user state migration is added. If this .cab file is recreated, the USMT control files have been modified, then this file must be re-added. o o Click OK Click OK to the update DP's warning
On the SMS Client tab On the Advanced tab - Set the Custom Actions for each phase
Add a Distribution Point to the Image Package
UofI
Page 36 of 52
Admin Guide
BDD 2007
o
Right-click the Distribution Points node under the Image Package created above, select New, Click Next, Check the distribution point(s) (itsnt129\Image DP), click Finish
Perform the following steps to finish the configuration in BDD. In the Deployment Workbench: Right-click the OSD/ZTI deployment point, select properties On the rules tab, verify CustomSettings.ini has the correct SMS settings [SMS] SQLServer="smsserver" Database=SMS_"SiteCode" Table=v_Program Parameters=PackageID, Programname SQLSHARE="sharename" Note: PackageID can be found in the details pane by selecting the image packages node Note: Programname can be found by selecting the programs node under the OS image package Verify bootstrap.ini has the correct SMS settings [Settings] Priority=Default [Default] OSDINSTALLSILENT=1 OSDINSTALLPACKAGE=PackageID OSDINSTALLPROGRAM=Programname
5.3.1.
Updating files in BDD and SMS
Although Microsoft has been able to provide some interesting and useful functionality by creating some methods to integrate BDD 2007 and SMS 2003 OSD, there are some pieces of the two solutions that do not line up quite as well as they could. Namely, the process of updating deployment files in the BDD deployment workbench and then updating the related files in SMS. The process includes the following steps. 1. In BDD, Update files only (deployment point) – Right-click the ZTI deployment point, select Update (files only) 2. In SMS, Update Image package source – Right-click the OS Image, select All Tasks, Update Operating System Package Files 3. In SMS, Update distribution points – Right-click the OS Image, select All Tasks, Update Distribution Points Optionally a batch script could be created to copy and paste the updated files into all of the necessary locations.
6. Deploying an Image
Deploying an image can be achieved through a number of different methods including: Lite Touch (LTI), Zero Touch (ZTI), SMS OSD, and ImageX deployment. The primary methods are LTI and ZTI. LTI and ZTI support a number of different deployment scenarios.
UofI
Page 37 of 52
Admin Guide
BDD 2007
The following table describes these scenarios.
Scenario Description User state Uses migrated existing computer No No File system preserved No
New Computer Upgrade Computer
A new installation of Windows is deployed to a new computer This scenario assumes that there is no user data or profile to preserve.
The current Windows operating system on the Yes target computer is upgraded to the target operating system. The existing user state migration data, user profile, and applications are retained (as supported by the target operating system). A computer currently running a supported Windows operating system is refreshed. This scenario includes computers that must be re-imaged for image standardization or to address a problem. This scenario assumes that the team is preserving the existing user state data on the computer. A computer currently running a supported Windows operating system is replaced with another computer. The existing user state migration data is saved from the original computer. Then, a new installation of Windows is deployed to a new computer. Finally, the user state data is restored to the new computer. Yes
Yes
Yes
Refresh Computer
Yes
No
Replace Computer
Yes
No
No
Table 2: Deployment Scenarios and Descriptions
LTI requires minimal infrastructure to operate. The target operating systems can be deployed over the network by using a shared folder or locally by using a removable storage (such as a CD, DVD, USB hard drive, or other devices). LTI supports the following deployment scenarios: New Refresh Replace Upgrade
ZTI requires SMS 2003, SMS 2003 SP2, and the SMS 2003 OSD Feature Pack. The target operating systems are deployed from SMS 2003 distribution points. The installation process is initiated by SMS 2003. The ZTI deployment process is typically initiated through an SMS advertisement. ZTI supports the following deployment scenarios: New Refresh Replace
The differences between LTI and ZTI deployments are contrasted in the following table.
UofI
Page 38 of 52
Admin Guide
BDD 2007
LTI deployment Provide configuration settings that are common to a group of target computers. Requires less up-front configuration time. Can be used with slow-speed connections or in instances where no network connectivity exists. Requires little or no infrastructure to support deployment. Supports deployment over the network or locally. Target computers are not required to be managed by SMS 2003 (or other software management tools). Supports security policies where automatic software installation is prohibited. Supports deployment of target computers isolated by firewalls. Supports Upgrade Computer deployment scenario.
ZTI deployment Provide all necessary configuration settings for each target computer. Requires more up-front configuration time. Requires a high-speed, persistent connection.
Requires an infrastructure sufficient to deploy operating system images by using SMS 2003 OSD Feature Pack. Supports only network deployments. Target computers must be managed by SMS 2003.
Supports only security where automatic software installation is allowed. Requires Remote Procedure Call (RPC) communication with the target computers (and as such usually requires too many ports to be opened through firewalls). Upgrade Computer scenario is not supported.
Table 3: LTI deployment vs. ZTI deployment
6.1. Lite Touch Deployment – New Computer
Windows is deployed to a new computer. This scenario assumes that there is no user data or profile to preserve. Perform the following steps to execute a Lite Touch New Computer Deployment. Boot a machine with the appropriate LiteTouchPE_xxx CD (LiteTouchPE_x86.iso created from a valid NETWORK Deployment Point) Complete the BDD Deployment Wizard using the below settings o o Keyboard Layout: United States Specify credentials for connecting to network shares: o o User name: Password: Domain:
Computer name: Join a Domain:
UofI
Page 39 of 52
Admin Guide
BDD 2007
o o o o o o o o o o
User name: Domain: Password: Specify whether to restore user data: Select an operating system image to install: Locale Selection: English (United States) Time Zone: Select one or more applications to install: Specify the BitLocker configuration: Review the Details and click Begin
BDD 2007 will now deploy a Windows Vista image.
6.2. Lite Touch Deployment – Refresh Computer
A computer currently running a supported Windows operating system is refreshed. The existing operating system is cleaned off the hard drive and a new OS is installed. This scenario assumes that the team is preserving the existing user state data on the computer. Perform the following steps to execute a Lit Touch Refresh Computer Deployment. Boot the machine and logon with an account that has local administrator privileges Run \\BDDServer\Distribution$\Scripts\Litetouch.vbs. (Note:Always use FQDN for BDDServer) Complete the guide using the following settings: o o o Choose a migration type: Refresh this Computer Computer name: (Default) Join a domain o o o o o o Domain: : Username: Domain: Password: Allow data and settings to be stored locally when possible
Specify where to save your data and settings: Automatically determine location Specify where to save a complete computer backup: Select an operating system image to install: Locale Selection: English (United States) Time Zone: Select one or more applications to install:
UofI
Page 40 of 52
Admin Guide
BDD 2007
o
Specify credentials for connecting to network shares: User name: Domain: Password:
o
Review the Details before clicking Begin.
After completion, logon and verify that the user settings and data where migrated.
6.3. Lite Touch Deployment – Replace Computer
A computer currently running a supported Windows operating system is replaced with another computer. The existing user state migration data is saved from the original computer. Then, a new installation of Windows is deployed to a new computer. Finally, the user state data is restored to the new computer.
6.4. Lite Touch Deployment – Upgrade Computer
The current Windows operating system on the target computer is upgraded to the target operating system. The existing user state migration data, user profile, and applications are retained (as supported by the target operating system).
6.5. Zero Touch Deployment – Refresh Computer
Like the LTI refresh scenario, a computer currently running a supported Windows operating system can be refreshed. The existing operating system is cleaned off the hard drive and a new OS is installed. This scenario assumes that the team is preserving the existing user state data on the computer. Perform the following steps to deploy an image using an SMS advertisement In SMS - Create a collection to target the machine(s) In SMS - Create an advertisement that included the Operating System Image Package On the Client - Initiate Action or wait for the advertisement to become available
Perform the following steps to deploy an image using the SMS Installation CD Launch the OSD installation CD from within the operating system
6.6. Zero Touch Deployment – New Computer
The New Computer deployment scenario for ZTI is a bare metal machine (Factory OS wiped clean ) deployment. The machine is booted from the OSD Image Installation CD which is created from the Image Package node of the SMS Administrators Console and the Deployment Wizard is initiated from there. No user data or computer backup data is captured.
6.7. Zero Touch Deployment – Replace Computer
When replacing an existing computer, you need to capture user state from the existing computer so that the user state information can be restored to the new target computer. In this scenario, the operating system is not deployed to the existing computer. Instead, you create an SMS 2003 package and program to capture the user state information. This is a standard SMS 2003 package and program—not an SMS
UofI
Page 41 of 52
Admin Guide
BDD 2007
2003 OSD package and program. After creating the SMS 2003 package and program, advertise the package and program to the existing computers (the computers being replaced). Deployment Workbench automatically creates the source files required to create the SMS package and program to perform user state capture. The files are stored in the OldComputer folder immediately beneath the folder that is the root for the deployment point. For example, if the root of the deployment point is C:\ZTI, then the path to the source files for creating the SMS package is C:\ZTI\OldComputer. Perform the following steps to deploy an image using an SMS advertisement In SMS - Create a collection to target the machine(s) In SMS – Create a standard package and program (to capture user state) In SMS - Create an advertisement (for the state capture) In SMS - Create an advertisement (for the OS deployment) On the Client - Initiate Action or wait for the advertisement to become available
6.8. Alternate Deployment Methods
Although images captured through the deployment workbench can be deployed using: SMS OSD deployment method without any of the ZTI scripts ImageX deployment Windows Deployment Services (WDS)
These methods will not be detailed in this guide.
7. Customizing Deployment
Customizing BDD 2007 deployments centers on processing rules and understanding how the scripts and other components interact with the BootStrap.ini file, the CustomSettings.ini file, and the configuration database.
7.1. BootStrap.ini
BootStrap.ini is the configuration file used when the target computer is not able to connect to the appropriate deployment point. This situation occurs in the New Computer scenario and for the replacement computer in the Replace Computer scenario In ZTI and LTI deployments, use the BootStrap.ini file to specify property settings prior to accessing the CustomSettings.ini file. The BootStrap.ini provides distribution point information, SMS OSD Feature Pack package and program information, logon credentials, and Microsoft Windows Preinstallation Environment (Windows PE) keyboard locale settings. The properties configured in BootStrap.ini help the BDD 2007 scripts locate the appropriate: BDD 2007 distribution point SMS 2003 OSD Feature Pack package and program
UofI
Page 42 of 52
Admin Guide
BDD 2007
The syntax of the BootStrap.ini file is identical to the CustomSettings.ini file. The BootStrap.ini file contains a subset of the properties that are used in the CustomSettings.ini file. The following table lists the common properties that can be configured in BootStrap.ini
Property Name DeployRoot SkipBDDWelcome UserDomain UserID UserPassword KeyboardLocale OSDInstallSilent OSDInstallPackage OSDInstallProgram LTI ZTI
X X X X X X X X X
Table 4: Bootstrap.ini properties
7.2. CustomSettings.ini
CustomSettings.ini is the primary configuration file for the BDD 2007 processing rules used in all scenarios. A CustomSettings.ini file includes: Sections Properties Settings
7.2.1.
Sections
Sections are identified by brackets that surround the section name (for example [Settings]). Only the [Settings] section is required. All other sections are optional. The BDD 2007 scripts require the [Settings] section in CustomSettings.ini to locate the reserved properties (Priority and Properties). Priority – determines the sequence and section of where to find configuration values. Each section is searched in the order specified. When a property value is found, the remaining sections are not used for that property. Properties – defines any custom, user-defined properties that you want to use in your deployment. These user-defined properties are located by ZTIGather.wsf script in the CustomSettings.ini file or configuration database. These properties are in addition to the predefined properties in BDD 2007.
The following describes how priority properties are used in CustomSettings.ini:
UofI
Page 43 of 52
Admin Guide
BDD 2007
Default - Rules that should be applied to all computers are generally specified in the default section. These values could be values such as the time zone or the BDD Deployment Root. Custom - There are three custom section types, dynamic, database or static. o o Dynamic - Using variables such as make model or default gateway you can dynamically specify what rules apply to these ―generic‖ groups of computers. Database - This will perform a database lookup and return a single record. It will then assign the values of any column that matches a BDD property to that property. Static - This is simply a section that is defined in the priority line that is not a dynamic or database section.
o
These optional sections in the CustomSettings.ini file are used to assign a group of configuration settings to the following: A group of computers An individual computer
7.2.2.
Properties
Properties are variables that need to have values assigned, these can be single values or lists. Properties are followed by an equal sign (―=‖). The scripts scan the CustomSettings.ini file to locate the properties. There are essentially two types of properties: Standard properties – These are the default properties defined within BDD Custom properties – Properties that are defined and declared by the deployment team
The types of properties that can be used in deploying your target computers include those properties: Automatically declared in ZTIGather.wsf – These predefined properties are declared in the ZTIGather.wsf script. In addition, ZTIGather.wsf automatically sets the values for these properties. These properties are not configured in CustomSettings.ini and should be treated as read-only. Declared in the ZTIGather.xml file – These predefined properties are listed in the ZTIGather.xml file. ZTIGather.wsf retrieves these properties by scanning the ZTIGather.xml file. You can divide the properties in this file into properties that: o o ZTIGather.wsf automatically assigns values – ZTIGather.wsf automatically sets the values for these properties, which need to be treated as read-only. You need to assign values to in CustomSettings.ini – You need to ensure that the value for any of these properties that you wish to use is set in CustomSettings.ini and is considered modifiable.
Declared in the Properties property – These are custom properties that you can declare, and they are in addition to the properties automatically declared in ZTIGather.wsf and in ZTIGather.xml.
UofI
Page 44 of 52
Admin Guide
BDD 2007
The way properties are used for ZTI and LTI are identical. However, some properties are unique to ZTI or LTI. Because ZTI uses Microsoft Systems Management Server (SMS) 2003 and the SMS Operating System Deployment (OSD) Feature Pack to deploy target operating system images, ZTI has properties that refer to SMS OSD Feature Pack values (such as OSDInstallPackage, OSDInstallProgram, and OSDNewMachineName). Like ZTI, LTI also has unique properties. Most of the LTI-specific properties relate to the Windows Deployment Wizard (such as SkipAdministratorPassword, SkipCapture, or SkipUserData).Although these properties use the same syntax as other properties, these reserved properties perform specific functions in the deployment processing rules.
7.2.3.
Settings
Values are the configuration settings assigned to the properties. Values are preceded by an equal sign (―=‖). The scripts scan the CustomSettings.ini file to locate the values. Values can be assigned to properties through a number of different methods, including: Hard-coded values Variable substitution Script functions Dynamic keys Database
7.3. Custom Settings Database
The configuration database is a logical extension of configuration settings that would normally exist in CustomSettings.ini. It is recommended that you create and manage the configuration database through the Database node in Deployment Workbench. The configuration database allows you to centrally store the configuration settings in a relational database. The configuration database is referenced in the CustomSettings.ini file. The scripts query that database to retrieve values for properties. Using the configuration database is appropriate when the target computers have a high-speed, persistent connection to the server running Microsoft SQL Server where the configuration database is stored. Otherwise, make all configuration settings in CustomSettings.ini. The scripts automatically retrieve appropriate environment variables. The variables are referenced like properties in the deployment processing rules. The environment variables can be referenced as any property in the configuration files or configuration database. You can configure the rules for LTI and ZTI deployments in the DWDB by using Deployment Workbench. The benefits of using the DWDB include:
More generic version of CustomSettings.ini - Storing the configuration settings in the DWDB removes most of the detail from CustomSettings.ini. This change helps make the CustomSettings.ini file more generic so that the same file can be used in multiple deployment points. Centralized repository for all property configuration settings - Centralizing the configuration for all property settings ensures consistency across all deployment points.
UofI
Page 45 of 52
Admin Guide
BDD 2007
The configuration of the property values in the DWDB is organized by the method for applying the properties to the target computers. A node beneath the Database node in Deployment Workbench represents each method, as listed in the following table.
Node Computers Use this node to define Specific target computers based on the AssetTag, UUID, SerialNumber, and MACAddress properties. You can associate property settings, applications, packages, roles, and administrative-level accounts with a computer. A group of computers based on the tasks performed by the users of the target computers (by using the Role property). You can associate property settings, applications, packages, and administrative-level accounts with a role. A group of computers by using the DefaultGateway property of the target computers to identify a geographic location. You can associate property settings, applications, packages, roles, and administrative-level accounts with a location. A group of computers by using the Make and Model properties of the target computers. You can associate property settings, applications, packages, roles, and administrative-level accounts with target computers that are of the same Make and Model Table 5: Database Nodes in the Deployment Workbench
Roles
Locations
Make and Model
Note: Create the items in the Role node before you create the other items beneath other nodes (Computers, Locations, and Make and Model) because the other nodes can then be associated with roles. After you have configured the property values in the DWDB, you need to configure CustomSettings.ini to perform the appropriate database queries. You can do so by using the Configure DB Wizard in Deployment Workbench. BDD automatically recognizes database sections based on the information they contain. The information is used to connect to the DB and construct a select statement that retrieves values from the DB. The following variables are used to declare DB connectivity requirements: SQLServer - This is the SQL Server hosting the DB you wish to connect to. Instance – The name of the instance of SQL Server to be used for querying property values. Port – The number of the port to connect to the SQL server, if required Netlib –The protocol to be used in communicating with the SQL Server. DBNMPNTW – Named pipes, DBMSSOCN –TCP/IP Sockets Database – The name of the database to be used for querying property values Table – The name of the table or view to be queried for property values. Parameters – The list of parameters to pass to the database query Order - The sorting order for the result set on a database query. SQLShare – Any share on the SQL server. You need to connect to a UNC path to get a secure named pipes connection as WinPE is not a member of the domain. [CSettings]
Here is an example snippet from CustomSettings.ini that may help explain the function better:
UofI
Page 46 of 52
Admin Guide
BDD 2007
SQLServer=itsnt129.iowa.uiowa.edu Database=BDD_ITS Netlib=DBNMPNTW Table=ComputerSettings Parameters=AssetTag SQLShare=miglogs This will connect to the machine using the share \\itsnt129.iowa.uiowa.edu\miglogs , then establish a connection the DB, next it will execute the following dynamically created select statement. SELECT * FROM ComputerSettings WHERE AssetTag = „%AssetTag%‟ This will perform a search for records where the AssetTag value is equal to that of the current machine. It will return any column values that match the standard properties or any custom properties declared in the properties section. For example, if the column Role had a value ―HR‖ it would update the Role property within BDD with that value. After you update CustomSettings.ini, you need to ensure the updated version is included in your images. For ZTI, the images created by the SMS OSD Feature Pack must be updated. For LTI, the images created by Deployment Workbench need to run the Configure DB Wizard each time updates are made. Each time changes are made in Deployment Workbench, update the corresponding deployment points in Deployment Workbench. Doing so ensures that all images and deployment configuration files contain the modifications.
7.4. Grouping Computers
You can group your client computers based on a number of different methods. After you determine how you want to group computers, you can select the appropriate properties to help group the target computers. Using the processing rules in BDD 2007, you can group computers based on any property that might be applied to a group of computers (such as Make, Model, DefaultGateway, and so on). The following table lists some possible methods for grouping computers, a description of the method, and the properties that you can use to group the computers.
Grouping Method Geographically Description Group configuration settings based on resources located within a geographic region (such as a shared folder on a computer within a geographic region). Group configuration settings based on hardware attributes (such as the make of the computer or processor architecture of the target computer). Properties DefaultGateway
Target computer hardware attributes
Architecture CapableArchitecture Make Model HALName OSVersion
Target computer software attributes Default attributes
Group configuration settings based on hardware attributes (such as the operating system version of the target computer). Apply configuration settings to all target computers when the properties are not located in other sections.
Default
UofI
Page 47 of 52
Admin Guide Table 6: Methods for Grouping Computers
BDD 2007
In most instances, you can nest computer groupings. For example, the DefaultGateway property can be used to designate the IP subnets on which a computer resides within a geographic location. Note: When grouping computers by hardware configuration, you can use a variety of methods, and the script searches for the substituted value. For instance, if you specify Priority=Make, the script substitutes the value for Make that it determines through a Windows Management Instrumentation (WMI) call and look for the corresponding section, for instance [Dell Computer Corporation]. Like grouping computers, there is more than one method for identifying individual computers. Once you select the method for identifying an individual target computer (hardware, software, user-defined), then you can select the appropriate properties (MACAddress, Product, UUID, AssetTag, SerialNumber).
7.5. Task Sequencer
The Task Sequencer runs the task sequence top to bottom in the order specified. Each task in the sequence is a step, and steps can be organized in to groups and subgroups. Task sequences contain the following
types of items: Tasks (steps) - Within a task sequence, tasks do the actual work. Tasks are commands that the Task Sequencer runs during the sequence, such as partitioning the disk, capturing user state, and installing the operating system. In the default task sequence, most tasks are commands that run scripts. Groups - The task sequence can be organized into groups—or folders that can contain subgroups and tasks. Groups can be nested as necessary. For example, the default task sequence puts tasks in groups by phase and deployment type.
The deployment team can filter both tasks and groups, including the groups and tasks they contain, based on conditions the team specifies. Groups are especially useful for filtering, because an entire collection of tasks can be run based upon a condition such as the deployment phase or type of deployment.
The BDD 2007 deployment process occurs in phases that are defined in the TS.xml file. Task Sequencer parses the TS.xml file to identify the appropriate sequence for performing the deployment process. The phases defined in the TS.xml file include:
Validate Phase - Performs validation checks to make sure that the operating system installation can proceed; specifically blocks installation on server operating systems. State Capture Phase - Gathers information from the configuration file, databases, and the local machine to determine how the image installation process should proceed, including whether there is enough space to do a local Microsoft Windows User State Migration Tool (USMT) state backup. The scripts also invoke the USMT ScanState.exe command as appropriate. Preinstall Phase - Confirms that the necessary information has been gathered in the State Capture Phase for the Refresh Computer and Upgrade Computer scenarios. In the New Computer and Replace Computer scenarios, the script gathers the necessary information in this phase because these scenarios do not perform the State Capture Phase. In addition, a backup of the computer can be optionally performed for the Refresh Computer and Upgrade Computer scenarios. Install Phase - Installs the target operating system on the target computers.
UofI
Page 48 of 52
Admin Guide
BDD 2007
Post Install Phase - Updates the Sysprep.inf file, Sysprep.xml file, or Unattend.txt file with information gathered in the previous custom actions based on the operating system being deployed. State Restore Phase - Invokes the USMT LoadState.exe command to restore the user state that was previously backed up.
The TS.xml file identifies the appropriate steps in each phase based on each type of deployment scenario (Upgrade Computer, Refresh Computer, Replace Computer, and New Computer). In addition, the TS.xml file identifies the steps that are run only for deployments based on the SMS OSD Feature Pack (used in ZTI only). You can modify the sequence of tasks performed for each build that is defined in the Deployment Workbench. The Task Sequencer used by BDD 2007 runs this task sequence. The task sequence information is stored in the distribution_point\build_id\TS.xml file. Through Deployment Workbench, you can: Add new tasks Modify existing tasks Remove existing tasks Change the sequence of tasks Group one or more tasks together Specify conditions for running a task
Note: Although you can directly modify the TS.xml file, it is recommended that you modify the task sequence by using Deployment Workbench. The Task Sequence can be customized through the following: Task sequence variables - allow Deployment team members to compare a variable to a static value using a variety of conditions, such as equal, greater than, and less than. The Task Sequencer maintains numerous variables that can be used in these tests. For example, the Task Sequencer defines a variable called DeploymentMethod that indicates the method of deployment. One possible value of DeploymentMethod is OSD. For a list of variables that the Task Sequencer maintains, see the Configuration Reference. IF statements - Use if statements to combine variables into bigger expressions. For example, create an IF statement that evaluates to TRUE only if all the conditions it contains are true (this is the same as a logical and). Create an IF statement that evaluates to TRUE if any of the conditions it contains are true (this is the same as a logical or). If ALL conditions were chosen in the previous step, all variables added must evaluate to TRUE for the group or task to run. If ANY conditions were chosen in the previous step, the group or task will run if any one of the variables added evaluates to TRUE. Nest if statements to create complex logic. If Boolean logic is familiar, represent Boolean expressions as if statements in the Conditions list. For example, the expression (A=1 and B=2) or (C=2 and D=3) can be represented in the Conditions list as shown in Figure 14. Operating System - The Task Sequencer allows Deployment team members to filter tasks and groups based on the computer’s current operating system. For example, run a preinstallation task only if the destination computer is currently running Windows XP Professional SP2. WMI - The Task Sequencer allows Deployment team members to filter tasks and groups based on WMI queries.
UofI
Page 49 of 52
Admin Guide
BDD 2007
8. Related Tools
There are a number of related tools which Microsoft has made available which add to the functionality of and in some cases are required by BDD 2007. These tools include but are not limited to USMT 3.0, Windows System Image Manager, and ImageX
8.1. USMT 3.0
Typically, user files and settings need to be migrated from Windows XP to Windows Vista. This can be done on an enterprise level using scripts and automation tools such as those found in BDD. The User State Migration Tool (USMT) provides a command line interface controlled by XML files. The USMT command line statements can be included in batch script files. USMT 3.0 comes with two template files. The MigApp.xml file controls what application settings are migrated. The MigUser.xml file controls what files, folders, file types, and desktop settings are migrated (it does not specify what users are migrated). There is also a MigSys.xml file, but it is for migrating to Windows XP only. Migration to Vista does not use the MigSys.xml file. By customizing the template files, you can exercise fine control over the migration process. Note: To save user state, ScanState is run specifying a StorePath and input control files. If a user state file already exists at the StorePath location, ScanState will fail unless /o is specified to overwrite the existing user state file. If there are encrypted files, using the /efs:copyraw option will automatically migrate the encryption certificates. In certain business scenarios, not all users should be migrated. For example, the local Administrator settings on Windows Vista should not be affected by Administrator settings on Windows XP. Additionally, some users may no longer work for the company and should not be migrated. The LoadState command is used to restore saved user state settings and files. The syntax is similar to the ScanState syntax with the notable difference of user and password options. The /ui option includes a domain or local user. The /ue option excludes a domain or local user. The /lac option is the Local Account Create option to create a local account when the account being migrated is not a domain account. If a password is optionally specified with the /lac option, one must consider the security implications if the password is stored in a script file. The /lae option is the Local Account Enable option to enable local accounts created by /lac.
8.1.1.
Customizing the USMT XML control files
The USMT control files: miguser.xml, migapp.xml, and migsys.xml determine what users to migrate, what groups to migrate, what files to migrate, whether or not to redirect files, and application settings. These XML control files can be edited using a simple tool like notepad or a full-blown XML editor. To edit the USMT control files, perform the following steps: 1. Copy the control files from ―C:\Program Files\USMT3.0‖ to a temporary location 2. Edit the files 3. Test the modified control files After editing these control files, it is a good idea to test the functionality of the files from the command line. This process will reduce the time necessary to identify problems with any customizations. Scanstate and Loadstate can be run from the command line specifying
UofI
Page 50 of 52
Admin Guide
BDD 2007
the updated control files as arguments. While logged in as a member of the local administrators group, perform the following tasks a. Run "\\deploymentserver\c$\programfiles\USMT30\ScanState.exe" /v:5 /i:miguser.xml /i:migapp.xml /i:migsys.xml c:\statestore b. Copy the scanstate data from the local machine to a network share c. Run "\\deploymentserver\c$\programfiles\usmt30\loadstate.exe \\server\share\migdata\ /v:5 /i:miguser.xml /i:migapp.xml /i:migsys.xml /lac:P@ssw0rd /lae Tip: When doing USMT customizations for some functions, like rerouting files, you may need to specify your custom xml control files in the loadstate command line as well. 4. Copy the modified control files from the temporary location to ―C:\Program Files\USMT3.0‖ 5. Recreate the USMT30_x86.cab file a. Open a command prompt, switching to the root of the C:\ drive, and run ―makecab /f usmt30_x86.ddf‖ b. Copy the updated usmt30_x86.cab file to the distributionshare\tools folder c. In BDD, Update files only (deployment point) – Right-click the ZTI deployment point, select Update (files only) d. In SMS, Update the OSInstall program – Right-click the OS Install program, on the Advanced tab, add the updated .cab file to the phase you added all the ZTI scripts to earlier. e. In SMS, Update Image package source – Right-click the OS Image, select All Tasks, Update Operating System Package Files f. In SMS, Update distribution points – Right-click the OS Image, select All Tasks, Update Distribution Points
Tip: Windows XP wallpaper may not migrate, to fix this, take exclusion out of migsys.xml to migrate wallpaper (change False to True), another option would be to not use migsys.xml at all.
8.2. Windows System Image Manager
The unattended Windows Setup answer file, typically called Unattend.xml, is the answer file for Windows Setup that is created by using Windows System Image Manager (Windows SIM). The answer file enables the configuration of default Windows settings, as well as the addition of drivers, software updates, and other applications. The answer file enables OEMs and corporations to customize Windows Setup tasks, for example, specifying disk configuration, changing the default values for Internet Explorer, and installing additional drivers. Note: The single answer file replaces all the answer files that were used in previous versions of Windows (Unattend.txt, Winbom.ini, Oobeinfo.ini, and Sysprep.inf Windows System Image Manager (Windows SIM) enables you to create and manage unattended Windows Setup Answer files. These answer files are used during Windows Setup to apply additional configurations and customizations to the default Windows installation. For example, you can change the setting for the Internet Explorer home page, enable or disable Windows Firewall, and partition and format a disk before Windows is installed.
UofI
Page 51 of 52
Admin Guide
BDD 2007
By using Windows SIM, you can also create an answer file that installs third-party applications or device drivers, additional language packs, service packs, or other updates. You can also specify custom commands to run during a particular configuration pass of Windows Setup. When you first open Microsoft System Image Manager, the default option is highlighted in the lower left Windows Image pane. The Windows System Image Manager user interface is composed of 5 panes: The Distribution Share pane - displays a local or networked distribution share. The Windows Image pane - displays the components, settings, and packages that exist in a Windows Image file (WIM) catalog. A catalog file (.clg) contains only the settings that exist in a specific Windows image. The Answer File pane - displays the Windows Setup configuration passes, the settings to apply in each pass, and the packages to install. The Properties pane - displays the properties for a selected component, container, or package. The Messages pane - displays log information from WSIM tool.
Note: Windows System Image Manager does not encrypt the Administrator password. It will be in the unattend.XML in an obfuscated manner. As a best practice, use Group Policy to change the Administrator password at first boot.
8.3. ImageX
ImageX is a command-line tool that can capture, modify, and apply file-based disk images for deployment. Windows ImageX uses a set of APIs, known as Windows Imaging API (WIMGAPI), to perform many tasks with Microsoft Windows Imaging (.wim) files. ImageX works with other technologies that use.wim images, such as Setup for Windows Vista and Windows Deployment Services (WDS). ImageX can also be used to manage the contents of the WIM file in offline mode. When coupled with the Windows Imaging API (WIMGAPI) and the file system filter, WIM images can be accessed as if they were just another folder. WIM images are unique when compared to other imaging formats for many reasons. One of the more important features of WIM images is that they store duplicate files only once in the image, thereby allowing multiple images to be stored in one file without greatly increasing its size. With the WIM Single Instancing feature, a WIM file can contain multiple images, but identical files are only stored once in the image. The following details some of the Imagex commands: Imagex /mount Imagex /mountrw Imagex /info Imagex /capture Imagex /apply
Tip: Drop Imagex in the System32 directory (default environment path) of your BDD machine to make working with Imagex easier.
UofI
Page 52 of 52