I am often asked how I install and configure BDD 2007.

So I thought now was a good time to detail at a high level the process I go through to create and deploy operating system images using BDD 2007. This is not a step by step guide but more of a rant about how I do BDD and the reasons why.

The first thing I must say is that this is just my way of doing installing BDD. And I am sure that there are many people using BDD in different ways, which may well be better than mine. BDD is a very flexible framework and allows many ways to perform these tasks.

If you have any other suggestions about how to install BDD then I would love to hear from you. (I always like new ideas!)

So here we go....

I have broken the configuration process into a number of steps. Each step in the process is detailed in the flowchart below:  

image

So let’s go through each of these steps in more detail.

Install BDD 

Installing BDD is very simple, the steps I follow are listed below:

  1. The first thing I do when installing BDD is install the prerequisites. This includes the WAIK and MS XML. These can be installed from within the BDD Workbench but I install them manually beforehand.
  2. I then install BDD. I usually locate the distribution folder within a folder on D drive (or whatever drive is available) called BDD. I then use this folder to store all other BDD related folders. (this keeps things nice and tidy:)). For example I tend to create the distribution folder in D:\BDD\Distribution.

TIP - Make sure you are using BDD patch 1 as this includes a number of fixes.

Import Source Files

Before I talk about importing source files it is best to discuss my philosophy when creating images. I believe that the process you use to create your images should be fully automated (where possible) and easily repeatable. I NEVER build an image manually. Let me put this another way, the scenarios where you would need manually create your image are very rare and should be avoided.

One of the major strengths of BDD is its ability to fully automate the image creation process. If you want an image that is easy to recreate and manage then BDD is the tool for you.

A good example of why you should use BDD rather than manually building an image illustrated by image patching. Let’s say you manually created your image six months ago and now you want to update the image with extra patches. With BDD you would simply update your build task sequence and recreate your image, EASY. If you manually created your image you could take one of two approaches:

  1. You could manually recreate your build and then add the patches. 
  2. Deploy the image, manually update it with the latest patches and then recapture the image.

Neither of these approaches is recommended. The first will most likely introduce inconsistencies as it is very hard to create a repeatable image when you are doing it manually. The second process is BAD as you should not sysprep an image multiple times.

So with that rant out of the way let see how I import the required source files.

I import all of the files that will be used in the image creation and deployment process. These Source files are divided into four distinct groups:

  • Operating Systems - Any operating system source files used during deployment. This can include Vista source files or even Windows PE 2004/2005 if you are deploying images using SMS.
  • Applications - I use the applications option to import more than just applications. I create an application to for every task that I want to perform with BDD, from installing office to removing unwanted shortcuts from the start menu. By doing this I can easily keep a track of the tasks I have created and reuse them across multiple builds.
  • OS Packages - If I am deploying Vista then I import language packs and patches. BDD will then integrate these automatically during deployment.
  • Drivers - I import the drivers required drivers for each hardware model I will deploy. If I need to use driver groups then I import the drivers using the PowerShell scripts from my previous post here. 

TIP - Create a naming standard that clearly identifies applications. This makes management easier particularly as the number of applications increase. I like to apply a prefix to each application that defines its purpose. For example an application used to install Office 2007 would be called “INSTALL-Office 2007” and an application used to configure the sound scheme would be called “CONFIG-Sound Scheme”.

Create an "Image Creation" Build

A Build binds together a number of components, source files, configuration settings and the installation process (task sequence) defining how to create an image.  With this in mind let’s detail how I create a master image.

  1. I create a Build using the New Build Wizard, specifying the operating system imported in the previous step.
  2. I then add all of the applications that I want include in the image to the task sequence state restore phase.

Easy huh? It is really that simple. Of course you need to test the installation process and you are unlikely to get it right first time but it really is that easy.

The key point is that I always add the applications to the task sequence; I do not select them during deployment using the wizard. Using this method gives you control over when applications install. It also allows you to control when reboots occur.

