IT dopers - Migrating Domain controllers to VMware.

Hi.

I have done some googling for this but I often find articles that are too generic, and articles that our out of date. What would be useful is a step-by-step guide for migrating two domain controllers into a virtual environment. Does such a thing exist?

I am willing to spend the time studying the more lengthy literature on the subject if required, but it seems silly not to ask if anyone knows of a shorter guide for this sort of thing…

I have a Domain that is domain functional level 2000 mixed and forest functional level 2000. Two physical domain controllers running windows 2003.

I want to (properly, no risky shortcuts) migrate these to two virtual machines running Server 2008 R2.

Optionally (ideally but not essential) I also want to raise the functional levels to 2008.
I also need to migrate the DHCP role which is running on one of the DCs (and DNS, but that’s usually the case)
Just to be clear - I’m not asking for you to do my research for me. I’m just asking if the experienced IT dopers know of a good guide in existence for this type of project.

I’d suggest first migrating your DCs to 2008, and virtualizing from there. 2008 is easier to work with in virtual environments.

Obligatory TechNet article: Virtual Active Directory Domain Services Domain Controllers Hyper-V | Microsoft Learn

You are going to want to set up your virtual machines to bridge their network to the host machine rather than use NAT through the host. Once you set it up that way, the virtual machines look like any other real machine as far as anything external is concerned.

At that point, there isn’t anything special about your virtual machines. You set them up the way you do any real computer. Install Windows 2008 server, set up the domain controller, DHCP, DNS, etc. the same way you would a regular installation of Windows 2008.

The issues you are going to run into are just the typical issues of running in a virtual environment. You need to manage resources so that some virtual machines don’t overwhelm the host and steal all of its CPU cycles, while at the same time balancing that out so that virtual machines that are busy servers don’t get starved for CPU time and perform slowly.

Also, be aware that shoving everything onto a single host means that a single failure takes down every virtual machine with it. We run a lot of virtual machines at work and even with host redundancy we’ve still had cases where a host problem has left us without the half a dozen virtual machines that were on it for several hours while the machine gets fixed.

Should be pretty straightforward.

I’d be tempted to not uplift before migration (that technote notwithstanding, but it is a good guide).

Bring the two VMs online into the domain, promote to DCs. Test.

Transfer the FSMO roles to the VMs, and the DHCP role. Test.

Shutdown the physical servers so you are running on the VMs. Test. You can force the physical servers out of the domain or bring them up and demote them.

Shutdown the domain. Shutdown the VMs. Snapshot. Bring them up again. Backup the AD. Uplift to 2008. Test - if it all goes badly, revert to snapshots.

Thanks for the replies so far guys.

I’ve imagined it much along the same lines that si_blakely describes.

To give a bit of background - The virtual environment in question is vmware esxi running on two physical hosts. I have already created/migrated a number of member servers so I am familiar with the vmware part of the job.

I suspect I won’t be able to clone a template machine to first create the machine that will become a domain controller, I am happy to build it from scratch.

I don’t think I can raise the functional level to 2008 before migrating because the physical dcs are currently running Windows Server 2003, and I don’t think that allows one to raise the functional level beyond 2003. So as si_blakely suggests I will probably do the raise after the migration (When I think about it - the migration is the critical bit because we need to get it done sooner rather than later so that we can free up rack space, but raising the functional level can be done much later)

Yeah, I think it’s pretty straightforward. I haven’t done it for a while, but…

Create the VM’s (or one) and do DCPROMO to tell it to become a domain controller.

If your DC’s need updating to allow the new server(s) to join, the DCPROMO will tell you and stop. I think you need 2003 level to add a 2008 DC; if you haven’t updated the existing DC’s since 2000, the software will complain.

I belive you’ll need to find the 2003 SYSPREP utility (not sure it’s built into basic Server 2003); then do SYSPREP /FORESTPREP and SYSPREP /DOMAINPREP - so all the more reason to not update if you don’t have to. Do the updates after you take the Server2003 offline. (DCPROMO also gives the option to demote domain controllers to member servers).

So yes - create and promote 2008 servers, and then demote and remove the 2003 servers. Do as little domain update as you can get away with before removing the 2003 servers.

Hint - take a snapshot of the 2008 server before DCPROMO - makes it easier to go back if the promotion screws up. But geneally, that’s not a problem.

You can create and configure a DHCP scope on a DC server (or any server), just don’t activate it until you are ready to turn off the old DHCP. I recall there was a way to transfer the scope database, but why? There is an option in the settings to tell DHCP to ping before handing out an address, so it won’t create a duplicate conflict. However, IIRC, a PC will not find a NEW DHCP - it will keep trying to find the old one. To force it to look for a new one, reboot or simply unplug the network cable from the PC for 20 seconds (make network connection go dead).

Lower lease time to 1 day or less (instead of 8 days?) to force quicker change-over. Don’t forget, new DC’s means new DNS addresses too. When the old DC’s go offline (or demoted?), no more DNS, the PC’s will lose their DNS unless they have the new DHCP settings for the new DC’s. So simpler to do the transition in the evening -shut down old DC, switch DHCP to new- and people will pick it up the next morning on boot.

Alternatively, until the transition is complete, set old and new DHCP options to 1 old DNS, 1 new DNS so it will at least find one.

(IF the PC stays on the network, it will continually try renewing its lease from its current DHCP server. When it receives no response by expiry time, it says “no ip address, no network communication”. I ran across this weird behaviour 8 days after switching DHCP servers. Maybe that’s fixed in Win7? Reboot or unplugging network causes the PC to broadcast for an IP from any DHCP server, at which point it will get a new address from the new server.)

Also note Microsoft’s warning about not snapshotting DCs. The process I describe (shutting down all DCs, snapshot all DCs, restart all DCs/revert all snapshots) is the only approach you can take, and it only works for a short period of time. Otherwise, the computer accounts start to update, and AD elements expire, then when you try to revert a DC it is out of sync with rest of the AD and you get into a right mess.

So the general rule (don’t snapshot DCs) is the right one - you will only end up in a world of pain. But in some specific cases (as I described) it can be really useful.

Reverting to a DC snapshot is no different than turning a DC off then on again.

Theoretically, it will find another, up-to-date DC, and update. (Please do not interrupt this process!!!)
If it’s been off too long, it may not believe it’s part of the same domain and you are royally up-creeked.

If you are in the habit of snapshooting, then randomly turning DCs off and on and rebooting them in the wrong order, so that you end up with 2 “live” versions of the database, or there have been machines and users whose accounts have lost their password updates, then all sorts of interesting results can happen and ou will earn your pay over the next few days.

HOWEVER this is is better than completely losing your domain’s assortment of users and their SIDs.

And this is the point - you may regularly power off a DC and restart it - a period of a few minutes. This will not cause any AD problems.
You may snapshot a DC, run it for a week/month/etc, then (due to a problem) revert the snapshot because it is there - and you are then up-creeked.

Snapshotting is a different use case to power down/power up - treat them differently.

Yeah, the last time I remember powering on a domain controller after an extended period was a BDC in NT4, and that was about 15 years ago. The hardest part was remembering what the administrator password was 3 months earlier. I don’t recall if we ever reconciled it, I think we were just wanted to get some files off and then put it back to sleep.

Snapshots are good, but abusing your domain is bad.