Simple, Scalable Deployment with BDD 2007
At a Glance:
- Core capabilities of BDD 2007
- Integrating with SQL Server
- Building a scalable deployment solution
Most people involved in deploying Windows have heard of the Microsoft Solution Accelerator for Business Desktop Deployment. Also known as BDD, it is a set of best practices guidance and
tools developed to help you deploy Windows® to client desktops. Windows Vista® includes an update to the Solution Accelerator in the form of BDD 2007. This version contains a new Microsoft® Management Console (MMC) and a task sequencer that originates from System Center Configuration Manager 2007, the successor to Systems Management Server (SMS) 2003.
One of the less understood features of BDD 2007 is its ability to function as a full deployment solution. In previous versions, BDD could help you create and maintain desktop images in a manageable and repeatable way. BDD 2007 now gives you the additional capability to build a scalable deployment solution by combining BDD with Windows Deployment Services (WDS), SQL ServerTM, and the Windows Server® 2003 Distributed File System Replication (DFS-R) .
But wait ... isn't using SMS 2003 with the Operating System Deployment (OSD) Feature Pack the recommended practice for Windows client deployment?
Yes, if you already have an SMS 2003 infrastructure, you should work towards using BDD 2007, SMS 2003, and the OSD Feature Pack for deployment. This is currently the most comprehensive way to achieve zero-touch deployment, and it can really drive down the costs of configuring, installing, and managing Windows in your organization.
However, many customers don't have SMS 2003 or any equivalent software deployment solution. For these customers, there is another option that I'll focus on in this article.
BDD 2007 Core Concepts
BDD 2007 offers two main methods of deployment. The first method, Lite Touch Installation, uses just BDD 2007 for deployment of the client. Out of the box this presents a set of wizards at build time to capture information about the deployment, such as what computer name should be assigned to the client (see Figure 1), what keyboard layout and time zone should be used, and so on. This method is referred to as "Lite Touch" because there's usually a minimal amount of manual input required to collect this information before the build process starts.
Figure 1 BDD 2007 Lite Touch Deployment Wizard (Click the image for a larger view)
The second method, Zero Touch Installation, builds on the capabilities of SMS 2003 with the OSD Feature Pack by integrating with BDD 2007. This configuration can provide a completely automated, scalable, and manageable hands-off deployment solution.
At build time, in one of the first steps of a client OS deployment, BDD 2007 gathers information from a variety of different sources. These sources include WMI calls and the BDD 2007 configuration files—Bootstrap.ini and CustomSettings.ini. The information is collected and stored as variables that are used throughout the deployment. For a Lite Touch scenario, the Bootstrap.ini and CustomSettings.ini files provide the ability to predefine all of the information that would otherwise be collected by manual input into the deployment wizards.
The ability to specify in advance all of the information that the Lite Touch wizards would otherwise need to capture at build time allows you to automate the entire Lite Touch process and move towards a Zero Touch solution in those environments not supported by SMS 2003. Examples of the information you might choose to predefine include ComputerName=RDG0001VST to assign the computer a name of RDG0001VDT or TimeZoneName=GMT Standard Time to ensure the computer time zone is set to Greenwich Mean Time. All of the available properties that can be used during a deployment with BDD are well documented in a configuration reference available at tech-net.microsoft.com/library/bb490302.aspx
For more on setting up and using BDD 2007, see the article "Deploying Windows Vista with BDD 2007" in the September 2007 issue of TechNet Magazine
BDD and SQL Server
Why use a database with BDD 2007? The answer lies in how you dynamically provide details during a deployment that you would otherwise have to manually input through the Lite Touch Installation wizards. As I noted, this can be achieved using the CustomSettings.ini file. The problem is that in a real-world deployment these details are going to change depending on which machine you're deploying to. Also, the CustomSettings.ini file can quickly become unmanageable if you're trying to define specific options and settings for 500 different machines. By attaching a back-end database to the BDD console, you add a much more manageable solution that's both dynamic and extensible.
Let's talk a little bit more about how SQL Server integrates with BDD 2007. First, you need to make sure SQL Server (preferably SQL Server 2005 or later) is installed on your deployment server. Thankfully, the steps to create the database in BDD 2007 are easy: you simply right-click on the Database node in the BDD 2007 Deployment Workbench, click New, and follow the instructions (see Figure 2). The BDD team has done a great job providing wizards that allow you to quickly and easily get up and running.
Figure 2 Deployment database configuration for BDD 2007 (Click the image for a larger view)
Once the database has been created, you can start exploring its capabilities. Entries in the database are split into four main categories: Computer, Role, Location, and Make and Model. Each category lets you define entries and, for each entry you define, populate with BDD 2007 variables, assign applications, and supply other key settings (see Figure 3).
Figure 3 Assigning deployment properties (Click the image for a larger view)
It's useful to look at these four categories in two distinct groups. The Computer, Location, and Make and Model categories give you different methods of identifying a computer at build time. Each identified computer can then be associated with a specific Role in the database so it is provisioned for a specific purpose, such as a sales, marketing or finance, with each role ensuring the relevant line of business applications are installed.
Use the Computer section to identify machines by using a MAC address, asset tag, universal unique identifier (UUID), or serial number. Because of the large number of entries likely to be created in this section, one for each computer in your organization, only add very specific properties such as ComputerName into each entry.
Use the Location section to create entries for specific geographical locations around your organization. Each entry is identified by the default gateway at that location. This can be especially useful if you have location-based organizational units (OUs) in Active Directory® and you want computers built at a location to be added to the domain in the OU that corresponds with that location.
Use the Make and Model section to create entries for each of the hardware types that your deployment must support. BDD 2007 matches these with information discovered through WMI calls. A common usage of the Make and Model section in development environments is to create an entry that looks to see whether the machine is a Virtual PC 2007 or Virtual Server 2005 virtual machine by checking for "Microsoft Corporation" and "Virtual Machine" Make and Model properties, respectively. If at build time you match these properties, you can tell BDD that it needs to install the Virtual Machine Additions application at deployment time simply by adding the application to the Make and Model entry.
Now that you've provided methods of identifying the machines, use the Roles section to create the entries for each deployment role you want to provision. Examples might include an entry for a Windows XP role and a Windows Vista role configured by adding the BuildID property that corresponds to the Windows XP or Windows Vista build defined in BDD to each entry. An alternative approach is to specify departmental roles such as Accounting, Sales, or Finance. I tend to populate the majority of the BDD properties in this section (time zone, regional settings, organizational information, and so on). This offers the minimum administration of the database because of the fact that the entries are not tied to any specific machine, hardware, or location.
We need to tell BDD 2007 that it should search the database at deployment time for any entries that match the computer it's currently building. To configure BDD to use the database during a deployment, right-click on your deployment point and click Configure DB. This takes you through a series of wizards that populate the CustomSettings.ini file with the entries that cause the Lite Touch Installation process to query the database for information.
Making Your Deployment Scalable
Now you have a deployment server that can automate the Lite Touch Installation and dynamically provision each machine to function in a specific business role. But how can you scale this solution?
The architecture of the solution is based around a hub-and-spoke topology as illustrated in Figure 4. The first deployment server that you set up will be the hub and the parent deployment server. Each of the child deployment servers will act as spokes.
Figure 4 Hub-and-spoke deployment architecture (Click the image for a larger view)
To enable this architecture, you need to use DFS-R to replicate the Distribution share to each of your deployment servers. Then use SQL Server snapshot replication to provision a copy of the BDD deployment database to each of the child deployment servers. The great thing about this solution is that the child deployment servers have minimal requirements—you only need SQL Server Express, WDS, and DFS-R installed on each machine to enable deployment.
Because of the large amounts of data that can be stored in the BDD 2007 Distribution share, I stipulate using DFS-R in Windows Server 2003 R2 instead of the File Replication Services in earlier version of Windows Server. DFS-R uses Remote Differential Compression (RDC) to only replicate differential (delta) changes of files between members of the replication group. This can have a big impact on the amount of replication traffic when a small change such as a new driver is made to your custom image file. With DFS-R, the replication traffic equates only to the size of the changes made instead of redistributing the entire image file.
There's a wealth of information about DFS on the Microsoft Web site—start by checking out microsoft.com/windowsserver2003/technologies/storage/dfs
—but I'll cover the basic setup and configuration steps required to give an overview of the process in the context of BDD-based deployment.
Note that if your servers have been running Active Directory based on an installation of Windows Server 2003 prior to R2, the Active Directory schema may need to be updated to allow for DFS-R as the replication service requires new object classes. For full details on extending the Active Directory schema in Windows Server 2003 R2 see go.microsoft.com/fwlink/?LinkId=99936
The first step is to install the DFS components onto your Windows Server 2003 R2 deployment server. You can do this in multiple ways, one of the simplest being the standard Add/Remove Windows Components wizard. Once that's done, you need to set up a replication group using the DFS Management console shown in Figure 5.
Figure 5 DFS Management console (Click the image for a larger view)
To scale out your BDD 2007 deployment solution, there are two specific folders that need to be replicated. The first of these is the BDD 2007 distribution share that holds all of the BDD source and configuration files. These files need to be available on each deployment server.
The second folder to replicate is the Boot folder that WDS uses to hold the LiteTouch_x86.wim file. This is the BDD boot environment that is delivered by WDS to your desktop client machines to start the deployment process. You need to replicate this file so that when a change is made to the boot environment on your parent deployment server, the changes get replicated around to the rest of the deployment infrastructure.
The paths to be replicated are X:\Distribution (where X is the drive letter you specify at BDD 2007 install time) and Y:\RemoteInstall\boot (where Y is the drive letter of the volume holding the WDS RemoteInstall share).
Replication in DFS-R is multi-master and therefore it is not possible to create a one-way replication topology. For this reason, to allow for centralized management of the distribution share, configure the distribution folder on each of your child deployment servers to be read-only. This allows only DFS-R replication to write into the folder (as it uses backup and restore rights). The client machines building from these child servers will never need to write into this folder, so there's no need to grant any accounts higher than read permissions.
The final configuration step to complete replication of data using DFS-R is to set the Boot Configuration Data (BCD) store refresh policy in WDS. This ensures that any changes made to your boot environment get reflected on each of the child deployment servers. This configuration change has to be set on all WDS servers, and I recommend building this into your build and configuration process for the provisioning of a deployment server.
At each deployment server, run the following command:
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
The time refresh period depends on how often you are refreshing the data on the deployment servers. If you're configuring DFS-R to replicate every hour, it makes sense to configure the BCD store refresh policy to refresh every 60 minutes.
SQL Server Replication
So far you've scaled out BDD 2007 to replicate the BDD distribution share and the WDS boot image from your primary deployment server to each of your child deployment servers. You now need to complete the process and replicate the BDD 2007 Deployment Workbench database so that it is available locally at each deployment server.
SQL Server uses a replication methodology that the product documentation describes as not dissimilar to the way magazines are published. With a magazine, there is a publisher who produces the magazine, distributors that distribute the magazine for the publisher, and subscribers who subscribe to and receive the magazine. SQL Server uses this same terminology for its built-in replication capabilities.
Note that, in order to be a SQL Server database publisher, the server cannot be running SQL Server Express Edition; it must be using a full version of SQL Server. For the primary deployment server, I use SQL Server 2005 (though SQL Server 2000 is supported, too). For each child deployment server, you can use either SQL Server 2005 or SQL Server 2005 Express.
Before you start configuring SQL Server replication, there are a few steps you should complete to ensure SQL Server is set up correctly to support replication. When provisioning your deployment servers, make sure that the Replication Components are included during the installation of SQL Server 2005 or SQL Server 2005 Express Edition. By default, SQL Server Express does not install Replication Components.
Next, allowing the Lite Touch boot environment to connect to SQL Server remotely requires that remote connections are enabled in SQL Server. To configure SQL Server for remote connections, launch the SQL Server Surface Area Configuration tool, select Surface Area Configuration for Services and Connections, and configure the server to accept both local and remote connections from TCP/IP and named pipes.
Then, on the primary deployment server, create a shared folder to hold the replication snapshot data that the replication agents on each child deployment server will read from. I'll be referring to this shared folder later on. I usually put this folder on the same volume as the rest of my deployment content.
The final setup steps are required only for SQL Server Express Edition on your child deployment servers. By default, the SQL Server Browser service is disabled. To allow replication, this service must be set to automatic and started. Use the SQL Server Configuration Manager tool to configure this service. You also need to create a database on the child servers that you will replicate the content into. Keep this database name the same as the name of your BDD 2007 database on the primary deployment server as it minimizes the additional configuration required.
Setting Up Replication
You're now ready to configure SQL Server replication. To get started, on the master deployment server, which should be running the full version of SQL Server 2005, launch SQL Server Management Studio. The first step is to create and configure a distribution. To do this, navigate to the Replication folder of the management console as shown in Figure 6. Right-click the Replication folder and select Configure Distribution to launch the distribution wizard.
Figure 6 SQL Server Management Server: Replication (Click the image for a larger view)
In the wizard, confirm that the primary deployment server should act as its own distributor. Set the root snapshot folder to be the UNC path of the SQL Server replication share that was created earlier. Finally, set the primary deployment server to be configured as a publisher.
When this wizard has successfully configured the server as a publisher and distributor, you need to tell SQL Server which database you want to be published. To do this, right-click the Replication folder and click Publisher Properties. In the properties dialog box, select Publication Databases and choose your BDD 2007 database for transactional replication as shown in Figure 7. Now you're not actually using transactional replication, but this same option is selected whether your intention is snapshot or transactional replication.
Figure 7 Publishing your database (Click the image for a larger view)
You now need to create a publication that your child deployment servers can subscribe to. In the Replication Folder, right-click on Local Publications and click New publication to launch the publication wizard. Select the BDD database as the database to be published. Select Snapshot replication as the publication type, and specify all tables, stored procedures, and views to be replicated. You should elect to have an initial snapshot created immediately. For scheduling the snapshot agent, it should be more than sufficient for this to run once a day by default unless you anticipate making frequent changes to the database.
The final step is to subscribe each of your child deployment servers to this publication. This tells SQL Server to push a copy of the database out at specified intervals to each child deployment server. In the Replication folder, under the Local Publications subfolder, locate the publication that was just created, right-click on it, and select New subscriptions to launch the subscriptions wizard. In this wizard, select the BDD publication created in the previous steps as the chosen publication. Choose to run all agents at the distribution, enabling the replication topology as a push subscription. Then add each child deployment server as a subscriber and nominate the database that you have created on each server to receive the copy of the replicated data (remember, this database should be named the same as the primary deployment database). Finally, configure an account to be used for the connections and define the schedule to be used for the replication. This should mirror the schedule you've chosen for the snapshot agent. That's a whirlwind tour of what you need to get up and running for SQL Server replication. You should start to see your data being replicated around in no time at all!
Configuring BDD 2007
So far you've configured BDD 2007 to use a database and set up replication of the database and BDD 2007 distribution share to your child deployment servers. To complete the deployment solution you need to configure BDD 2007 so that, when a client downloads the BDD boot environment, it automatically connects to whichever server is its local deployment server.
When you boot into the Lite Touch Windows PE environment, if the client has booted from a WDS server, a registry value is set in Windows PE that stores the name of the server that the client has just downloaded the boot environment from. The initial BDD 2007 deployment scripts pick up this value and store it in an environment variable called %WDSServer%.
Note that, if you're using the initial BDD 2007 release, you may find that this value isn't populated properly in the Windows PE registry. An update to fix this behavior is available from support.microsoft.com/kb/937191
To configure BDD 2007, just edit the BootStrap.ini and CustomSettings.ini configuration files so that any references to the deployment server are replaced with %WDSServer%. This usually involves replacing the values for the SQL Server instance name along with the value of DeploymentRoot, the server that holds the distribution share. A sample Bootstrap.ini and an excerpt from a CustomSettings.ini file are shown in Figure 8 and Figure 9.
Figure 9 CustomSettings.ini
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Parameters=UUID, AssetTag, SerialNumber, MacAddress
Parameters=UUID, AssetTag, SerialNumber, MacAddress
Figure 8 Bootstrap.ini
Note that this solution stipulates having WDS on the same server that stores the BDD 2007 replicated database and the BDD 2007 replicated distribution share. The reasons should be apparent: it enables you to use the %WDSServer% variable to provide a simple failsafe method to tell your client machine where its local deployment server is and prevent it from talking back across the WAN.
The great thing about BDD 2007 is that it's extensible, so there are many more aspects that can be considered for extending this solution. For example, you could use the built-in capabilities for monitoring SQL Server and DFS-R, designing methods for populating the computers in your environment with information from an asset management database, or even using a SQL stored procedure to retrieve such information. Unfortunately, I don't have the space to cover these here, but hopefully I've given you a glimpse of some ways you can harness BDD's capabilities inside your own organization.
Adam Shepherd is a consultant working for Microsoft Consulting Services in the UK. Adam's technical focus is on deploying, maintaining, and managing the Windows Client. You can reach Adam at firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited