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.