Our website use cookies to improve and personalise your experience and to display advertisements (if any). Our website may also include cookies from third parties like Google Adsense, Google Analytics, Youtube. By using the website, you consent to the use of cookies.

Configuring Windows Time for Active Directory

Over recent years I have noticed that Windows time configuration is sometimes overlooked and misconfigured and at some point may cause you major hassles.

For anyone not aware, all machines in an Active Directory environment automatically find a time server to sync time with. Workstations use their authenticating Domain Controller, and the DCs sync with the server holding the PDC Emulator FSMO role. In a multi-domain forest, the PDC Emulator in each child domain synchronises with a DC or the PDC Emulator in the forest root domain. To ensure the time remains reliable across the forest, only the PDC Emulator in the forest root domain should ever sync with an external time source – this leads to only one source of time being used across the forest.

image

The Windows Time Settings

It’s worth checking your settings for the time service in the registry, the key is HKLMSYSTEMCurrentControlSetServicesW32TimeParameters. The most important value to note is the ‘Type’ string – on any domain machine other than the PDC Emulator in the forest root, this should be set to NT5DS. That name isn’t particularly descriptive; if it is set, it means the machine is finding a time server in the Active Directory hierarchy.

If it isn’t set to NT5DS, you should think about resetting the time service on that machine. To do that, run a Command Prompt as an Administrator and execute the following commands:

 

Once complete check the registry again, and the Type should now be in domain sync mode (NT5DS).

Sometimes, I have found that when checking the registry you may find an NTPServer key even though the Type is to NT5DS.  NT5DS doesn’t use an NTP Server, so you may ask yourself why this key is there.  In a nut shell it is left over from when the machine was connected to a workgroup before joining the AD domain. Provided the Type is set to NT5DS, the NTPServer entry can be completely ignored or even deleted. Running the above commands on a domain-joined machine will delete it automatically.

The Forest Root PDC Emulator Settings

After a bit of a configuration reset, all your DCs, member servers and workstations should now be set to sync from the domain hierarchy. But what about the PDC Emulator in the forest root?

The fact of the matter is the PDC emulator doesn’t actually need to synchronise with anything. It automatically designates itself the most reliable time server in the domain and it can run quite happily like that, without ever talking to an external time server.

However it is always a good idea to have some form of external time sync on the forest root PDC Emulator. There are a number of ways to do this – for example, an external hardware clock which syncs with GPS. However, the most common I have come across is synchronising with an NTP server on the Internet.

To configure the time sync on the PDC emulator, you can run the following command.  Before running this I would make sure you you have checked that there isn’t another server connected to an external time source.

w32tm /config /manualpeerlist:”uk.pool.ntp.org,0×8? /syncfromflags:MANUAL /reliable:yes /update

I have used the free NTP project (www.pool.ntp.org) and selected the closest server to me.

Check Time Synchronisation

The safest is to wait for a scheduled time sync to take place, or restart the machine. Either will trigger Event ID 35 to be logged in the System log. This event’s description shows the time server the machine is synchronising with. This will be logged on both the PDC Emulator and all DCs, member servers and workstations. You can check for this on member machines to ensure a DC in the domain hierarchy is being found and used correctly – and to ensure your custom NTP servers configured on the PDC Emulator are being used as intended.

As a note, no time synchronisation will take place if the difference between the current system time and the new time provided by the time server is too great. A minute or two is fine, but I would not set the difference to be any more than that. The system checks this difference at each sync, and will reject the new time provided by the time server if it is too large.

Conclusion

You should now have an understanding of how the time service works and where it stores its settings in the registry. While time isn’t one of the most fun services an Active Directory administrator will work with, it is important you ensure the forest stays in sync if you want to avoid major problems with time skew, Kerberos and Active Directory in general.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts