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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yeah unfortunately both of these machines have an entire boatload of other things on them... so it's not that easy.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
http://blogs.technet.com/b/askds/archive/2010/06/10/how-to-virtualize-active-directory-domain-controllers-part-1.aspx
http://blogs.technet.com/b/askds/archive/2010/06/15/how-to-virtualize-active-directory-domain-controllers-part-2.aspx
in our case the old DCs were wiped so they can't be brought back online so no chance of USN rollbacks.
Thanks
Mike
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
http://blogs.technet.com/b/askds/archive/2010/06/10/how-to-virtualize-active-directory-domain-controllers-part-1.aspx
http://blogs.technet.com/b/askds/archive/2010/06/15/how-to-virtualize-active-directory-domain-controllers-part-2.aspx
in our case the old DCs were wiped so they can't be brought back online so no chance of USN rollbacks.
Thanks
Mike
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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
Thanks
Mike
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.
Thanks
Mike
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 download.microsoft.com/dow
[/quote]
http://communities.vmware.com/thread/16115
http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
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 download.microsoft.com/dow
[/quote]
http://communities.vmware.com/thread/16115
http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
Hold on - I just looked over VMware's best practices for time keeping, there are some great recommendations:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1318
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.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1318
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.
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..
Thanks
Mike
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..
Thanks
Mike
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.
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.
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: http://blogs.dirteam.com/blogs/jorge/archive/2010/09/26/configuring-and-managing-the-windows-time-service-part-1.aspx
They key on Windows machines is they are within 5 minutes of each other (due to Kerberos)
Thanks
Mike
Great diagram here: http://blogs.dirteam.com/blogs/jorge/archive/2010/09/26/configuring-and-managing-the-windows-time-service-part-1.aspx
They key on Windows machines is they are within 5 minutes of each other (due to Kerberos)
Thanks
Mike
ASKER
I live cloned one and created a new one as well so both worked great!
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.