8 comments

Synchronizing Time on Azure Virtual Machines

Published on Friday, June 5, 2015 in ,

I’m currently setting up a a small Identity infrastructure on some Azure Virtual Machines for a customer. The components we’re installing consist of some domain controllers, a FIM server, a FIM GAL Sync server and an SQL server to support the FIM services. All of those are part of the CONTOSO domain. Besides the Azure virtual machines we also got two on-premises machines, also member of the CONTOSO domain. They communicate with the other CONTOSO servers across a site to site VPN with Azure.

Eventually I came to the task of verifying my time synchronization setup. Throughout the years there have been small variations in recommendations. Initially I had configured time synchronization like I always do: configure a GPO that targets specifically the PDC domain controller. This GPO configures the PDC domain controller to use an NTP server for it’s time.

Administrative Templates > System > Windows Time Service > Global Configuration Settings:

image

Set to AnnounceFlags to 5 so this domain controller advertise as a reliable time source. Besides that we also need to give a good source for the PDC domain controller:

Administrative Templates > System > Windows Time Service > Global Configuration Settings > Time Providers

image

In the above example I’m just using time.windows.com as a source and the type is set to NTP. Just for the reference, the WMI filter that tells this GPO to only apply on the PDC domain controller:

image

Typically that’s all what’s needed. Keep in mind, the above was done on a 2012 R2 based domain controller/GPMC. If you use older versions you might have other values for certain settings, on 2012 R2 they are supposed to be as per current recommendations. But that’s not the point of this post. For the above to work, you should make sure that the NTP client on ALL clients, servers and domain controllers OTHER than the PDC is set to NT5DS:

w32tm /query /configuration

image

Once the above is al set the following logic should be active:

Put simple: if you got a single domain, single forest topology:

  • The PDC domain controllers syncs from an internet/external source
  • The domain controllers sync from the PDC domain controller
  • The clients/member servers sync from A domain controller

You can verify this by executing w32tm /query /source:

On my PDC (DC001), on a DC (DC002) and on a member server (hosted in Azure):

time1

=> VM IC Time Synchronization Provider

On my DC (DC003)(hosted on premises on VMware):

time2

=> The PDC domain controller

On my member server (hosted on premises on VMware):

time3

=> A domain controller

As you can see, that’s a bit weird. What is that VM IC Time Synchronization Provider? If I’m not mistaken, it’s a component that gets installed with Windows, and is capable of interacting with the hypervisor (E.g. on-premises Hyper-V or Azure Hyper-V). As far as I can tell, VMware guests ignore it. Basically it’s a component that helps the guest sync the time with the physical host it runs on. Now you can imagine that if guests run on different hosts, time might start to drift slowly. In order to mitigate this, we need to ensure the time is properly synchronized using the domain hierarchy.

Luckily it seems we can easily disable this functionality. We can simply set the enabled registry key to 0 for this provider. The good news: setting from 0 –> 1 seems to require a Windows Time Service restart, but I did some tests and setting from 1 –> 0 seems to be come effective after a small period of time. The good news part 2: setting it to 0 doesn’t seem to have a side effect for on-premises VM’s as well.

In my case I opted to use group policy preferences for this:

time4

The registry path: SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider set the Value Enabled to 0

And now we can repeat our tests again:

On my PDC (hosted in Azure):

time5

On my DC (hosted in Azure):

time6

On a member server (hosted in Azure):

time7

Summary

I’ll try to validate this with some people, and I’ll definitely update this post If I’m proven to be wrong, but as far as I can tell: whenever you host virtual machines in Azure that are part of a Windows Active Directory Domain, make sure to disable to VM IC Time Provider component.

Imho this kind of information is definitely something that should be added to MSDN: Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines or Azure.microsoft.com: Install a replica Active Directory domain controller in an Azure virtual network

References:

Related Posts

8 Response to Synchronizing Time on Azure Virtual Machines

Anonymous
08 June, 2015 20:39

Thanks for the informative post. Definitively a time saver (not the first time this blog saved me time!).

08 June, 2015 23:26

Thanks for taking the time to post back! Much appreciated.

29 November, 2016 07:25

Hi

Great article! Just wanted your thoughts on why NOT to trust the VM IC Time Synchronization Provider, as I assume it would get the time from the Azure host and should be updating itself from time.windows.com or similar. Having said that, I can't find any doco from MS confirming it is a trustworthy source.

17 July, 2017 02:22

Even disabling the VM IC Time Synchronization Provider the time sync doesn't happen. Changed the source to ntp server but the change in time doesn't takes place for Azure VMs

15 August, 2017 18:58

Good stuff. Testing out the registry change now w/out stopping/starting the service.
Now, if only I could figure out a way to WMI filter so that I'm only hitting the Azure machines in my environment since they're the only ones affected. . .

SaraG
25 August, 2017 19:49

Excelent article!

02 April, 2019 13:40

Is this still relevant if the Domain is Windows2016, seems to suggest in 2016 time sync-ing has changed a bit so no loner need to do this (I think) , appreciate any input on this.

02 April, 2019 14:11

Honestly I don't know. I have been focussing on different areas in the last 2 years...

Add Your Comment