Time on Windows is usually straight forward. For home computers (not joined to a domain), they simply get their time from an Internet source like time.windows.com and the main trick is just to adjust the time zone from Pacific Time to your own when you first get it. For domain-joined computers, they will pull the time from the domain controllers by default. If somebody changes those settings though, all bets are off.
Yesterday, I got to dive into a computer that had been setup by a vendor and was receiving a different time than the domain computers even though it had been joined to the domain. A configuration must have been changed manually somewhere, which meant I got to dive into all of these settings in order to track down where the change had been made. Through the process, I documented some commands and registry keys that help troubleshoot Windows time issues.
If you love life, don’t waste time, for time is what life is made up of. – Bruce Lee
When you start talking about time on endpoints, so much of it is perception. Enable a screensaver to kick on after 15 minutes and users will tell you that it locks the computer every 5 minutes until you take a stopwatch and time it. When working on a time sync issue, it’s important to know what you’re dealing with and simultaneously check the time on different devices to make your comparison. Run these commands from an elevated command prompt or as a script run by an administrator.
See what time the domain thinks it is:
Net time /Domain:domain.name.fqdn
I found this command useful as it was reported that three computers were all set at different times. I used the domain command and the following command to query all four devices for their time nearly simultaneously.
See what time each computer says it is:
Net time \computer-name
After running the above commands, I found that one of the computers was about a minute and a half ahead of the others which were correctly pulling the domain time. It’s not enough of a difference to cause issues with Kerberos authentications but the computer is part of a fail-over system with logs that would have a hard time syncing up alarms with different timestamps.
See where the computer is pulling its time from:
W32tm /query /source
After running the above command, it returned an IP address that meant nothing to me. It was pulling its time from some other server and that was the source of the problem.
You can ask Windows for its Windows Time configuration. It’s not very informative if everything is working properly but gives you something to compare to a working computer.
See Windows Time configuration:
W32tm /query /configuration
The next commands are not going to do a whole lot of good if the computer pulls from the wrong source but they will be helpful once we can update the source.
Have Windows Time update its configuration:
W32tm /config /update
Have Windows Time resync to its source:
W32tm /resync
Check each DC to see how much it differs:
W32tm /monitor /domain:DomainName
Always in motion is the future. – YODA, Star Wars Episode V: The Empire Strikes Back
Other areas to check for Windows Time issues include Services, Event Log, firewall, and Registry.
Check that the Windows Time service is running and set to Automatic. You can restart Windows Time service from the command line with:
net stop w32time net start w32time
Check the event logs for any errors with the Time sync process.
The Windows Firewall needs to allow UDP traffic on port 123 for NTP to work.
The Registry has two locations of importance when it comes to Windows Time.
Time Sources
In the Registry, at the following path, you will find the default servers like time.windows.com and time.nist.gov as individual numbered entries. It was here that I found the IP address that the w32tm /query /source command returned. This told me where it was hard-coded but it wouldn’t do me any good to just remove the source. I wanted it pulling from the domain, not a NTP server directly.
HKLMSoftwareMicrosoftWindowsCurrentVersionDateTimeServers
Sync Source
The following path in the Registry is where I found the source of the reported problems. The Type entry was set to ‘AllSync’ instead of the default for domain computers NT5DS.
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters
Name: Type
Value: NT5DS
The TechNet article on Windows Time Service Tools and Settings lists the possible values for the key. The page also documents other important Windows Time settings that you might check in case this isn’t the source of your problem as it was mine.
NoSync. The time service does not synchronize with other sources.
NTP. The time service synchronizes from the servers specified in the NtpServer registry entry.
NT5DS. The time service synchronizes from the domain hierarchy.
AllSync. The time service uses all the available synchronization mechanisms.
After I changed it from AllSync to NT5DS, I ran the command w32tm /config /update and the w32tm /query /source command to see that its source was now a domain controller. I then ran w32tm /resync and watched it fall back in line with the other computers as time went on.