Using ADS to deploy Windows XP

This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the main reasons for needing to SysPrep my Windows XP installation was that I wanted to see if it is possible to use Microsoft Automated Deployment Services (ADS) to deploy Windows XP.

Microsoft has a plethora of deployment solutions and the main one for workstation deployment is the solution accelerator for business desktop deployment (BDD); however the enterprise edition of this relies on the use of Microsoft Systems Management Server (SMS) and the standard edition requires third-party imaging tools.

Microsoft Remote Installation Services (RIS) is a perfectly good PXE boot server included within Windows 2000 Server and Windows Server 2003 but what I like about ADS is that it uses PXE to boot a miniature version of Windows Server 2003 (not Windows PE) called the ADS deployment agent (DA), which allows control from the server end. Using this technology, sequences can be built up to powerful jobs that control most aspects of a server build and I wanted to do this with a Windows XP workstation build.

The official line from Microsoft is that ADS is not supported for Windows 2000 Professional or Windows XP. Microsoft states that it is not possible to use ADS to deploy Windows XP or Windows 2000 Professional because:

“In addition to licensing constraints, the design of ADS is limited to servers as follows:

  • There is no ability to migrate user state, thus all user information is lost when a new image is applied.
  • ADS is designed to run on server-class hardware and cannot handle the diversity of client hardware.
  • ADS deploys images using a ‘push’ method and does not allow users or staff to initiate a deployment from the client computer.
  • Clients often exist behind slow links and ADS is designed to operate over a well-connected network.”

But ADS works with Windows 2000 Server and Windows Server 2003 (which is very similar to Windows XP in many ways) so I thought it must be possible. In addition, Windows Vista deployment will use Windows Deployment Services (WDS), and although I haven’t looked at WDS, the Windows Automated Installation Kit (WAIK) User’s Guide for Windows Code named “Longhorn” says that:

“WDS enables companies to remotely administer and deploy the latest operating system, using Windows PE and WDS Server. This deployment scenario can be fully unattended, and is customizable and scalable. [WDS] replaces the existing Remote Installation Services (RIS) deployment technology.”

(that sounds like a development of ADS to me!)

One of my ex-colleagues at Conchango pointed me to Paul Edlund’s blog post on using ADS with Windows XP.

This gives advice on SysPrepping the source machine to dump all of the plug and play IDs into the sysprep.inf file (thus avoiding issues with the variety of client hardware).

Quoting from Paul’s article (with minor edits for flow and grammar):

“This allows you to take an image from one machine and use it on a different desktop (assuming the HAL is the same). To perform this step, create a blank sysprep.inf file in the same directory as sysprep.exe. Now open the sysprep.inf file and add the following text to the first line of the file:

[SysprepMassStorage]

Without this tag in the file, SysPrep will run but it won’t put anything in the file (so you can’t forget this). Now save and close sysprep.inf and run sysprep -bmsd. This will dump all of the plug and play IDs from the driver.cab file into the sysprep.inf file. These IDs are used to populate the critical devices database in the registry.

Now copy the contents of the [SysprepMassStorage] section and paste it into the actual sysprep.inf file you want to use from the ADS sysprep.inf templates. The problem is that you will now have populated a huge number of entries in the critical devices database which means that every time your XP machine tries to start, it will try to load each of these drivers, resulting in a very long startup time. So to stop this from happening, add the -clean switch when running SysPrep.”

The SysPrep syntax which Paul gives for the next step didn’t work for me, but I ran sysprep -clean followed by sysprep -reseal -mini -pnp -reboot (although I think the last switch should have been -noreboot as my source computer booted into the mini-setup wizard after SysPrep had completed and I really wanted it to shut down).

There’s some more information in Paul’s article about the various SysPrep switches and the need for a blank administrator password on the source PC (Microsoft knowledge base article 302577 details the usage of SysPrep including the various command line switches).

Screen shot with the ADS deployment in progress

