P2V: Domain Controllers in-depth

The official VMware KB 1006996 on virtualizing existing domain controllers recommends 4 options (simplified below):

  1. Demote the DC via dcpromo, do the conversion, then promote the DC back again using dcpromo–With all that trouble why not just build a new one?
  2. Cold Clone–Cool, except if I’m working remote I need a working out of band management solution to boot the DC with the ISO…or setup a PXE server to provide a bootable cold clone image to do this, regardless too much extra leg work.
  3. Use Directory Services Restore Mode (DSRM) and do a hot conversion, cool, but now I need to reboot these guys and hope someone remembers the DSRM password, or reset it before hand…
  4. Get rid of the old DC via dcpromo and build a new VM and promote it–no conversion at all, wait what?

Having to P2V over a hundred DCs we didn’t particually like any of these options, the KB focuses on the possibility of a corrupt NTDS.DIT if you don’t follow any of those recommendations.  For our first few we did the DSRM route:

First obstacle

What the hell is the DSRM password?
 These DCs were built years ago and no one really knew what the password was–configuration documentation be damned!
So we had to reset the DSRM password following Microsoft KB 322672.

Second obstacle

Wait, we need to reboot these things into DSRM and to do that we need to change our selection at the boot menu.
Not all of these servers have reliable out of band management solutions…

Editting boot.ini on the DC to switch the boot order seems to do the trick:

Well thats nice, now we can edit the boot.ini and just reboot the DC and when it comes back up it’s in DSRM mode (you can TS into it and verify it did infact start in restore mode).

This is still a lot of extra–there has to be a better way…

Solution

We feel disabling inbound/outbound replication and ensuring no one modifies AD objects in the DC during the conversion process is sufficient to prevent a corrupt NTDS.DIT.

We use the following two scripts, DisableRep.bat is used prior to conversion to disable replication.

EnableRe.bat is used post conversion to re-enable replication:

Remember the big rule of P2V’ing a Domain Controller is that you do not want a Update Sequence Number rollback (USN rollback).
Once you start the converted VM do not allow the source physical DC to boot up again. See this Microsoft KB for more info on USN Rollback: Microsoft KB 875495

Related posts:

  1. Linux P2V Issues
  2. P2V: VolGroup00 not found – Linux LVM
  3. Location of VMware log files
  4. P2V Tips
  5. Use VNC to manage VMware ESX/ESXi VMs
Posted in VMware | 3 Comments »

3 Responses

  1. Hyper H Says:
    March 11th, 2011 at 5:10 pm

    Have you tried creating Hyper-v on the windows 2008 domain controllers that are VMWare guess? I was talking to a co-worker who told me I would need to install IIS on them and cluster the servers before I can get to do that. This would allow a windows 2003 domain to run inside for comatiblilty of outdated apps. Do you have a doc on how to do that?

  2. Jihemme Says:
    September 4th, 2012 at 11:46 am

    Hello,

    By far the best solution is the 4th one…P2V of a DC is a non sense, period. Especially with AD where there is no primary / secondary thing. Just create a clean VM with the correct OS version, promote it, transfer roles if needed, end of the story.

    If you don’t need physical one anymore, demote it, that’s all.

    It is the fastest, safest and cleanest way to virtualize DCs, by very far.

  3. Michael Requeny Says:
    October 27th, 2012 at 9:59 pm

    Creating a new DC is definitely the safest–cleanest, best way if you can…but this article was written for an environment that was huge (DIT file was almost 20GB), consisting of many low-bandwidth circuits to these branch sites–promotion times were well over 10 hours (and would saturate the circuit).

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.