I've been working with Bart Lagerweij's BartPE (Preinstalled Environment) lately to see if I could get a reliable method for restoring partition images created by Runtime Software's free DriveImage XML. Most of the issues I've encountered have been resolved by adding drivers for network and disk hardware. This article describes the changes I've made in order to get BartPE to boot on a variety of hardware.

After some time working with BartPE, a forum user suggested that I try the Ultimate Boot CD for Windows, also known as UBCD4Win. This is a significant extension to BartPE. I've added some comments on UBCD4Win at the end of this article.

Disk Management

I wanted to be able to run Disk Management from the BartPE environment so I could create partitions in a disaster recovery scenario. I finally found an MMC plugin that lets me run not only Disk Management, but also Computer Management with Device Manager and Event Viewer.

In order for the MMC plugin to work, you must also enable the following plugin in BartPE's plugin list: "RpcSS needs to launch DComLaunch Service first - SP2". And in order for that plugin to work with Windows 2003 as well as Windows XP SP2, you must edit the plugin's dcomlaunch\dcomlaunch.inf file to remove the ".2600" from the [SetupReg.AddReg] section. The ".2600" is apparently restricts the registry modification to Windows XP; by removing it, the modification applies to Windows 2003 as well. The respective lines in dcomlaunch.inf now look like this:

; [SetupReg.AddReg.2600] - removed .2600 so it will work with Win2003 as well as WinXP
[SetupReg.AddReg]

Disk Hardware

BartPE recognizes all the IDE and USB drives I've used. However, it requires additional drivers to see RAID and SATA controllers. Each set of driver files goes in its own folder (of any name) under BartPE\drivers\SCSIAdapter (even if it's not a SCSI driver). If txtsetup.oem includes multiple OS choices, I commented out all but the WinXP or Win2003 options in the [scsi] section.

