Selecting a Server Role
A machine running Domain Time Server must play one of three roles: Master, Slave, or
Independent Server. (See Cascading Time Hierarchy
for more information about the roles and their responsibilities).
- A Primary Domain Controller (or FSMO acting as PDC emulator) must be a Domain Time II Master.
The only real difference between a Master and an Independent Server is that a Master may have Slaves.
By default, Domain Time II Server on any other Domain Controller will automatically be installed as a Slave.
Any other domain member machine may also be a Slave.
- A Backup Domain Controller (DC) may either be a Slave or an Independent server. If it is a
Slave (the default), there are no options to set except on the Slave's Advanced Settings
tab, where you can choose what time protocols that machine will serve. All other Slave settings are controlled
automatically by the Master.
- Any other Windows server or workstation that is a member of a domain may be either a Slave or an Independent
server. If it is an Independent Server (the default), its settings are exactly the same as for
a Master, except that it can have no Slaves.
- A Windows server or workstation that is stand-alone or a member of a workgroup instead of a domain
does not have the option of being a Slave. It must be an Independent Server.
Why Have Slaves?
Unlike other time synchronizers (such as Microsoft's Windows Time Service - see
Overview of Microsoft Windows Time (W32Time) Service),
Domain Time provides a critical benefit on Windows networks -- failover protection. Domain Time is aware
of and takes advantage of the Microsoft domain controller hierarchy to enhance redundancy and
ease-of-configuration. All the information for the time settings on the Domain Time Master (the PDC)
is automatically propagated and shared among the Slaves and is not lost in the event of a PDC failure.
When a DC is promoted to PDC, it also automatically becomes the Domain Time Master for its domain,
regardless of whether the DC used to be a Slave or an Independent Server. If the DC used to be
a Slave, it will automatically pick up where the old PDC left off, using the same settings as the old PDC.
If the DC used to be an Independent Server, it will continue using the same External Time Sources settings
it had previously as an Independent, but it will revert to the factory default settings for its new Slaves.
Therefore, Slaves are more useful as true backups for the Master than are Independent Servers, although both will
take over as Master in the event their machine is promoted to PDC. In both cases, the old PDC automatically becomes
a Slave of the new PDC.
In addition to making the entire time system more robust, having a Domain Time II Server installed on all Domain Controllers is
particularly useful in an Active Directory network. Under Active Directory, every Domain Controller advertises itself as a
time server whether a time service is correctly configured (or even running on it) or not. Having Domain Time Server on each
DC ensures that any machine that contacts the DC for time will get the correct time.
Also, having a Domain Time II Server on every DC helps insure that Domain Time Clients have a Server available on the local subnet,
so that clients can reliably auto-discover their servers (lets you use Thin Client or Full Client in automatic mode).
Machine Role selection
The current role of the server is shown in the Machine Role section of the Domain Time
Control Panel applet. The Master option is automatically determined and is only available on a PDC. Other
servers may be set to be either Slaves or Independent Servers. Unavailable Machine Role choices are greyed out.
Time Protocols Served by this Machine
Domain Time II Server will service clients that request the time using the protocols selected on this screen. See the
Time Protocols page for more information on the
capabilities and limitations of each protocol. If you will be using Domain Time II to broadcast the time to clients,
you will also need to configure the broadcast protocols on the Broadcast Time tab page.
It is possible on Master and Independent Servers to configure the server to serve different protocols than the
ones it uses to obtain the time. Use the Time Sources tab to configure how Domain Time II Server
obtains its time. Slave servers always receive their time from the Master over Domain Time II protocols.
By default, a Domain Time server will not begin to serve the time to other machines until it has
successfully set its own clock at least once externally from a trusted network source.
Check the domtimes.log file to verify that Domain Time has successfully synchronized with the trusted time source and is serving the time.
A log excerpt showing the Server is ready to serve time to clients
Note: If you want Domain Time II Server to use its own local system clock as the time source instead of getting
time from another machine (as you might if you have a GPS card installed in the machine, for example), you need to uncheck both the
Serving NTP on Windows Active Directory Domain Controllers.
Because of how Microsoft designed the client portion of the Windows Time service included with Windows 2000 and later, it is
necessary to allow Windows Active Directory Domain Controllers to serve NTP via the Windows Time service when Windows Time clients in
NT5DS sync mode are in use on a Windows Active Directory domain.
Since only one time service can own the NTP port (123 UDP) at a time, if Windows Time serves NTP, Domain Time II cannot, and
vice versa. Therefore, for maximum compatibility with NT5DS mode clients, the default installation of Domain Time II Server automatically
configures the Windows Time service to serve NTP and disables its own NTP function. It also forces Windows Time to NoSync mode
so that only the Domain Time II Server is responsible for obtaining the correct time and setting the local system clock.
Although this configuration proves the most compatible with the default configuration of Windows Active Directory domains, it may not
be optimal for your situation. The NTP server portion of the Windows Time service is not a particularly accurate implementation due to its design
target of only needing accuracy within several seconds. If you are concerned with accuracy of the time served to NTP and Windows Time clients,
you should change the default settings so that Domain Time Server serves NTP on your Domain Controllers (and Windows Time does not).
If you do so, you will also need to change the sync mode of any Windows Time clients from NT5DS to NTP Client (of course, the best solution is to
use a Domain Time client on such machines instead of Windows Time and avoid the NTP issue entirely).
To enable Domain Time II to serve NTP on an Active Directory Domain Controller:
- Click the NTP checkbox on the Server tab of the Domain Time II Server applet. You'll receive
a warning about the potential conflict with Windows Time which you can ignore.
- Pull up the Domain Time II Windows Time Agent control panel applet
(either from the Control Panel or from the right-click context menu of the Domain Time system tray icon). Use the Server tab to disable
the NTP server function of Windows Time.
- Restart the Domain Time II Server service after making these changes.
- On Windows Time clients, you can either install and use the Domain Time II Windows Time Agent
control panel applet to change the Client sync mode from NT5DS to NTP Client on individual machines, or you can use Windows policies to set the NTP
Client mode network-wide.
This subject is covered in detail on the Co-existing with Windows Time page.
Thread settings for the Domain Time II UDP and Domain Time II TCP protocols.
Domain Time II Server allows you to specify the number of worker threads assigned to the Domain Time II UDP and TCP protocols to
adjust how responsive the server is to large numbers of simultaneous time requests. One to two threads per protocol is
usually sufficient for most networks. However, if you have a large number of machines synchronizing to the machine simultaneously
you can increase this setting as necessary. Increasing the threads will use additional memory and resources from your machine.
Note: Setting either the UDP or TCP thread setting to 0 will disable that protocol entirely. However, at least one thread should
always be assigned to the Domain Time II UDP protocol in order for the server to send and receive Domain Time sync triggers and
control messages. The Server needs to have the Domain Time II UDP protocol available regardless of what other time protocol is
actually being used to sync time.
There is no significant performance penalty for enabling Server to provide all the listed protocols, and
this allows Server to work with the widest range of clients. However, you may wish to disable any
protocols that you do not use, or if you want Server to respond only using using a particular protocol
(note, however, that the Domain Time II UDP and LAN Manager protocols are always available).
The Domain Time II over HTTP protocol
This is a special time protocol that is communicated using standard HTTP packets over TCP port 80 (by 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.
For example, a Domain Time II server could be set up outside a firewall to obtain time from public NTP
servers, and then an internal Domain Time II Server could use the web proxy to contact the server and
distribute time to the internal network.
However, we recommend you only use this protocol if you must obtain time through a firewall and your
firewall administrator is unable/unwilling to allow the regular Domain Time II protocol (UDP port 9909)
or other timeprotocols to pass the firewall.
Due to the nature of HTTP and the variability of proxy configurations and load, the Domain Time II
over HTTP protocol is subject to 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.
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.
See the Server Registry Settings page for info on changing the HTTP Server Listen Port.
Built-In Web Server
This is a special feature of the Domain Time II over HTTP protocol.
If you enable the Domain Time over HTTP protocol to be served by the Domain Time II Server,
Domain Time will provide both a human-readable web page (when the server is visited by a browser) and a
compact time data packet (when the server is queried by a Domain Time II client).
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.