How to Set NTP Server for Windows 2016 in a few easy steps

We don’t always need to configure the Network Time Protocol (NTP), but we’ve recently incorporated an old domain with a new primary domain controller. This new controller wasn’t set up yet for NTP. As a result, our entire network fell an hour behind due to daylight savings time and lack of synchronization with a legitimate NTP server. Our work operates on an AirGapped or Disconnected Network, which means we don’t have Internet access for all servers which made this situation more difficult. Below is the process I went through in fixing these issues.

Check Existing Time Servers

  1. Let’s start with querying to find out which domain controller is in charge so we know where to set the time correctly.
netdom query fsmo
Using Powershell to query the fsmo domain roles
Using PowerShell to Query the Domain Controller Roles

Use Time Servers on the Internet

If you have an Internet-connected system, you can start by updating the Windows Time Service.

To maintain accurate time synchronization, it’s recommended to use at least five stable time sources that can be reached over a reliable network connection. If the environment contains Windows Active Directory servers, the cluster should be configured to sync to the same time source as the AD environment.

w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:MANUAL

2. Stop and Start the Windows Time Service.

Stop-Service w32time
Start-Service w32time

You can also start and stop the service together in the same command.

net stop w32time && net start w32time

Resync the Time Service back to the NTP server it is configured to sync with.

w32tm /resync
Cloudways Hosting
Set NTP Server Windows 2016 - Resync NTP
Resyncing the Windows Time Service to the NTP Server

Check NTP Status Locally

Check the status of the local NTP.

w32tm /query /status
Set NTP Server Windows 2016 - Query NTP Status
Query the Status of the NTP Server in PowerShell

One issue is when NTP service rejects a configured server. This could be due to various reasons such as reachability, dispersion, and jitter. For instance, if the NTP server is blocked by a firewall or fails to respond to queries, NTP synchronization may fail. Also, if the maximum difference recorded between the NTP client and the NTP server (known as dispersion) or the variation of repeated time queries (known as jitter) is too high, the time source will not be trusted.

In cases where the NTP server does not respond to queries, the reachability value is used to indicate the number of responses received out of the last 8 requests. A reachability of ‘0’ indicates that no valid response has been received.

Fix NTP Sync Issues

Sometimes, the Windows Time Server has some issues within itself. During those times, you can unregister and re-register the service on the server to help out.

In configuring Network Time Protocol (NTP), it’s necessary to understand some common issues users may encounter and how to resolve them.

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Then, if you only want the clients to sync NTP from the Domain Controller, you can run this command on the domain clients.

w32tm /config /syncfromflags:domhier /reliable:yes /update

This is the command I have used to run on the Domain Controller itself to get the primary NTP server in sync.

w32tm /config /syncfromflags:manual /manualpeerlist:0.ca.pool.ntp.org,1.ca.pool.ntp.org,time3.google.com /reliable:yes /update
Cloudways Hosting

High values for dispersion, root dispersion, or jitter can cause a configured NTP server to be rejected by the NTP client. These values can be investigated through ntpq commands.

It’s also important to note that the Windows W32time daemon was developed by Microsoft to keep Windows AD environments synced within the 5-minute allowable clock skew defined by the Kerberos v5 protocol. However, the W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds.

Using public NTP pools also requires some considerations. For example, it’s not advisable to use just two NTP server entries as this can lead to wrong time synchronization. It’s recommended to use at least one local stratum-1 NTP Server or three to five time sources for a quorum-like effect that can prevent mistakes in the time received.

If an internal stratum-0 or 1 device is not available, reliable time sources such as ISPs, Google Public NTP, time.cloudflare.com, and time.apple.com can be used. However, using rate-limited services like NIST is not recommended as they may block queries from the CVMs and AHV Hosts.