Cold converting Active Directory server for VMWare ESX

We have a two host VMWare ESX system setup and are moving all our servers on to this system.

I need to convert two AD servers, both are running AD and DNS.  Both are global catalog servers.  I have made a cold boot cd with the correct drivers injected into it for booting them and cold cloning.

My question is if I shut down one of the AD servers on a weekend and cold clone it and then bring it back up hours later won't there be issues because of the changes made on the other AD/DNS server while this one was being cloned?

After I clone it, I will need to boot it and setup networking correctly, remove all the ghost hardware remaining in the system, etc.  

Will I need to then boot into DSRM once the machine is ready and do a non-authoritative AD restore?  Is this even necessary?

What is the best method for cold cloning AD servers, any known issues, etc?
Who is Participating?
jdfultonConnect With a Mentor Commented:
I have successfully virtualized domain controllers with very little issues.  One main recommendation is not to do them all at once.  I would do the primary first then let it settle for a few days and verify everything is working.  Then move to the next.  Below is a good article to read about the whole virtual DC scenerio.  Again it all depends on your situation and what your DC's have running.  Naturally if DHCP is running on one server you will want to make sure it is working correctly.

If the two AD servers only host AD and DNS, then why bother cold cloning?

It would probably be quicker and easier to install an OS and DCPromo the servers into AD.

If you do clone it, there won't be any problems with bringing it back on line a few hours later.  Recommend you run DCDIAG before you start and after the cold clone.

The one problem I can see you have is when you setup the network after cold cloning.  Because you have removed the old NIC and created a virtual NIC, the DC may have a fit if it can't establish it's own IP address.

If it were me - I wouldn't clone it.
norcaltyAuthor Commented:
Yeah unfortunately both of these machines have an entire boatload of other things on them... so it's not that easy.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

jakethecatukConnect With a Mentor Commented:
What else is running on these servers then?

What may be a better option for you is to do the following: -

1. Run DCDIAG /E to check your AD
2. Create a couple of brand new VM's and DCPROMO them up.  Transfer all the FMSO roles and schema to one of the new servers.  Also, make them all GC's.
3. Run DCDIAG /E again.
4. On your physical servers, DCPROMO them down and remove AD from them.
5. Run DCDIAG /E again.
6. P2V your physical servers without the issues of AD.

Obviosuly, once the physicals have been coverted and you want to make the DC's again, run steps 1-5 again but with step 4, DCPROMO the VM's you created earlier.
Mike KlineCommented:
Those changes will just replicate to the box, what you don't want to do is bring the original back online once the new one is up

We just went through P2Vs where I am with DCs and we used the offline/cold clone method using VMware converter and it worked fine.  We did run into 13559 FRS events (easily fixed).  On the next set I'm going to use VolumeID to change the volume ID to match the original disk.

Our back end has good redundancy and our data centers are 2,000 miles apart so we are also not in danger of losing all of our DCs with a single SAN failure or a single host failure.

So far we have not noticed any performance issues

The DS team wrote a good blog series that may help you too

in our case the old DCs were wiped so they can't be brought back online so no chance of USN rollbacks.


Paul SolovyovskySenior IT AdvisorCommented:
The only way I convert Domain controllers if I really need to is disconnect from network connect via crossover cable to ESX host and convert using vCenter vmware converter.  This way there is absolutely no way that any changes can be made or any workstations or AD records updated until you P2V the machine
VMwareGuyConnect With a Mentor Commented:
It sounds like a big headache - especially when you can deploy a new VM in minutes and promote it to become a DC.   However, the extra services, hmmm, you will have to decide if these services can also be easily created just like promoting the DC.  Regardless, I have P2V so many servers I can;t count em all, and I have always used live cloning, not cold, did you even try a live P2V with VMware standalone converter?  

Either way - what ever method you choose to P2V, or not to P2V, when you bring up the new VM (DC) make sure the old one is offline, then force replication to and verify all is working.

Now, here is the important piece - you now have a DC running as a VM.  This is where you need to be careful with time sync in your environment.  You will need to make sure all of your clients still have a time source right?  VMware recommends syncing your VMs time with the service console, this is done using VMware tools within the guest OS, and shutting off windows time service.  But with a DC, your clients typically get time from it right?  So how do you do what VMware recommends?  You simply enable time sync in VMware tools, but keep windows time running to serve time to clients, and you then go into the registry and set a NOSYNC option so windows time doesnt' try to sync with any outside source, this way the VM gets its time from ESX, but can still serve time to the environment.. On that note, make sure your time source for ESX is a good one!  

