A
AllanSandoval
Hey everyone! Allan Sandoval from the Directory Services team here.
We've all experienced a lot of changes since the rise of cloud computing and virtualization, and our time synchronization technology (Windows Time) is no exception.
Today, I want to shed light on the VMICTimeProvider and its impact on Virtual Machines (VM) within an Active Directory Domain Services (AD DS) environment. If your domain members and/or Domain Controllers (DC’s) are virtualized, this article is for you.
Typically, in an on-premises deployment, you use your Forest Root Primary Domain Controller (PDC) as a time source for all your domain client machines and for other DCs. This PDC syncs its time with your configured external time source, and this setup remains effective for many of our customers. But what happens if your DCs are virtualized?
The VMICTimeProvider allows VMs to synchronize their time with their host. While this can be useful for some organizations, you might prefer to have your machines synchronized from the same time source and maintain a traditional AD DS Time Hierarchy; (which is the Microsoft recommendation). If this traditional hierarchy resonates with you, then your clients should sync their time with their closest DC and have those DCs synchronize their own time with the PDC.
Azure Virtual Desktops (AVD) sync with their host by default. You can query the current configuration’s Time Provider on any Windows machine with either of these two commands:
From both commands you will get the currently configured Time Source provider, if you get “VM IC Time Synchronization Provider” as a result in the output, then that machine is using the VMICTimeProvider.
If this is the case for you, and you want to keep the traditional ADDS Time hierarchy, you should disable the VMICTimeProvider on your desired VMs. To do this, modify the following registry value, which will effectively disable the VMICTimeProvider as a time source on these:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\ VMICTimeProvider\
DWORD: Enabled
Value: 0
The default value for this DWORD is 1.
For this change to apply to the machine you must restart the W32Time Service, you can perform that using the following commands on an Elevated Command Prompt:
You should be working with your previously configured ADDS Windows Time settings afterwards.
But it doesn't stop there. It’s not uncommon to find DCs being virtualized nowadays. In this case, you would also want to disable the VMICTimeProvider on those DC's, so they get their time from the Forest Root PDC. The Forest Root PDC must also be configured in this way, so it too gets its time externally from your configured time source, rather than syncing with its own host. The same registry key specified above can be modified on the DCs to make that change.
What about physical machines?
You can also deploy this registry key on bare metal machines for an added benefit, this will prevent the regular informational Event ID 158 from Time-Service getting logged in their System event log.
We have recommended this approach for customers who have faced issues with their Windows VMs time jumping around in their on-premise domains. This has occurred even though they have their Time Settings configured through a well configured GPO (Group Policy Object). The virtualized machines were not following the GPO settings because they were picking up their time from their host instead. This is expected behavior and here is a reference:
“w32time would prefer the time provider in the following order of priority: stratum level, root delay, root dispersion, time offset. In most cases, w32time on an Azure VM would prefer host time due to evaluation it would do to compare both time sources.”
Time sync for Windows VMs in Azure - Azure Virtual Machines | Microsoft Learn
We recommend disabling the VMICTimeProvider if you plan to leverage an existing on-premises ADDS Time Hierarchy. This way your machines will avoid syncing the time with the host and follow your designed Time Hierarchy instead, this way the time across your domain will remain both reliable and accurate.
References:
Time mechanism for Active Directory Windows Virtual Machines in Azure - Azure Virtual Machines | Microsoft Learn
Time sync for Windows VMs in Azure - Azure Virtual Machines | Microsoft Learn
Configuring an Authoritative Time Server with Group Policy Using WMI Filtering - Microsoft Community Hub
Continue reading...
We've all experienced a lot of changes since the rise of cloud computing and virtualization, and our time synchronization technology (Windows Time) is no exception.
Today, I want to shed light on the VMICTimeProvider and its impact on Virtual Machines (VM) within an Active Directory Domain Services (AD DS) environment. If your domain members and/or Domain Controllers (DC’s) are virtualized, this article is for you.
Typically, in an on-premises deployment, you use your Forest Root Primary Domain Controller (PDC) as a time source for all your domain client machines and for other DCs. This PDC syncs its time with your configured external time source, and this setup remains effective for many of our customers. But what happens if your DCs are virtualized?
The VMICTimeProvider allows VMs to synchronize their time with their host. While this can be useful for some organizations, you might prefer to have your machines synchronized from the same time source and maintain a traditional AD DS Time Hierarchy; (which is the Microsoft recommendation). If this traditional hierarchy resonates with you, then your clients should sync their time with their closest DC and have those DCs synchronize their own time with the PDC.
Azure Virtual Desktops (AVD) sync with their host by default. You can query the current configuration’s Time Provider on any Windows machine with either of these two commands:
w32tm /query /sourcew32tm /query /status From both commands you will get the currently configured Time Source provider, if you get “VM IC Time Synchronization Provider” as a result in the output, then that machine is using the VMICTimeProvider.
If this is the case for you, and you want to keep the traditional ADDS Time hierarchy, you should disable the VMICTimeProvider on your desired VMs. To do this, modify the following registry value, which will effectively disable the VMICTimeProvider as a time source on these:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\ VMICTimeProvider\
DWORD: Enabled
Value: 0
The default value for this DWORD is 1.
For this change to apply to the machine you must restart the W32Time Service, you can perform that using the following commands on an Elevated Command Prompt:
Code:
net stop w32time
net start w32timeYou should be working with your previously configured ADDS Windows Time settings afterwards.
But it doesn't stop there. It’s not uncommon to find DCs being virtualized nowadays. In this case, you would also want to disable the VMICTimeProvider on those DC's, so they get their time from the Forest Root PDC. The Forest Root PDC must also be configured in this way, so it too gets its time externally from your configured time source, rather than syncing with its own host. The same registry key specified above can be modified on the DCs to make that change.
What about physical machines?
You can also deploy this registry key on bare metal machines for an added benefit, this will prevent the regular informational Event ID 158 from Time-Service getting logged in their System event log.
We have recommended this approach for customers who have faced issues with their Windows VMs time jumping around in their on-premise domains. This has occurred even though they have their Time Settings configured through a well configured GPO (Group Policy Object). The virtualized machines were not following the GPO settings because they were picking up their time from their host instead. This is expected behavior and here is a reference:
“w32time would prefer the time provider in the following order of priority: stratum level, root delay, root dispersion, time offset. In most cases, w32time on an Azure VM would prefer host time due to evaluation it would do to compare both time sources.”
Time sync for Windows VMs in Azure - Azure Virtual Machines | Microsoft Learn
We recommend disabling the VMICTimeProvider if you plan to leverage an existing on-premises ADDS Time Hierarchy. This way your machines will avoid syncing the time with the host and follow your designed Time Hierarchy instead, this way the time across your domain will remain both reliable and accurate.
References:
Time mechanism for Active Directory Windows Virtual Machines in Azure - Azure Virtual Machines | Microsoft Learn
Time sync for Windows VMs in Azure - Azure Virtual Machines | Microsoft Learn
Configuring an Authoritative Time Server with Group Policy Using WMI Filtering - Microsoft Community Hub
Continue reading...