Use this page to set which time protocols are served by Domain Time II Server.
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.
This section controls whether Domain Time II Server will provide time using the Domain Time II (DT2) protocol.
The DT2 protocol is a high-efficiency protocol optimized for time synchronization that also allows for bi-directional communication between Domain Time components using Domain Time control messages that enable advanced management and monitoring functions.
This setting only controls whether Domain Time will respond to DT2 time requests and/or transmit DT2 time broadcasts or multicasts.
These settings do not affect DT2 control messages. Even if the protocol is turned off on this page, Domain Time II Server will still send/receive DT2 control messages on port 9909 UDP and TCP. See the Advanced... Command Restrictions section of the
Security Settings page for information on controlling command messages.
When DT2 Server Enabled is checked, Domain Time Server will reply to either UDP or TCP time requests. UDP is an excellent choice for time packets, since it is connectionless and does not
incur the overhead necessary to establish and tear down a full TCP session. TCP is often used for sending larger amounts of data in control messages.
Your network will need to pass both port 9909 UDP and TCP packets in order to work correctly with Domain Time II version 5.x and above. See Installation Planning for more information.
Should I choose DT2 or NTP? DT2 UDP sync packets tend to be smaller and therefore somewhat more efficient than NTP time packets. In normal networking applications, either protocol is a good choice.
However, if you are attempting to achieve very high-accuracy, the difference in overhead between DT2 and NTP packets can become significant and you will want to use DT2 UDP whenever possible.
DT2 Broadcasts/Multicasts
The normal operation of Domain Time Server is to respond to unicast NTP time requests from time clients. This is a "pull" method of obtaining the time, where clients request the time on their own schedule.
Domain Time Server can also be set to transmit NTP on a regular schedule. This is a "push" method of distributing time where clients listen for time packets from the server.
The Broadcast and Multicast addresses used by Domain Time are configured on the Broadcasts and Multicasts page.
The Send IPv4 broadcasts
Send IPv4 multicasts
Send IPv6 multicasts
checkboxes on this page set the method used to transmit DT2 packets when using the "push" method of distributing time.
IPv4 Broadcasts are sent to the configured broadcast address (usually the local network). Broadcasts do not typically pass routers, so you will likely use this option
only if your clients are on the same local subnet as the server. Broadcasts are deprecated in favor of multicast starting with version 5.x.
IPv4/IPv6 Multicasts are usually able to pass routers/switches without additional configuration and are therefore usually a better choice for transmitting heartbeat packets.
Domain Time handles all of the details of joining the correct multicast group for the protocol for you. You may select IPv4 and/or IPv6 multicasts.
Be sure the TTL (IPv4) or Hop Count (IPv6) settings on the Broadcasts and Multicasts page are set correctly so that multicasts
reach your desired subnet(s). Multicasts are supported as of version 5.x.
Bcast Version: selects whether a Broadcast pulse contains a timestamp (version 4) or not (version 3).
If you select version 3, the Client will be triggered to synchronize its time when the pulse is received. It will then make a unicast request for the time from whatever Domain Time Server it is configured to use.
Version 3 heartbeats are compatible with Domain Time version 3.1 and above.
If you select Bcast version 4, the Server will include the current time in the broadcast time packet. Clients will set their time to the included timestamp and do not make any requests of a server.
Version 4 heartbeats are compatible with Domain Time version 4.x and above.
Multicasts always include the current time in the timestamp. This setting has no effect on Multicasts.
What about Windows Time?
In most cases, Domain Time II will completely replace Windows Time, so the Windows Time service can and should be disabled in most cases*.
In previous Domain Time versions, it was necessary to set the Windows Time service to run in a special mode called NoSync on Domain Controllers (DCs)
to allow Windows Time to provide the proprietary NT5DS-mode authentication timestamp required by domain members running Windows Time.
As of version 5.x, this is no longer required since Domain Time II can provide the correct NT5DS-mode timestamp directly to all domain members.
Installing Domain Time on all your systems is preferred for many reasons, but if this is not practical for all your machines, having Domain Time
provide NTP with Windows authentication directly to Windows Time clients is still a great advantage in accuracy and reliability over W32time.
Also, unlike with w32time, you can serve NTP with Windows Authentication from any domain member machine, not just a DC.
*Windows Time will still need to be set to NoSync mode on older (Server 2003 or earlier) Windows Cluster Servers, since
the Cluster Service has a dependency on the w32time service in order to start on those versions. w32time is not required after the Cluster Service has started.
See the Advanced page for more information.
When Windows Time is disabled on a DC, you may see spurious messages in the log or in DCDIAG about Windows Time not being synchronized. You can
disregard these faux warnings, since Domain Time is indeed accurately synchronizing the domain.
This section controls whether Domain Time II Server will provide time using the NTP protocol, either by unicast requests from clients or by broadcast and/or multicast.
There are special considerations for this setting when you are running on a Windows Domain Controller. See the What About Windows Time? sidebar for details.
When NTP Server Enabled is checked, Domain Time Server will reply NTP UDP time requests.
Your network will need to pass port 123 UDP packets in order to communicate with devices that use NTP.
Although port 123 UDP is sufficient to pass time traffic, you will also want to
pass DT2 control messages if you want to use many of Domain Time's advanced features. See the Network section of the Planning page for more information.
When enabled, Server will also be able to respond to a subset of requests from the standard UNIX/Linux ntpq and ntpdate query utilities. See the ntpd Compatibility page for details.
NTP Stratum
By default, Domain Time selects an NTP stratum number based on on strata reported by its time sources (including PTP, which uses "StepsRemoved" to correspond, roughly, with NTP strata).
Since Domain Time can use multiple sources with multiple protocols, there may not be an ultimate single stratum from which time was received.
In these cases, Domain Time takes the highest-level stratum reported by all used sources, and adds one to derive its own stratum number.
So, for example, if Domain Time obtains its time from a PTP grandmaster directly, it will report itself as stratum 2. If it receives its
time from three NTP sources, two of which report stratum 1, and one of which reports stratum 2, Domain Time will report itself as stratum 3.
If all three NTP sources reported stratum 1, Domain Time would report stratum 2, and so forth.
If there are no upstream timesources (such as when you select the "Do not set this machine's time" radio button on the
Obtain the Time page), Domain Time will assign itself stratum 15, which
is the lowest valid stratum number. However, some NTP clients will refuse to synchronize with lower stratum levels. In this case,
you will need to use the
HKLM\SOFTWARE\Greyware\Domain Time Server\NTP Server Stratum registry
key to assign a higher stratum, i.e. a registry value of 1 assigns stratum 1.
Versions prior to 5.2.b.20150516, automatic assignment applied a default Stratum depending on the type of Server Role selected:
Master Server: Stratum 2
Slave Server: Stratum 3
Independent Server: Stratum 2
NTP Broadcasts/Multicasts
The normal operation of Domain Time Server is to respond to unicast time requests from time clients. This is a "pull" method of obtaining the time, where clients request the time on their own schedule.
Domain Time Server can also be set to transmit time on a regular schedule (also referred to as "heartbeats"). Heartbeats are a "push" method of distributing time where clients do not obtain the time until signaled by the server.
The Broadcast and Multicast addresses used by Domain Time are configured on the Broadcasts and Multicasts page.
The Send IPv4 broadcasts
Send IPv4 multicasts
Send IPv6 multicasts
checkboxes on this page set the method used to transmit NTP packets when using the "push" method of distributing time.
IPv4 Broadcasts are sent to the configured broadcast address (usually the local network). Broadcasts do not typically pass routers, so you will likely use this option
only if your clients are on the same local subnet as the server.
IPv4/IPv6 Multicasts are usually able to pass routers/switches without additional configuration and are therefore usually a better choice than broadcasts.
Domain Time handles all of the details of joining the correct multicast group for the protocol for you. You may select IPv4 and/or IPv6 multicasts.
Be sure the TTL (IPv4) or Hop Count (IPv6) settings on the Broadcasts and Multicasts page are set correctly so that multicasts
reach your desired subnet(s). Multicasts are supported as of version 5.x.
Bcast Version: selects what NTP version the time packet reports for compatibility with various NTP implementations. The default value is 3, which should be correct for most situations. Don't select version 1 or 2 if you are using authentication.
Select whether to enable the DT2 over HTTP and/or the Domain Time I (mailslots) protocols.
DT2 over HTTP
This is a special time protocol that is communicated using standard HTTP packets. The typical port used is TCP port 80.
(Note: some older versions of Domain Time shipped with this setting set to port 90 as the default)
Since this protocol uses the same standard HTTP port used by web browsers, it can pass through most firewalls transparently.
This can easily solve firewall connectivity issues for obtaining time.
However, we recommend you only use this protocol for time synchronization if your firewall administrator is unable/unwilling to allow the regular Domain Time II protocol
(UDP port 9909) or other native time protocols to pass the firewall. Due to the nature of HTTP and the variability of proxy configurations and load,
the DT2 over HTTP protocol is subject to unpredictable latencies that can affect the accuracy of the time being sent.
Also, many of the advanced features of Domain Time II such as remote control, monitoring, and upgrade/installation are not available using this protocol.
CAUTION: Only one service can "own" the HTTP port 80 on a machine at a time.
Domain Time II Server starts very quickly at boot-up. If the Domain Time II over HTTP protocol is enabled, it will very likely attach to port 80
before any other service can start (such as standard web servers like Microsoft's IIS). This will prevent the web server from responding correctly.
If you are running Microsoft's IIS or another web server on your machine, you should change the Domain Time II over HTTP IP port to an unused number
to avoid these conflicts.
If you enable the DT2 over HTTP protocol, Domain Time Server can provide a compact DT2 over HTTP time protocol packet (if you have either the Allow clients and/or
Allow servers checkbox checked).
Web Page Stats Display
Domain Time can also provide a special human-readable web page if you have the Allow browsers checkbox checked.
The web page provides a great deal of useful information about the status of the Domain Time II Server, and is a great way to monitor the operation of your servers from any machine with a browser.
To view the webpage, enter the name or IP address of your Domain Time II server (plus ":" and the port number, if needed) into your web browser address bar,
i.e.
You can customize the appearance of the web page using standard HTML code. See the Customizing the appearance of Domain Time over HTTP registry entry
on the Server Registry Options page for details.
DTLinux Updates
The Serve DTLinux Updates checkbox allows Domain Time Server to act as an alternate data source
for DTLinux updates (Domain Time Manager must also be installed on this machine). The Test Server link will display the available DTLinux distribution files. Please see
the UpdatingDTLinux.html file
located in the DTLinux distribution files or in the
/opt/domtime folder of your DTLinux system for full instructions.
Domain Time I (mailslots)
Domain Time I is a proprietary protocol used by version 1.x of Domain Time.
It uses LAN Manager's Mailslots function to obtain the time from a Domain Time Server. You will only need this protocol
if you have any Domain Time version 1.x clients in use.
You may enable PTP Master mode operation by checking this box. Click the Options link to bring up the PTP configuration pages.
NIST Daytime is an older, human-readable time protocol.
Domain Time II Server will serve time via the Daytime protocol, but no Domain Time II component uses Daytime for time synchronization purposes.
Domain Time II Server's Daytime string format defaults to the NIST standard (see below), but may be customized to other formats using a registry setting.
TIME/ITP is another older protocol used by some legacy systems.
Domain Time II Server will serve time via the TIME/ITP protocol for compatibility with Domain Time II version 2x - 4x, but as of version 5.x, Domain Time II does not use TIME/ITP for obtaining the time.
Serve 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 Domain Role page
Back to the Correction Limits page