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).

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.

I’m trying out some workstation deployment scenarios right now and need to use the Microsoft System Preparation Tool (SysPrep) to prepare my Windows XP SP2 build for imaging. The trouble is, that SysPrep was refusing to play ball reporting the following error message:

There is an incompatibility between this tool and the current operating system. Unable to continue.

Although there are other tools available for changing workstation SIDs, like Sysinternals NewSID, SysPrep is the only one supported by Microsoft.

I was using the version from the deploy.cab file on the Windows XP SP2 CD (dated 4 August 2004, 13:00), so I thought that a later version may be available but Microsoft knowledge base article 838080 links to an identical set of deployment tools and even indicates that the version on the SP2 CD is current.

It turns out that because the latest version of SysPrep can be used for either Windows XP or Windows Server 2003, it asks the Server service which operating system it is running on. If the server service is not running (e.g. if the File and Print Sharing for Microsoft Networks service is not installed), this fails.

The workaround is to install the File and Print Sharing for Microsoft Networks service, start SysPrep, and then uninstall the File and Print Sharing for Microsoft Networks service whilst SysPrep is working. I found the answer on the Microsoft Software Forum Network Unattended Windows board, but I’m amazed there is not a Microsoft knowledge base article on this.

Thomas Lee reports that Microsoft have released updated versions of the business desktop deployment (BDD) enterprise edition and standard edition solution accelerators.

As he provided my BDD training, Thomas knows far more on the topic than I do and his blog carries details of the improvements in BDD v2.5.

If BDD is a mystery to you, check out my post from earlier in the year about the Microsoft solution accelerator for business desktop deployment, the Microsoft solutions framework and the Microsoft operations framework.

Earlier in the year I blogged about discovering unknown devices in Windows for integration into an unattended build. What I didn’t detail at the time was how to work out which device driver files are needed for a particular device.

Some device driver packages are pretty simple, but others are several megabytes in size. Rarely is the whole driver package required and it is usually sufficient to just copy a few files to the (RIS) installation source – generally:

• An .INF (setup information) file with an associated .CAT (security catalog) file.
• One or more .SYS (system) files.
• Possibly some .EXE (application) and .DLL (application extension) files.

I usually start off by reading the setup information file which relates to the Windows XP version of a driver. It’s straightforward enough to identify the catalog file (used to confirm the digital signature for the other files) from the CatalogFile= line in the [Version] section and for many simple .INFs, it is easy to identify the device driver files from the [SourceDiskFiles] section, but sometimes the setup information file supports a variety of devices and not all of the files are required. For complex driver configurations (e.g. an ATI video driver), I usually copy the .INF and .CAT files to the installation source and then attempt to install the driver from a reference workstation. As Windows XP throws an error each time it is unable to locate a file, I add the requisite file to the installation source, retry and repeat until all the necessary files are present (which normally only takes a few minutes).

