Our server 2008 R2 (non domain member) GCE instance has had system clock issues in the past couple weeks.

Using the Windows clock interface, the time zone was set to Mountain Time (UTC-07:00) and set to automatically sync with pool.ntp.org (changed that setting to time.google.com this AM). I have also verified the TZ with tzutil. Last week the time stayed correct, surviving nightly maintenance window restarts, until some point over the weekend when it changed. The effect of the change was that the time became UTC, but the time zone stayed set to Mountain Time - thus the GCE system's clock was 7 hours ahead of the local time.

There are a couple applications installed that would be buggers to "convert" to work with UTC as they send user notifications on events occurring out of office hours, so I'm trying to figure out how to keep it on MST.

Have looked at this option: Google Compute Engine Windows locale

And didn't really find any answer from this post: exact documentation for clock sync on GCC VM's?

Anyone else had to solve issues keeping windows servers in GCE synced with local time?

  • 3
    It might help to set the RealTimeIsUniversal registry key. – Michael Hampton Dec 12 '17 at 16:37
  • From what I'm reading about that it sounds like a likely fix. Thanks for the help....I've added the key and value, and gave it a clean reboot cycle, and the time has held. I'm thinking that the reason the issue doesn't manifest itself during nightly maintenance windows is that the instance hasn't been going through a clean windows shutdown. – Pat Weichel Dec 12 '17 at 17:30

As a workaround for Windows Server 2008 R2 you can try to use RealTimeIsUniversal registry key, as it was suggested in the comment section by @Michael Hampton, if you're facing same issue.

Newer versions of Windows Server contains improvements 1 2 that give a more accurate system clock with NTP, and make it more accurate when running in a VM.

Also, please have a look at the documentation Set up network time protocol (NTP) for instances section Configure NTP for your instances:

Google can’t predict how external NTP services, such as pool.ntp.org, will handle the leap second. If at all possible, it is recommended that you do not use external NTP sources with Compute Engine virtual machines. Even worse, using both Google's NTP service and an external service can result in unpredictable changes in the system time. Using only a single external NTP source is preferable to using a mix, but external NTP services, such as pool.ntp.org, will likely use stepping to handle the leap second. As a result, your virtual machines may see a repeated timestamp.

You can check current configuration on your Windows VM with PowerShell command:

w32tm /query /configuration

If you see a single record pointing at metadata.google or metadata.google.internal, you do not need to make any changes. If you see multiple sources, mixed between metadata.google and a public source, you need to remove the external server.

In addition, be aware that Windows Server 2008 and Windows Server 2008 R2 are approaching the end of their support lifecycle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.