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 time.nist.gov and 2 other stratus 1 NPT servers as it's time source:

w32tm /config /manualpeerlist:"time.nist.gov,0x8 utcnist.colorado.edu,0x8 utcnist2.colorado.edu,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 should not need to be restarted.

Correctly Specifying an NTP server

w32time is the name of the service which is normally configured automatically to query the time from a domain controller in an Active Directory domain, if the machine is a member of an AD domain, or from one of Microsoft's public NTP servers which can be accessed via time.windows.com, if the machine is a standalone machine or an AD domain controller.

The w32tm command, however, is an utility program that can be run in a console (cmd) window with administrator permissions to configure and monitor the w32time service. The following commands can be used to specify the host name or IP address of an external NTP server to be queried, and check the current settings.

When specifying an NTP server then it may be required to add a specific flag to the host name or IP address, even though this is poorly documented by Microsoft. According to the Microsoft documentation at

the following flags are supported:

Some versions of w32time previously sent symmetric active peer requests to NTP servers by default, but if the NTP server runs the standard NTP software (ntpd) then the server may not reply to such unauthenticated peer requests at all. The normal behavior is to send client requests to a server, in which case the server sends a server reply.

So it's safe to use flag 0x8, or a combination of other flags with 0x8, if required. E.g., 0x8 and 0x1 would result in a flag 0x9.

So actually the following command can be used to specify a single server:

w32tm /config /manualpeerlist:[server],0x8 /syncfromflags:MANUAL /update

Of course the IP address or the DNS hostname of the NTP server has to be entered instead of [server], and the flag 0x8 is appended after a comma, as explained above.

If several servers are to be configured for redundancy then the servers specified by /manualpeerlist have to be separated by a space, so the whole parameter has to be enclosed in double quotes:

w32tm /config /manualpeerlist:"[server1],0x8 [server2],0x8" /syncfromflags:MANUAL /update

The parameter /update makes sure the changes become effective immediately.

The following command can be used to check the list of servers (actually always labelled peers) that are currently in use:

w32tm /query /peers 

The output of this command also shows a mode for each specified server/peer, which should be 3 (Client) in most cases.

For other options of the w32tm command please see the usage information displayed if the command is run without any parameter.

Registry Settings

The following settings are required on every node that runs w32time to achieve the best results:

These parameters are controlled via registry settings, or via the some group policies. See the WARNING section on this web page:

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 /unregister
W32tm /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.