Configuring an authoritative time source for your Windows domain

7 Mar 2013 Update: If you read this article, you’ll note that there is no mention of Group Policy.  Some of you have asked why that is (especially since I’m such a big fan of management via GPOs).  It’s because the time policies are only useful if you’re doing some type of non-standard configuration.  The only real configuration you need for a ‘typical’ time sync setup is for the DC with the PDC emulator role.  As such, there really is no reason to set Group Policy (well, you could for the PDC DC, but I think it’s kinda ridiculous to set up a complex GP for only one machine).  Besides, performing the settings in the registry ensures that the settings will persist, even if GPs fail to apply for some reason.  – Ed.

This is an article that I’ve been meaning to write for some time now, but always forgot. Well, this morning, we had a problem with one of our time servers which reminded me about this topic. I will show you how to properly configure time services for your Windows domain. While all of this information is already out on the Internet, it is located in many disparate sources; so this is my effort to give you a one-stop shop by providing comments where I thought the Microsoft article was lacking…

First, I have to go over a few caveats:

  • A typical domain uses the Windows Time Service (w32tm) to manage time synchronization within the domain. This service works fine for Kerberos (which is the primary reason we like to keep clients in sync). It is interesting to note that Windows doesn’t really care if the time on the domain is CORRECT, just IN SYNC (within a very generous tolerance). Although a properly configured time service will be very accurate, the precision of the time on clients can vary. So, you don’t want to use this method to sync the clock on stock trading workstations, for example. They need something more sophisticated, like dedicated NTP clients that sync to the time server directly.
  • Second, I am assuming that you want to sync to an external source (i.e. an Internet NTP server or your own hardware time server) so that your time reflects real-world time.

Step 1 – Configure your domain’s authoritative time server. For a domain, this will be the Domain Controller that holds the PDC emulator role. To find out which DC has this role, run netdom query fsmo at the command prompt.

