Time management is one of the most critical things to take care off in an Active Directory (AD) domain. Due to the implementation of the Kerberos protocol used for authentication, an ADdomain cannot work correctly (or at all) if all clocks are not synchronized between all Domain Controllers (DCs) and domain members, like members servers and workstations. When a Windows server receives a Kerberos authentication request, it compares the timestamp in the request to its local time. If the difference between the local time and the timestamp is too big (within 5 minutes of each other – default setting), the authentication request is rejected and Kerberos authentication fails and users won’t be able to login.
Besides that, the use of the correct time is also important for AD’s multi-master replication model used between all DCs, were timestamps are used to resolve AD replication conflicts.
As shown in the picture above, all DCs should synchronize their time with the DC holding the PDC Emulator FSMO role for their domain. In the AD domain hierarchy, the PDC emulator DCs of a child domain then synchronizes time with the PDC emulator in its parent domain. The PDC emulator DC in the root domain of the AD forest is the authoritative time source for the forest. This DC is responsible for the time in the complete AD environment.
It is a best practice to manually set this server (root domain PDC emulator) to synchronize his time with an external time source on the Internet, like time.windows.com, be.pool.ntp.org or us.pool.ntp.org. All other DCs should sync their time with the DC holding the PDC Emulator role for their child domain.
Other than DCs, member servers running as a virtual machine (VM) can use the Time Synchronization Integration Service to sync time with the Hyper-V host their running on, which in his place syncs time with the domain hierarchy.
All physical member servers and workstations in turn will sync time with their authenticated DC.
In AD, we use the Windows Time service(W32time.exe) for time (clock) synchronization with the Network Time Protocol (NTP) as the default time synchronization protocol. By default all members of a domain act as a time client, therefore, in most cases it is not necessary to configure the Windows Time Service. Windows servers and workstations that are not joined to a domain will synchronize their time, also by default, with time.windows.com.
Furthermore, as a best practice recommendation for VMs running as a DC, you should disable time synchronization between the Hyper-V host and the VM itself. This will enable your guest DC to synchronize time from the domain hierarchy or when the DC holds the PDC Emulator role, to synchronize time from any reliable external time source, like time.windows.com.
To disable (or enable) the Hyper-V time synchronization provider, you can follow the steps shown below.
Hyper-V Manager
Open Hyper-V Manager, select the DC VM and click Settings….
Click Integration Services and clear the Time Synchronization option check box. Click OK to apply.
Exit Hyper-V Manager and reboot the VM.
PowerShell
You can also use PowerShell to disable the Time synchronization service.
To get a list a list of the running Integration Services of a VM, run the following command (replace the VM name by your own) in a PowerShell window (as Administrator) on the Hyper-V host hosting the VM (replace the “VMName” to the name of your DC VM):
Get-VMIntegrationService -VMName "VMName"
Run the following command in a PowerShell window (as Administrator) on the Hyper-V host hosting the virtual DC (replace the “VMName” by your own):
After disabling theTime synchronization service, there are also some settings that need to be configured in the DC VM itself and on other DCs running in your AD environment. If these are already configured, you can skip some of the steps shown below.
First logon to the DC VM which holds the PDC Emulator role (root domain). In my case it is my DC VM, because I am currently only running one DC in my demo environment. When logged on with a user who has administrator rightsopen a PowerShell window.
If you are not sure or do not know, which DC currently holds the PDC Emulator role, you can always run the following PowerShell command on any DC to find out:
(Get-ADDomain).pdcemulator
When logged on on the DC holding the PDC Emulator role, check or the correct Time Zone is in use, by running the following PowerShell command:
Get-TimeZone
To set (or change) the time zone (e.g. Romance Standard Time), run the following PowerShell command:
Set-TimeZone -Id "Romance Standard Time" -PassThru
To check if the current time on the PDC DC is correct, you can check it against an external time server (e.g. time.windows.com). To do so, run the following command:
To set the current time on the PDC DC in synchronization with an external time server (e.g. time.windows.com), run the following command in a PowerShell window (as administrator):
To check if all time configuration settings are applied correctly on the DC holding the PDC Emulator role (or any other server), you can run the following command in a PowerShell window (as administrator). When running it on the PDC DC, you should see the [TimeProviders] setting NtpServer set to time.windows.com.
w32tm /query /configuration
You can also run the following command to check from which source the PDC DC syncs it’s time settings.
w32tm /query /source
Like already said above, all other DC’s (not holding the PDC Emulator role) and domain members in your domain, should synchronize from the domain hierarchy, except for member servers running as a VM. These servers can use the Time Synchronization Integration Service to sync time with the Hyper-V host their running on, which in his place syncs time with the domain hierarchy.
You can run the following command in a PowerShell window (as administrator) to set the correct synchronization method on physical DCs and domain members (by default when a member server or workstation is added to the domain, these time settings should be configured correctly):
You can run the following command in a PowerShell window (as administrator) to see if the time settings are applied correctly. You should see the [TimeProviders] setting Type set to NT5DS.
w32tm /query /configuration
You can also run the following command to check from which source the physical member server or workstation syncs its time settings. It should show the FQDN of your DC running the PDC role.
w32tm /query /source
On a VM with Time Synchronization enabled the command should show VM IC Time Synchronization Provider as Time source.
Conclusion
Time management is one of the most critical things in an AD domain because without using the correct time settings and time synchronization, servers and workstation would not be able to communicate with each other.
For DCs running as an Hyper-V VM you should disable the Hyper-V time synchronization provider and set those DCs to sync their time with the DC holding the PDC Emulator role for their child domain. You should also verify that all other domain members use the correct time configuration and synchronization settings for Kerberos authentication and AD replication purposes.
Wim Matthyssen 
Time management is one of the most critical things to take care off in an Active Directory (AD) domain. Due to the implementation of the Kerberos protocol used for authentication, an AD domain cannot work correctly (or at all) if all clocks are not synchronized between all Domain Controllers (DCs) and domain members, like members servers and workstations. When a Windows server receives a Kerberos authentication request, it compares the timestamp in the request to its local time. If the difference between the local time and the timestamp is too big (within 5 minutes of each other – default setting), the authentication request is rejected and Kerberos authentication fails and users won’t be able to login.
Besides that, the use of the correct time is also important for AD’s multi-master replication model used between all DCs, were timestamps are used to resolve AD replication conflicts.
As shown in the picture above, all DCs should synchronize their time with the DC holding the PDC Emulator FSMO role for their domain. In the AD domain hierarchy, the PDC emulator DCs of a child domain then synchronizes time with the PDC emulator in its parent domain. The PDC emulator DC in the root domain of the AD forest is the authoritative time source for the forest. This DC is responsible for the time in the complete AD environment.
It is a best practice to manually set this server (root domain PDC emulator) to synchronize his time with an external time source on the Internet, like time.windows.com, be.pool.ntp.org or us.pool.ntp.org. All other DCs should sync their time with the DC holding the PDC Emulator role for their child domain.
Other than DCs, member servers running as a virtual machine (VM) can use the Time Synchronization Integration Service to sync time with the Hyper-V host their running on, which in his place syncs time with the domain hierarchy.
All physical member servers and workstations in turn will sync time with their authenticated DC.
In AD, we use the Windows Time service (W32time.exe) for time (clock) synchronization with the Network Time Protocol (NTP) as the default time synchronization protocol. By default all members of a domain act as a time client, therefore, in most cases it is not necessary to configure the Windows Time Service. Windows servers and workstations that are not joined to a domain will synchronize their time, also by default, with time.windows.com.
Furthermore, as a best practice recommendation for VMs running as a DC, you should disable time synchronization between the Hyper-V host and the VM itself. This will enable your guest DC to synchronize time from the domain hierarchy or when the DC holds the PDC Emulator role, to synchronize time from any reliable external time source, like time.windows.com.
To disable (or enable) the Hyper-V time synchronization provider, you can follow the steps shown below.
Hyper-V Manager
Open Hyper-V Manager, select the DC VM and click Settings….
Click Integration Services and clear the Time Synchronization option check box. Click OK to apply.
Exit Hyper-V Manager and reboot the VM.
PowerShell
You can also use PowerShell to disable the Time synchronization service.
To get a list a list of the running Integration Services of a VM, run the following command (replace the VM name by your own) in a PowerShell window (as Administrator) on the Hyper-V host hosting the VM (replace the “VMName” to the name of your DC VM):
Run the following command in a PowerShell window (as Administrator) on the Hyper-V host hosting the virtual DC (replace the “VMName” by your own):
To turn on the “Time Synchronization” service when it is disabled you need to run the following command (replace the “VMName” by your own):
After disabling the Time synchronization service, there are also some settings that need to be configured in the DC VM itself and on other DCs running in your AD environment. If these are already configured, you can skip some of the steps shown below.
First logon to the DC VM which holds the PDC Emulator role (root domain). In my case it is my DC VM, because I am currently only running one DC in my demo environment. When logged on with a user who has administrator rights open a PowerShell window.
If you are not sure or do not know, which DC currently holds the PDC Emulator role, you can always run the following PowerShell command on any DC to find out:
When logged on on the DC holding the PDC Emulator role, check or the correct Time Zone is in use, by running the following PowerShell command:
To set (or change) the time zone (e.g. Romance Standard Time), run the following PowerShell command:
To check if the current time on the PDC DC is correct, you can check it against an external time server (e.g. time.windows.com). To do so, run the following command:
To set the current time on the PDC DC in synchronization with an external time server (e.g. time.windows.com), run the following command in a PowerShell window (as administrator):
To check if all time configuration settings are applied correctly on the DC holding the PDC Emulator role (or any other server), you can run the following command in a PowerShell window (as administrator). When running it on the PDC DC, you should see the [TimeProviders] setting NtpServer set to time.windows.com.
You can also run the following command to check from which source the PDC DC syncs it’s time settings.
Like already said above, all other DC’s (not holding the PDC Emulator role) and domain members in your domain, should synchronize from the domain hierarchy, except for member servers running as a VM. These servers can use the Time Synchronization Integration Service to sync time with the Hyper-V host their running on, which in his place syncs time with the domain hierarchy.
You can run the following command in a PowerShell window (as administrator) to set the correct synchronization method on physical DCs and domain members (by default when a member server or workstation is added to the domain, these time settings should be configured correctly):
You can run the following command in a PowerShell window (as administrator) to see if the time settings are applied correctly. You should see the [TimeProviders] setting Type set to NT5DS.
You can also run the following command to check from which source the physical member server or workstation syncs its time settings. It should show the FQDN of your DC running the PDC role.
On a VM with Time Synchronization enabled the command should show VM IC Time Synchronization Provider as Time source.
Conclusion
Time management is one of the most critical things in an AD domain because without using the correct time settings and time synchronization, servers and workstation would not be able to communicate with each other.
For DCs running as an Hyper-V VM you should disable the Hyper-V time synchronization provider and set those DCs to sync their time with the DC holding the PDC Emulator role for their child domain. You should also verify that all other domain members use the correct time configuration and synchronization settings for Kerberos authentication and AD replication purposes.
Share this:
Like this: