I have previously mentioned how to create a custom task sequence to save time when testing application installation in BDD 2007.

You will find the article here.

There are two problems you could run into when using this process with Deployment 4.

1. If you create a custom task sequence based on a REPLACE template then it fails saying it cannot find \distribution$\control\ts.xml
2. If you use a different template then I get an error saying you haven’t specified a deploymenttype value.

These problems are caused by checks put in place to verify the type of task sequence being executed. This design essentially means that you cannot use a custom task sequence unless you include an “Install Operating System” task in the task sequence.

Don't worry, there is no need to despair...... I have a solution.

1. Simply add an “Install Operating System” task to your the task sequence and then you can disable it.
2. Never use a Replace template to create your custom task sequence.

The task sequence and the process will then function as it would in BDD 2007.

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.

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:  

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.

Here is a simple tip when using BDD. DO NOT use special characters anywhere. They cause problems.

Let's illustrate this with an example. I create an application with the name "AT&T Dialer". Then when I add this application to the task sequence I see that it is now displayed as "INSTALL-ATT Dialer".

You can also have problems when you use special characters in your password. This causes issues when BDD tries to save the password to the unattend.xml file, causing the build to fail.

So my simple advice is, avoid using special characters as this is save you time trying to debug those "weird" errors.

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.

Well for those of you that have already installed Deployment 4 may have notice that Deployment 4 does not use builds anymore. Task sequences are used instead.

Task sequences are very similar to builds with a few subtle changes.

All of the task sequence configuration information is now maintained within the task sequence itself, NOT in the general and settings tabs settings tab.

So let’s compare builds and task sequences. The screen shots below are from a BDD 2007 build.

So where exactly is this information stored in Deployment 4?

The information is stored with the task that uses it. So for example let’s have a look at the operating system deployment task. As you can see from the screen shot below there is a drop down box that allows you to choose an operating system.

Now let’s look at the disk partitioning task. As you can see below this task allows you to specify the disk configuration in the task itself... NICE ... no more mucking around with diskpart files!!

I really like this new approach to to configuring settings. I think it will prove to be much more flexible than the way builds are configured. 

Unfortunately there is not currently an interface to configure the following operating system configuration settings:

• Admin password
• Product key
• Full name
• Organization
• IE home page
• Unattend/Sysprep file editing

Don’t panic! The Deployment 4 team is working on adding this functionality to the operating system deployment task before it is released. For now you will have to manually update the configuration files. As a teaser I have included a screen shot from an SCCM task sequence to show you the “apply windows settings” task, as this is what the final solution might look like.

For more information about task sequences please have a look at this post by Michael Niehaus.

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.

It looks like the BDD team has been very busy! They have just released Deployment 4 Beta 3 the worthy successor to BDD 2007.

Having spent a reasonable amount of time testing Deployment 4 I must say I am very impressed, particularly when it is combined with SCCM.

So what is it that has impressed me about Deployment 4?

• Support for both desktop and server deployment
• Integration with SCCM - right into the SCCM console itself
• Enables the use of static IP's (very important for server deployment)
• Enhanced disk partitioning support
• Support for multiple task sequences - Templates are included for both client and server deployment
• Builds no longer exist - Everything revolves around the task sequence now!
• Support for multicast deployment when combined with Windows Server 2008
• Support for web service calls as part of the rule processing

These are only a few of the improvements, more detailed information is included in the release notes.

But the thing I like the most about deployment 4 is the subtle changes, those little improvements to the deployment workbench and task sequences that make deployment easier.

While there are significant improvements from BDD 2007 the overall  concepts remain the same. So, you should easily be able to get up to speed.

So go and test it for yourself (particularly with SCCM). I know you will be pleasantly surprised!

Deployment 4 is now available for download now at the following location:

https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=14&DownloadID=8689

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.

Many of my customers have Group Policy settings that are very restrictive and cause problems during operating system deployments. For example the legal notice messages can interrupt an automated logon process.

This can be a real hassle to get around when deploying so to solve the issue the I perform by performing one of the following steps:

1. If the computer is already in the domain - I move the computer to a "Staging OU" that has no group policy settings applied.

2. If the computer is not in the domain - I ensure that the computer will be created in the  "Staging OU".

This process is performed during the State Restore phase from within Windows PE. At the end of the deployment I then run another script that moves the computer to the correct OU, the group policy is applied and everyone is happy. :)

To make this happen I use two scripts:

1. Z-MoveComputer-StagingOU.wsf - This script move the computer to the "Staging OU" and updates the MachineObjectOU property with the "Staging OU" value.

