Issues encountered with Microsoft VSMT

We’ve been migrating a few servers to Virtual Server 2005 virtual machines using the Microsoft Vitrual Server Migration Toolkit and had a few head scratchers during the process. Hopefully Google will index this stuff so others using the same keywords as I used will have better luck getting to the documentation. I’ve found that newsgroups are almost better than any other resource for cross-indexing support documentation. Not everyone uses the same nomenclature!

Here we go:
Moving ADS Controller to a new subnet / IP address required hacking registry (We ended up uninstalling / reinstalling to be safer).

If you change IP addresses or subnets on your ADS controller, you’ll need to change some registry keys for the service to function properly. HOW TO: Change the IP Address of an Automated Deployment Services (ADS) Controller
Running DHCP on ADS Controller requires running script “ADSDhcpConfig.wsf”

Just like it says. It took a little while to figure this one out. It wasn’t obvious in the documentation. The reason is that PXE and DHCP both respond to DCHP requests, so when they’re on the same server, the responses need to be coordinated. Here’s how to fix it: Configuring DHCP and PXE on the same server.
PXE Boot process fails at “requesting a bootable image from the build server” and an event log entry is generated.

You’ll have to get into the event log for this one. It will tell you the hardware ID of the device that the builder service did not have drivers for. In the case of network or storage drivers, this can prevent the DA from booting. Track down the hardware ID, get the latest drivers for the device, then add them to the ADS controller in the C:\Program Files\Microsoft ADS\nbs\repository\windows\ folder, restart the Builder service, and retry booting.
Reinstallation of ADS requires re-registration of ADS Administration Agent certificate.

While troubleshooting a physical server to virtual server migration using the VSMT, a our Virtual Server would not show up as connected in the ADS console. Simply deleting it and re-adding as the microsoft VSMT deployment guide suggested did not seem to remedy the situation. A few newgroup users who encountered this problem were successful in booting the device into the Deployment Agent, which caused the controller to discover the device. I had no problem booting to the DA, but once I rebooted, the device would show up as disconnected again.

I checked the dates on the two adsroot.cer files and they were different. I copied the newer one from the ADS Controller to the virtual server, then re-installed the ADS Administration Agent using the new cert. Voila! the device popped up in the console as connected to Windows. YAY!

All in all, we’ve successfully migrated 2 physical machines that were not in production, and are currently (as I write this) moving a production server to VS 2005. Let’s hope MS really believes their own hype about DSI :-)