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 (recommended)
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.
As of version 5.2, The IEEE 1588-2008 (PTP) protocol options will also become available when this method is selected. The protocol is enabled
using the checkbox on this page (see the Additional Options section below), but is configured on its own dialog screens.
Click the IEEE 1558-2008 (PTP) Options link to configure PTP.
See the IEEE 1588-2008 (PTP) documentation page for details.
Set this machine's time from broadcast or multicast sources (deprecated)
This selection sets Domain Time to listen for incoming broadcast or multicast DT2/NTP 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).
This selection is marked (deprecated) because very few administrators choose to use broadcast/multicast DT2/NTP for distributing
the time, but the option is still supported.
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 servers found according to the specified criteria.
If the Use last-known-good servers (recommended) option Client will remember which
server(s) provided valid time. The last-known-good cache expires when the machine is rebooted or the service restarted. If
"Use last-known-good servers" is unchecked, Client will perform the entire discovery process again at each timecheck.
If the Use servers in configured list of time sources is checked,
Client will attempt to use the same list of Time Sources displayed when the Set this machine's time by querying a list of servers radio button is selected on the Obtain the Time property page.
If all discovered servers becomes unavailable, Client will automatically re-start the discovery process to find another server to use.
As of v5.2.b.20110831, you have the option of enabling/disabling the Windows Authentication function when communicating with domain controllers discovered using the Windows domain hierarchy.
This option was automatically selected on previous versions.
See the Symmetric Keys page for more information.
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 broadcasting/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 broadcast/multicast time pulse is occurring rapidly enough to collect your required number of samples
before the clock drifts outside your target tolerance.
As of v5.2.b.20190701, Domain Time Client and Server support Windows NDIS software timestamping, which allows measurement of network stack delays.
Software timestamping is only available on Server 2019 (or newer) and recent updates of Win10. You may want to experiment with this setting
to see if it improves your accuracy. See KB2019.708 for more information.
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 from all servers and choose the best
This controls whether Domain Time applies advanced analysis algorithms to all of 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 derive the correct time.
See the "About Time Samples" sidebar on the right side of this page for more information and rule-of-thumb suggestions on acquiring time samples.
If you are collecting multiple samples from unicast or broadcast sources using the NTP or DT2 protocols, checking this box will almost always improve your machine's accuracy and reliability.
Note: If you are using the IEEE 1588-2008 (PTP) protocol to synchronize your time, including other time sources in the time calculations can cause
inaccuracies at very high levels of precision. Therefore, as of version 5.2.b.20150828, Domain Time automatically excludes all other sources from time calculations when using PTP, falling back to them only if PTP fails, so you may leave this box checked.
However, on versions prior to 5.2.b.20150828, you must manually uncheck this checkbox to prevent skewing of the time from additional non-PTP sources.
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 the first listed time server. This server will always be used unless it becomes 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.
When analysis is enabled and more than one time source is used in a time calculation, the logs (when set to the default
"Information" detail level) and other display fields without room for multiple entries will show the source for the time
as "Averaged Time", otherwise the IP address of the single time source used will be displayed.
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 the machines you list (and enable) on this page for the current time.
The machine list can consist of servers that use the NTP, DT2 (UDP or TCP), or DT2-HTTP protocols. As of version 5.2, you may also select the IEEE 1588-2008 (PTP) Precision Time Protocol as
a time source. See the IEEE 1588-2008 (PTP) page for details on using the Precision Time Protocol.
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.
Note: As of v5.2.b.20190701, NetBIOS and DNS names are checked first for IPv4, and only use IPv6 if the IPv4 lookup fails. (If you
use an IP literal, Domain Time will use the protocol family associated with what you entered, and the information in this section does
not apply.)
To force a NetBIOS name or DNS name to use either IPv4 or IPv6, enter either the text "IPv4" or "IPv6" anywhere in the comment field.
For example, if your source is specified as
ntp.mydomain.com without specifying either IPv4 or IPv6 in the Comment field,
Domain Time will first try to resolve the name using IPv4. If that lookup fails, Domain Time will try to resolve the name using IPv6.
If, however, you put either "IPv4" or "IPv6" in the comment line, Domain Time will look up ntp.mydomain.com's IP address using only the IP
family you specify.
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.
The Port: field displays the IP port used by the selected protocol. This is a display-only field for all protocols except the DT2-HTTP protocol.
The DT2-HTTP protocol port may be changed to match the DT2-HTTP listen port set on the Serve the Time page of the target Domain Time II Server. The default value for this is port 80.
The Redirect allowed checkbox specifies whether the DT2-HTTP time requests will honor HTTP 301 and 302 redirects. Only one level of HTTP redirection is permitted.
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), and as of v5.2.b.20170922, SHA1 authentication as well. 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.
Import/Export
You may easily save or restore the Time Sources list settings by clicking the Import/Export link. You can use this
function to quickly update just the list of time sources used without affecting any other settings.
This function does not preserve IEEE 1588-2008 (PTP) settings, it only saves/restores machines in the time sources list.
If you have multiple machines to update or need to configure other settings, you
should use the full Import/Export features found on the Advanced -> Import/Export property page or use Domain Time II Manager's
Templates feature.
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 DT2/NTP 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 Symmetric Keys 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.
Import/Export
You may easily save or restore the Time Sources list settings by clicking the Import/Export link. You can use this
function to quickly update just the list of time sources used without affecting any other settings. If you have multiple machines to update or need to configure other settings, you
should use the full Import/Export features found on the Advanced -> Import/Export property page or use Domain Time II Manager's
Templates feature.
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 IEEE 1588-2008 (PTP) page
Back to the Installation page