AS for this boot into DSRM, I don't see why this is all needed... you should be able to bring the VM\DC up, and let it sync, or manually force it to.  Important thing to do is disable the hardware related services in the service applet during the P2V process so that the server will come up clean.. also, try booting into safe mode first before booting up normal, it helps to ensure a safe transition.  You will have the same SID, and most everythign will be exactly as it was before and your services should work normally.    
Mike KlineCommented:
I would not time sync with the host, let the windows time hiearchy work as intended.  
From the Microsoft Link part 1
For Microsoft Virtual Server or Hyper-V server, turn off host time synchronization from the properties of the VM.
What I find interesting is that in VMware the default is to not sync with host and in Hyper-V the default is to sync with host.  I'm guesing future versions of Hyper-V will follow VMware and not sync with host by default.
Who cares what the default is, the are plenty of "defaults" that are corrected with the publication of white papers and best practices which you need to pay attention to.  and who cares about Hyper-V? Is that part of the post?  

Read this from VMware:

If You Must Run Windows Time Service
If you use a virtual machine as a primary domain controller for a Windows network, the primary domain controller must run the Windows Time service as a time server, to provide time to secondary domain controllers and other hosts on the network. However, that primary domain controller does not need to use the Windows Time service as a client to receive time synchronization input for its own clock. You can still use VMware Tools to synchronize the virtual machine's clock while running the Windows Time service in a server-only mode. For instructions on setting up the Windows Time service this way, see the Microsoft document titled "The Windows Time Service," at Search the document for the NoSync registry option.

Hold on - I just looked over VMware's best practices for time keeping, there are some great recommendations:

Ironically, I read that the above quote I left you with has been removed from this article, it used to be in there but I think that VMware has recognized that you can effectlively use windows time in the configuration outlined in this article.
Mike KlineCommented:
I brought up Hyper-V because I was referencing the Microsoft article, that is why I mentioned both products.  It looks like both Microsoft and VMware are giving out the same recommendation.
In the end he will be running the Windows OS on most hosts so you have to look at recommendations and articles from both vendors.
I'm not here to try to get into a flame war with you about the merits of Microsoft vs VMware and who will dominate the planet first..
I have extensive experience with time drift issues.  I worked in an enterprise that over loaded VMs on its hosts, this resulted in a lack of available CPU cycles needed for the VMs to keep proper time.  The nightmare you have heard about happened to me, the clocks were ticking slow and access denied message were happening within applications becuase the time skew and with kerberos etc etc...  

The resolution consisted of some re-architecting yes, but it also included changing from using windows time within the windows guest OS to using the the sync option in VMware tools.  

VMware tools sync option will sync time each minute, w32time does it every 4 or 6 hours, can't remember, but it is one of these..   so in retrospec, knowing that the VM clock can drift, wouldn't you want it to sync more frequently?  This parameter can be adjusted in w32time and the VMware KB ariticle I mentioned provides recommended parameters. So its not like you are stuck with the windows default.    

But Also, when a VM has been powered down for a while its clock isn't ticking, its dead because it relies on CPU cycles.  The VM then must sync up with the DC during boot up to get its time right, and we all know how inefficient that is.. you might end up with a clock that is behind and is being speeded up in order to get it in sync, that is what w32time does.. you don't need a clock that is being forced to speed up.. after all, it was only behind because the VM was down and failed to contact a DC upon boot, it isn't really lagging, so therefore the algorythms in place that would help a physical server actually work against the VM.

This is what you need to think about.  

In summary, as long as your VMs can reach a DC to perform time sync when they are booted up after maintenance, you are good.  If you want your w32time to sync more often modify the registry of all your windows VMs, kind of a pain..

Finally, the DC needs to provide time to clients, but should also have a good time provider.. make sure you have a good master time server, and make sure the primary time provider in your environment is a physical server, not a VM.  
Mike KlineCommented:
Right generally the PDCe in the forest root syncs with a external/reliable source and then the rest of the domain uses the windows time hierarchy from there.
Great diagram here:
They key on Windows machines is they are within 5 minutes of each other (due to Kerberos)
norcaltyAuthor Commented:
I live cloned one and created a new one as well so both worked great!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.