The clock has been a part of the Windows operating system for as long as I can remember. Windows 3.1 included a desktop clock application, and Microsoft brought the clock to the Windows taskbar in Windows 95. Even before people began widely adopting Windows, the DOS operating system made extensive use of the system clock. My point is that the system clock is such a simple and long-lived part of the operating system, that most of us don’t even think about it. Even so, Windows Server time clock skew remains a serious issue even today.
Just to illustrate the point, consider that as I write this article, the clock on my Windows 10 desktop shows the time as 4:48 p.m., but my Windows Server 2019 lab server’s clock displays a time of 4:40 PM. Both clocks were initially synchronized with one another, but have drifted apart over time.
Why does Windows time clock skew matter?
Before I show you how to fix the problem of clock skew, I want to take a moment and talk about why the issue even matters. I could probably write an entire article on all of the different problems that clock skew can cause, but let me give you a personal example from long ago.
For many years, I hosted my email on a Microsoft Exchange Server residing in my house. One day, I found that Outlook was no longer able to connect to Exchange. I spent several days going over my Exchange Server in granular detail, looking for the cause of the problem. However, all of the services were running, the databases were mounted, and the various diagnostic checks were all coming back clean. The Exchange Server seemed to be in perfect health, and yet clients were unable to connect to it.
Through dumb luck, I just happened to notice that the server’s clock was wrong. I set the clock to the correct time, and all of a sudden everything started working again. The reason why I had this particular problem is because the Kerberos protocol is time-sensitive. Excessive differences between client and server clocks can cause Kerberos to malfunction.
Fixing the problem
Windows operating systems use the Windows Time Service to control the clocks. As you can see in the screenshot below, Windows 10 sets this service to use a manual (triggered) startup by default. This means that the service does not run unless you manually start it. As you look at the screenshot, however, you will notice that the service description indicates that if the service is stopped then date and time synchronization will be unavailable.
The first thing that I recommend doing is configuring the Windows Time Service to run. The easiest way to do this is to open the Service Control Manager (by entering the services.msc command at the Windows Run prompt) and locating Windows Time among the list of services. Next, right-click on the service and select the Properties command from the shortcut menu. Now, set the Startup type to Automatic and then click the Start button (shown in the next screenshot) to start the service.
The Windows Time Service is designed to keep your clock in sync, but there is a good chance that simply starting the service will not correct clock skew that has already occurred. The trick to making sure that your clock is accurate is to configure the Windows Time Service to synchronize itself with a network time server. Thankfully, this is easier than it sounds.
To synchronize your clock to a time server, open an elevated command prompt window and enter the following commands:
w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:yes /update net stop w32time net start w32time
The first of these commands links the Windows Time Service to a public network time server. The second command stops the Windows Time Service, and the third command restarts it. You can see these commands in action in the screenshot below.
Of course, this raises the question of how to know if this process worked. Presumably, you can check the clock. If the clock was already correct however, then the command will appear not to have done anything. The easiest way to know for sure if the process worked is to enter the following command:
w32tm /query /status
This command will tell you where the computer is getting its time from, how recently it performed a time synchronization, and how precise the computer’s clock is. You can see the command and its output in the screenshot below.
What went wrong?
The process of synchronizing your server’s clocks to a network time server seems simple enough. However, you may occasionally find that even after doing so, the clock continues to be incorrect. One reason why this happens is because domain joined computers will usually synchronize their clock to a domain controller even if you have manually instructed the server to synchronize with a network time server. The fix is to create Group Policy settings that address the problem.
The time-related Group Policy settings are located at Computer Configuration | Policies | Administrative Templates | System | Windows Time Service | Time Providers. You can specify the time provider for your Active Directory forest through these Group Policy settings. Remember, there are typically separate policies for domain controllers and member servers, so you may have to create the policy settings in multiple locations.
One more thing that can cause the time synchronization process to not work correctly is that the server is running on a virtual machine. Hyper-V includes an integration service called Time Synchronization. When enabled, this service causes the virtual machine to get its time from the host server. You may, therefore, need to fix the time on the Hyper-V host before you will be able to get your virtual machines to display the correct time.
Featured image: Shutterstock