Smooth Deployment Wrinkles with ADS

Bill looks at the pros (lots) and cons (few) of Microsoft's Automated Deployment Services tool.

• By Bill Boswell
• March 01, 2005

If your job description includes setting up and configuring servers, you probably spend a considerable amount of time installing operating systems, selecting drivers, fussing with patches, configuring applications, and generally watching the days of your youth expire as you get boxes ready for production. Every week, you perform essentially the same set of steps that take the same number of hours with the same kind of hassles. If you're not allowed to play music in the server room to at least keep your toes tapping, rigor mortis may well set in.

How much simpler it would be to provision one server then use it as a template for all the others. Utilities such as Symantec Ghost and Acronis True Image can image one server's hard drives for later deployment to other servers, but imaging as a deployment tool is risky. Vendors often make small (or what they consider to be small) adjustments to hardware configurations without changing the model number. These differences can cause significant performance and stability issues if you use disk images for server deployments.

The Microsoft-approved method for avoiding hardware-related issues when deploying images involves using the Sysprep utility to remove hardware-specific information from the Registry prior to imaging.

Another alternative for doing a hardware-agnostic server deployment is Remote Installation Services (RIS). RIS uses a file-based image captured with a utility called Riprep that it integrates into an existing repository of installation files for the target platform.

RIS has its place, but it's not the ideal deployment tool. First off, it's time-consuming to capture and deploy RIS images because RIS essentially performs a scripted version of a standard OS installation using file-based images that are difficult, if not impossible, to change. Also, RIS is only useful for deploying the OS. You must install (and learn) some other application to deliver patches and service packs. Finally, RIS requires Active Directory, which means having access to a production domain controller from the setup lab, often a difficult thing to arrange in today's era of tight security.

Microsoft has addressed these and other RIS limitations by releasing a completely separate deployment tool called Automated Deployment Services, or ADS. It carries no license fee and has no client access license requirements. You will need to purchase Windows Server 2003 Enterprise Edition, which has a street price of $2,200, making ADS a somewhat pricey option for smaller organizations.

ADS Advantages
Like RIS, ADS uses the Preboot Execution Environment (PXE) to deliver boot images. For details of how PXE works in a Windows network, take a look at Microsoft Knowledge Base (KB) article 244036.

Using PXE to deploy a boot image is pretty much where the similarity between ADS and RIS ends, however. The chief advantages of using ADS over RIS are:

• ADS captures and distributes sector-based images that can be modified easily by mounting the image as a standard disk volume.
• ADS uses a SQL database (or Microsoft SQL Desktop Engine) to store configuration information, and therefore doesn't require AD or domain authentication. To validate computer identities, ADS uses Secure Sockets Layer (SSL).
• ADS is configured and managed via an MMC console (Figure 1) that gives you access to all services, devices and support files. ADS also comes with a wide variety of command-line tools and a rich set of Windows Management Intstrumentation (WMI) commands that can be used to write automation scripts.
• ADS can image up to 126 target servers simultaneously using multicast.
• Unlike RIS, which can capture and deploy only the operating system partition, ADS can capture and deploy any volume on a server.
• Although not normally an advantage for servers, ADS can image FAT and FAT32 volumes along with NTFS.

Figure 1. The ADS Management console includes a number of templates that make automating server deployments easier. (Click image to view larger version.)

In addition to its deployment-related features, ADS can send scripts and executables to managed servers where they run locally. The results are returned to the ADS server for review. This makes ADS a nifty platform for centralizing server management.

Although ADS was designed to deploy Windows server OSes, there are no blocks against using it to deploy Windows 2000 Professional and XP. This isn't specifically supported, however, meaning that Microsoft Product Support Services (PSS) has no obligation to help you if you encounter a problem.

ADS Process Overview
The most difficult part of installing and configuring ADS is getting accustomed to the complex interdependencies of the various components. ADS uses three server-based components plus a client component:

• ADS Controller Service: Validates the identity of a managed device, sends commands to the device, accepts requests from the device and orchestrates image delivery to the device.
• Network Boot Service: Listens for managed ADS devices as they come onto the network via PXE boot and delivers boot images to the devices. The boot images contain a Deployment Agent that can communicate with the ADS Controller.
• Image Distribution Service: Captures an image, stores the image file and delivers the image to managed devices.
• ADS Administration Agent: Client-based component that runs on a managed device and engages in SSL communication with the ADS Controller.

In a small data center, you would install all three server-based components onto a single physical server. If you want to deploy a large number of servers, you may want to put the Image Distribution Service on separate hardware to improve performance.

Image Deployment Overview
Configuring ADS is a little like preparing to teach a roomful of 14-year-olds: The secret to success is getting their attention early, then delivering the absolute minimum required information using terms they're willing to acknowledge.

ADS first gets the attention of a newly installed device during a PXE boot. Once the device has downloaded a boot image, the ADS Controller sends the device commands that tell it to partition and format hard drives, apply images from the Image Distribution Service, modify the Registry, run scripts and so on.

The ADS Controller stores these commands in a set of sequence files. Sequence files are XML files, so you can use Notepad, gvim (www.vim.org) or some other text editor to modify them. However, ADS comes with a GUI utility called a Sequence Editor that displays the XML content as fields in a form, and shows the actual XML content. Figure 2 on shows an example.

Figure 2. The ADS Sequence Editor, here showing the contents of the Reboot sequence file, displays XML content in an easily readable format. (Click image to view larger version.)

A standard image deployment using ADS involves these major steps:

1. A PXE device gets an IP address from a DHCP server and then requests a boot image from the Network Boot Service (NBS).

2. The NBS determines the device's identity via a Globally Unique Identifier (GUID) included in the DHCP discovery packet. It verifies with the ADS Controller service that the device is managed by ADS; that is, that the GUID is in the ADS database.

3. The NBS delivers a boot image to the managed device.

4. The device executes the image and displays the result on the console.

5. The device establishes a connection to the ADS Controller, which instructs the device to partition a boot drive and download an image from the Image Distribution Service (IDS).

6. The device contacts the IDS and downloads a sector-based image captured from a master device. The image was prepared using Sysprep.

7. The device applies the image to the partitioned drive then asks the ADS Controller for more instructions.

8. The ADS controller instructs the device to assign values to certain entries in the Sysprep.inf file and the Registry then restarts to complete the mini-setup.

9. The device is now a full-fledged server with its own name domain identity.

ADS Drawbacks
ADS is a great way to provision new servers and manage existing ones, but it does have some rough spots. For example, Sysprep isn't the ideal method for preparing a server for imaging. OEM vendors get to use a much better tool called WinPE, which is currently available only to registered system builders. The next version of ADS, due out either as a revision to the current downloadable version or as part of Windows Server 2003 R2, will contain a derivative of WinPE for preparing images. The next version will also have better reporting features.

Even with its limitations, ADS is a great way to deploy servers and well worth your time to evaluate. If you have questions, feel free to e-mail me.