Executive Summary: The Microsoft Solution Accelerator Business Desktop Deployment Tool 2007’s Deployment Workbench toolset is designed to automate Windows Vista and Windows XP deployments and manage multiple operating system configurations. With Deployment Workbench’s Lite Touch Installation capability, administrators can create and deploy a generic Windows Vista installation on target machines.

In the Learning Path article “Planning Your Vista Deployment with BDD” (October 2007, InstantDoc ID 96906), I began a tour through the Microsoft Solution Accelerator for Business Desktop Deployment 2007 (BDD) tool by explaining how to install and run the BDD tools that make planning for a Windows Vista upgrade and deployment a lot easier. In this article, I continue the journey by exploring Deployment Workbench, a BDD toolset that helps you automate your Windows Vista and other OS deployments and manage multiple OS configurations. I’ll step you through the basics of a Lite Touch Installation (LTI—my next article in this series about BDD will focus on Zero Touch installs). We’ll create a generic Vista installation complete with applications, patches, and out-of-box drivers and deploy it to target machines.

Getting Started
If you haven’t already done so, download and install BDD 2007 as “Planning Your Vista Deployment with BDD” describes. Next, log on as an administrator and open Deployment Workbench from Start/All Programs/BDD 2007/ Deployment Workbench.

Deployment Workbench is a Microsoft Management Console (MMC) 3.0 snap-in whose default view includes an Actions pane that displays the same menu options that you’d see by right-clicking an object. I recommend closing the Actions pane so that you have more room on the desktop. Most of Microsoft’s MMC 3.0 snap-ins have a button that lets you hide or show the Actions pane, but Deployment Workbench does not. To remove the Actions pane for good (not just from the single instance of Deployment Workbench you’ve launched), you must edit the Deployment/Workbench.msc file. To do so, click Start, Run; browse to C:\Program Files\BDD 2007\Bin\DeploymentWorkbench.msc; append the /a switch to the end of the run statement; then execute the command. Deployment Workbench will open in editable mode (aka author mode). From the View menu, click Customize, clear the Actions pane check box, then click OK. Close MMC by clicking the white X in the top right-hand corner. You’ll be prompted to save the console settings: Choose Yes to save the display in a single window interface.

When you installed BDD, a folder named Distribution was created on a drive on your machine that has the most available free space. The Distribution folder contains subfolders that correspond to Deployment Workbench’s subnodes. As you add components to Deployment Workbench, XML files are created to contain metadata about the components. To easily browse and edit these XML files, I recommend that you download and install a free Microsoft tool called XML Notepad (available from www.microsoft.com/downloads/details.aspx?FamilyID=72D6AA49-787D-4118-BA5F-4F30FE913628&displaylang=en).

Inside Deployment Workbench
Deployment Workbench has four nodes, which Figure 1 shows: Information Center, Distribution Share, Builds, and Deploy. The Information Center node thoroughly documents Deployment Workbench; Microsoft has outdone itself with this documentation set. Distribution Share introduces OS images and patches, applications, and third-party out-of-the-box drivers to Deployment Workbench. The Builds node groups OS images and drivers as well as some settings for the installation, and the Deploy node contains your deployment points, the locations to which target machines connect to install the new Vista build you will create and distribute.

Beware of a quirk in Deployment Workbench: If you open more than one instance at a time, Deployment Workbench exhibits unpredictable— and annoying—behavior. (Every time I opened two instances of Deployment Workbench, both instances would freeze.) Avoid problems by having only one instance open at a time.

Adding an OS
Let’s begin our new Vista deployment by launching the New OS Wizard: Expand the Distribution Share node in the Deployment Workbench console tree, right-click Operating Systems, and choose New. For the first OS you add, you must choose Full set of source files from the wizard’s Choose the type of operating system to add page, which Figure 2 shows. The Full set of source files option copies all files, including setup.exe.

It appears as though you have a choice as to the type of OS to add, but you really don’t. If you select either Custom image file or Windows Deployment Services images before you add a full set of source files, you’ll be met with a “Lite Touch Installation is failed” with the error code (0x00000001) when you attempt to deploy the installation image to a target machine. After you’ve added a full set of OS files, you can add additional OSs from custom OSs from custom Windows Imaging Format (WIM) files or from images stored on a Windows Deployment Services (WDS) server. The Custom image file option requires you to enter the path of the .wim file you want to use. The Windows Deployment Services images option lets you point to a WDS server that contains images you’ve previously created. (For more information about WDS, see this article’s Learning Path.) If a .wim file doesn’t contain a necessary OS file, the .wim file will use the file from the “Full set of source files” that you originally added.

