The monster project on my plate (I’ve been building up to it since around March) is to migrate our existing NT 4 domain to Windows 2008. This project has been joy and pain, and it is finally nearly done.
For the last few months, I’ve been getting the new domain ready, like upgrading the domain controller to server 2008, getting a new SQL Server install in place, SharePoint, and so on. I still need to do Exchange, CRM 4,0, and Office Communications Server, but we agreed that those items need to wait until after the migration.
When I went to do the initial batch of migrations, though, I hit a snag. The Active Directory Migration Tool (ADMT) version 3.0 supports migrating from NT 4, but not migrating to 2008. The newest version 3.1, supports 2008 as a target but not NT 4 as a source. So we needed to get the NT 4 server upgraded to 2000 or higher. For safety’s sake, we decided to use a VMWare image of the server for this.
The VMWare conversion process worked fine, but when we fired up the VM, it claimed that there was no system disk. This wasn’t a huge surprise – the original machine is an ancient Compaq Proliant with an EISA SCSI controller in it; the MBR points to a tiny 36 MB partition on the RAID 1, which contains the SCSI tools to get into the card’s firmware, and then boot off of the true C drive. Gotta love 1990’s technology. After contacting VMWare, we decided that the best route was to do the following:
- Take a drive image of the original server, and copy it to the VMWare computer’s local drive.
- Create a new VM with disks of the appropriate size (I made the C drive 20 GB larger than the original, to provide ample space for the upgrade to take place), and also mount the local drive with the image file as a disk in the VM.
- Start the VM and boot off of the imaging software’s CD.
- Blast the image onto the virtual drives.
- Copy the VM back to the NT 4 server (to ensure the same version of NTFS) and run the virtual machine conversion wizard.
This worked great, except for when it didn’t work. Why not? Well, we still didn’t have an MBR pointing to the right place, since we weren’t going to get the EISA SCISI tool partition (we tried it once on a drive image, it complained about jumpers…). So what did we do? We made floppy images of the NT 4 install floppies, and a floppy image of a fresh NT 4 Emergency Repair Disk, and ran the NT 4 recovery mode, to “Inspect Boot Sector”. That fixed the MBR issue!
Now, we got NTLDR issues. So we brought the VM back to the NT 4 server, and tried to run the conversion utility. It groused about not being able to identify the OS. Huh? Looking at the VMWare converter logs, we found the problem. It turns out that the VM was still set to mount the local drive of the VMWare workstation; removing that virtual drive solved that problem, and the conversion continued.
And lo and behold, it worked! We actually managed to virtualize a server that I originally built when I was (I beleive) a sophomore in college. This machine was my introduction to SCSI, TCP/IP, NT 4 (I had experience with NT 3.51, 3.5, and 3.1 before that, as well as NetWare), multi-CPU machines (it had 2 CPUs, amazing for the time), and a lot of other technologies (DNS and DHCP come to mind immediately). This machine really got me started hardcore in systems administration. And now it is a VMWare VM.
But I digress.
We then performed the upgrade to Windows Server 2003 R2. This went extremely well; the only hiccups we had were remembering to make a floppy image containing the VMWare SCSI controller driver to feed to the Windows setup program, and then remembering to disconnect the floppy image before the next reboot (we got another scary NTLDR error… woops!).
On a side note, we needed to make the Active Directory install post-upgrade be in a completely separate forest, since the 2003 domain can’t participate in the 2008 forest.
But we are now finally ready to migrate this domain, and I can’t wait. If our NT 4 domain could last from 1997 to 2008, I shouldn’t have to upgrade this domain until around 2019.