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.
Installing BDD is very simple, the steps I follow are listed below:
TIP - Make sure you are using BDD patch 1 as this includes a number of fixes.
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:
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:
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”.
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.
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.
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.
Once the deployment point is configured we can capture the image.
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)
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:
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”.
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:
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.
Good information. I do just about the same process. One thing I like that you do is the 'Image Creation Build' and 'Image Deployment Build' names that you mentioned. I always strugle with naming my build so they make sense, and doing something like this will probably help a lot.
A very good blog post that points out potential pitfalls and a little bit of 'best practice' advice for deployments. Very handy to keep bookmarked for anyone just learning how to use BDD or for the seasoned veteran that is looking for some helpful tips
This type of summary is sorely needed in the BDD documentation. It takes a lot of reading to get to the point of coming up with this fairly simple sequence!
Fantastic blog! I am just learning BDD 2007 and it has given me some good tips. One question I have is, how do I perform a bulk import of all the Windows XP update patches into the work bench? We have WSUS on the networks we are dploying to, but I would rather the latest patchs were slipped into the Image creation installation. Is this best practise?
You cannot import XP patches into the workbench. You can import Vista patches however. What I do to get around this problem is download all of the patches required for the build and then install them via vbscript. I then import these files as an application specifying the script to install the patches. I then add the application to the state restore phase.
Thanks for this summary. I have configured the lab deployment point successfully, but I am running into an issue with the network deployment point on a different server. Everthing is synchronized properly, I added the DeployRoot=\\server\share to the Bootstrap.ini and Rules, but I am still unable to image properly.
The system boots to PE, runs the rule set correctly, adds the drivers, but then fails applying the WIM. The error is:
ERROR-Unable to find SETUP, needed to install the image \\server\share\Operating Systems\folder\image.wim
ZTI ERROR - Non-zero return code by LTIApply. rc=1
Non-zero return code executing command "X:\Deploy\Tools\X86\Tsmbootstrap.exe" /envAStart, rc=-2147467259
When you import a custom WIM you are given the option to include the setup files. If these files are not specified and there are no Vista source files on the LAB deployment point then the build will fail.
So reimport you image and when asked provide the vista setup files and everything should work.
Thank you, that resolved it.
I used the original Vista DVD for the setup file location. I then updated my deployment share and it worked great.
just would like to ask that what's the use of "LT flat boot" "LT bootable ramdisk" iso?
I first thought that the flat image does require less memory, but still doesn't work with 256MB.
thank you very much
The flat image does require less memory than the RAM disk but 256 is not quite enough.
I can apply an image to a PC just fine, but when we try to image over that image again, I get the following error:
ZTI ERROR - Non-zero return code by LiteTouch. rc=1
This could mean many different things. Could you send me a copy of the entire log.
My email is ben dot hunter at microsoft dot com.
I created a WIM via ImageX. I usually run sysprep before I capture an image with ImageX.
This time I want to try something different.
I want to try sysprepping my image after BDD has installed it.
How could I do this? Should I put it in the BDD Task Sequence: "State Restore"?
I do not want to do any capturing! I just want to lay down the image and THEN sysprep.
BDD will handle this automatically. Try adding the following lines to your customsettings.ini file:
You can also specify this information via the wizard.
Thanks for your help. I wanted to see if you knew of a way to sysprep without doing a capture.
Is there any way with BDD to install an image, then sysprep without capturing?