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

Set this machine's time from an external time source checkbox on the Time Sources tab

      and the

Refuse to serve time until this machine's clock has been set checkbox on the Advanced tab before other machines can sync with the server.

Serving NTP on Windows Active Directory Domain Controllers.


IMPORTANT:

---

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:


1. 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.
2. 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.
3. Restart the Domain Time II Server service after making these changes.
4. 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.

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. 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.


Sample browser page output from the built-in web server (reduced size)

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.

Additional Items

• View Log
  You may view the current Domain Time II Server log file (kept in the %systemroot%\system32\domtimes.log file) on your local machine by clicking this button. See the Log Settings tab page for more information about the logs.

• Sync This Machine Now
  Clicking this button will cause the local machine to attempt to synchronize its time with whatever system it has been configured to use as its time source -- clicking this button on Domain Time Slaves causes them to synchronize with the Domain Time Master. Master and Independent Servers will synchronize with whatever servers are configured in the External Time Sources section.

• Sync Entire Domain Now (Available on Master and Slaves only)
  Clicking this button will trigger a domain-wide update of the time on every machine running either Domain Time Server or Client. (See Cascading Time Hierarchy for more information about how time is propagated through the network).

• System Tray Applet
  The Server can display the DTTray System Tray Applet in the Start Bar system tray. The System Tray icon provides visual and audible (if desired) confirmation that the system is correctly synchronized. It also allows a user the ability to trigger a time sync, launch other Domain Time II applications, turn the chimes features on or off, view the Activity Monitor, the client and server time statistics and drift graphs, etc.

  Hint: Right-click the system tray icon to see the context menu.

  You can also use the System Tray applet to check for and download new versions of the software (if your support contract is current). The logged-in user must have access to the Internet and also have rights to install software in order to check for new versions.

  If you do not want the system tray applet to appear, it can be disabled from the System Tray menu. This feature can also be disabled by default during installation by changing the INI Defaults file.

  Read more about the full capabilities of the System Tray applet.

• How to implement Domain Time II on your network
• Domain Time II Clients
• Domain Time II Management Tools
• How Domain Time II distributes time
• More information about time protocols
• Co-existing with Windows Time
• When to use Heartbeats and NTP Broadcasts
• Using Domain Time II across routers and firewalls

 Proceed to the Time Sources page

 Back to the Server Installation page