To be (reliable) or not to be (reliable)
Of the many things that w32time does, figuring out which host to sync from is one of the most important, and thus, one of the most talked about. In the stand-alone scenario, peer discovery (aka figuring out which host to sync with) is an entirely manual process. W32time chooses a peer based on the contents of the NtpServer registry key, which contains a list of hosts and some optional host-specific flags. However, in the domain-joined scenario, the peer discovery process is almost completely automatic. In a domain, computers inform each other of what "services" they provide through the use of NetLogon flags. Services running on a particular machine can use the NetLogon facility to set these NetLogon flags. W32time makes use of these flags to inform machines on the domain of where to find a time source.
NetLogon provides two flags that are created specifically for w32time's use. These are the TIMESERV flag and the GTIMESERV flag (note the subtle 'G' at the beginning of the second flag). Note that changing the state of the advertising flags does not stop w32time from sending & receiving requests and responses. This is an important distinction that is overlooked sometimes by even the brightest (myself included). The TIMESERV flag indicates that the machine is currently synchronized and can provide time sync responses. The GTIMESERV flag means that a machine is "special" because it is a "good" source of time. In practice, a machine is declared to be a good source of time when it is directly connected to a reliable time source (such as a hardware clock) or when it is simple the most reliable source of time on the network. For example, a small business might not have the bankroll to afford a $2000 NTP hardware device to synchronize with, so they configure the PDC of their domain to synchronize with the NIST time servers. In this case, the PDC might not be a perfectly accurate time source, but it is in fact the most accurate time source on the domain. You can view flags using the nltest utility. The output should look something like the following:
D:\Program Files>nltest /dsgetdc:
DC: \\mydc.mydomain.com
Address: <some ip>
Dom Guid: d1e31ae5-fe27-4cbf-9b41-c2d0f6b2c895
Dom Name: mydomain.com
Forest Name: mydomain.com
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET
The command completed successfully
Note the TIMESERV flag in the 'Flags' section above. Now that we know a bit about the flags that w32time leverages and how they are used, let's take a look at how we can control these flags.
As discussed in a previous post, the domain hierarchy serves as the base for which peers are selected, with one major (and maybe one or two other small) exception. The AnnounceFlags registry key allows an administrator to control a bit of the peer selection process. This key is a bitwise mask, with the following flags:
- 0x00 Not a time server
- 0x01 Always time server
- 0x02 Automatic time server
- 0x04 Always reliable time server
- 0x08 Automatic reliable time server
0x00 will cause the service to not advertise at all (via NetLogon) as a time service. It will still respond to NTP requests (both NTP and NT5DS types), but other peers will not be able to discover it as a time source
0x01 will cause the service to always advertise as a time server, regardless of its own status
0x02 will cause the service to only advertise as a time source when it is receiving reliable time from another peer, either via NTP or NT5DS
0x04 will cause the service to always advertise as a reliable time source. This is actually the bit that gets set when you use the w32tm command with the Reliable:YES option
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.
The purpose of the 0x08 flag dates back to the original design for w32time. The primary goal of the w32time service is to keep all of the clocks in the domain in loose synchronization with each other. As a secondary goal, keep all of these clock also in sync with an external time source. However, it is worth mentioning that the reason for this design is because if the clocks are more than 5 minutes out of sync, Kerberos will fail and problems in the domain will begin to mount.
To be (reliable) or not to be (reliable)
So one of the most common question I get is "When should I use the GTIMESERV flag?" (or other variations on that theme). If you refer back to one of my original posts on how domain synchronization works, I showed the scoring mechanism that w32time uses to decide what machine is the "best" candidate. In the scoring, the highest criteria that is scored is whether or not the machine has the GTIMESERV flag set. The reason is straightforward: The administrator of a network needs to have the ability to override where a machine synchronizes.
The most common situation for using the GTIMESERV flag it to create a reliable time source in the root domain to safeguard against a failed PDC. In a typical situation, the PDC in the root domain is configured to synchronize with an external time source. If the PDC goes down (or the role is transferred or seized), then the new PDC needs to be configured in the same way. In an ideal world, this "moving of configuration" would happen automatically, but we don't live in a perfect world. The new PDC goes into place, and does not sync externally. Eventually, it begins to lose sync with the outside world, and the whole domain suffers.
To safeguard against this, we recommend electing a machine in the root domain as a GTIMESERV, and configuring it to synchronize to your external time source. This will allow the PDC (both the old one and the new one) to correctly pick the GTIMESERV as their time source, keeping the domain always on time.