Join Our Team
Contact
Insights Windows Time Settings in a Domain
Insights

Windows Time Settings in a Domain

Time synchronization is an important part of any Active Directory domain.  In this post, we’ll look at the impact of time being out of sync, how to configure time sync correctly, and how to troubleshoot when things go wrong.

Why We Should Synchronize Time

When time among the devices in a domain is out of sync, various problems can occur.  The most significant issue is authentication and access issues due to Kerberos failing.  If the time on a member server is more than 5 minutes different than the domain controller, Kerberos will fail all authentication requests from that server.  This is a security mechanism to prevent replay attacks.  Although the default time sync tolerance of 5 minutes is typically left in place, this can be customized if required using Group Policy.  In addition to Kerberos issues, you want time on the member servers to be in sync for practical purposes.  For example, reviewing log files combined from multiple servers would be difficult if each server had a different time. 

Configuring Time Sync

In the default configuration, which is also best practice, time sync settings follow the domain hierarchy for all servers except the PDC Emulator.  The domain controller with the PDCe role should sync with an external, reliable time source.  This could be an internet time server, a hardware time-keeping device, or an internal NTP server that isn’t part of the domain.  From there, the other domain controllers in the domain will sync their time from the PDCe.  Finally, workstations and member servers will sync their own time from an available DC.  This may be the PDCe or it may be another DC in the domain.  If this all functions correctly, time across the domain will be in sync with a margin of error of less than a few seconds.  The PDCe is the master time keeper, and all other devices in the domain should match the PDCe.

The preferred method for configuring Windows Time is with the w32tm command.  The PDCe needs to be configured to point to an external time source — typically an internet NTP server.  If not configured, the PDCe will sync from the BIOS clock by default, which will naturally drift over time.  This example command will configure the PDCe to use both time.windows.com and time.nist.gov as it’s time source:

w32tm /config /manualpeerlist:"time.windows.com,0x8 time.nist.gov,0x8" /syncfromflags:manual /reliable:yes /update

For the rest of the servers in the domain, you would use this command to configure them to sync from the domain hierarchy.  This will let them choose the correct time source automatically (either the PDCe or another DC):

w32tm /config /syncfromflags:domhier /update

After running either of these commands, the Windows Time service needs to be restarted.

Troubleshooting Time Sync Issues

There are a few ways you’ll know that there are issues with Windows Time in the domain:

  1. Visibly observing that the time on the servers is wrong or doesn’t match other servers in the domain
  2. Receiving authentication errors pointing to a time or date difference causing an issue
  3. Warnings in the System event log with a source of Time-Service

If you notice any of the above, you’ll need to do some troubleshooting.  Depending on how the issue appears, you’ll need to either review the configuration of a specific member server, its nearest DC, or the PDCe.  Here are some tips and guidelines:

  • Use the w32tm /query /configuration command to review the current configuration.  A member server should show “Type: NT5DS”, which indicates it’s syncing from the domain hierarchy.  The PDCe should show “Type: NTP” to indicate that it’s configured to use an NTP server.
  • Use w32tm /query /source to see what the current running source is.  If the Windows Time service is unable to contact the configured NTP server, this may return “Local CMOS Clock” or “Free-Running System Clock”.  Otherwise, it will return the NTP server or the DC that the server is currently syncing with.
  • w32tm/stripchart /computer:<ntpserver> (example: w32tm /stripchart /computer:time.windows.com) can be used to verify network connectivity to an NTP server.  This command will reach out to the target server and compare the local time to the server’s time.  If it’s unable to contact the target NTP server, you’ll see error codes instead.  If that happens, you may have network issues, such as a firewall, preventing communication with the NTP server.
  • w32tm /resync will force the service to try to resync with its configured source.  You would run this command after making other changes to see if the issues are resolved.
  • If the time service is simply not behaving, you can use these commands to completely re-register the service.  Note that this will remove all configuration related to Windows Time and restore it to default:
    • Net Stop W32time
    • W32tm.exe /unregister
    • W32tm.exe /register
    • Net Start W32time
  • For more verbose information, enable debug logging with this command: w32tm /debug /enable /file:C:\windows\temp\w32time.log /size:10000000 /entries:0-300 and then review the generated log file for issues.  The log will contain an entry for each operation that the service performs.  It can be difficult to sort through all of the information, but it can be extremely valuable to see each step in detail.
  • If a single member server is wrong, review the System event log to determine which DCs it is trying to sync from, and ensure those DCs are working correctly.  Sometimes, a failure will cascade through the domain.  A networking issue may prevent a set of DCs from syncing with the PDC, which can then cause the member servers in that network to stop as well.  You may need to trace the issues up the hierarchy.