Deployment

Make Server Rollouts a Snap with Automated Deployment Services

John Savill

At a Glance:

• Making machine images
• Deploying servers
• Making backups for DR
• Other uses for ADS

It's easy in small environments to assume that you don't need to automate the deployment of servers. After all, the up-front effort to create the infrastructure and images for deployment without

intervention may not be easy to justify. But you don't need hundreds of servers for automated deployment to be worthwhile. The benefits of standardized builds, fast rebuild times, and consistent supportability can be compelling—even in small environments. Convinced? Great. Now let's look at how you can deploy servers automatically.

You might first think of the Operating System Deployment (OSD) Feature Pack for SMS, which is not, strictly speaking, a desktop deployment technology. Indeed, if you look at some of its dialog boxes, you'll notice provisions for licensing options, number of seats, and so forth. So, can you use OSD to deploy your servers and have a single deployment infrastructure? It depends on your server hardware. OSD deploys by booting to Windows® PE (Preinstallation Environment), which in the current version of OSD is based on the Windows XP operating system. This fact represents the first challenge. Windows XP lacks the drivers necessary for many servers to function, and while it sometimes may be possible to inject them into Windows XP, they may not function correctly if at all. A better option, Automated Deployment Services (ADS), has superior driver management compared to OSD, full server driver support, and support for deployment to partitions other than the C: drive (which is an OSD limitation).

There are other reasons to choose ADS. In most scenarios new servers require flashing (updating) the BIOS or configuring a RAID or SAN controller, which is often accomplished via MS-DOS® on a floppy disk. If you have to manually perform these floppy-style configurations, it's not exactly an automated deployment. OSD has no ability to virtualize an MS-DOS-type floppy disk, while ADS can capture the floppy content and required actions and send them over the network to enable a total hands-off deployment.

Furthermore, OSD doesn't really handle complicated multi-NIC configurations, while ADS has full support built in. In the end, OSD may be able to deploy a server operating system, but ADS is designed for it. When Windows Vista™ and Windows Deployment Services arrive we'll see a merging of these technologies, but for now ADS is the way to go.

Inside ADS

ADS is essentially a sector-based imaging technology, similar in many ways to other third-party imaging tools with which you may be familiar. Where ADS differs, though, is in its ability to understand the NTFS file system structure, remove duplicate and unnecessary files (such as page and hibernation files), and perform other optimizing techniques prior to image deployment. (Note, however, that this imaging technology is not the one used in Windows Vista; ADS uses a different technology.)

Another key feature of ADS is multicast support, which allows you to deploy up to 128 machines concurrently through one set of network traffic. In addition, highly configurable task sequences allow granular configuration and full system build-out. Plus ADS can mount captured images and modify content if required.

ADS can be used only for the deployment of 32-bit server operating systems, Windows 2000, or above. Deploying client operating systems such as Windows 2000 Professional or Windows XP is not supported. The ADS server component will run only on Windows Server® 2003 Enterprise edition or above. You can download it from go.microsoft.com/fwlink/?LinkId=71491. At press time, the current version is 1.1 (improvements from version 1.0 include support for booting to Windows PE via a new repository in ADS for the storage of PE environments).

ADS consists of three core services, though it also requires DHCP to be running to enable IP address allocation to servers.

The controller service is the core of ADS, performing all communication with the database. (The database type, either SQL Server™ or an MSDE instance, is selected at ADS installation; the controller provides the information to the other services.) It is through the controller service that administration inputs such as the Microsoft® Management Console (MMC) snap-in, Windows Management Instrumentation (WMI) interface, and command-line tools function. The controller maintains the records for each ADS device (a server, typically identified by its MAC address but possibly by its SMBIOS GUID). During the build process, the controller service instructs the pre-boot execution environment (PXE) component with the boot commands/images to provide to the device at each stage in the deployment process.

The controller service lets you group servers into sets, allowing them to be managed as a single entity (for deployment and post-deployment administrative functions). You can also have set references from other sets, forming a hierarchy.

The Network Boot Service (NBS) works with the DHCP service to enable the PXE client to find the NBS server. DHCP does not have to be running on the ADS server itself, but it can. NBS includes the PXE service and the ADS deployment agent builder. The PXE service can instruct the PXE client on target servers to download and boot an ADS deployment agent, boot to Windows PE (if configured), boot a virtual floppy disk, or just boot from the hard disk. Using instructions from the controller service, the NBS is mainly responsible for the building of the remote servers. Data is transferred using the built-in Trivial File Transfer Protocol (TFTP) service.

Image Distribution Service manages the storage of the operating system images.

ADS Agents

