Some web resources about how to virtualize a domain controller;

Best practices and recommendations:

Please pretty please do not just hit the button and P2V/ColdClone/HotClone/Copy your Windows Server Domain Controllers, regardless if they run Windows Server 2000/2003/2008 etc.

In best case You accomplish to virtualize your domain controllers, wich You could have done with a few simple steps just as easily with out any danger.

In worst case You render your Domain Controllers useless, create several other problems and hickups in your infrastructure, not limited to complete production halt and at least several hours of pain and horror trying to get everything back and running!

Personally I have nothing against virtual Domain Controllers, usually best practice is not to run all kinds of other software or services on a Domain Controller, plus the need to have multiple Domain Controllers for redundancy will quickly add alot of boxes doing very little. Virtualizing some or all of these Domain Controllers, will put better use of ressources and still keep the box seperate from other services. Dont forget to change time synchronisation settings in the w32time service, vmware tools and ntp servers in the ESX’s, but thats another story.

One of the big problems with doing a clone of a Domain Controller, is that if you get problems, you will not notice them untill it is too late. The domain controller will seem to function and work with clients, but it will actually have stopped replicating with all other domain controllers, because it has detected that it has been copied. The result is an inconsistent domain with client records not being updated, they will slowly stop working depending on what domain controller they get in contact with, untill everything goes dead. If you have then virtualized ALL domain controllers, You will be left with 1-3 months of changes going down the tube together with your damaged Domain Controllers. Dont forget to take a full backup of at least 1 Domain Controller before starting your cloning!

So what happens when things go bad?

  • First of You might get problems, but no event log entries – aarrggh try and detect that!
  • If a Domain Controller replicates data after being cloned, it will acknowledge what information it has replicated to the other Domain Controllers. In effect they know what the cloned Domain Controller knows. If the Cloned machine is then turned on, with older information, the other Domain Controllers will refuse to give it the information – after all they know it has allready gotten it! This will create a missing gap of information potentially creating big problems. It is usually refered to as USN Rollback and is a common symptom of a Hot Clone or a Domain Controller that was cloned but the original got Turned On after the cloning. More info here
  • If a Domain Controller detects disk signature changes, it will put it self in isolation and refuse replication. Basicly it has detected it has been copied and to avoid replicating wrong information to others it isolates it self. It still keeps on running and serving users, but since it can not replicate, it does not replicate important information like password changes, machine information, etc.
  • Microsoft does not support cloning of Domain Controllers – your on your own!
  • VMware does not support cloning of Domain Controllers – your still on your own!

VMware have more pain and death information about cloning an existing domain controller here

How do we avoid all this pain and death? Here is a couple of ways You can safely virtualize your Domain Controllers.

  • My prefered way. If it is just a Domain Controller (It should be), why not just create a new virtual server from scratch and DCPROMO the server up to a new Domain Controller, and DCPROMO down your old server and decommission it? Safest, easiest way of doing things. (dont forget to move FSMO & GC Roles)
  • Now imagine You have a server full of other servicesas well, and for some reason You feel it is just not worth it doing one from scratch (Yes you can copy DHCP databases, shares, DNS, etc. from one server to another!), well then do this – Make sure You have another Domain Controller running including a Global Catalog server, move any FSMO roles away from the domain controller to another server, then DCPROMO it down to a regular server. ColdClone the server. Turn off the physical server (never reintroduce it to the network!). Turn on your virtual server, DCPROMO it back to a DC and move any FSMO/GC roles as needed. Done!
  • You only have one server, it is full of stuff (i.e. SBS?). You could just clone it hope for the best and cry if it fails… Or set up a temporary Domain Controller on a new (virtual?) server (yes it is possible to have multiple domain controllers in a Small Business Server setup – but only 1 SBS), replicate the domain, create a full backup, backup and restore the database.. up to you, but I would not recommend it. Whatever You choose here, make sure the physical server is never turned on after cloning, dont change disk sizes, and create a full backup before you start! Basicly your physical server will be your best backup, but it is not enough to ensure no problems will happen!

I know some people say, well it worked when I did it.. It is like saying I do not need RAID on my servers storage, I have not had a Disk failure ever! When You have the problem, it doesnt matter how many times it worked, you have the problem!

So a quick check list of do’s and dont’s

  • Do a full backup first (at least active state!)
  • Do have more than one Domain Controller
  • Do NOT turn on the physical server again – ever – after cloning it
  • Do clone your server, while de-promoted and promote after cloning again
  • Do NOT clone ALL your Domain Controllers at the same time, leave at least one physical for 3 months
  • Do create new virtual Domain Controllers to replace old physical
  • Do NOT change disk sizes or types during a clone
  • Do check event logs after cloning to check for problems
  • Do NOT use normal time settings on virtual Domain Controllers
  • Do look up best practices for virtual Domain Controllers time settings