After you choose Full set of source files and click Next, you’ll be prompted for the path to the Vista OS files. The wizard’s final page asks for the name of the folder in which to create and store the OS.

Adding Applications
Now that you’ve introduced the Vista image, it’s time to add the applications that you want to deploy with the OS. Begin by launching the New Application Wizard in Distribution Share: Right-click Applications, then click New. Select either Application with source files or Application without source files or is elsewhere on the network. If you choose the second option, you can specify a Universal Naming Convention (UNC) path (i.e., \\servername\sharename) to the application’s location. You can use Distributed File System Namespace (DFSN) and Distributed File System Replication (DFSR) to group and replicate multiple applications.

You’ll need to supply the wizard with the application’s name, source directory, and supported platform (your choices are All platforms, x86 only, x64 (amd64) only, and ia64 only); the name of the directory for the wizard to create in the Distribution\Applications folder; the command line to be run in quiet mode; and the working directory to begin the command from. Figure 3, shows how applications are listed in the Applications subnode.

An Applications.xml file is created in the Distribution\Control folder and contains information on all applications you add to Deployment Workbench. Each application is given its own globally unique identifier (GUID) in the Applications.xml file. To edit an application, double-click the application name to view its properties. There are two tabs on an application’s properties page: Dependencies and General. The Dependencies tab lets you specify applications that must be installed prior to this application being installed. If the dependent applications aren’t installed, the application you’ve added will fail to install.

Adding Vista Security Updates, Service Packs, and Language Packs
Next, launch the New Package Wizard from Distribution Share to add Vista security updates, service packs, and language packs to your Vista image: Right-click OS Packages, then click New. You’ll be prompted for the paths to the folders that contains these patches; the wizard will add everything a folder contains to Deployment Workbench.

Adding Drivers
Launch the New Driver Wizard from Distribution Share by right-clicking Out-of-Box Drivers, then click New. The wizard prompts for the folders that contains the drivers you want to add to Deployment Workbench and adds everything a folder contains.

Creating a Build
Up to this point, you’ve introduced to Deployment Workbench all the components you want to install on target machines. Now let’s add those components to the build that Deployment Workbench will deploy. To begin, launch the New Build Wizard under Distribution Share by right-clicking Builds, then clicking New. The wizard will ask you to create a Build ID, such as “Vista01” (the ID can’t contain spaces) and a descriptive Build name, such as “Vista Build for VPs.” A field exists where you can add comments, and there’s plenty of room to document what’s in your build and why. The New Build Wizard lets you choose an OS to associate to this build (the list of OSs is based on what you added earlier in the Distribution/Operating Systems node). You can specify a product key for the OS at this time or not (you might want someone to enter a product key for each install). Next, specify the name, organization, and Microsoft Internet Explorer (IE) home page that will be used for all installations from this build. Finally, type in the local administrator’s password or specify that you don’t want to use a password, and click Create.

You can access your build’s properties by double-clicking the build name under Builds. The build properties page has three tabs. On the General tab, you can edit any unshaded properties and enable or disable the build. The Settings tab lets you edit Organization name, Full name, Local administrator password, Internet Explorer home page, and product key information.

If you’re familiar with Microsoft System Center Configuration Manager (SCCM), then you’ve already met the task sequencer, which lets you add tasks to your installation in the exact order they should occur. Maybe you want to add a task (perhaps as another way to add patches) after the installation is complete. Highlight the Postinstall node on the Task Sequence tab, click the Add button, and choose Task. Give your new task a name and description and specify the command line to run and the location to run it from. On the Options tab of your new task you can choose Disable this step (I like this for troubleshooting purposes), continue on error, or create dependencies for the successful completion of this task.