ADS supplies two agents for managing deployment. The deployment agent mentioned earlier is essentially a RAM-based mini-operating system that ADS uses to boot servers to when it needs to capture or deploy an operating system, partition disks, or perform certain other tasks. Additionally, an administration agent is installed on the reference server as a service before image capture. It allows the ADS server to manage deployed servers via various command and scripting engines, giving ADS capabilities not only to deploy the operating system but also to manage deployed servers. For example, servers can be placed into groups and then actions or commands can be performed on the entire group.

Task Sequences

At the heart of ADS is a powerful, XML-based format that allows sequences of tasks or steps to be defined and executed in order. These task sequences are stored in XML files, which gives ADS its ability to go beyond simple image deployment. Image deployment is one task in the sequence, but before you deploy an image you can send a virtual floppy to flash the BIOS, then another to configure a SAN controller, then wipe all partitions and create several in its place. You can also deploy images to separate partitions, perform changes to the file system, and once the deployed operating system is booted you can run any other number of other commands to customize the environment.

Creating a Reference Machine

The first task after downloading and installing ADS is to prepare the reference server, which will form the foundation of the image that will be deployed to the target servers. Since this machine will be the source for deployed servers, the size of its boot drive (C:) will become the minimum size of any deployed server. Thus, when you are preparing your reference machine, make its C: drive as small as possible; it only needs to be able to hold the operating system, the ADS Administration Agent, Sysprep, and any other applications or tools you decide need to be part of the image. Remember that any applications installed as part of the image must be fully Sysprep-compliant.

When the reference machine is ready, install the ADS Administration Agent, which allows the ADS server to perform the tasks defined in the task sequence and ultimately capture the reference machine. To install this agent, run the adssetup.exe you used to install the ADS services on the ADS server, choosing "Install ADS Administration Agent". During installation, you must pass the location of the certificate the ADS server created during installation. This certificate is used to secure communication between the device and the ADS server; you can copy it locally or specify a UNC path. You'll be asked for credentials for the administration agent, which can be the LocalSystem account or a domain account if various types of network resource access will be required. Note that manually installing the ADS Administration Agent on the reference machine is necessary to enable the ADS server to control it.

Finally, create a Sysprep folder on the root of the C: drive with an i386 subfolder underneath, then copy into it sysprep.exe and setupcl.exe from the deployment tools that match the operating system (and the service pack version) installed on the reference machine. You must also place a sysprep.inf (based on one of the four templates provided with ADS in the samples\Sysprep folder) in the Sysprep folder (not the i386 subfolder). Templates are provided for Windows 2000 Server and Windows Server 2003, one each for a workgroup member and a domain member. You can customize these templates to suit your business and technical requirements. Take note of the "^variable^" entries in the file. These variables will be replaced with values for the actual device during deployment, giving you customization of the target server beyond that defined in the captured image. For example, the default Windows Server 2003 domain Sysprep template includes entries for items such as computer name, product key, and domain. Figure 1 illustrates.

Figure 1 Sysprep Template Entries

;SetupMgrTag
[Unattended]
    OemSkipEula=Yes
    InstallFilesPath=C:\sysprep\i386
    TargetPath=\WINDOWS

[GuiUnattended]
    AdminPassword=^ADMINPASSWORD^
    EncryptedAdminPassword=NO
    OEMSkipRegional=1
    OEMDuplicatorstring=sysprep-id
    TimeZone=4
    OemSkipWelcome=1

[UserData]
    FullName="ADS"
    OrgName="Microsoft"
    ComputerName=^ADS_COMPUTER_NAME^
    ProductKey=^ADS_WINDOWS_PRODUCT_KEY^

Capture the Image

After preparing a reference machine, the next step is to capture it. First, add the machine as a device. Without this step, the machine won't get past the stage of getting addresses from DHCP when it attempts to boot from the network and you'll have no way to send a task sequence to enable actions to be performed. You add the device via the ADS Management MMC snap-in that is part of the "Microsoft ADS" program group. Right-click Devices and select "Add Device...". After you enter a name for the server, a description, and its MAC address (or SMBIOS GUID), click OK, and close the dialog.

Right-clicking on a device brings up various context-sensitive options that will vary depending on the state of the device. Since this is a new device, the first action is to "Take control," which, if successful, will switch the status to Yes for Control. The device is now ready to accept commands that will allow us to perform the capture.

Now you need to create a task sequence that will run Sysprep, reboot the server to the deployment agent, and capture the C: drive to an image with the name of your choice. Under the samples\Sequences folder you'll find a number of templates. In this example I'll use capture-image.xml and tweak it slightly as needed. I'll leave the first two steps in the template alone—they just run Sysprep and boot to the deployment agent. In the third step I'll set a real name for the image and a description, as shown in Figure 2.

