A build binds operating system source files with a configuration. Builds include:
Operating system Choose an operating system image to use for the build.
Unattended setup answer file (Unattend.xml)
Create 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. Generally, allow BDD 2007
control the settings in Unattend.xml and use the BDD 2007 database to
configure destination computers.
Task sequence Each build has a default task sequence.
To create a build for image capture
1. | In the Deployment Workbench console tree, right-click Builds, and then click New to start the New Build Wizard.
|
2. | On the Specify General Information About This Build page, provide the information described in Table 1, and then click Next.
Table 1. The Specify General Information About This Build Page| In this location | Provide this information |
|---|
| Build ID box | Unique
ID for the build. You cannot change this ID later, so decide on a
naming scheme for build IDs in advance. Because you’re creating builds
for image capture in a lab, one possible naming convention is LabNN. | | Build Name box | Descriptive name for the build. Users see this name during LTI installation. | | Build Comments box | Additional
information about the build. User see this description during LTI
installation. Describe the build and what it installs in the image. |
|
3. | On
the Select An Operating System Image To Use With This Build page,
choose an operating system image to install with this build, and then
click Next. Only the operating system images added to Operating Systems
earlier are visible.
|
4. | On the Specify The Product Key For This Operating System page, perform one of the following tasks, and then click Next:
- Select Use The Specified Product Key, and then type the product key in the Product Key box.
- Select Do Not Use A Product Key When Installing.
Generally, volume license
customers deploying Windows Vista to 25 or more computers should select
the Do Not Use A Product Key When Installing option. Customers 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.
|
5. | On the Specify Settings About This Build page, provide the information described in Table 1,
and then click OK. The values you provide on this page are irrelevant,
as you are creating a build for image capture and you will change these
values during production deployment.
Table 1. The Specify Settings About This Build Page| In this location | Provide this information |
|---|
| Organization box | Name of the organization | | Full Name box | Owner name | | Internet Explorer Home Page | URL of the default Internet Explorer home page, such as the URL of the organization’s intranet home page |
|
6. | On
the Specify The Local Administrator Password For This Build page,
select Do Not Specify An Administrator Password At This Time, and then
click Create. Do not specify a local Administrator password for image
builds so that you can specialize the password during deployment.
|
After adding a build to the distribution share,
it appears in the Builds details pane. It also in appears the
distribution share in Control\subfolder, where subfolder
is the build ID. Deployment Workbench stores metadata about each build
in Builds.xml, which is also located in the distribution share’s Control
folder.
To associate a catalog with a build
Normally, Deployment Workbench generates catalog
files for each operating system you add to the deployment. However, if
you base a build on an operating system image that you added from
Windows DS, you must manually associate a catalog file with the build,
because BDD 2007 doesn’t have a catalog for the image.
1. | In the Deployment Workbench console tree, click Builds.
|
2. | In the details pane, right-click the build you want to edit, and then click Properties.
|
3. | Click the General tab, click Browse, select a catalog file, and then click OK.
|
To associate a device driver group with a build
1. | In the Deployment Workbench console tree, click Builds.
|
2. | In the details pane, right-click a build, and then click Properties.
|
3. | Click the General tab, select a group from the Drive group list, and then click OK.
|
To disable a build
1. | In the Deployment Workbench console tree, click Builds.
|
2. | In the details pane, right-click the build you want to disable, and then click Properties.
|
3. | On the General tab, clear the Enable This Build check box, and then click OK.
|
Note
Disabling a build
prevents the Windows Deployment Wizard from displaying it in the list of
builds the user can choose from during an LTI deployment. |
To remove a build
1. | In the Deployment Workbench console tree, click Builds.
|
2. | In the details pane, right-click the build you want to remove, and then click Delete.
|
To edit the build’s answer file (Unattend.xml)
1. | In the Deployment Workbench console tree, click Builds.
|
2. | In the details pane, right-click the build you want to edit, and then click Properties.
|
3. | On the Settings tab, click Edit Unattend.xml to open the build’s answer file in Windows SIM.
|
More Info
For more information about using Windows SIM to
edit Unattend.xml, see the topic “Windows System Image Manager
Technical Reference” in the Windows AIK.
We put the 2007 Office system and a virus
scanner on every image. That way, the customer can be productive
regardless of the method we use to deploy other applications. Also, a
lot of things just make sense to put in the image so the user doesn’t
have to download them later; I can’t think of a single customer that
doesn’t have Adobe Acrobat Reader.
The VPN and dialer installation programs are in
the image, but we don’t install them. When we deploy the image, the
task sequence checks WMI to see if it’s a mobile device. If it’s a
mobile device, we then install the VPN and dialer software; otherwise,
we delete the installation programs.
We also never use a product key. Instead, we use the Key Management Service to simplify our images and reduce key lost.
Having a single image
to deploy is very handy and works well. We encourage people to change an
image only when they need new software. Whenever a new update or device
driver is required, we just replicate that information and then inject
it into the image, rather than making a new image every month and
replicating the image. If this is the approach you plan to take, image
versioning is very important to track.
