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.