Domain Time is designed to easily set up and use a Time Hierarchy to distribute the time to machines on your network.

One option is to set up a Domain Time hierarchy that follows the Windows domain hierarchy, where the domain controller machine holding the FSMO PDC (Primary Domain Controller) Emulator role acts as the Master Time Server for the domain and all the other domain controllers act as Slave Time Servers who automatically get their time directly from the Master. Clients on the network can auto-discover and get their time from their nearest Slave Server. Domain Time components automatically set themselves up correctly for this hierarchy when installed.

The main strength of this hierarchy is the efficient distribution of time in an existing domain or forest. However, this is not necessarily the most accurate method of providing time synchronization, and is therefore deprecated in favor of a flatter heirarchy where Clients synchronize as directly as possible with top-level time sources.

See the The Domain Time Cascading Hierarchy section below for more details on the Domain Time hierarchy.

Of course, you may choose to set up your own time distribution hierarchy instead of using the Domain Time II Master/Slave method. You do this by using Domain Time II Independent Servers which can be installed on any machine, whether it is part of the domain or not.

Independent Servers do not have the automatic settings replication, client recommendations, auto-promotion, and failover benefits of the Master/Slave relationship, but your clients will respond to Independent Server advisory signals (see below) so that they can auto-locate the server and you can still achieve excellent timekeeping and propagation of time changes to all of your clients.

The Installation Planning page describes the best practices for configuring your time hierarchy.

 

This section shows the Domain Role assigned to this machine.

• Master Time Server

  Domain Time II Server installed on the machine with the PDC-Emulator role is the Master Server. This setting cannot be changed and no other machine can be set to be the Master.

  If the PDC Emulator role is moved to or seized by another domain controller running Domain Time II Server as a Slave, that machine will automatically become the Master Server and it will take over performing exactly as the previous Master did, using the same settings. Slaves will automatically begin synchronizing with the new machine.

  The cascading time hierarchy (see below) will assure that all other machines match this machine's time as accurately as possible and that any corrections propagate nearly instantaneously to every machine.

  The Master Server also has the ability to set the recommended timing settings for other Domain Time machines in the time hierarchy so that you can centrally control the accuracy of your time network from one location. See the Recommendations page for more info.

  Time Sources
  The Master should be set to get its time from multiple stable, trusted time sources, such as GPS Clocks or other known good network time sources. However, it can also get its time by auto-locating the PDC of another domain by entering the name of the domain in the Time Sources list. This is useful if you have multiple domains and you want to easily set up a time structure among your domains.

  Note this is not a "foreign slave" relationship; the remote PDC will not send slave synchronization signals, and the local PDC will not replicate the remote PDC's settings. The older "Foreign Slave" function in versions prior to v5.1 is no longer used.

  Alternately, you can set the Master to use its own internal clock as the time source, but this is not recommended unless you have a clock card or other external time clock attached directly to the machine that is correcting the local clock. You can use the uncorrected local clock as a last resort, but be aware that the time will almost certainly drift unpredictably across your domain as your Master's clock drifts.

• Slave Time Server

  Any domain member machine other than the PDC-Emulator may be set to be a Slave Time Server. Domain Time II Server installed on a domain controller will automatically become a Slave. Slaves will automatically find and synchronize their time with the Master.

  Domain Time II Server in Slave mode performs two important functions in the time hierarchy:

  1. Slaves allow you to place time servers as close as possible to your time clients (such as on other subnets or remote locations) to allow clients to auto-discover their servers, and maximize accuracy while minimizing the network traffic load.

  2. Slaves provide robust automatic-failover protection for the network. If the Master becomes unavailable, the Slaves will automatically start obtaining the time using the Master's settings. Also, as described above, if any Slave machine is promoted to the PDC-Emulator role, it will automatically become the new Master machine.

• Independent Time Server

  Any machine running Domain Time II Server (other than the PDC-Emulator) may be set to be an Independent Time Server. Independent Servers do not participate in the Master/Slave time hierarchy and are therefore responsible for obtaining their own time from time source(s) you configure.

  It is usually better to use Masters and Slaves if you have a domain structure. However, you may use Independent Servers on a domain if you prefer, and you may manually construct your time distribution structure using Independents without using Master and Slaves.

  However, if you deploy Independent Servers on a subnet where a Master or Slaves are also visible to clients, you should be sure the independents get their time directly from the Master or the Slaves to prevent sending conflicting time and/or cascade messages to clients.

These settings control whether Domain Time II Server sends cascade and/or advisory messages to other Domain Time components.

---

IMPORTANT: These signals greatly enhance the overall synchronization of your time network. Disable only if necessary.

---

Cascade messages are used to propagate time corrections quickly down the hierarchy without having to wait for each component to synchronize on its own. This causes your clocks to converge on the correct time across your network in seconds instead of minutes/hours it takes using other non-signaled methods such as standard NTP or Windows Time. Cascade messages are considered mandatory and are always acted upon by the receiving component (unless explicitly disabled).