2. Z-MoveComputer-SwapOUValues.wsf - This script runs after BDD has configured the Sysprep or Unattend.xml files, it's purpose to change the MachineObjectOU and  "Staging OU" properties back to their original values.

I have attached the required scripts, to implement the scripts follow the steps detailed below:

Enable ADSI in Windows PE

Windows PE must have ADSI enabled (not officially supported) for these scripts to work, the steps below details how to enable ADSI.

To enable ADSI to in Windows PE 2004/2005 (ZTI Only) you will need to perform the following steps:

1. Update Extra.inf located within the WinPE source directory with the following lines:

                  [ExtraFiles]

                  activeds.tlb = 1,,,,,,,2,0,0,,1,2

                  adsldp.dll = 1,,,,,,,2,0,0,,1,2

2. Update the BDD OSD deployment point creating an updated Windows PE source

3. Import the new Windows PE source into SMS

4. Recreate SMS deployment CD

To enable ADSI in Windows PE 2.0 (LTI) then follow Johan Arwidmark's instructions here.

Update the deployment point rules

1. The following properties to be declared in the deployment point rules. These properties are used to connect to AD and move the computers. The account used must have the rights to create and delete computer objects in the domain:

               DomainAdminDomain
               DomainAdminPassword
               DomainAdmin

2. You also need two new custom properties to be declared in the deployment point rules:

               StagingOU – The full staging OU path, this is in the same format as the MachineObjectOU property.
               DomainDC – The name of a Domain Controller to connect too.

Here is an example CustomSettings.ini file:

               [Settings]
               Priority=Default
               Properties=StagingOU,DomainDC

               [Default]
               StagingOU=OU=Staging,DC=domain,DC=com
               DomainDC=DC01
               DomainAdminUser=Account
               DomainAdminDomain=domain
               DomainAdminPassword=password

Update the scripts folder

Next you must add the scripts to the .\distribution\scripts folder. You will notice that the script names have the prefix "Z-" this is because BDD automatically copies all scripts that start with "Z" from the distribution share to other deployment points when they are updated.

Update the build task sequence

The next thing you do is add the scripts to the build task sequence. I would recommend creating an application for each script that executes a script and then add it to the task sequence as shown below. It is important to note that the "Move Computer" script must be run before the Configure task and the "Revert OU" script must be run after the configure task.

Update your deployment points

Finally you should update your deployment points to so that these changes are propagated to the correct places.

If you want to see how to move the computer to it's final OU (MachineObjectOU) then have a look at this blog post.

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.

When troubleshooting the BDD deployment I often make a change then test. Then find that I need to make another adjustment and test again. Well this this process can be time consuming especially if you have to wait for Windows PE to reboot each time.

Well I have a couple of tips to help speed this process up!

When troubleshooting BDD 2007 deployment issues there is a quick way to restart the deployment process without having to restart the computer. I detail methods for both LTI and ZTI deployments that should save you a lot of time in the deployment process below.

ZTI Deployments

The first thing you need to do is make sure that you have enabled the "Lab Shell". The Lab Shell allows you to start a command prompt from within Windows PE. Once you have enabled the Lab Shell then you can use the methods detailed below once the build process has failed:

       1. Delete the MININT folder - This folder contains information from the previous failed deployment and can cause problems if not removed.

                      rd C:\MININT /q/s

       2. Delete the _SMSTaskSequence - This folder contains information from the previous task sequence and can cause problems if not removed.

                      rd C:\_SMSTaskSequence /q/s

       3. Remove any network connections - SMS will try to reconnect to the distribution point, this process will fail if these connections exist.

                      net use * /d

       4. Restart the build process

                      OSDShell

LTI Deployments

The process to restart an LTI deployment is also very similar to the ZTI process. Once the build process has failed perform the following steps:

       1. When the build process fails you should close the summary window using the window close button in the top left hand corner. Do not use the finish button.

       2. Maximize the command prompt window.

       3. Delete the MININT folder - This folder contains information from the previous failed deployment and can cause problems if not removed.

                      rd C:\MININT /q/s

       4. Delete the _SMSTaskSequence - This folder contains information from the previous task sequence and can cause problems if not removed.

                     rd C:\_SMSTaskSequence /q/s

       5. Remove any network connections - SMS will try to reconnect to the distribution point, this process will fail if these connections exist.

                      net use * /d

       6. Restart the build process

                      X:\Deploy\Scripts\LiteTouch.wsf

Hopefully these tips will help save you time when troubleshooting the BDD deployment process.

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.