1 person found this helpful
There's your problem, you have Windows time service running and are syncing from the ESX host. It should be one or the other. The PDC should be the only DC syncinf from an NTP source. Try disabling the VMware Tools time sync.
Good docs to read...
Configuring windows time service (not in ESX) - http://www.windowsnetworking.com/articles_tutorials/Configuring-Windows-Time-Service.html
Vmware time sync and windows time service (understand windows time first) - http://kb.vmware.com/kb/1318
Timekeeping in VMware virtual machines - http://www.vmware.com/pdf/vmware_timekeeping.pdf
How to configure an authoritative time server in Windows Server 2003 - http://support.microsoft.com/kb/816042
Fyi if you find this post helpful, please award points using the Helpful/Correct buttons.
Visit my website: http://vmware-land.com
I disagree with that approach! There's no reason you can't use both in conjunction with one another, and with our DC's, we do use both. The issue, as we've found it on our DC's, is that using the "nosync" option has led to the time not synching properly and time drift occurred with fair regularity on the DC's. In the enve, we just left w32time alone on the DC's, but still sync time with the hosts. That's worked out to be the best option in our environment.
In a Windows AD environment the top of the time pyramid is the PDC. Using "nosync" is an option but I would rather use Windows Time Service and not have another variable that could potentially change the time. What if the time changes on the ESX host and incorrectly changes the time on the DC. I prefer to set the PDC to sync from NTP and then rely on Windows Time Service to do it's job to propagate the time throughout the domain.
This issue seems to have no definitive answer. Thank for the insight provided above.
The problem I see with relying only on W32time is clock drift on the VM during the 8 hours between the NTP polling cycle. Is there an option to force NTP to poll hourly instead of waiting the 8 hours?
The problem I see with relying only on VMtools and using W32time with the "nosynch" on the PDC is that because of "nosynch" the PDC will eventually stop considering itself to be a valid time source and stop serving time internally.
Using both would seem to be the logical choice but VMware recommends against it. Why?
In my environment we have an edge device getting time from a NIST source and serving it to the inside. If the PDC VM and the ESX Host were both using that as their trusted time source what would be the problem.
VM support informed me of a bug in 3.0.1 that can cause Host time to drift. I have set up an hourly cron job to restart NTPD and force a synch to remedy this.