• For a Lenovo ThinkPad T60p with a SATA drive, I added the Intel Matrix Storage Manager driver for the 82801GBM SATA AHCI Controller, then edited txtsetup.oem to exclude all but that driver from the [scsi] section. (Another alternative would have been to change a setting in the ThinkPad's BIOS so that the hard drive runs in IDE compatibility mode. I did not test this option.)

• For Dell PowerEdge 1500SC and 1600SC servers with PERC 3/SC and 4/SC cards, I added the Dell drivers for Win2000/2003, then edited txtsetup.oem to comment out the Win2000 driver in the [scsi] section.

• For a Dell PowerEdge 1900 server with PERC 3/SC and 4/SC cards, I added the Dell driver for Win2003. I used the driver from the CD that came with the server. To extract the drivers, with the Dell "Installation and Server Management" version 5.2 CD in the E: drive, I used the following command to create a folder of Windows 2003 drivers for the PowerEdge 1900:

  E:\server_assistant\driver_tool\bin\make_driver_dir.exe -i e:\ -d "C:\delldrivers" -p pe1900 -o w2003 --extract

  I then used the driver in the w2003\sas_raid\r149460 folder. The txtsetup.oem file only lists Windows 2003, so no edit is required. Note:  this driver will not load unless you build the BartPE environment with a Windows 2003 CD. If you build it with a Windows XP CD, you will get the message "percsas.sys could not be found."

• For a server with a SIIG eSATA II-150 PCI eSATA card (model SC-SA2012-S1), I used the drivers from the "Floppy" subfolder of the drivers folder, and edited txtsetup.oem to exclude all but the WinXP driver in the [scsi] section. I also had to modify the [Disks] section to remove the winxp/ subfolder, since the driver is in the same folder as the txtsetup.oem file. The modified lines look like this:
  
  ; d3 = "INITIO INIC1620 S-ATA Adapter for Windows XP/2003",winxp\inic1620.sys,winxp
  d3 = "INITIO INIC1620 S-ATA Adapter for Windows XP/2003",\inic1620.sys,\

Network Hardware

BartPE also allows you to add network drivers. Each set of driver files goes in its own folder (of any name) under BartPE\drivers\Net. In most cases, just copying the XP drivers for any given network card to a subfolder was enough. A couple cases warrant special notes:

• The Dell PowerEdge 1900 has an embedded Broadcom NetXtreme II adapter. I finally got this to work by following the instructions in this post:

1. Download and extract the BroadCom NetXtreme II Windows 2003 drivers from the Dell FTP site.
2. Open the RIS_Drivers folder and edit the b06nd.inf file. Change "class=net" to "class=Net" and save. After doing that, BartPE can handle the RIS drivers. After the change, the [Version] section of b06nd.inf looks like this:

   [Version]
   signature   = "$Windows NT$"
   ; class = net -- Apparently BartPE requires that "Net" be capitalized
   class       = Net
   classguid   = {4d36e972-e325-11ce-bfc1-08002be10318}
   catalogfile = b06nd.cat
   compatible  = 1
   provider    = %brcm%
   driverver   = 04/05/2006,2.6.1.0

3. Copy the b06nd.inf and b06nd51x.sys files to their own folder under BartPE\drivers\Net.
   

• For the Lenovo ThinkPad T60p, creating a separate folder containing the Intel Pro1000 drivers downloaded from Lenovo is not enough. Google takes me to a few threads about how to create a BartPE plugin, modify .inf files, etc. This is more work than it is worth to me right now. Even if I start using DriveImage XML to back up my T60p, I can always attach a USB hard drive containing the image to restore, so the network is not absolutely required. Update 3/3/2008:  I was having similar trouble getting Intel network drivers to work on a Dell Optiplex 755. I came across a blog that said that the issue is that the drivers are incompatible with Windows 2003, so you have to use Windows XP SP2 media when building the BartPE image. Sure enough, once I had done that, I was able to load the network on the ThinkPad under BartPE!

Boot from USB Thumb Drive

By default, BartPE is set to create a bootable CD, which can only be created on CD-R media (not RW). Working through all the issues above I created quite a collection of coasters. Then I found a little program called PEtoUSB that lets me take the CD folder created by BartPE Builder and create a bootable USB Thumb Drive. Brilliant! CD-Rs are good for the "final" version, since they are more universally bootable, but the USB approach would have helped prevent creating so many dead discs.

Update 3/6/2008:  One limitation I've found is that if I use PEtoUSB under Vista to format the USB drive, the drive does not boot. Instead I get this error:

Remove disks or other media
Press any key to restart

The workaround is to run PEtoUSB under XP to format the drive (uncheck "Enable File Copy"), then run PEtoUSB under Vista only to copy files (uncheck "Enable Disk Format"). The only reason this matters is that my laptop runs Vista, so when I'm at a customer site trying to fiddle with BartPE configurations until I get one that works, the Vista laptop is the machine that I have available for creating BartPE images.

UBCD4Win:  The Ultimate Boot CD for Windows

UBCD4Win is quite an amazing collection of drivers and utility programs. Unlike BartPE, it is still actively maintained, so it is more likely to contain current drivers and programs. It includes not only Disk Management and DriveImage XML, but browsing, virus checking, hardware testing, and more, all built as extensions to the original BartPE system. I only found two "gotchas" working with UBCD4Win:

• UBCD4Win has so far been able to load network drivers on every machine I have, including the difficult ThinkPad T60p. It also loaded a driver for the ThinkPad's SATA hard drive. However, it did not load drivers for Dell's PERC 3/4/5 RAID controllers. I was able to rectify that deficiency by simply copying the PERC drivers from my BartPE build, then creating the UBCD4Win CD using a Windows 2003 CD as required by the PERC 5 driver.
• Because UBCD4Win is so extensive, it is also significantly slower to boot than a BartPE CD. (The UBCD4Win .iso file is 537MB as opposed to my BartPE build which is 169MB.)

For now I'll keep both CDs around:  BartPE for quick booting to a couple of essential programs, and UBCD4Win for a more comprehensive set of utilities that will probably load even on hardware I haven't tested.

Time Server Upgrades Expose W32Time Bug 

Some time ago, I set up two NTP time sources for my Windows 2003 / SBS 2003 domain controllers:  time-nw.nist.gov in Redmond, Washington, and time-a.nist.gov in Gaithersburg, Maryland.

I noticed that the machines don't ever seem to sync with time-nw.nist.gov. I keep getting W32Time errors:

Event ID: 38
"The time provider NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov"

Event ID: 47
"No valid response has been received from manually configured peer time-nw.nist.gov,0x8 after 8 attempts to contact it."

However, my second source, time-a.nist.gov, usually works, so the servers' times are still in sync:

Event ID: 37
"The time provider NtpClient is currently receiving valid time data from time-a.nist.gov"

I tried replacing  time-nw.nist.gov with a couple other servers from the NIST's list of public servers, but the other two options failed as well. What's going on here? Only one clock in the country works? Finally I came across this thread on a Channel 9 forum.

On April 25, 2007, "PeterInSydney" turned on w32time logging (here's how), and discovered that the w32time client was rejecting time with a "precision" value of -31. A Microsoft employee in Redmond, Matthew van Eerde, confirmed that this is a bug in the w32time client:  "The w32time client incorrectly rejects packets with precision < -30." Van Eerde followed up on April 27 with a very helpful summary of what situations are broken (basically any XP or Win2003 machine trying to talk to a "very high-precision" server). The April 27 post mentions that, "Recently (March time frame) time.nist.gov became 'very high precision.'" The workaround is to use a lower-precision server.

Sure enough, when I turned on w32time debugging on my server, I see that time-nw.nist.gov is also returning a -31 precision, whereas time-a.nist.gov is still "only" -30. That explains why only time-a.nist.gov is working.

Pardon the pun, but isn't this a time bomb waiting to explode? So far I haven't been able to find a list of which servers offer what level of precision. But if the NIST servers are gradually being upgraded to higher precision, won't the Windows machines that rely on them eventually be left high and dry?

The Hotfix 

Fortunately, reading further in the (four-page) Channel 9 thread, on September 4, Microsoft's van Eerde announced that a hotfix for Windows Server 2003 is available:

The Windows Time service in Windows Server 2003 does not synchronize time with a time server if the precision value of the NTP response is less than -30
http://support.microsoft.com/kb/940742

So I submitted an online hotfix request, and in under two hours, the hotfix instructions arrived. Once applied and rebooted, time is now syncing properly with very high precision servers.

Still Getting Errors 

Even though the Windows servers will now sync with very high precision NTP servers, I still sometimes get the 38 and 47 errors. Examing the debug log, this time it is due simply to the NTP server not responding to a query:

Polling peer time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123)
Sending packet to time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123) in Win2K detect mode, stage 1.
No response from peer time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123).
Logging information: NtpClient cannot reach or is currently receiving invalid time data from time-nw.nist.gov (ntp.m|0x8|192.168.1.2:123->131.107.1.10:123).

So even though Windows is now able to handle high precision servers, you still have to find servers that are responsive. I never got time-nw.nist.gov to respond, and time.nist.gov was intermittent. Maybe w32time made too many requests and was blocked by the servers. In any case, I finally found two geographically separated NIST servers that are responding well. Here's how I set them up (commands adapted from KB 875424):

w32tm /config /manualpeerlist:"nist1.symmetricom.com,0x8 time-b.timefreq.bldrdoc.gov,0x8" /syncfromflags:MANUAL
net stop w32time
net start w32time
w32tm /resync