I think it must have been slowly working it's way out of sync since the internet time server stopped working. Over a long weekend while I wasn't monitoring it I could easily see it build up an hour. Will monitor the exact delta over the rest of the day and see if it creeps any more.
CMOS isnt reliable my servers were doing wierd things when it looked at CMOS so just point to uk.ntp servers then send resync command to clients
Sorry, I understood that Sync is disabled, but the Virtual BIOS has to get the initial time (during its 'power-on') from somewhere. In this case the initial seed from the host has the correct time settings, so either way can't be the root of the problem.
Just out of interest is it exactly or 'about' one hour out? <<-nevermind, answered already!
VMs cannot hold time. this is why they must sync with an external source, and why the Time Sync Service exisits, however as you have done, Best practice for domain environments is to disable that and use NTP instead. If connection to NTP is lost then the PDC emulator falls back to 'clock ticks' which are generally fine when running on bare metal, but utterly unreliable inside a Virtualised environment.
VMWare based but the prinicples hold: http://www.vmware.com/files/pdf/Time...alMachines.pdf
Last edited by psydii; 3rd May 2011 at 01:25 PM. Reason: too slow, question answered already.
If you are part of an LEA you may find that some external times sources are blocked. I know that I have to use our LEA's timeserver as we cannot get out on port 123(i think its that)
We're independent, our Internet connection is a raw VDSL feed from Zen. Port 123 is not blocked on our router.
Only $1500! BARGAIN!
Now I think about it, I wonder why all our phones that have GPS built in can't sync time from it? My Android can only sync from NTP or the mobile network, but the data is clearly available because I can see it in the GPS Essentials app.
Use uk.pool.ntp.org rather than europe.pool.ntp.org
OK, it seems to be good news so far:
After reconfiguring the FSMO DC to sync from a different time source, it synced correctly. Logged in to each replica DC via RDP and ran w32tm /resync /rediscover, and they synced correctly with the FSMO DC.
I then moved on to the other servers, but before I could get to all of them, some had already resynced on their own. Same for some of the workstations I've hit so far. I've also tested a simple reboot and that kicks the time update into effect as well, so if any are being petulant tomorrow morning I can hopefully instruct users to restart them and all will be well.
Finger crossed for tomorrow morning!
There are currently 1 users browsing this thread. (0 members and 1 guests)