Creating a Deployment Point
Next, use the New Deployment Point Wizard to create the deployment point, the location to which target machines connect to install a build. To launch the wizard, expand the Deploy node in the console tree, right-click Deployment Points, and click New. The wizard will prompt you to choose from among four deployment point types: Lab or single server deployment, the default option, uses the deployment share on the computer on which Deployment Workbench is running; Separate deployment share lets you provide a UNC path to a server and share of your choice; Removable media lets you create a shared folder to use to create images for deployment on removable media; SMS 2003 Operating System Deployment (OSD) Feature Pack, lets you create a shared folder for creating Microsoft Systems Management Server (SMS) OSD Feature Pack images (I’ll cover this option in more detail in my next article in this series).

Subsequent wizard pages prompt you to give your deployment point a name, choose whether to allow users to select additional applications to be installed during an upgrade, and specify whether to prompt users to capture an image of the target computer (for our sample deployment, clear the Ask If an Image Should Be Captured check box). Next, specify whether to prompt users to provide the local administrator password for target computers and whether to prompt users to provide a product key. Finally, specify the server and share name of the deployment point, specify whether users will be prompted to save user state migration options, and click Create. Nothing substantial happens just yet, but a deploy.xml file is created in the Distribution\Control folder.

What really gets things rolling is updating your deployment point. To do so, right-click the deployment point name under Deploy/Deployment Points, and choose Update. A Microsoft Windows Preinstallation Environment (WinPE) file, LiteTouchPE_x86, is created in the Distribution\Boot folder and is converted to a bootable ISO file, LiteTouchPE_x86. iso. Three files are created in the Distribution\Control folder: Bootstrap.ini contains the UNC path to the deployment point; CustomSettings. ini contains your selections in the New Deployment Point Wizard; TS.xml contains the task sequencer list of tasks and the order in which they are to be performed when a target machine connects to the deployment point. To see the deployment point’s properties, double-click the deployment point’s name in the console tree. The properties page has three tabs. The General tab, which Figure 4, shows, displays the deployment point’s name and type, the UNC and local path to the shared folder, and the platforms that the deployment point supports.

The Rules tab contains the settings from the CustomSettings.ini file that determine which screens will display during the installation. You can edit the UNC path to your deployment point by clicking Edit Bootstrap.ini on the Rules tab and entering your changes.

The Windows PE tab, which Figure 5 shows, gives you options for controlling how your WinPE file is configured. You can generate a Lite Touch bootable ISO image that contains scripts for connecting to the deployment server, or you can create a generic ISO image. You can also choose additional language support (i.e., optional fonts), specify driver groups to be installed, add a custom background bitmap file for the desktop, and add directories to the WinPE file.

Deployment
Now it’s time to boot the target machines and begin the deployment. Target machines must boot from the WinPE file that the New Deployment Point Wizard created. You’ll have two WinPE files by default: LiteTouchPE_x86 .iso and LiteTouchPE_x86.wim. To boot from LiteTouchPE_x86.iso, you must first burn it to a CD-ROM or DVD. To boot from Lite- TouchPE_x86.wim, add it to your WDS server. Storing this .wim file on your WDS server lets you PXE boot (F12 for a network boot) your target computers, connect to the WDS server, and boot the custom WinPE file.

Whichever method you use to boot the target machines, your custom WinPE file contains scripts that direct the target machines to connect to the deployment point and read the rules for the installation. With the default set of rules, the target machines will launch the Welcome Windows Deployment screen. On this screen, choose your desired Keyboard Layout from the drop-down menu, and click Next to start the Windows Deployment Wizard. You’ll be prompted for credentials to the deployment point: The account you use must have read, write, and execute permissions to the deployment point. Click Next. The next pages ask you to supply the target computer’s name, credentials for joining the target computer to a domain or workgroup, whether you want to restore users data (e.g., if you had previously saved users’ IE favorites, My Documents, and other settings with User State Migration Tool—USMT). Next, you’ll choose a build, choose whether to provide a product key, and specify language settings and time zone. A list of applications that you’ve added to the deployment point will appear, and you can specify from the list which applications you want to deploy. Finally, supply the local administrator password and specify whether BitLocker is to be enabled on the target machine, and if so, where the BitLocker key is to be stored, then click Create. A progress box will display, and if you watch it closely, you’ll see all the steps that the deployment process goes through. When the progress bar reports a successful completion, you’ll have brand-new Vista machines with all your applications, patches, and out-of-box drivers installed perfectly—again and again and again.