Timing is everything, and this is especially relevant in a Windows-based environment.
The system clock has been a key part of the Windows operating system from its earliest days. While it might be tempting to dismiss clock accuracy as a trivial issue, ensuring that computer clocks are accurate and in sync with one another is critical to maintain the health of the systems on your network. There are any number of issues that can occur because of clock skew. The best way to avoid time problems is to synchronize your forest root domain controller to an external time source.
Why correcting clock skew matters
The Windows Kerberos protocol relies on computer clock synchronization for authentication-related functions. If the system clocks fall out of sync by more than a few minutes, Kerberos will stop functioning, leading to the failure of any service that depends on Kerberos. For example, a computer whose clock is set incorrectly may be unable to join an Active Directory domain.
Clock skew can also cause problems for database applications and for event logs even if Kerberos is not involved. Clock skew might affect time-sensitive transactions that make it appear events occurred in different order than the actual time.
How to keep computer clocks in sync
The best way to make sure that Windows machine’s clocks are correct is to take advantage of the Network Time Protocol (NTP), which synchronizes the clocks to a centralized authoritative time source.
In an Active Directory environment, domain joined Windows desktops and member servers automatically synchronize their clocks to the domain controller that authenticated them into Active Directory. That domain controller, in turn, synchronizes its clock to the primary domain controller (PDC) emulator. In a multi-domain environment, the PDC emulators synchronize their clocks to the forest root operations master. As such, all computers in an Active Directory domain should automatically be set to the same time. It is possible to synchronize all Windows machines to a time source outside of the domain, such as a router or an external NTP server, but best practices dictate Windows clients should synchronize their clocks to a domain controller instead.
If the clock is set incorrectly on the domain controller, which sits at the top of the Active Directory hierarchy, then the incorrect setting will propagate to all other computers within the Active Directory environment. The best way to prevent this issue is to synchronize your domain controller to an external time source.
Initially, even your forest root domain controller is configured to use only local time synchronization. You can verify this by opening a command prompt window and entering the following command:
W32tm /query /configuration
W32tm is the utility used to configure and troubleshoot the Windows Time service. The command makes a query for time-related statistics. Figure 1 shows the configuration from a forest root domain controller.
In Figure 1, in the NTPClient section the Type is set to NT5DS (Local). In the past, synchronizing the forest root domain controller’s clock to an external time server required modifications to the Windows registry, but a better option is to make the change via a group policy setting.
To start, open Server Manager and then choose the Group Policy Management option from the Tools menu. When the Group Policy Management console opens, select the Domain Controllers folder. Right-click on the Default Domain Controllers policy — or the policy used on the domain controllers — and choose the Edit command from the shortcut menu. Navigate through the console tree to Computer Configuration>Policies>Administrative Template>System>Windows Time Service>Time Providers.
Double-click on the Configure Windows NTP Client setting. From the dialog box, enable the setting and then set the Type field to NTP. Enter the following line to populate the NTP Server field with the NTP servers:
us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1
After the configuration change, force a policy update and then restart the Windows Time Service with the following commands from an elevated PowerShell window:
GPUpdate /force
Restart-Service W32Time
The configuration changes should ensure that the clocks on the Windows machines enrolled in Active Directory are accurate. It can take a few minutes for the settings to circulate through the environment.
Return to the command prompt window and run the W32tm query; the NTP Server list should reflect the changes. For example, Figure 3 indicates the Type in the NTPClient section has been changed to NTP (Local) and there is now an NTPServer entry that displays the NTP servers now being used for clock synchronization.
How to troubleshoot external NTP server problems
If Windows clocks will not synchronize with a time source, make the following checks:
- Make sure that UDP port 123 is open on the firewall to let NTP traffic pass through.
- Make sure the virtualization hosts acquire time from the same time server. Virtual machines often get their time from the virtualization host.
- Make sure clients can resolve the domain names of the time servers.
- Verify that a valid communications path exists between the client and the time server.