Using Paul’s article, combined with the information in the ADS quick start guide (part of the ADS installation), I was able to successfully capture and deploy a Windows XP image in a Virtual Server environment although there were a couple of gotchas (two of which are related to my use of a virtual environment):

  • Because I’d already SysPrepped the source PC, I couldn’t use the supplied capture-image.xml sequence without editing it to drop the first step (actually I just used the boot-to-da.xml sequence and a one-time job to run the /imaging/imgbmdeploy.exe command with the imagename \device\harddisk0\partition1 "description" -c -client parameters).
  • Also, my use of dynamically expanding virtual disks in Virtual Server meant that the volume size was recorded by ADS as 17166127104 bytes and so I had to use the ADS sequence editor to edit the parameters in the da-deploy-image-wg.xml sequence to use /C:16371 before the deployment was successful.
  • Finally, as the current version of Virtual Server doesn’t include PXE boot capabilities, I needed to use a virtual floppy disk with the contents of the RIS boot floppy (for details, see my earlier post on trials and tribulations with RIS, although Roudy Bob’s virtual RIS boot disk has moved so the link in my original post seems to be broken).

It’s also worth noting that because I was using Virtual Server, all of my hardware was standard. I’d be interested to hear how anybody gets on with this using a variety of physical workstations, but I didn’t have the time or resources to take the experiment that far.

To summarise, capturing and deploying Windows XP using ADS works, but it is not supported by Microsoft. It’s still something to think about if you’re willing to take that risk (I’m not prepared to risk an unsupported solution on my current project with 16,000 workstations spread across hundreds of sites) but if nothing else it’s a good way to spend some time familiarising yourself with SysPrep and ADS.

6 thoughts on “Using ADS to deploy Windows XP

  1. Thank you for the information in your article. I am in the middle of trying to create an imaging using sysprep.

    I have a question for you in regards to the -bmsd and the -clean switches for Sysprep.

    Assuming you have first placed the [SysprepMassStorage] entry into the Sysprep.inf file, when you run the -bmsd switch it populates the field with all the PnP Mass Storage Devices. When you run the -clean switch after the -bmsd switch, it seems counter productive because the -clean switch would remove the entries just made by the -bmsd switch?

    MS KB article (http://support.microsoft.com/?kbid=302577) seems to make a distinction between “Clears the critical devices” for the -clean switch opposed to “Populates all the available mass storage devices” for the -bmsd.

    My question is, do you think it is fair to conclude that the -bmsd switch dumps all the storage devices in the Sysprep.inf file and then running the -clean switch removes the critical devices that would prevent the image from loading on another hardware platform.

    I have been trying to prepare the image by performing the following commands in this order:

    1) Adding [SysprepMassStorage] to the Sysprep.inf file
    2) sysprep -bmsd
    3) sysprep -clean
    4) sysprep -reseal -mini -pnp -quiet -forceshutdown

    When I enter the last sysprep with the reseal switches, the Sysprep hourglass runs for a lot longer that it usually does (10 to 15 minutes) and then just disappears without shutting down the system. When I manually shut it down, it runs through the initial shell, so that it looks like everything executed as it should, but then it never runs through the mini setup, nor strips the SIDs or anything else and it just returns me to the log in prompt.

    I have a feeling that I am doing something in the wrong order, but for the life of me I cannot figure it out. Microsoft’s documentation is somewhat descriptive, but I have not found anything that lists out the specific order to which these steps are to be taken.

    Any help you can offer would be greatly appreciated.

  2. Jason – remove the -PnP switch from your command-line. Unless you have true non-PnP peripherals attached to that system, it will do nothing but add significant time – possibly terminally – to the process.

    Also, remove sysprep -clean. That should be run ONLY on the client once the sysprep image has been deployed. That’s what cleans out the massive collection of storage drivers running on the end system.

    Mark – an important point – WDS is actually not derived from ADS. They are quite different internally (and were developed in two different areas of Microsoft). The image format for WDS is also completely different. ADS images are sector based (like most imaging tools today) and WDS images (WIM images) are file-based.

  3. Wes,
    Thanks for that – both the SysPrep advice and the note on ADS/WDS differences are really helpful.

    For anyone reading this – check out STOP: NOW_WHAT? – Wes’ blog has some really useful information (and he’s a fellow Saab driver…).

    Mark

  4. sysprep -bmsd and -clean negate eachother if I am not mistaken

    i do sysprep -bmsd and then sysprep – mini -reseal -activated

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.