Figure 2 Giving the Image a Real Name

<!-- start sequence -->

<sequence command="capture-image.xml" description="capture image"
     xmlns="https://schemas.microsoft.com/ads/2003/sequence" version="1">

    <!-- STEP 1 sysprep step -->
    <task doesReboot="true" description="sysprep target">
        <command>c:\sysprep\i386\sysprep.exe</command>
        <parameters>
            <parameter>-quiet</parameter>
            <parameter>-reseal</parameter>
            <parameter>-reboot</parameter>
        </parameters>
    </task>

    <!-- STEP 2 boot to deployment agent -->
    <task description="Boot to deployment agent">
        <command>/pxe/boot-da</command>
    </task>

    <!-- STEP 3 capture image -->
    <task description="Capture image">
        <command>/imaging/imgbmdeploy.exe</command>
        <parameters>
            <parameter>Win2003EntSP1</parameter>        <!-- name of the image  -->
            <parameter>\device\harddisk0\partition1</parameter> 
            <parameter>"Windows 2003 Ent SP1"</parameter>    <!-- image description -->
            <parameter>-c</parameter>                   <!-- specifies capture mode  -->
            <parameter>-client</parameter>              <!-- required parameter  -->
        </parameters>                                            
    </task>
</sequence>

You can now initiate the task sequence, but first make sure the server boot priority is configured to attempt to boot from the network first (prior to the hard drive). Otherwise get ready to manually force a network boot when the reference service shuts down after Sysprep execution. To initiate the capture task:

1. Right-click on the device and select "Run job...", then click Next.
2. From the job type options select "Create a one-time job" and click Next.
3. Enter a description, for example "Capture reference server 2003", and click Next. A list of command types will be displayed, select "Task sequence", and click Next.
4. Select the name of your customized task sequence (see Figure 3), and click Next. Then click Finish and the job will begin.

Figure 3** Always Use a Custom Task Sequence **(Click the image for a larger view)

The device's state will change to Busy and a new entry will be added to the Running Jobs branch of the ADS Management snap-in, which, when selected, will give detail about the exact stage of the job process. You'll notice in Figure 4 that the Sysprep target and boot to deployment agent tasks have completed successfully and the actual image capture is in progress.

Figure 4** Detailed Status of the Selected Job **(Click the image for a larger view)

Once Sysprep has executed, the server will reboot, booting to the ADS deployment agent, and the capture process will execute, as shown in Figure 5.

Figure 5** Booting to the ADS Deployment Agent **(Click the image for a larger view)

The commands are executed as defined in the XML task sequence file, which in this case is running the imgbmdeploy.exe tool. Upon completion, the reference machine stays booted to the deployment agent, awaiting further action. At this point, you can instruct it to shut down from the ADS server or just manually cycle it, and then either deploy an image to it to test what you've captured (a good idea) or perhaps rebuild another flavor of server to form the basis of another image. The new image will show up under the Images branch of the ADS Management snap-in, and there will be a file created in the ADS Images folder (by default the root of the C:\ drive) named with the GUID of the capture. You can find it by looking at the image entry in the ADS Management snap-in.

Deploying the Image

Some of my clients use ADS to capture a server for basic disaster recovery and restoration. If you perform a typical capture without the Sysprep stage, you boot to the deployment agent and capture the disk. Doing this every couple of weeks is a very fast way to create an image for restoring the server in the event of a disaster. However, capturing machine images is not the goal of this process; the goal is to simplify deployment, so let's deploy a server.

Deployment is actually quite simple once the task sequence is created. Just as with a capture, you must create a device for the server to be deployed. The device will have unique variables defined by the administrator and they will be used to populate the placeholders in the sysprep.inf file. You configure the device to boot to the deployment agent and then run a deployment task sequence. It's easy.

Once you've created the device, open its properties and define the variables needed to complete its Sysprep population. The exact variables will depend on the Sysprep modifications made, the sample used, and the task sequence mapping. However, if you used the Windows Server 2003 domain sysprep.inf sample and your task sequence on the domain deployment (da-deploy-image-domain.xml), you'll need the variables as shown in Figure 6. Note that these names don't match those that were in the sysprep.inf. Don't worry; the task sequence for the deployment has a "Customize sysprep.inf" stage that shows which variable from the device it will place in the sysprep.inf placeholder.

Figure 6** The Device's User Variables **(Click the image for a larger view)

The next step is to create the task sequence. I'll use da-deploy-image-domain.xml as the basis for the deployment. After you customize your file, save and name it based on its content, (like deploy-2003entserver.xml) for easier management in the future. Not much customization is required in this case, but let's walk through the main steps.

