Search
Wednesday, January 07, 2009 ..:: Home ::.. Register  Login
Blog roll

Topic search

UsersOnline
Membership Membership:
Latest New User Latest: ginnyihmv
New Today New Today: 1
New Yesterday New Yesterday: 0
User Count Overall: 121

People Online People Online:
Visitors Visitors: 0
Members Members: 0
Total Total: 0

Online Now Online Now:

Blogs
Aug 21

Written by: Justin James
8/21/2008 5:46 PM

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:

  1. Take a drive image of the original server, and copy it to the VMWare computer's local drive.
  2. 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.
  3. Start the VM and boot off of the imaging software's CD.
  4. Blast the image onto the virtual drives.
  5. 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. :)

J.Ja

Tags:

7 comments so far...

No Guts, No Glory!

Sounds like pure torture to me. Anyhow, glad you were able to persevere.

Some of the steps taken weren't detailed but folks who do the 'VM thing' may avail themselves to pointing their CD/DVD ROM to a Knoppix ISO file.

Advantage? You bring in a host of utilities (free) which can help you maneuver out of tight spots.

o fdisk
o qtparted
o gparted
o ntfsresize
o ntfsfix
o ntfsclone
o ntfsundelete
o dd
o dd_rescue
o ssh

In fact, just because of these, creating a persistent knoppix image on a usb pen drive hanging around your neck on a lanyard is the way to go. An instant bootable 'Swiss Army Knife'.

Good Work Justin and You have nothing to fear but fear itself. ;)

By dietrich on   8/21/2008 8:55 PM

Re: NT 4 to Windows 2008 Migration - almost ready!

P.S. That's booting Knoppix 'inside' the VM to access the VM's drive image Folks.

By dietrich on   8/21/2008 8:58 PM

Re: NT 4 to Windows 2008 Migration - almost ready!

Yeaqh, what you describe with Knoppix is more or less what we did, with Acronis. I did consider using a *Nix live CD, but since we already had other tools that we were comfortable, we did it like that (personally, using *Nix tools on an NTFS partition has always worried me).

J.Ja

By jmjames on   8/21/2008 11:06 PM

Re: NT 4 to Windows 2008 Migration - almost ready!

Yuck. If it's fewer than 50 users, just recreate all the accounts and redo the security permissions and start fresh with 2008. I wish Microsoft would simply let you export the AD database and import it in to 2008 rather than going through all that crap.

By host on   8/22/2008 7:44 PM

Re: NT 4 to Windows 2008 Migration - almost ready!

The problem with doing that, is that it means that when the users log into their PCs, even if it is the same username in the new domain, it will treat it as a new user account. That means that all of their previous user-specific information, like application settings, will be lost. The general feeling is that the amount of time needed to do a true migration (so far, about 2 man-weeks to get both domains in a state that they are ready to be migrated... which was 90% problems with the NT 4 server described above) is still far less than the pain that would be caused by having all users lose their settings. The big one, for example, isn't just the users per se, it's the zillions of VMs set up for test purposes! We've got something like 15 - 20 truly active user accounts, about 40 physical machines, and a ton more VMs. Overall, if it's a choice between dealing with frustrating computer stuff in the backend, or dealing with frustrated users... I'll slave away in the server room. :)

J.Ja

J.Ja

By jmjames on   8/22/2008 10:25 PM

Re: NT 4 to Windows 2008 Migration - almost ready!

I think there are SID migration tools, but I believe they're commercial. XP had a user profile migration tool I think built in.

By host on   8/23/2008 12:18 AM

Re: NT 4 to Windows 2008 Migration - almost ready!

Heck, the SID migration tools are free... just download the "Active Directory Migration Tool". It nicely handles things... it creates a new user in the new domain with the same settings, membership, etc., and adds the previous SID to its SID history. This way, the clients treat it merely as a SID change for the same user, and permissions don't need a reset either. The problem is, this tool in version 3.0 supports NT 4 domains, but not Windows 2008 domains. And the version 3.1 (latest version) supports Windows 2008 domains, but not NT 4 domains. That's what the last 2 weeks have been about for me, figuring out a way to safely upgrade the NT 4 domain to 2003, while people were using it on a daily basis. And that's where all of the crazy VM'ing came into play.

Once the upgrade was finally done, it took me less than an hour's worth of work to get ADMT working and a sample user migrated over. :)

J.Ja

By jmjames on   8/23/2008 1:03 AM

Your name:
Title:
Comment:
Add Comment    Cancel  

Links

Blog_Archive

New_Blog
You must be logged in and have permission to create or edit a blog.

Search_Blog
Print  

Copyright 2008 by George Ou or Justin James   Terms Of Use  Privacy Statement
DotNetNuke® is copyright 2002-2009 by DotNetNuke Corporation