Use this page to configure where Domain Time will get the time to set the local system clock.
Note:
If you see the Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the Active Directory page for more information on using Group Policies.
Domain Time Client has four basic methods of obtaining the time; three of these are selected using the Control Panel applet as shown below.
The fourth method is to assign time sources using Active Directory Group Policies.
See the Active Directory page for more information on using Group Policies.
Set this machine's time by querying a list of servers
This selection instructs Domain Time to make outgoing unicast time requests to the servers
you list on this page. Domain Time will query this list on the schedule you set on the Timings property page.
See the Time Sources (Unicast) section below for details on configuring Domain Time for this method.
Set this machine's time from broadcast or multicast sources
This selection sets Domain Time to listen for incoming broadcast or multicast time packets that are being transmitted from the
sources you list on this page. Domain Time will set the local clock whenever it receives a time packet from the listed source(s).
Discover sources automatically, instructs Domain Time Client to attempt to auto-discover a time server to use.
Client uses a reliable and sophisticated process to discover available servers to use. You may customize the discovery process by clicking the
button to pull up the Discovery Options dialog box:
Client will try the selected discovery methods in the order listed and use the first server found. Once a server has been found,
Domain Time will continue to use that server as long as the Client service is running. It will also use the same server after restarting if
the Use last-known-good servers (recommended) option is selected.
Otherwise, Client will attempt to re-discover a server each time the service is restarted.
If the discovered server becomes unavailable, Client will automatically re-start the discovery process to find another server to use.
DHCP Options
You may use DHCP to assign time sources to Clients. If enabled in the Discovery Options above, the Client will do a DHCP discovery broadcast
to find a local DHCP Server. If the IP address of a time source is defined in DHCP Option 004 or 042, the Client will use the specified source.
Note: You may assign a time server using DHCP Options whether or not the machine on which Client is running is using DHCP
to assign an IP address. Client's DHCP discovery broadcast to determine the value of Options 004 and/or 042 is completely separate
from the IP address assignment used by the network stack.
Option 004 ("Time Servers") is used only for discovering DT2 servers. If a
server is listed in option 004 that doesn't support DT2 UDP, it will be ignored.
Option 042 ("NTP Servers") is used to discover both NTP servers and DT2
servers. If a server is listed in option 042, it will be checked for NTP first.
If NTP fails, it will be checked for DT2 UDP. If it does not provide time under
either of these two protocols, it will be ignored.
Additional Options
About Time Samples
When obtaining time from external time sources, Domain Time uses Time Samples to determine the correct time.
A time sample is collected either by (a) sending a unicast time request to a time server and receiving a unicast reply, or by (b) accepting an incoming time
packet sent from a broadcasting or multicasting server.
By default, Domain Time analyzes the collected time samples using sophisticated statistical methods to reject bad samples and derive the correct time.
It then sets the local clock to the correct time using the greatest accuracy possible.
Any single time sample from any time source may not reflect the correct time, either because of network delays, operating system load, or many other transient causes.
Therefore, it's usually a good idea to collect more than one sample. If querying a list of servers, you may specify
multiple time servers and also set the number of samples to request from each source. If accepting incoming broad/multicast packets, you can specify the number of samples that
must be received from the source before making a correction.
In general, time will be more accurate the more samples you collect; however, there is a point of diminishing returns. Each
sample takes a fixed amount of time to collect. If the overall time taken to collect the samples is too long, the clock may drift significantly in the interim so that
any additional accuracy you obtain from the larger number of samples will be offset by the additional drift.
A good rule of thumb for querying servers is to configure at least three or more sources, which provides additional sanity checks and fallback in case any one server
is unavailable. Then, specify an odd number of samples from each server; three samples each is a good choice. An odd-number of samples makes the calculations necessary
to reject a bad ticker more likely to be accurate. You can then use trial-and-error to determine if adding more samples increases your accuracy.
If taking multiple samples from any time server, take care to request a reasonable number of samples and set a delay between the samples to avoid being flagged as making a Denial-of-Service attack.
If you're using broad/multicasting, you can require that multiple samples be collected before setting the time. However, multiple samples may or may not increase accuracy,
depending on a number of factors. Consider this option only if the broad/multicast time pulse is occurring rapidly enough to collect your required number of samples
before the clock drifts outside your target tolerance.
The following options may be available depending on which of the three basic methods of obtaining the time you've selected (see above):
Analyze time samples and choose the best, or average equally good samples (recommended)
This controls whether Domain Time applies advanced analysis algorithms to the collected time samples.
When this box is checked, Domain Time contacts all of the listed servers to collect a group of time samples (if you're querying servers) or
waits until it has collected the specified number of incoming time packets (if you're using broadcast/multicast sources). It then performs
statistical analysis on the collected samples to determine the reliability and uses the most reliable samples to derives the correct time.
See the "About Time Samples" sidebar for more information and rule-of-thumb suggestions on acquiring time samples.
If you are collecting multiple samples, checking this box will almost always improve your machine's accuracy and reliability.
If this box is unchecked, no comparative analysis among samples is performed. In addition, the list of time servers to query becomes a fallback-only list.
In other words, the Server will only contact first listed time server. This server will always be used unless it is unavailable, at which point the
next listed server will be used. If that server is unavailable, the next server in the list will be tried, etc. When the first listed server becomes available again,
the Server will revert to using it exclusively.
If all listed servers fail, try to discover sources automatically
This selection causes the Client to use the Discover Sources Automatically process (described above) to try to automatically find an available server
if it cannot communicate with your specified time sources.
Do not enable this option if you always want your Client to attempt to use only the specified sources under all circumstances.
Match server's timezone if available (DT2 protocol only)
When selected, Client will change the local machine's Windows timezone settings to match the timezone setting of the Domain Time Server it contacts.
Note that this is a global change to the operating system which will affect all programs that display local time (the same way that manually changing the timezone using
Windows' Date & Time Applet does).
In order for this feature to work, the Domain Time Server you are contacting must be set to recommend the Time Zone to Clients
(see the Allow clients to match this server's timezone setting on the Server's Recommendations property page)
and the Client must be using the DT2 protocol to synchronize its time with the Server.
Time Sources (Unicast)
If you have selected the Set this machine's time by querying a list of servers
method of obtaining time, Domain Time will query each of the machines you list (and enable) on this page for the time.
You may add machines to the list manually or by scanning for them on your network automatically.
To easily identify available time servers on your network, click the Local Time Servers link at the bottom of the list box.
This brings up the Time Sources Search dialog, where you can scan your network for time servers and then add your choice(s) to the Time Sources list automatically.
If you will be using time servers over the Internet, please click the Public Time Servers
link to find reliable servers.
Use the Time Source Type: radio buttons to indicate whether you want to contact a server directly using its machine name or IP address,
or to automatically find and use the domain controller holding the PDC Emulator role on the specified Windows domain.
If you enter a machine name in the Time Source Name field, it must be resolvable to an IP address using DNS, WINS, Active Directory, from the HOSTS file, etc. If entering the IP address, you may use either the IPv4 or IPv6 address of the server.
You may use the Comment field to annotate this entry, if you want.
Use the Time Protocol: drop-down list to indicate which time protocol to use when contacting this server. You can use DT2-UDP, DT2-TCP, DT2-HTTP,
or NTP. See the Time Protocols page for more information on these protocols.
The Authenticate using: drop-down list selects which authentication key to use when exchanging packets with this server.
A key will show up in the list if it has been configured on the Symmetric Keys property page of the Control Panel applet.
Domain Time supports MD5 symmetric-key authentication compatible with NTP version 3 and later (AutoKey is not supported). Windows Authentication compatible
with Windows Time NT5DS-mode timestamps is also supported. Either authentication method can be used over any supported time protocol (NTP, DT2-UDP, etc.) See the Symmetric Keys page for details on using authentication.
Hint: When possible, be sure all of your time systems are working correctly before enabling authentication. Authentication requires a correct setup on both
ends of the connection, and changes at either end can cause a previously-working connection to fail. Disabling authentication temporarily should always be
one of the first steps when troubleshooting a connection issue.
Number of Samples: sets how many individual requests Domain Time will make of this server during each time check.
CAUTION: Take extreme care with this setting. Many time servers have Denial-of-Service (DOS) protection to prevent abuse.
Issuing too many time requests in a row to one server over a short period of time can cause your machine to be locked out or even be permanently blacklisted.
Use the Delay between samples (ms) setting to space out your sample requests over a reasonable length of time. You may want to contact the administrator
of any time server you will be using to find out what the acceptable retry period is on that server. Another option is to use fewer samples per server and
simply check against more servers if you need to increase your sample count.
Click the button to be sure the server you've selected is reachable using the protocol specified.
Note: The Control Panel applet you're using for the test is running in the foreground security context of the currently logged-in user, but, in normal operation,
the Domain Time service will use the context of the background service account under which it runs (by default, LocalSystem). There are some circumstances where the
foreground test will succeed in contacting a source but the Domain Time service will fail, or vice versa. If this occurs, check your firewall and security settings to
allow the Domain Time service the necessary network access to send/receive time protocols.
Time Sources (Broadcast/Multicast)
About xcasting
Using broadcast or multicast (sometimes referred to in this document as "xcast") time packets to obtain time has distinct advantages and disadvantages.
One advantage of using xcast to obtain time is that there is often lower processing overhead than when you're sending unicast time queries to a server.
The unicast method must send queries to various servers, receive the responses, compensate for latency on each sample, and then analyze the samples to determine the correct time.
The xcast process is comparatively simple. The listening machine merely accepts the time presented in the packet as valid, subtracts out the estimated latency
of the connection (see Estimated delay below) and sets the clock.
This can be useful in tightly-controlled networks where network propagation delays are known and unchanging. Under those circumstances, it is sometimes possible
to achieve higher accuracy on clients by using a very rapid xcast pulse rather than by having the clients each make many individual requests
of the server.
However, there are many disadvantages to xcast time under normal network operations. The most significant of these is that network conditions are rarely static,
and the latency between time server and client can vary substantially in a short period of time. This can severely affect the accuracy of the incoming time stamp,
causing jumps in time. In addition, broadcast time can be very susceptible to interference from rogue broadcast servers on the network, packet-spoofing (although
signed packets can help avoid this), and other disruptions which can adversely affect reliability.
In most cases, modern time request/reply protocols with sophisticated round-trip latency detection such as NTP and DT2 are the better choice.
However, broadcast time is still used by some legacy equipment, so it may be the only time synchronization option available for those devices.
Domain Time allows you to configure to receive broadcasts and/or multicast packets using either the NTP or DT2-UDP protocols. There are
efficiencies in the DT2-UDP protocol that result in slightly-higher accuracy than NTP overall; otherwise, the packets function very similarly.
If you have selected the Set this machine's time from broadcast or multicast sources
method of obtaining time, Domain Time will listen for broadcast or multicast packets from the listed time sources and extract time data from them.
In addition to the options described above, you'll see the following settings when you select Set this machine's time from broadcast or multicast sources:
Only accept signed packets
If checked, only packets using authentication will be accepted.
See the Authentication page for more information on packet authentication.
Log rejected packets
When checked, rejected packets will be noted in the log.
Samples required for sync:
This sets how many time packets with time data must be received before a correction occurs.
This is also the number of samples used for analysis if the Analyze time samples and choose the best... checkbox (discussed above) is checked.
Be careful not to specify a number of samples that would result in long period before the clock is corrected, since the clock may drift
significantly before all the samples have been collected.
Only accept from well-known source port
If checked, only packets originating from port 123 UDP (if using the NTP protocol) or port 9909 UDP (if using the DT2 protocol).
Use this setting with caution, since the default behavior of many servers is to send outgoing traffic from a random source port.
Broadcast/Multicast Time Source List
Shows the currently configured time sources. Domain Time will only listen for time packets from sources listed (and enabled) here.
You may add machines to the list manually or listen for broadcasting servers on your network.
To easily identify available broadcast time servers on your network, click the Local Broadcast Sources
link at the bottom of the list box. This brings up the Time Sources dialog, where you can listen for broadcast sources on your network and then add your
choice(s) to the Time Sources list automatically.
Use the Time Source Type: radio buttons to indicate the type of time packet to listen for from this server. You can accept either DT2-UDP, NTP, or both.
IMPORTANT: Only one service may own a particular port. If you will be accepting NTP broadcast packets with
Domain Time, you will need to disable any other service that may be using the NTP port (such as the Windows Time service).
You may use either the IPv4 or IPv6 address of the broadcast server in the IP Address: field.
You may use the Comment field to annotate this entry, if you want.
Estimated delay is the expected amount of latency in milliseconds a time packet will encounter between the transmitting server and this machine. Domain Time
will adjust the time contained in the timestamp by subtracting this value to improve accuracy. The closer this value is to the actual latency on your network connection, the more
accurate your time synchronization will be. You may enter this value yourself, or click the button to calculate it for you.
You may need to adjust this value if the overall propagation delay changes on your network.
Obtain the Time
Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the 
Proceed to the Timings page
Back to the Installation page