Here’s how you know your week is going to contain 50% less sleep … one of your co-workers walks up to you and asks "Hey, did you know there’s a loud beeping noise coming from your server room?"

I should have gone home right then and gotten my jammies and pillow to prepare for the week.

As it turns out, the beeping was exactly what I thought it would be.  Another hard drive had bitten the dust in our would-be file server, PowerEdge 1400 that up to this point had been rock-solid for us.  With dual 1GHz P3 CPUs and 2GB of RAM, it would have made a great file server.  WOULD HAVE … except for that it had somehow managed to eat 3 hard drives before I could even put it into production.  However, this was the last straw.  3 dead hard drives in 2 months is enough to convince me that I don’t want this machine in the lineup anymore.

The plan this week was supposed to be simple.  Copy our file server and EMS Lite data to the PE1400 and bring it online.  After that, install a second array of disks in the PE1800 (where the file server once was), install Ubuntu on it, and begin using it as our VM host.  Why Ubuntu?  Because I’m budget-tight at the moment, and also because the current install of Win 2k3 Standard wasn’t utilizing all 8GB of RAM as well as the 64-bit CPUs that the 1800 now has.

This plan seemed pretty airtight, except I didn’t plan on losing server hardware just before making this transition.  However, the migration needed to proceed, and so I loaded a working RAID5 array (controller and drives) into a newer desktop box, threw Server 2k3 on it, and began the Robocopying all over again.  By now it’s Tuesday, and tonight I’m scheduled to take all the servers down and transition our PE1800 over to Ubuntu so it can be a big bad 64-bit VM host.  However, in the midst of copying file server data, I forgot about EMS Lite.

EMS our current calendaring software, and the only SQL (MSDE) database we have on-site that gets any end-user interaction.  It figures that this tiny-but-critical program would hold things up for about 24 hours while I learn how to successfully migrate the database from one instance to another without breaking things.  HUGE thanks to Jeremy Marx for taking time out of his day to help me through this.  (That’s the power of the CITRT community!)

That 24-hour period was not wasted though … during that time I did some test runs with Ubuntu 64-bit and also got our new file server straightened out.  By 3:30pm Wednesday (yes, it’s Wednesday now) I had been up for about 30 hours, but I was very please just to have conquered the EMS data issue.  I fell asleep around 4pm Wednesday and didn’t wake up until about 8am Thursday morning.

It’s now Thursday night (almost Friday morning) now, and I’m on the last leg of this transition.  All of our VMs are being copied over to another server, and once that’s done, I’ll take the old array out of our PE1800 and install a new array.  That new array will have Kubuntu 8.04 on it, and will server as our new 64-bit VM host.

I’m already starting to wear down a bit (I wouldn’t ever make it as a Bering Sea crabber), but I’m pumped to see this project finally coming to a close.  It took longer than I thought and it cost a few hours of sleep, but I feel like the benefit will be worth the trouble.

[Note:  As of 4/25/2007 The procedures in this entry were found to be incorrect, and are NOT suitable for a domain controller P2V conversion.  Please read only if you are bored.]

Some time ago, we attempted a Physical-to-Virtual conversion on our domain controller with no luck (seems the SYSVOL tree doesn’t make it through the process).  Since then we’ve brought another DC online, so I’ve been itching to give this another try.

This past Tuesday was a scheduled work night for me, so I decided to see if we could make this work.

Before I started the VMware converter program, I made a backup of the System State of the DC (still in its physical form), that way we would have a copy of Active Directory, SYSVOL, all our active policies, etc. 

After the backup was complete, I went to the VM Host machine that the Domain Controller would live on and started the P2V using VMware Converter.  After an hour or so, the conversion was done and I had an image of the domain controller sitting on the host machine.

After shutting down the physical version of the domain controller, made the proper setting changes for the VM (brought the memory allocation down and disconnected the floppy and CDROM drives), held by breath, and clicked “Start.”

The machine seemed to start up ok, but soon I started to see notices that “services have failed during startup.”  A peek into the event log revealed the problem:  The VM didn’t have a static IP address like it was supposed to.  DOH!  During the conversion process, the physical network card goes away, and with it goes your TCP/IP settings.  After adjusting the network settings and rebooting, things smoothed out quite a bit.

However, a look at the File Replication events showed that things were still not cool.  The SYSVOL tree was missing and therefore replication was not happening.

Ok..reboot again…this time I booted into Directory Services Restore mode and restored the system state that I had saved before doing the conversion.  After doing this, you’ll have to reconfigure the network adapter in your VM again to get your TCP/IP settings back.

WHEW!!  A look into the event log showed that replication was happening, and thus the system was now functioning as a domain controller again.  The only weirdness I saw was that the Net Logon service was paused.  Hm?!  I got it going, rebooted a couple times to make certain it wouldn’t pause again, and all seems to be well.

The next step?  Make double-sure that any changes you make to Active Directory get replicated to your other domain controllers.  I went ahead and brought down the second domain controller (the one that didn’t get converted) to make sure that the VM could service logons and run scripts and such.  So far, everything appears to be good!

Right now, the only “What If” I can think of is this… what if we had put the physical DC in Directory Service Restore mode BEFORE the conversion?  Would I have had to restore the SYSVOL tree from a backup?  Is there anything else that could have been avoided?  I’m no expert in this area, but it intrigues me enough that I may try the whole thing over again just to see the results.  I don’t have immediate plans for the physical box, so if it flops, I can always switch it back on for a fix.

Now I just have to find the spare time to try it out.