Some device drivers include a subfolder within the [SourceDiskNames] section. In this case you have a choice – either edit the .INF (not recommended as it will break the digital signature), or place the appropriate files (geneally all except the .INF and the .CAT into an appropriately named subfolder and extend the OemPnPDriversPath in the [Unattended] section of the unattended setup file.

One final note. In my unattended build, I have support for a variety of PC models, some of which use different drivers for what would seem to be identical hardware. For example, both the IBM ThinkPad T40 and the Compaq Evo N620c have an Agere Systems AC’97 Modem, but the driver version I downloaded from IBM and integrated into the build for the T40 was not recognised by the N620c (due to different PCI device instance IDs – the T40 implementation is PCI\VEN_8086&DEV_24C6&SUBSYS_05241014&REV_01\3&61AAA01&0&FE whilst the N620c is PCI\VEN_8086&DEV_24C6&SUBSYS_00580E11&REV_03\3&61AAA01&0&FE). I didn’t have access to a spare T40 in order to regression test a version of the driver with support for both device instances (assuming there is one), so I downloaded a version of the driver from HP, which does work with the N620c. Although the .INF and .CAT files are different, both the IBM and HP drivers have a number of files in common (AGRSM.SYS, AGRSMMSG.EXE and AGRSMDEL.EXE – albeit with different date and time stamps), so I left the newest versions of the common files in place (which happen to be the IBM versions). As I haven’t changed the files for the IBM driver, the T40 build should be fine, but the N620c build fails a check on the digital signature due to a mismatch between the file versions. There are two ways around this: either place the two driver versions into different folders and extend the OemPnPDriversPath in the [Unattended] section of the unattended setup file; or disable the check for signed drivers as detailed in Microsoft knowledge base article 314479.

After a few weeks developing my unattended PC build using physical PCs, today I needed to deploy a virtual PC (VPC). It should be simple to boot a VPC to a Remote Installation Services (RIS) server and apply an image as normal, but in case anyone else out there is googling to find out why they can’t get it working, here’s some of the stuff I’ve found today.

The SMC 9332 NIC which VPC emulates does not include PXE support, but RIS has provision for this in the form of the remote installation boot disk, which may be created using the \\servername\reminst\admin\i386\rbfg.exe tool (and for VPC users, Roudy Bob has published a virtual RIS Boot Disk on his website).

I spent a while this morning wondering why I was receiving the following message, even though my virtual PC was using the host PC’s network card and the DHCP logs in %systemroot% showed an IP address being assigned to a device with the MAC address of my virtual PC:

DHCP
No reply from a server
Press any key to reboot system

This particular problem turned out to be related to my RIS configuration – after a not inconsiderable time spent searching, Microsoft knowledge base article 891372 reminded me that I had selected the checkbox to prevent responses to unknown clients in the properties for the RIS server (I pre-stage client PCs so that when they are rebuilt, RIS already knows the computer name).

Once that was fixed, everything was looking good, except that the Client Installation Wizard was not displayed. I enabled debug logging on the Boot Information Negotiation Layer service and the %systemroot%\debug\binlsvc.log file indicated that the RIS server was communicating with my client, but for some reason it was hanging after the server had sent a response:

[BinlServer] 02/15 14:07:30 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:31 [MISC] MachineDN = CN=VPC1,OU=Policy,DC=home,DC=local
[BinlServer] 02/15 14:07:31 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:07:31 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:07:31 [MISC] SamName = VPC1$
[BinlServer] 02/15 14:07:31 [MISC] Name = VPC1
[BinlServer] 02/15 14:07:31 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:32 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:32 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [STOC] Sending response to = 192.168.7.106, XID = 63702087.

Compared with a working (physical) PC, where the log read:

[BinlServer] 02/15 14:17:01 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:01 [MISC] MachineDN = CN=LAPTOP1,OU=Policy,DC=home,DC=local
[BinlServer] 02/15 14:17:01 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:17:01 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:17:01 [MISC] SamName = LAPTOP1$
[BinlServer] 02/15 14:17:01 [MISC] Name = LAPTOP1
[BinlServer] 02/15 14:17:01 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:02 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:02 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [STOC] Sending response to = 192.168.7.104, XID = 8831c65a.
[BinlServer] 02/15 14:17:04 NULL screen name so we are retrieving the Welcome Screen.
[BinlServer] 02/15 14:17:04 Retrieving screen file: 'E:\RIS\OSChooser\welcome.osc'

I spent hours trawling the ‘net, completely mistified as to why physical PCs worked, but not virtual PCs, until a colleague reminded me that RIS servers should not have multiple NICs installed (they can have but it is not recommended – this is also explained in Microsoft knowledge base article 891372). My RIS server does have two NICs – one connected to a 3Com SuperStack 3300 switch (downstairs), and one wireless LAN connection to the LAN in my office upstairs (which uses a mixture of wired and wireless LAN technologies). As a last resort, I plugged the host PC into the downstairs switch and the VPC suddenly found the RIS server.

For reference, by default, after obtaining an IP address and downloading the boot image, RIS displays a prompt for the user to press F12. This may be disabled by renaming startrom.com to startrom.old and startrom.n12 to startrom.com (found at \\servername\reminst\oschooser\i386). You can also edit the .osc files used by the Client Installation Wizard as these are simply OSCML documents (modelled on HTML 2.0).

Now RIS is working as I expected and I can even go back to pre-staging clients (GUIDs for VPCs are formed with the MAC address for the virtual NIC, prefixed with 00000000-0000-0000-0000-).

This should have been simple, but a couple of minor issues made it very difficult – I just hope my experience is useful to someone else out there in cyberspace.

Links

How to set up, configure, and use Remote Installation Services in Windows 2000
Customising RIS Installations