TIP: Changes made to applications after they have been added to a task sequence are not propagated to the task sequence. So if you make a change then the best approach is to simply remove the application from the task sequence and add it again. The changes will then be applied to the build.

TIP: If the Master Image is to be deployed by SMS then make sure that you include the SMS client in the build.

Create and Capture master image

Now that I have created a build that defines how to create an image we need to execute the build and capture the image.

The first step in this process is the configuration of the Lab deployment.

  1. Configure the deployment point to automate the build process. I tend to to update the deployment point rules so that the only questions I am asked are the capture method and the build I want to execute.
  2. Ensure that the deployment point has been updated using the "Update" option (not "update (files only)").

Once the deployment point is configured we can capture the image. 

  1. Boot to the LiteTouch_x86 image created - I tend to load the image onto a USB stick and boot from there but you could also use a Windows DS server or cut the image to a CD/DVD.
  2. From the Lite Touch Wizard I select the build I just created.
  3. From the Lite Touch Wizard I select the capture type. If it is SMS then I select prepare, for LTI deployments I select yes and specify where the image will be saved. The image will now begin to build.
  4. If we specified the capture to be LTI then the image will be captured automatically. However if the image is to be deployed using SMS then the final step in the process is to capture the image using the SMS capture CD.
  5. Once the image has been captured I then import it into the deployment workbench as a “Custom WIM”.

TIP: Instructions detailing how to fully automate the BDD Lite Touch Wizard are included in the "Configuration reference" document  included with BDD 2007. (Hint: look at the last two pages)

Create an "image deployment" build

One aspect of BDD that causes a lot of confusion is the purpose of Builds. Particularly as builds can be use to both create and deploy images. I prefer to think of builds is as task sequence that controls the execution of a series of scripts which has an operating system and settings associated with it. Task sequences can be used to control the deployment of an image or create an operating system image from scratch.

NOTE: The next version of BDD will no longer refer to builds; instead it makes the task sequence the center of the image creation process.

So with this in mind I create a build that is used to deploy the master image:

  1. Create a build using the New Build Wizard specifying the operating system image I imported in the previous step.
  2. I then update the task sequence adding the customizations required during deployment such as my SMS GUID reuse script (detailed in a previous post).

TIP: To avoid confusion over the purpose of each build use a naming convention that clearly identifies the builds purpose. For example a build that is used to create a master image could be called “Create-Master Image” and a build used to deploy the image could be called “Deploy-Master Image”.

Deploy the Image

The last thing we need to do is deploy the image we have created. While deployment methods can vary depending on the situation from using SMS to deploying via DVD or directly from BDD itself the overall principles remain the same.

I NEVER deploy an image using the lab deployment point. I always create another deployment point to deploy the image. If I am not using SMS OSD then I will create a Separate deployment point (Network) to deploy the image. This approach allows granular control over the rules used to deploy the image.

I always create a deployment process that is as automated as possible. This is achieved using rules to define values for BDD deployment properties. Where possible I use the BDD Database to define values for properties but I also use UserExit scripts and static assignment when required. Very occasionally I will prompt the user for information if required.

When deploying an image you need to ensure that the correct drivers and applications are applied during deployment. BDD manages the application of drivers for you but extra effort is required to manage hardware specific applications. To address this issue I import each application into the BDD Workbench and then associate it with the appropriate hardware type using the BDD database.

So here are the steps I follow to deploy the image:

  1. Create a Deployment Point to deploy the image
  2. Configure the Deployment Point with the rules required to automate the deployment process
  3. Configure the BDD database
  4. Create a database entry for each model type.
  5. Create a database entry for each computer
  6. Deploy the image.... NICE!

TIP: For further information on rules please refer to my previous post here.

TIP: For further information on prompting users for information during deployment then refer to my previous posts here and here and Johan’s post.

So that is how I create and deploy images using BDD. Low on detail and high on opinion I know, but this is an approach that I have found to be very successful. Hopefully you will be able to use some of these methods to make your deployments equally successful.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.