Windows Server 2003's new Automated Deployment Services (ADS) lets you remotely deploy and manage new Windows 2003 or Windows 2000 Server installations through a central Microsoft Management Console (MMC) snap-in or Windows Management Instrumentation (WMI) scripts. As part of the Microsoft Dynamic Systems Initiative (DSI), ADS is designed for high-bandwidth datacenter environments and combines several existing technologies—including a Preboot Execution Environment (PXE) server, volume-imaging tools, Deployment and Administration agents, a WMI interface, and command-line tools—to provide a framework for mass server deployment and administration. (By volume imaging, I mean a technique that captures a hard disk volume's contents to a file that you can then copy to similar hardware. ADS is Microsoft's first volume-imaging technology and complements other Microsoft deployment technologies such as Remote Installation Services—RIS.) Let's take a look at ADS's architecture and operations and a basic ADS-driven deployment.
The ADS Architecture
Figure 1 shows ADS's basic architecture. At the top of the architecture are various ADS management interfaces—the MMC ADS snap-in, command-line tools, and customized WMI scripts and applications—that interact with ADS's core service through WMI. The ADS snap-in lets you manage the ADS server (i.e., the server on which you install ADS) as well as the various systems you want to image, deploy, and manage. The command-line tools basically perform the same functions that you can invoke from the ADS snap-in. (The ADS online documentation, which is available at http://www.microsoft.com/windowsserver2003/technologies/management/ads/default.mspx, includes a complete list of the available command-line tools and their purposes.) During setup, ADS adds several WMI classes to the WMI Common Information Model (CIM) repository; developers can use these classes to create customized ADS applications or scripts. You must run ADS (which you can download at http://www.microsoft.com/windowsserver2003/techinfo/overview/adsbenefits.mspx) on a Windows 2003, Enterprise Edition or Windows 2003, Datacenter Edition system.
ADS comprises three services: the Controller service, Network Boot Services (NBS), and Image Distribution service. These services handle the sequencing of jobs, PXE boot requests, and volume imaging. NBS includes the PXE service and is mainly responsible for the ADS Deployment Agent's boot capability. The Image Distribution service supports the downloading or uploading of images through the Deployment Agent.
ADS provides two agents: a Deployment Agent and an Administration Agent. The Deployment Agent, which NBS boots from the network through PXE, implements a small subset of Windows to let you deploy systems from the ADS server. (This agent includes several Windows 2003 components, so you'll need the Windows 2003 CD-ROM during ADS setup.) Among other things, the Deployment Agent lets you download a disk image from or upload a disk image to the ADS server. The Deployment Agent executes specific tools and commands through XML files, which define a sequence of operations for typical jobs (e.g., partitioning the disk, changing the registry's image content, copying extra files from the ADS server onto a deployed system's hard disk). These jobs are known as ADS task sequences. (For more information about how ADS executes these sequences, see the Web-exclusive sidebar "ADS Sequence Files," http://www.winnetmag.com, InstantDoc ID 41399.)
The Administration Agent runs as a service in the deployed OS. You must install this agent in the OS that you plan to deploy before you take an image of that OS. You can use the agent to perform various management tasks (e.g., execute Windows 2003 tools such as the WMI Command-line—WMIC—tool, use WMI or Active Directory Service Interfaces—ADSI—to start Windows Script Host—WSH—scripts) in the deployed OS from the ADS server. You can also execute, through the Administration Agent, any third-party scripting engines that you install in the image (so long as any components necessary to execute a task are also installed in the deployed image). Although you can use the agent to execute most traditional management tools, be sure that you carefully select the security context in which you run the agent (i.e., whether you run the service from the Local System account or a domain account). If you don't need network connectivity, running the agent in the local security context is best.
ADS logs all its job activities to a Microsoft SQL Server 2000 or Microsoft SQL Server Database Engine (MSDE) database. ADS comes with MSDE, which you can use if you don't have SQL Server. If you require a more scalable architecture or want to use a decentralized SQL Server database to store ADS information, you can specify database-access parameters during ADS setup.
ADS also provides a set of interactive volume-imaging tools that you can use to mount an image as a mapped volume so that you can transparently explore and update the image content as if it were on the local hard disk. This capability lets you modify an existing image without needing to recapture the volume. You can also use the imaging tools to capture or restore an image from which a deployed system can boot. For example, you can use these tools to boot a target system from Windows Preinstallation Environment (WinPE), then capture the volume to create an image on or download an image from the ADS server. (WinPE is a "light" version of Windows that you can boot from a CD-ROM to access a Windows command prompt. WinPE supports technologies such as WSH, HTML applications, and ADO, which permit script execution. WinPE is available only to Enterprise Agreement—EA—or Select License customers who've signed up for Software Assurance—SA. You can find more information about WinPE at http://www.microsoft.com/licensing/programs/sa/support/winpe.asp.) However, this method requires you to be physically present at the target system to boot WinPE and doesn't support multicast Trivial FTP (TFTP), which can improve performance. Using the Deployment Agent to copy and restore images is a better method because the agent lets you use multicast TFTP to broadcast the image to a group of machines, without requiring you to visit each target system.
Installing ADS and Capturing an Image
Now that you have an idea of the ADS architecture, let's take a look at the process of installing and setting up ADS and capturing the OS image that you want to deploy. The examples in this article provide a basic approach—more complicated deployments are beyond the scope of the article—but are sufficient to give you an idea of the way ADS works.
To install ADS, download it to a folder on a Windows 2003 Enterprise or Windows 2003 Datacenter server, then run the executable. The examples in this article assume that you'll accept the option to install MSDE and that you'll accept all default installation parameters for ADS. (You'll need the Windows 2003 CD-ROM during the setup process.) After the Setup program is complete, go to C:\program files\microsoft ads\samples\sequences and start the create-templates.bat file to register the default ADS sequences in the ADS server database.
To prepare and capture the OS image, choose a reference system (i.e., a Windows 2003 or Win2K server that represents the standard installation you plan to image and deploy). Tune all Windows services as necessary, customize the desktop, and add any additional packages (e.g., Support Tools, resource kit tools, antivirus tools) that you want in the reference installation. Install applications only if they support the Sysprep process, which is a necessary part of capturing an image to deploy to multiple servers. For example, don't install Microsoft Exchange Server or SQL Server, which don't support Sysprep, on the reference system. Also install the Administration Agent on the reference system by starting the ADSAgentSetup.msi package. You'll need to provide the ADS certificate file (ADSCert.cer), which you can find in the ADS server's C:\program files\microsoft ads\certificate folder, during agent setup. This certificate is necessary to establish encrypted communications between the agent and the ADS server.
Next, copy Sysprep (sysprep.exe), which you can find in support\tools\deploy.cab on the Windows 2003 or Win2K Server CD-ROM, to the reference system's C:\sysprep\i386 folder. During its first phase, Sysprep generalizes the original OS installation by removing all settings specific to the installation (e.g., computer name, SID, IP address). During Sysprep's second phase, at the first boot of the imaged OS on a target system, Sysprep runs a mini-setup process to customize settings that are specific to the target system. These settings are defined in the sysprep.inf file—an ASCII file that contains a series of placeholder strings for system-specific ADS device variables. ADS replaces these strings with values that you define for the target system. (For more information about these variables and how to configure them, see the Web-exclusive sidebar "Device Variables," http://www.winnetmag.com, InstantDoc ID 41400.)
ADS comes with several sample sysprep.inf files (in the ADS server's C:\program files\microsoft ads\samples\sysprep folder), each of which corresponds to a particular deployment setup. Choose the file that suits your deployment—for our example, I use sysprep-wg-w2003.inf, which is designed to deploy Windows 2003 in a workgroup environment—and copy it to the reference system's C:\sysprep folder. When you use one of ADS's default deployment task sequences, ADS will automatically execute Sysprep's first phase, with the help of the Administration Agent.
When your reference installation is complete, you need to register the reference system as a new ADS device (i.e., a system that ADS can control). ADS supports automatic registration of devices, as I explain later, but let's look at the manual registration process first. ADS stores a device record for each device, identifying the system by its media access control (MAC) address or System Management BIOS (SMBIOS) globally unique identifier (GUID). ADS uses MAC addresses by default. If you want to use the SMBIOS GUID rather than the MAC address to uniquely identify a device, you'll need to open the Controller Service's Properties dialog box from within the ADS snap-in, then change the Device Identifier setting. This example assumes that you'll use MAC addresses.
First, use ipconfig.exe (or getmac.exe, on Windows 2003 only) to determine the reference system's MAC address. Reboot the system and let it remain at the logon screen. Open the ADS snap-in, right-click the Devices folder in the console's left pane, and select New from the context menu. Specify a device name—for this example, I use the name MAC0008C79905F1, where 0008C79905F1 is the reference system's MAC address—and type the MAC address in the MAC field. Click OK and wait for a message confirming the successful creation of the device, then click Cancel to close the dialog box.
To control a device from the ADS server, you must configure the device to operate in Control mode. To do so, right-click the device and select Control from the context menu. The device's status (listed in the State column) should change from Disconnected to Connected Full OS. If it doesn't, the ADS server isn't communicating with the Deployment Agent, perhaps because of a mistake in the MAC address or because of a network communication problem between the ADS server and the system (e.g., the Deployment Agent isn't running).
After the device is connected, you can start the capture process on your reference system. Right-click the device and select Run Job. Click Next, select Run a template, and select a capture job template (I use capture-image.xml). This sequence uses the Administration Agent to execute the first phase of the Sysprep process, with Sysprep's -quiet, -reseal, and -reboot switches. Next, the sequence reboots the system into the Deployment Agent to capture an image of the local disk (the default sequence settings are first disk, first partition). This sequence is designed to capture an image of a booted, fully customized OS. To monitor the capture's progress, open the Running jobs folder in the ADS snap-in's left pane and double-click the job in the right pane. The capture's duration can vary greatly depending on the size of the image, the reference and ADS systems' hardware capabilities, and network performance.
Preparing the Target System
After you've captured a reference installation image, you're ready to use ADS to deploy that image on one or more target systems. To do so, you must register the target system as a device so that the ADS server can accept PXE requests from the target system. I've explained the process of registering a system as a device, but collecting MAC addresses or SMBIOS GUIDs for many target systems can be tedious. However, ADS can create a device on the fly when it receives a PXE request from a target system.
To take advantage of this functionality, open the Controller service's Properties dialog box and set the PXE Action field to Add. (You'll need to make sure that no other system on your network, such as a RIS server, will be affected if you configure the ADS server to accept all PXE requests in this manner. For this reason, and because the deployment process can put a high demand on bandwidth, Microsoft recommends that you use a separate LAN for your deployments.) You must also configure the target systems to issue PXE requests and to boot in a specific sequence—NIC PXE boot, 3.5" disk boot, CD-ROM drive boot, then hard disk boot. (If the ADS server doesn't answer a system's PXE request, the target system will boot as defined in its BIOS settings.) Finally, make sure you have a DHCP server available to distribute IP addresses to systems that boot through PXE. Be aware that any router between the ADS server, the DHCP server, and the target system must support the DHCP relay feature that Internet Engineering Task Force (IETF) Request for Comments (RFC) 1542 describes and will complicate deployment.
After you configure the ADS server to accept the target system's PXE boot request and to automatically add the system as a device, boot the target system. Figure 2 shows the resulting process, from the target system's first boot-up to the deployment of the OS image. First, the target system issues a PXE boot request to the ADS server (Step 1). The ADS server adds a device record for the target system. After the creation of the device, you must place the device in Control mode, as I explained earlier. If a specific hardware setup (e.g., for a RAID configuration) is necessary, you can use ADS's virtual floppy tool (vfloppy.vfi in C:\program files\microsoft ads\tools) and dskimage.exe tool to customize a bootable DOS image disk that will execute that configuration. ADS then loads the Deployment Agent onto the target system, which stores the agent in RAM (Step 2). At the end of this process, the device's status is Connected to Pre-OS.
Deploying an OS Image
To illustrate the deployment process, let's run through a sample deployment of the OS image you created earlier (i.e., the device MAC0008C79905F1). For this deployment, you'll use ADS's da-deploy-image-wg.xml sample sequence, which corresponds to the sysprep-wg-w2003.inf file that I mentioned earlier. First, you'll need to create variables for the target device (as I explain in the sidebar "Device Variables"), set a default job template for the device, and ensure that the device is under Control mode.
For this example, the following device variables are necessary:
- The ProductKey variable, which must contain your Windows Product Key, replaces the ^ADS_WINDOWS_PRODUCT_KEY^ placeholder string in the sysprep-wg-w2003.inf file.
- The adminpassword variable, which must contain the default Windows Administrator password, replaces the ^ADMINPASSWORD^ placeholder string.
- The machinename variable, which must contain the machine name to set during the Sysprep process, replaces the ^ADS_COMPUTER_NAME^ placeholder string.
After you set the device variables, select boot-to-da as the default job. This job assumes that the device is a new system without an existing OS and instructs the system to boot to the Deployment Agent, after which you can perform ADS management tasks such as capturing or restoring a local disk image. Finally, set the device to Control mode and reboot the target system.
To deploy the OS image, right-click the target device and select Run Job from the context menu. Click Next and select Run a template. Select da-deploy-image-wg.xml to begin the deployment sequence, during which ADS downloads the OS image onto the target system's local disk, using multicast TFTP by default (Step 3 in Figure 2). After the sequence is completed, the target server reboots to the imaged OS (Step 4), which contains the Administration Agent, which in turn lets you manage or customize the target server (e.g., install additional applications) by pushing scripts from the ADS server (Step 5). You can monitor the deployment by opening the Running jobs folder in the ADS snap-in and double-clicking the job.
The Image of Easy Deployment
ADS is useful for performing Windows 2003 and Win2K Server deployments. Although ADS requires some customization, it uses standard OS tools and technologies, so you don't need to learn a new set of tools or languages—you simply need to learn how ADS's sequences work and how to organize them.