I have a Windows 2008 server - 32bit - running in an ESX environment.
I can manually sync the time to a time server (time.microsoft.com, tick.gatech.edu, or any other time server) and the time is properly set and displayed in the system tray clock. I am also setting the time zone correctly to Eastern Time - Adjusted for DST.
Everything looks good at this point.
However, if I restart the system then the system clock is set 4 hours earlier. (i.e. 4:00 PM real time becomes 12:00PM on the system).
I then have to either force a time resync or mannual set the time to the correct hour. Minutes are not affected -- but the time is set exactly 4 hours back.
This is driving me nuts and I'm looking for a solution to this. Unfortunatly several key tasks on this server are time sensitive and this is causing a real problem.
I have doubled checked that the VMtools is not set to sync the clock to the ESX server.
Thanks for any help.
We had the exact problem last week. Turns out the time of the ESX host really does matter, as that's what the server starts with when it is reset (which we found out after Microsoft patch-reboots). What was really suspicious was that it kept resetting to the same timescale back after the reboots. In your case it is now-4h, in our case it was Now-42days. Once we got the ESX host's time straightened out, it stopped doing that and the normal Windows time-sync was able to keep it on time.
@ScottWarren - Your are correct that is the long term solution. However I wanted to take the time to fully explain why this was happenning in the first place so that other users will know why it happens to them.
Remember - in VM Tools within the client I selected that the client should NOT sync the system time with the ESX Host, however this was still occuring.
The reason for this is explained in VMWare's KB 1189.
Basically there are there are two times when a VM will ignore your request not to have a guest sync to the ESX host:
This is why this system was getting the time reset each time it rebooted. It is strange that VMware ignores the user's request for this not to occur in the first place, but now I have a complete understanding of how and why it was happening.
In this case I was seeing the time difference because of a new install of ESXi 4.1 in our environment. The new server did not have NTP settings, and therefore was suppling incorrect time information to the clients.
I also had the exact same problem a few days ago. Bottom line is that the ESX time needs to be correct or the BIOS (presented by the ESX host) comes up with an incorrect time after every reboot which messes with the time in windows. If the time delta is too large then w32tm will fail to synchronize.
Best bet is to correct the time on the ESX host, but if you are unable to do that, you can always change the maximum phase correction(MS KB article) to a larger number (default is only 5 minutes) which will let you synchronize under the condition you are in... although there are potential negative implications here if you set this to a high number (read the notes on the kb article for examples)