First, the bmpart.exe utility is called to delete all existing partitions and create a single 5GB partition that will become the C: drive. You can customize this to create additional partitions of varying sizes but remember, the first partition must be at least the size of the C: drive of the captured reference server. It does not matter if the content is only 3GB. If the reference machine had a 20GB C: drive, any server to be deployed must have at least 20GB available for its C: drive.

Next, the image is written to the first partition using the imgbmdeploy.exe utility. You'll need to change "imagename" to the actual name of the image to deploy (such as "Win2003EntSP1", the image I previously captured). Now the sysprep.inf placeholders and variable names I defined for the device will make sense, showing which variable for the device is read and which placeholder it replaces in the sysprep.inf file. Next, a number of ADS management functions are performed after the device is deployed, as long as the correct certificate is in place to allow communication with the ADS server.

The server is then rebooted from the local hard disk instead of the deployment agent and the device is set to boot from the local hard disk on subsequent reboots. You should leave all ADS managed servers to boot from the network by default and let ADS then instruct each server to boot from its local hard disk. Then you won't have to manually tell the server to boot to the network when an ADS-type capture or install is required.

The final step is to tell the device to boot to the deployment agent by selecting the properties of the device and on the General tab set its "Default job template:" to "boot-to-da" and click OK, as shown in Figure 7. Now turn on the server to be deployed (ensuring it's configured to boot from network as its first boot device). Note that after the server is deployed its default job template will change to boot-to-hd which is its local hard disk.

Figure 7** The Server's Default Job Template after Deployment **(Click the image for a larger view)

Once the server to be deployed is booted to the deployment agent (its status will be "Connected to DA" instead of "busy"), execute the deployment task sequence in the same way we executed a capture task sequence. That is, right-click on the device and select "Run job...", then follow the same steps except this time select the deployment task sequence created.

The restoration status will show on the server being deployed and once again on the ADS server the job status can be monitored to see exactly where it is in the process and which steps have been completed. The deployed server will reboot twice, once after the image has finished deploying and again after the mini-setup wizard execution that processes the Sysprep answer file. In Figure 8 you can see that the image has been deployed and the sysprep.inf file updated. The rest of the actions are performed quickly.

Figure 8** Deployment Task Status **(Click the image for a larger view)

So there you have it—the entire process for a basic capture and deploy. Obviously, more steps will be added in many server deployments to take advantage of ADS functionality such as capturing a virtual floppy to perform a BIOS update or performing hardware RAID configuration and post-deployment actions, but getting the main process working is a vital first step. Once you understand the construction of task sequences, progress in more advanced areas will be rapid.

Extended Uses

Included with ADS are a number of tools that prove very useful for adding functionality to ADS. For example, the imgmount.exe tool lets you mount an ADS image to a drive letter and then view and modify the content. Use caution, however—modifying an image without careful control may render the image unusable.

Another great tool is imgdeploy.exe, which can be used in other environments such as Windows PE to perform image captures and restorations. It's via this method that you could, theoretically, capture desktop images if you so desired.

I edited the XML files in Notepad, but ADS includes the ADS Sequence Editor, which provides a graphical environment for manipulating the task sequence XML files. This may prove more intuitive to use for many administrators (see Figure 9).

Figure 9** Editing a Task Sequence File **(Click the image for a larger view)

You will also want to understand the role of ADS in server consolidation. Because ADS can capture entire disks and restore them, it is very useful if you want to take physical boxes and move them into a virtual environment. The Virtual Server Migration Toolkit, which can be downloaded from microsoft.com/windowsserversystem/virtualserver/evaluation/vsmt.mspx, fully leverages ADS capabilities while adding features to help you configure the Virtual Server 2005 environment to closely emulate the physical hardware you were running on.

If you have a large server farm and have ADS deployed, it's not too difficult to repurpose groups of servers as required by simply selecting them as a group and, for example, rebuilding them as IIS servers when needed, or quickly adding some additional domain controllers.

Ultimately the decision to use ADS will depend on a number of factors, including whether you have Windows Server 2003 Enterprise servers that can host the ADS service, whether you deploy enough servers to warrant the initial effort to set up and configure ADS (though it is possible to get ADS up and running in a minimal fashion with a very small amount of effort), and whether you need to back up servers or perform server consolidation. Once you determine your needs, however, you'll find that ADS has a lot to offer.

John Savill is Director of Technical Infrastructure for Geniant. He is a CISSP, a Security and Messaging MCSE on Windows Server 2003, a six-time MVP, and a Krav Maga instructor. He is the author of Windows Server 2003 Active Directory Design and Implementation (www.packtpub.com/book/active_directory).

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.