The DC with ‘PDC’ is the one we’re interested in. We will now configure this DC as an NTP CLIENT. (Comment: There is some confusion of the meanings of NTP server versus client. In this case, you are configuring your Domain Controller (which happens to be a server), to use NTP as a client (we are consuming this service from an NTP SERVER). So, try not to get the terms mixed up! Just follow my directions, and you’ll be fine). Reference: Microsoft KB 816042:

  1. Change the server type to NTP. To do this, follow these steps:
    1. Click Start, click Run, type regedit, and then click OK.
    2. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
    3. In the right pane, right-click Type, and then click Modify.
    4. In Edit Value, type NTP in the Value data box, and then click OK.
  2. Set AnnounceFlags to 0xA (EDIT: There is some confusion about this setting.  Technet tells you to set this to 0x5, I recommend this be set to 0xA instead, see below). To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
    2. In the right pane, right-click AnnounceFlags, and then click Modify.
    3. In Edit DWORD Value, type A in the Value data box, and then click OK.
      Notes
      – If an authoritative time server that is configured to use an AnnounceFlag value of 0x5 does not synchronize with an upstream time server, a client server may not correctly synchronize with the authoritative time server when the time synchronization between the authoritative time server and the upstream time server resumes. Therefore, if you have a poor network connection or other concerns that may cause time synchronization failure of the authoritative server to an upstream server, set the AnnounceFlag value to 0xA instead of to 0x5.
      – If an authoritative time server that is configured to use an AnnounceFlag value of 0x5 and to synchronize with an upstream time server at a fixed interval that is specified in SpecialPollInterval, a client server may not correctly synchronize with the authoritative time server after the authoritative time server restarts. Therefore, if you configure your authoritative time server to synchronize with an upstream NTP server at a fixed interval that is specified in SpecialPollInterval, set the AnnounceFlag value to 0xA instead of 0x5 (Comment: AnnounceFlag settings are described in http://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx#w2k3tr_times_tools_uhlp. Multiple flags are set by adding the hex values together. Based on the configuration example, I recommend setting this to 0xA)This is because you want to ensure that your domain always stays in sync, even if the NTP source(s) go offline.  By using 0xA, which is a combination of 0x08 and 0x02, you ensure that even if NTP is unavailable, the server still self-elects that it is the authoritative time source for the forest and will keep the domain in-sync with itself.)
  3. Enable NTPServer. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\W32Time\Providers\NtpServer
    2. In the right pane, right-click Enabled, and then click Modify.
    3. In Edit DWORD Value, type 1 in the Value data box, and then click OK.
  4. Specify the time sources. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
    2. In the right pane, right-click NtpServer, and then click Modify.
    3. In Edit Value, type Peers (Comment: This is where you will enter the names of the time servers you will sync with. The best option is to have your own NTP server. Understanding that many don’t have the need (or money) to do this, connecting to an Internet NTP is your alternative. Whatever you do, DO NOT use time.windows.com. Think about it, Windows dominates the PC market, and all of these clients are configured, by default, to get their time from this site. Pick some other time servers (at least two): http://support.microsoft.com/default.aspx?scid=kb;EN-US;262680). in the Value data box, and then click OK.
      Note Peers is a placeholder for a space-delimited list of peers from which your computer obtains time stamps. Each DNS name that is listed must be unique. You must append ,0x1 to the end of each DNS name. If you do not append ,0x1 to the end of each DNS name, the changes made in step 5 will not take effect (Comment: Technet tells you to set the value to 0x1. But it’s more complicated than that. The value of the flag is dependent on how you want the server to be used. See the NtpServer registry value settings in http://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx#w2k3tr_times_tools_uhlp. My recommendation is to set TWO servers, with your primary as 0x9 and your secondary as 0xA. A good article that describes setting up alternate time sources is located at: http://blogs.technet.com/b/askds/archive/2007/11/01/configuring-your-pdce-with-alternate-time-sources.aspx).
  5. Select the poll interval. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\W32Time\Providers\NtpClient\SpecialPollInterval
    2. In the right pane, right-click SpecialPollInterval, and then click Modify.
    3. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.
      Note TimeInSeconds is a placeholder for the number of seconds that you want between each poll. A recommended value is 900 Decimal. This value configures the Time Server to poll every 15 minutes (Comment: If you’re using someone else’s NTP server, you might want to set this to >= 14400. Many public NTP servers will blacklist you if you try to sync too frequently, and word on the street is that the magic number is 4 hours between syncs…).
  6. Configure the time correction settings. To do this, follow these steps:
    1. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxPosPhaseCorrection
    2. In the right pane, right-click MaxPosPhaseCorrection, and then click Modify.
    3. In Edit DWORD Value, click to select Decimal in the Base box.
    4. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.
      Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour (3600) or 30 minutes (1800). The value that you select will depend upon the poll interval, network condition, and external time source (Comment: What they’re trying to tell you, is that the better the connection, the smaller you can set this value. If your local time exceeds this value, the time will not automatically set, but you will get an error in the event log. You will then need to manually set the time so that it is close to the time on the NTP server. The default is 54000 (15 hours).
    5. Locate and then click the following registry subkey:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxNegPhaseCorrection
    6. In the right pane, right-click MaxNegPhaseCorrection, and then click Modify.
    7. In Edit DWORD Value, click to select Decimal in the Base box.
    8. In Edit DWORD Value, type TimeInSeconds in the Value data box, and then click OK.
      Note TimeInSeconds is a placeholder for a reasonable value, such as 1 hour (3600) or 30 minutes (1800). The value that you select will depend upon the poll interval, network condition, and external time source (Comment: This is the same as the prior setting, except going into the past).
  7. Quit Registry Editor.
  8. At the command prompt, type the following command to restart the Windows Time service, and then press ENTER:
    net stop w32time && net start w32time

Step 2 – Configure your domain clients to use domain time. To do this, join your computers to the domain. That’s right, you don’t do any configuration on your clients; they will, by default, connect to the PDC DC to get their time synchronized. I know it’s funny that I list this as a step, but surprisingly, a lot of people get hung up on this. Remember, only the PDC DC is an NTP client. Everyone else uses windows time…

22 Comments

  1. Posted December 27, 2012 at 8:42 pm | Permalink | Reply

    Not sure where you got the “5” value for Announce Flags in step 2…KB options are: 0x00, 0x01, 0x02, 0x04, and 0x08. Is 0x05 a viable option, and what is the value it represents?

    • Posted December 27, 2012 at 9:36 pm | Permalink | Reply

      0x5 is a valid value. Announce flags can be combined, so 0x05 is a combination of 0x01 and 0x04. This indicates that this machine is a time server and is reliable. If you have an unreliable connection or poll the upstram NTP server on a fixed interval, it is recommended that this flag is set to 0xA instead. Both of these settings come directly from Microsoft, located here at item 2.

  2. Grost
    Posted April 4, 2013 at 3:35 pm | Permalink | Reply

    All Windows machines are NTP clients by default even if using NT5DS domain hierarchy to synchronize time. Being an NTP client does not imply that the machine must or can only connect to an external NTP server. You can verify this by checking the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
    and observe that Enabled = 1.

    • Posted April 4, 2013 at 3:49 pm | Permalink | Reply

      Hi Grost,

      You are correct that machines are setup as NTP clients by default. But, in a domain joined configuration, Windows will by default choose to use the domain hierarchy to get its time, unless you manually do something the change that (regardless of how this value is set). The point is that unless you have a good reason to do so, you should just leave client workstations in their default time configuration and only modify the DC that will be providing time services (by configuring that as an NTP client). Manual configuration is necessary for this machine in order for it to use an external timing source! Thanks for the feedback!

  3. Posted June 18, 2013 at 7:28 am | Permalink | Reply

    BTW we moved our from Windows w32time to alternative ntp client http://nts.softros.com/client.html and forgot all that “hell” with w32tm

  4. Kurt
    Posted August 5, 2013 at 9:39 am | Permalink | Reply

    Hi,
    great article, i love it.
    There´s one thing i dont understand: First you write: “We will now configure this DC as an NTP CLIENT.” But in step 3. you define the PDC as a NTPServer. Why not set Enabled=1 under HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\W32TimeTime\Providers\NtpClient ?

    • Posted August 12, 2013 at 4:33 pm | Permalink | Reply

      Hi Kurt,

      From what I understand, w32tm uses NTP as an underlying protocol to distribute timing messages on the domain. By setting NtpServer\Enabled to 1, you are telling the PDC emulator DC that it will now be serving time requests on the domain. If this is set to 0, the AnnounceFlags value is ignored, meaning that you cannot make the machine a reliable time server.

      By default, NtpClient\Enabled is already set to 1 on workstations and servers alike so that they can consume time information from another machine, which on the domain will be the PDC emulator DC, by default.

  5. Posted December 27, 2013 at 5:06 pm | Permalink | Reply

    There are a couple of places where you use the registry key …\W32TimeTime\Providers\… whereas what you mean is …\W32Time\TimeProviders\… Caused me a moment or two confusion.

    • Posted January 10, 2014 at 5:16 pm | Permalink | Reply

      You are correct. Sorry about the error. The post has been fixed.

  6. Gerald
    Posted March 28, 2014 at 4:20 pm | Permalink | Reply

    Hi,

    At teh start, you write:
    As such, there really is no reason to set Group Policy (well, you could for the PDC DC, but I think it’s kinda ridiculous to set up a complex GP for only one machine).

    I don’t fully agree. The PDC Emulator isn’t a machine, it’s a *role*. And that role can be transferred. So I still see a need for a GPO… after all, if I run this on a server today and that server dies in a few months, there’s no guarantee that the external time sync is reinstated on the new PDC emulator.

    • Posted March 28, 2014 at 4:27 pm | Permalink | Reply

      Hello Gerald,

      Thank you for your comment.

      The issue that arises in the event of a DC failure, is that you must still manually transfer the PDC emulator role to another server. I guess my logic was if you’re going to be under the hood moving DC roles, one can also perform time server configuration at the same time.

      Please understand, that if you want to configure this via GPO (that targets a single machine), that is certainly your choice. I understand your concern regarding server failure. It just a different operating philosophy than mine, but certainly not any less valid.

      • Gerald
        Posted March 29, 2014 at 9:13 pm | Permalink

        Hi,

        Ofcourse the admin transferring the role, could and should update the time server config as well. But somehow I don’t have full confidence in people remembering to do things 😉 I prefer to have the extra safety. There’s a nice article about setting the time config on a PDC emulator on the Ask the Directory Services Team blog at http://blogs.technet.com/b/askds/archive/2008/11/13/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering.aspx
        They recommended using the WMI filter:
        Select * from Win32_ComputerSystem where DomainRole = 5

      • Posted June 16, 2015 at 9:29 pm | Permalink

        Gerald,

        Sorry about the VERY late reply on your comment, but I finally got around to looking at what you posted. It is a BEAUTIFUL solution and has caused me to rethink using a GPO for this. If I ever get around to actually doing it, I will be sure to make a new post about it!

  7. Dan
    Posted November 18, 2014 at 6:26 pm | Permalink | Reply

    Thanks for a most excellent article. Most importantly the ‘Why’ behind the specific settings.
    Really helped nail down a domain wide client non-sync issue for us.

  8. Jerry White
    Posted June 16, 2015 at 9:04 pm | Permalink | Reply

    Is there anything extra to do on other Domain Controllers that aren’t the PDC?

    • Posted June 16, 2015 at 9:12 pm | Permalink | Reply

      Hi Jerry,

      No. The only time you’ll need to mess with other DCs is if you ever migrate the PDC FSMO role. Note that migrating the PDC emulator role is not enough to restore time services; you have to perform the steps in this post on the new PDC DC (even if the old DC is offline and the role has been seized). If the old DC is still online, you’ll need to reverse the settings so that it gets its time from the PDC DC too. By default, domain-joined computers (to include domain controllers), look to the PDC DC for time synchronization using w32tm.

      • Jerry White
        Posted June 17, 2015 at 2:19 pm | Permalink

        Thanks for the quick reply. When I run netdom query fsmo I get everything pointing to my main (A)DC. The important one being PDC in this case I believe. When I run w32tm /resync at this location the computer immediately re-syncs with no problem. At another facility I have another (Q)DC that replicates with (A)DC. On (Q)DC when I run w32tm /query /status it says free-running system clock. When I run dcdiag it says not advertising as a time server. Also the computers at this location say source:free-ruuning system clock. Am I missing something?

      • Posted June 17, 2015 at 2:29 pm | Permalink

        When a server is dcpromo’d, it will join the domain time hierarchy by default. The most likely case is that the (Q)DC time settings were previously (mis)configured. Try this on the DC that is reporting as free-running:

        w32tm /config /syncfromflags:domheir /update

        net stop w32time && net start w32time

        If this doesn’t fix the issue, check that UDP 123 is not blocked, and that there aren’t any GPOs interfering with the settings.

        Let me know if this fixes it (or not)!

      • Jerry White
        Posted June 17, 2015 at 4:10 pm | Permalink

        After running a w32tm /query /status gives
        Leap Indicator: 0(no warning)
        Stratum: 1 (primary reference – syncd by radio clock)
        Precision: -6 (15.625ms per tick)
        Root Delay: 0.0000000s
        Root Dispersion: 10.0000000s
        ReferenceId: 0x4C4F434C (source name: “LOCL”)
        Last Successful Sync Time: 6/17/2015 11:09:09 AM
        Source: Local CMOS Clock
        Poll Interval: 6 (64s)

        Should this work instantly or might it take a while to populate?

      • Jerry White
        Posted June 17, 2015 at 4:11 pm | Permalink

        Sorry, to clarify I ran your suggestion first and then the above to see the results.

  9. Bjørn Inge Krakeli
    Posted June 23, 2016 at 11:30 am | Permalink | Reply

    I have a couple questions regarding the following comment in the section about AnnounceFlag:
    “I recommend setting this to 0xA. This is because you want to ensure that your domain always stays in sync, even if the NTP source(s) go offline. By using 0xA, which is a combination of 0x08 and 0x02, you ensure that even if NTP is unavailable, the server still self-elects that it is the authoritative time source for the forest and will keep the domain in-sync with itself.”

    Article https://technet.microsoft.com/en-us/library/cc784191(v=ws.10).aspx tells us that:
    0x01 = “Timeserv_Announce_Yes. The domain controller always advertises time service.”
    0x02 = “Timeserv_Announce_Auto. The domain controller automatically determines whether it should advertise time service.”
    0x04 = “Reliable_Timeserv_Announce_Yes. The domain contoller will always advertise reliable time service.”
    0x08 = “Reliable_Timeserv_Announce_Auto. The domain controller automatically determines whether it should advertise reliable time service.”

    Ref. your comment, how is it possible that a domain controller can automatically advertise itself as the authoritative time source and reliable time service for the forest when the connection to the upstream time server is lost?
    Isn’t this exactly the situation where the domain controller should NOT advertise itself as the reliable time service?
    If your comment is correct, what is the difference between 0x01 and 0x02, and what is the difference between 0x04 and 0x08?

    • Posted June 23, 2016 at 1:08 pm | Permalink | Reply

      Hello Bjørn,

      I haven’t worked on time service in a while, so I had to read up a bit before replying 🙂

      To answer your question, we have to first understand that the principal reason for time synchronization in a Windows domain is to facilitate Kerberos authentication. The fact that it can also be used to track “real-world” time just happens to be a nice side effect. Keeping this in mind, we see that it is most important to keep the machines in sync so Kerberos doesn’t fail, with accurate timekeeping being the secondary goal.

      A good reference for the proper use of AnnounceFlags is at https://blogs.msdn.microsoft.com/w32time/2008/05/30/to-be-reliable-or-not-to-be-reliable/

      From that blog entry:

      0x08 will cause the service to automatically advertise as reliable when the DC is a) the PDC in the root domain of the forest, and b) when it is unable to locate a time source. The reason for this flag is to allow the root domain PDC to self-elect as the authoritative time source for the forest, allowing all other DCs to use it for time.

      It is not sufficient to use 0x04 and 0x08 on their own; a computer will not be classified as reliable unless it is also classified as a time server [ref: https://technet.microsoft.com/en-us/library/cc784191(v=ws.10).aspx]. Thus, these values must be combined with either 0x1 or 0x2 to indicate that the DC is providing a time service. My understanding is that it doesnt really matter if you use 0x1 or 0x2 (resulting in 0x9 or 0xA, respectively) since the 0x8 will override if external time is lost. Note that 0xA appears to be the default setting for Domain Controllers which makes sense, since the 0x8 portion only applies if the DC is the PDCE, and 0x2 is inferred when it is not.

2 Trackbacks

  1. By Server Time Issue on March 7, 2013 at 3:52 pm

    […] the info from here How to configure an authoritative time server in Windows Server and here Configuring an authoritative time source for your Windows domain | Windows HELL and it seemed to go ok… Oh and by the way, I used uk.pool.ntp.org in the 'peers' section and […]

  2. […] http://binarynature.blogspot.fr/2012/04/configure-active-directory.html#!/2012/04/configure-active-directory.html   http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/e6295b20-9821-4882-bc62-931a3c5fdd43/   https://windowshell.wordpress.com/2012/01/02/configuring-an-authoritative-time-source-for-your-window… […]

Leave a reply to Gerald Cancel reply