Fixing Active Directory Time Sync Issues

You might think that AD time sync in your organisation is something that just works out of the box but Sander Berkouwer has just done a post about what you need to do to setup time sync for Windows Server 2008 & R2. Apparently the default time sync server for Windows Server 2003 ( no long works so you need to make sure that you DC are configured with a valid time source.

Check out the whole article here The things that are better left unspoken : Active Directory Time Sync (broken by default)

Tip: One of the steps in the article is to configure the time server using the “w32tim” command on your PDC emulator. You can do this via Group Policy Preferences using the scheduled task option and then use Item-Level Targeting to only apply the command to the computer name of your PDC Emulator. By scheduling this command on a regular basis you can ensure that the time zone list of the server gets refreshed to the proper values periodically.

Author: Alan Burchill

Microsoft MVP (Group Policy)

8 thoughts on “Fixing Active Directory Time Sync Issues

  1. Could you please write up an article elaborating on your tip of using GPPs to automatically set up the time services?


  2. Why not simply use the Computer\Administrative Templates\System\Windows Time Service section combined with a WMI filter (Select * from Win32_ComputerSystem where DomainRole = 5)? I love preferences and item level targetting. But for this I believe it’s overkill.


    1. That could work but now you have the processing ovehead of running a WMI filter on every domain controller every 5 minutes…. and Does the “DomainRole = 5” mean its a DC or does it mean its the PDC Emulator for the domian?

  3. That would only apply to the PDC as “domainRole=5” indeed means the PDC.

    I think the GPP setting the Scheduled Task using targetting to only the PDC would cause also some kind of overhead. Not sure whether the difference is that remarkable.

    P.S. I didn’t came upon myself. Using google I got my source back:

  4. Ok… was not familar with what 5 meant with that WMI query… I thought as much that what it meant.

    WMI filtering on a GPO has a much higher overhead in processing than using native Group Policy Preferences targeting… Granted that one WMI filter is not going to add that much but they should defenitly be used sparingly.

    WMI Fillter is also applied at the GPO level so you would need to create a new seperate GPO to target this one setting…

    Thanks for the feedback and goes to show that there is defenitly more than one way to skin a cat…

Leave a Reply