Domain controller time drift

[snowmizer]

I have a virtual domain controller running Windows 2003 Sever. This DC is set to perform time synchronization via VMWare tools with the ESX host. The ESX hosts get their time from a physical DC that gets its time from an external source. Everything on all of my servers appears to be fine with time except on my virtual DC. The virtual DC time is ahead by 3-4 minutes. This VM used to be on a different ESX host but was migrated recently to another ESX host. So the only thing I can figure is that for some reason the old ESX host was off on time by 3-4 minutes. All other VMs and all of my ESX hosts are reporting the same time as my physical DC.

I would like to get my virtual DC back in sync with the rest of my domain. I contemplated the possibility of shutting off the virutal DC until the time it was reporting is past then disconnecting it from the network, changing the time so that it matches the rest of my domain. My problem though is that since this is a domain controller I don't want to do anything that is going to cause me to have to rebuild this domain controller.

Has anyone else run into this issue? Is what I'm thinking valid for a domain controller?

Thanks.

[rossb2b]

I use vmware tools for time sync on all VMs except DCs. My DCs use NTP as do my ESX servers. I have not had any issues with time in my environment with this setup.

[aguacero]

DC's should time sync with other DC's. Not recommended to get time from ESX hosts unless in a test environment but never in production. Have the domain controllers time sync between each other. Master time server (DC) have it pointed to public pool ntp server e.g. us.pool.ntp.org. Then have each esx hosts point to the same pool or use 0.vmware.pool.ntp.org, 1.vmware.pool.ntp.org., 2.vmware.pool.ntp.org. This setup rocks for me!

[snowmizer]

I had my virtual DC set up to sync it's time from an external source but the site I was using for my time sync was causing issues with time being synched correctly. I haven't had any real issues with synching from the ESX host via VMWare tools (actually this was how VMWare told me I needed to set up my time sync).

I just think my problem this time was that the ESX host I had this VM on started off by being 3-4 minutes off so that's why the DC is off now. Unfortunately, this was an old ESX host so I can't prove that theory.

I just want to make sure that if I shutdown the VM, disconnect it from the domain, wait until the time it reported is past, power the VM on and then manually set the time it will work without causing havoc on my domain.

Thanks.

[snowmizer]

One other note, my ESX hosts are synching with my physical DC.

[ctfoster]

It's not recommended to use VMTools to keep Windows DC's in line. Why don't you simply turn off VMTools time sync and allow the VM to take the time signal from the DC with the PDC Role. I assume the physical DC is the PDC.

The command

net time /setsntp .. will force the DC to take the time signal from the PDC. Stop and start the Windows Time Service and check the log for errors. See if that improves the situation. Don't worry about the time difference it converge over a period of time.

[rossb2b]

check out this VMworld presentation: http://download3.vmware.com/vmworld/2006/tac9710.pdf

[snowmizer]

Thanks for all of the great input. One other question, in our DR scenario we don't have a physical DC so the time sync would not be configured properly on our restored DC. How are other people handling DR?

Thanks.

[ctfoster]

One other question, in our DR scenario we don't have a physical DC so the time sync would not be configured properly on our restored DC.

The issue might a liitle more fundamental than that. If you are planning a complete DR strategy that takes into account AD then you will need to end up with a machine, VM or Physical, that holds all the FSMO roles. Assuming that the only machines you have are your VM's you will have to use one of the them to sieze the roles of the missing physical DC - that includes the role of PDC Emulator which acts as the time source for the domain. Once this is done and the panic is over I would add a new physical DC and move the PDC emulator back onto it.

[snowmizer]

We do have the seizing of the FSMO roles in our DR notes since we don't have a physical DC. Maybe we just need to change our notes so that we set up the virtual DC to access the external time source after we seize the FSMO roles.

Thanks.

[piercelynch]

I for one have also had issues with VMWare Tools and Time Syncing on guest VM's like this - which drove me insane for a few weeks. In the end I scraped it, and using a proper NTP service which all machine sync to on a given network. The DC's sync between each other, as to all other member servers. The main DC server respoinsible for NTP collects this from an external NTP server which is maintained for all networks to access.

Never could of thought having the correct time could be so much hassle 😛

[ctfoster]

Yes - the PDC really needs to see the external source whatever its status.

[snowmizer]

Turns out that the method we are using for setting up NTP on our virtual DC is fine in our case (verified with VMWare). I was able to get this time difference resolved this weekend.

Thanks to everyone who posted a response. Your responses were helpful.