Advisory messages are used to help components determine the structure of the time hierarchy, such as by helping clients auto-locate available time servers. Components may act on or ignore advisory signals depending on their current configuration.

Cascade and Advisory signals may be unicast, broadcast, or multicast (any combination).

Each server has its own settings for whether or not it sends cascades, and if so, what type . A server can send broadcast IPv4 only, multicast IPv6 only, multicast IPv4 only, or any combination. IPv4 broadcasts are sent to 255.255.255.255. This is not configurable. If you need your cascades to cross routers, you must use IPv4 or IPv6 multicast instead.

See the hierarchy description below to see which type of cascade/advisory is used.

The Domain Time Cascading Hierarchy

Domain Time II is designed to use a cascading time hierarchy to distribute the time. The Domain Time hierarchy is more robust than the inbound time partner structure of Windows Time and much simpler than manually configuring NTP peering and strata. In the hierarchy, each server is responsible for matching its time with the server above it, and providing the time to servers or clients below it.

• Level 1 (Master)
  Domain Time II Server installed on the domain controller with the Primary Domain Controller (PDC Emulator) role becomes the Master time server for the domain. When the Master's time is corrected to match its time source(s), the Master directs a Level 1 unicast cascade signal to each known Slave. These are the only unicast cascade signals, and they cannot be disabled.

  The Master expects an acknowledgement to the Level 1 cascade from the Slave. If a Slave fails to acknowledge (perhaps because it is currently offline), this is noted in the Master's log file.

  After signaling each known slave, the master broadcasts/multicasts a Level 1 cascade signal to the network. It will be an advisory if at least one slave was contacted successfully, else mandatory (the assumption being that there are no slaves to relay the signal to waiting clients). A master may be configured to skip sending this Level 1 signal to the network.

• Level 2 (Slave)
  Any other domain controller, member server, or member workstation can be configured as a Slave (this is the default for domain controllers). Slaves automatically discover and synchronize with the Master Server. Slaves synchronize time with the Master using the DT2-TCP and protocol, so any intervening firewalls, routers, and/or switches must pass port 9909 TCP (note, it is always a good idea to pass both 9909 TCP and UDP traffic).

  When a Slave receives a Level 1 cascade signal from the Master, it immediately synchronizes its clock and acknowledges the signal.

  After resynchronizing with the Master, each Slave will broadcast/multicast a Level 2 signal to the network. If the resync was due to a Master's Level 1 trigger, the packet will be advisory, else mandatory. The Slave uses the Master's Level 1 sequence number, so any client that happens to hear from multiple Slaves, or from Slave(s) and the Master itself will not resynchronize multiple times. Slaves may be configured to skip sending Level 2 signals to the network.

• Level 3 (Independent Server)
  Any machine running Domain Time II Server (except the domain controller with the PDC Emulator role, which must be a Master) can be configured as an Independent Server.

  When an Independent Server corrects its clock, it broadcasts/multicasts a Level 3 advisory. Independent servers may be configured to skip sending Level 3 signals to the network.

  An Independent Server does not actively participate in the cascading hierarchy with Masters and Slaves. Independent Servers acknowledge Level 1 cascade signals from the Master, but do not act upon them. Independent Servers ignore Level 2 cascade signals from Slaves.

• Level 4 (Client)
  A client both listens for cascade signals and sets its own time independently based on its timing settings.

  If a client is in automatic mode, it uses discovery broadcasts at startup to determine if any Level 2 (Slave) machines exist on the local subnet. If so, the client enters normal operating mode, and will synchronize its clock upon receipt of a Level 2 cascade signal.

  If no Level 2 machine is found (perhaps because all Slaves are currently offline, or the client is not connected to the network), the client enters pessimistic mode. In pessimistic mode, the client listens for all cascade and advisory signals and responds by synchronizing its time with whatever machine sent the cascade signal and taking the following actions:

  If the cascade signal comes from a Master Server, the client assumes that the network has only a Master and clients. From that point on, the client will ignore Level 3 cascade signals (Independent Servers). This is called Master-only mode. Master-only mode converts to normal mode upon receipt of the first cascade signal from a Slave.
  • If the cascade signal comes from a Slave Server, the client assumes that Slaves are now present, and from that point on ignores both Level 1 (Master) and Level 3 (independent server) signals. This is normal mode.

  • If the cascade signal comes from an Independent Server, the client will sync with the Independent Server, and assume the network has neither Master nor Slaves. The client continues in pessimistic mode until a Master or Slave signal is seen.

Note that this procedure allows the time hierarchy to automatically collapse levels so that clients respond only to the next-highest level at any time. If a Slave comes online after the client is started, the client will note this fact and move from Master-only mode to normal mode immediately. If, while in normal mode, no Slave can provide the time, the client will automatically move into Master-only or pessimistic mode, as needed.

This hands-free configuration allows you to have any mix of Master, Slaves, and independent servers on your network, any of which may be working or not at any given time, and still use Domain Time II's hierarchy to (a) limit network traffic, and (b) ensure quick, uniform updating of all levels when the highest-level time source is updated.

 Proceed to the Recommendations page

 Back to the Serve the Time page