Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Virtualizing Domain Controllers

Status
Not open for further replies.

Murugs

Technical User
Jun 24, 2002
549
0
0
US
We have 2 offices, one in the US and other in Canada. In canada there is just 2 physical boxes of the DC's replicating with the master domain controllers in USA through a firewall to firewall VPN setup.

Basically I need to virtualize my 2 Domain controllers in the USA. Is there a best practice document or a step by step link to achieve a smooth transition.

I plan to do this sunday.
-Take system state backups for DC1 and DC2.
-Power down DC2
-Use VMware Converter Cold boot CD and migrate the DC1.
-Power the virtual DC1 and check if everything is ok..
-If not boot into directory restore services mode and do a restore on the system state backup
-Convert DC2 the above way

Any tips here.

Murugs
 
In my experience doing a P2V on a DC is not advisable. We had nothing but problems. Our DNS wouldn't replicate, there were LDAP/Kerberos issues. You're better off creating a new, fresh, DC then demoting your old ones out. I am sure there are others that have done it and have worked but I've tried to P2V DC's on two different domains for two different companies both didn't end well. One was a 2k domain the other a 2003 domain.

I brought it up at our last VMUG meeting and most of the users there agreed that you're better off creating a new domain controller than doing a P2V of an existing DC.

If you do it, and it works, great for you but I think you'd save yourself a lot of work (and your users a lot of complaining) if it doesn't, by not doing a P2V.

Cheers
Rob

The answer is always "PEBKAC!
 
Yep defiantly just build a new DC virtualised and don't P2V or you are in for a world of hurt.
 
Agreed, build a new one. We had nothing but problems after one was p2v'd
 
The issue happens to be that there is no write cache on a DC and therefore when you P2V it, it never gets all of the data.

I recommend building a fresh DC in the VM environment. Just as theravager and ArizonaGeek have stated.


_______________________________________
I hope any help I give leads to great successes.
MCSE, MCSA, MCTS, CCA, VCP, CCNA
 
I also agree with the above

--------------------------------------
"Insert funny comment in here!"
--------------------------------------
 
Thanks to everyone for your response..I see it is best to create a new VM and then move the DC's..Is there a detailed link on the above steps as well.
 
Create a VM

Make sure dns is pointing to a existing dc

dcpromo

Wait a day check replication then configure dns to point to itself.

Move any fsmo roles if required.

 
Agreed as well. DC's should be physical, not to say you cannot have multiple VM's in the background
 
They don't need to be physical, just built from scratch as opposed to converting.

-------------------------------

If it doesn't leak oil it must be empty!!
 
you would not carry a physical DC? That is one server minus SQL in which I would keep physical. That is not to say that you cannot create VM's for backups just in case something was to crash
 
All of our DCs are virtualized, I struggled with the idea of not having a physical DC, but in reality, it's really no different than a virtual one. Sure the OS can crash, that's why you have another, sure the hardware can crash, that's why you have another...plus better use of the iron. Now, my virtual DCs are on different hosts not the same host, they're also on different SANs, gotta keep that redundancy.
 
I have to be honest and say that we have never experienced any issues with P2V'ing our DC's, admittedly they were dumped into test\training environments rather than our production one but all the same we haven't had them failing at all (they run DNS, DHCP, WINS etc) and we refresh these environments quite often (AD and Exchange etc).


If you are worried about the reliability of virtual DC's then there are a couple of ways around that, you can always utilise HA, this will reduce the risk of physical ESX Hosts crashing.

Alternatively you could have a remote DC that has a delayed replica copy of AD sent to it so that should anything occur on your live AD you can always go back to the version that is older (generally speaking keep it 90 minutes behind the live site).

Simon

The real world is not about exam scores, it's about ability.

 
It's VMware's High Availability, basically if the hardware the server is running on craps out, the VM will reconfigure itself to run on a different host.

It's really a little more complex than that and I'm sure someone with more experience can explain it better, but you get the gist of it.

 
High Availability, useable only with Enterprise ESX and you need shared storage (iscsi or fc san or nas devices) rather than local storage.

I should add that HA reduces the risk of losing the VM should a host crash rather than reducing the risk of losing the host.

Simon

The real world is not about exam scores, it's about ability.

 
I would add that Virtualizing a DC is actually possible with out worrying about AD corruption. 2 out of the 3 DC's in my domain are virtual and 1 was done with p2v. You can do this by shutting down the DC and then booting to the vmware converter boot disc. Just don't convert a dc when its live our your asking for trouble.

This worked for us at least.

John Sorensen
Network/Systems Admin
 
Oh... and one more thing to add is to set the virtual DC's nic not to connect on boot at first. You will need to reconfigure it to match what it was do to the fact that its considered new hardware with the default settings. This way you don't mess with dns.

John Sorensen
Network/Systems Admin
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top