The clock has been a part of the Windows operating system for decades and is one of those things that most of us rarely even think about, aside from occasionally glancing at the time. Even so, the system clock plays a vital role. Kerberos authentication is tied directly to the clock, and if the clocks on computers within a domain fall out of sync, Kerberos breaks down and stops working. This leads to any number of other issues. Windows typically does a good job of keeping the PC clocks synchronized across a domain. However, I recently ran into a situation where the Windows PC clocks had fallen out of time sync with one another. None of the usual methods for bringing the clocks back into synchronization seemed to be working. As such, I wanted to share with you what I did to fix the problem.
Windows time sync problem: What happened?
Before I share my solution with you, I want to take just a moment and explain what happened. I have a small Windows domain consisting of two domain controllers that are running on physical hardware. There are also several member servers, but those member servers are virtual and are hosted on Microsoft Hyper-V. The Hyper-V hosts belong to a different domain that is a part of a different forest. Herein lies the problem.
The two domain controllers clocks were synchronized to one another. However, those domain controllers were not being synchronized to an authoritative external network time server. Instead, the CMOS clock on the PDC emulator acted as a time source for the entire domain. Over time, that CMOS clock’s time drifted, leading to the domain controllers clocks being off by about 15 minutes.
As previously noted, the member servers were hosted on Hyper-V servers. Those Hyper-V servers were part of another domain that was not experiencing any time issues. Hence, the Hyper-V clocks were correct. The member servers were getting their time from the Hyper-V hosts, not from the domain controllers. As such, the domain controllers’ clocks were wrong, but the member server’s clocks were correct. This caused significant Kerberos issues between the domain controllers and the member servers.
So now that I have described this Windows time sync problem, I want to walk you through the steps required to fix it.
Step 1: Check your firewalls
The Network Time Protocol (NTP) uses UDP port 123. As such, you will need to verify that your servers are able to communicate across this port. This means making sure that UDP port 123 is open on the Windows firewall and on any other firewalls that you might have in place.
Step 2: Clear any existing group policy settings
Many organizations use group policy settings to enforce network time synchronization. While you can do this, I recommend clearing out any existing time-related group policy settings. The idea is that when we begin configuring Windows time sync, we want to make sure that we are starting with a clean slate.
There are two main places that you will need to check for group policy settings. Begin by opening your Default Domain Policy and then navigating through the console tree to this location
Computer Configuration \ Policies \ Administrative Templates \ System \ Windows Time Service
Make sure that the Disable Global Configuration Settings are set to Not Configured, as shown in the image below.
Next, open the Time Providers folder, and set all of the policy settings within that folder to Not Configured. You can see what this looks like below.
You will also need to repeat this process for the domain controllers policy and any other group policy objects that apply to the servers having problems.
Locate the PDC emulator
The next thing that you will need to do is to locate the PDC emulator for the domain. To do so, open a command prompt window and enter the following command:
Netdom /query FSMO
Once you know which domain controller is acting as the PDC emulator, you will need to open an elevated command prompt window on that domain controller and enter the following command:
GPUpdate / Force
This command applies any changes that you have made to the group policy. You can see what this looks like in the figure below.
Resynchronize the clocks
The next step in the process is to resynchronize the clocks. To do so, use the following commands:
net stop w32time w32tm /config /syncfromflags:manual /manualpeerlist:"0.it.pool.ntp.org 1.it.pool.ntp.org 2.it.pool.ntp.org 3.it.pool.ntp.org" net start w32time w32tm /config /update w32tm /resync /rediscover
The first command shown here stops the Windows Time Service. The second command points the Windows Time Service toward a series of network time servers that are maintained by ntp.org. The third command restarts the server. After that, the fourth command updates the service’s configuration, and then the last command initiates a resynchronization. The whole process is illustrated below.
When you are done
I ran the commands listed above on both of my domain controllers, although it is entirely possible that the second domain controller may have synchronized with the PDC emulator’s clock automatically.
It’s easy to tell whether or not this procedure worked because you will see the clocks update to reflect the new time. However, if you want to verify that Windows has accepted the new configuration and is getting its time from the right place, you can enter this command:
W32tm /query /source
Once you have confirmed that everything is working as it should be, it’s a good idea to designate your PDC emulator as a reliable time source for the other computers joined to the domain. You can accomplish this by opening an elevated command prompt window on the PDC emulator and running the following command:
W32tm /config /reliable:yes
Your Windows time sync issues should hopefully be cleared up.
Featured image: Pixabay
