P2V a Domain Controller? Why would you?

Some topics seem to pop up at random intervals, one of them being virtualizing Microsoft Active Directory Domain Controller servers. The question is often either “Should I virtualize my Domain Controllers, and if so should I virtualize all of them?” or “Should I do a P2V (Physical 2 Virtual) conversion of my existing Domain Controllers, or create new ones?

In this post, I’ll be talking about the second question. While there is a lot to be said about the first one as well, I’ll leave that for future post.

Most businesses have an existing Active Directory when they decide to virtualize. There might be different reasons for going virtual with regards to Active Directory, but in my mind there are close to no scenarios where I would even consider doing a P2V conversion of an Domain Controller.

The reasons for this are plenty:

  • You need to do a cold conversion
    You absolutely should not do a hot P2V migration of a DC. If you try to hot migration, you will end up with a domain controller that is out of sync with the others, lots of issues and a really painful headache
  • Never power on the old server
    The old server, the one you did a cold P2V migration of, must never be powered back on after the new virtual instance is started. If it gets powered back on, you will once again be in a world of hurt.
  • Potential Cleanup problems
    You need to clean up the old driver stack (most P2V tools will do this for you), and you might end up with for instance two network cards that share the same IP, one of them hidden from view and not very easily removed. This could in turn make the DNS services on a converted domain controller does bind to the wrong network interface. And we all know what happens to Active Directory if DNS doesn’t work right.

I’m sure there are many other potential issues as well, like Kerberos authentication or trust failures and so on. This is not a situation you want to end up in, especially not in your production environment.

Gabrie van Zanten recently published a recipe for P2V migrations of existing Domain Controllers, called Virtualizing a domain controller, how hard can it be? and I’m confident that this method would probably work out fine.

My question is this; Why would you want to do this in the first place? It’s not like it’s hard to set up a new Domain Controller, make sure it replicates properly with the existing physical or virtual ones, transfer any FSMO roles the soon-to-be-decommissioned Domain Controller has to the new instance and then safely and timely remove Active Directory from the old server.

Of course, Gabe has a point when he mentions that the issues you might get with a botched P2V of a Domain Controller would be the same as old style bad management like using Symantec Ghost on a DC and roll back to an old image if something fails, but why risk it at all?

Deploying a new Windows Server 2008 R2 VM, running dcpromo and setting up DNS does not take a long time, nor is it very complex to do.

I have not timed this, but I seriously doubt that creating a cold P2V migration boot device, shutting down the physical server, booting the cold migration tool, do the actual P2V conversion and powering on the new VM takes less time than it takes to set up a new VM. You might argue that you will have to install anti-virus and backup agents and possibly other tools to the new VM as well, but if your infrastructure is somewhat reasonably set up with automation tools etc. this should not really be a factor to consider. Besides, if you do it this way you have a return path, after all you haven’t removed anything!

In fact, I’m pretty sure this whole post took longer to write than it would take to actually set up a new Domain Controller in my production environment.

My conclusion is, don’t bother risking a P2V of a Domain Controller. Set up a new VM instead, it’s easy, quick and risk free.

In other words, as the vSensei would say “just because you can, no mean you should”

So Gabe, as far as this one goes; You’re on your own! ;-)


  1. Whilst i would always create a new dc where possible, sometimes timescales of a virtualisation project, legacy software installed on a dc and large file server on dc’s with small companies all mean p2v ing a dc is a consideration.

  2. @Barry: Well, do you want to have large file servers on DC’s? Do you want Legacy software on it? Why not use the virtualization “excuse” and create separate VMs in those cases? Set up DFS on a new VM, and replicate the file server data. Create a new DC VM, transfer roles etc, and then remove AD from the old one. Then you can P2V it if you want to keep your lagacy app.

  3. Would be lovely if time was not objective unfortunatly when dealing with smaller customer time for ps is a big objective. In these scenarios the first aim is to virtualise to get away from the aging and unreliable hardware. Future projects can then be planned to improve on active directory and server design etc.

    I completly agree with what your saying and in an ideal world money and time no object you would everytime create new vms for the specific roles. Please also be aware I am talking about the small end of small as well.

  4. @Barry: Sure, I do see your point. I’m just playing the devils advocate, as I’m sure you are as well. There are indeed cases where time/cost will prohibit you from doing this in in a proper manner. Licensing costs alone, when splitting up different server roles, might be enough to not getting it done in the best way possible.

  5. Yeah that’s it, would be lovely if we lived in that ideal world. Unfortunatly working as a tech consultant designing and implementing virtualisation solutions on a daily basis we have to make compromises from time to time and this occasionally is one of them. But it won’t happen with great consideration.

  6. @Barry: I know how you feel. I worked as a tech consultant from ’97 to 2003 so I understand your position and that some times there just are variables that are completely out of your control.

  7. With all things once you know the risks you can plan for those risks. If you understand how active directory works virtualising AD should not be an issue.

    I prefer the cold method but have done several hot, ok warm migrations of AD (in recovery mode).

    Just be aware of how replication works and when virtualising make sure replication is paused i.e. recovery mode. Don’t forget about sysvol make sure you check it when your done.

    If you’re not comfortable with troubleshooting replication take the easy option. demote >> P2V >> premote your legacy apps and all other services should remain where you left them.

  8. I’m with Barry. “Why would you?” … Because small customers don’t have the money or ops budget to buy and maintain separate Windows servers for every new software role that M$ deems incompatible with all its other software’s roles.
    Your approach works in the corporate space where scale may justify separating the workloads, and budgets can cope with that, but for everyone else, the costs don’t justify the solution.

    1. @Ian: Fair point indeed, but in many cases switching from Windows Server Standard licenses, to Windows Server Enterprise licenses might just get you a “get out of jail free card” when it comes to adding new servers.

      Not always, not every time, but it´s well worth looking into for small businesses that are virtualizing their domain controllers.

      Also, when doing P2V of an existing DC, you will probably need a new Windows Server license anyway, it´s not like the OEM license you have on the physical server is valid when it´s virtualized now, is it?

Leave a Reply