This page gives you access to various advanced Domain Time II settings.
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.
CAUTION: The default settings on this page are usually correct for most applications. Only make changes if you are sure you need them and you fully understand the effects of the change.
Incorrect settings may adversely affect your clock accuracy or even prevent clock corrections entirely.
Miscellaneous options include:
Enable Test Mode
Checking this box causes Domain Time to operate in all ways as it would in normal operation, except for actually
setting the time or changing the machine's slew rate. This allows you to test or troubleshoot the server's ability
to obtain and serve the time, but without actually changing the server's time.
Results of all operations are logged normally, so you can use the log in test mode to track down any communication
or other synchronization issues. Note: Be sure to disable this option when you're through testing!
Enable Clock-Change Monitor
Domain Time's Clock-Change Monitor notifies Domain Time if another user or process attempts to change the time on this system.
When an unauthorized clock change is detected, Domain Time immediately re-synchronizes the time with its time source(s) and makes
a warning entry in the logs. This prevents inadvertent or malicious tampering with the system clock.
This setting should always be enabled unless you are doing testing that requires you to change the system clock manually, either from the
Windows Date/Time applet or from some other application.
Force setting of CMOS clock at service shutdown
Controls whether Domain Time should perform an API system call to write the current system time to the CMOS Real-Time Clock (RTC) on the motherboard each time the service stops.
On modern operating systems, the CMOS RTC clock is primarily used to provide something approaching the current date/time to the operating system while booting until the operating system
can take over timekeeping. The CMOS clock is subject to all manner of inaccuracies, and is therefore not used for timekeeping while the OS is running, nor is it updated often.
The CMOS clock can therefore go for long periods without having its time corrected, resulting in huge drift. By default, Domain Time will update the CMOS with
the current time either when doing so doesn't cause a disruption to the operating system time (during stepped corrections) or just before shutdown so
that the CMOS has its best chance to be accurate during the time the system is not running.
When this box is unchecked (the default), Domain Time writes the current time to the CMOS RTC clock:
when making a stepped time correction.
if the Domain Time service is running and it receives a system shutdown command from the operating system.
If the box is checked, then Domain Time will also write to the CMOS clock any time the Domain Time service is stopped, whether or not the stoppage is due to
a system shutdown.
Although at first read this may seem desirable, there is a downside to writing to the CMOS clock if the machine isn't already being hard-set (stepped) or in the process of shutting down.
The API used by the operating system to write to the system clock also immediately steps the system time to the same time as the RTC but only at the resolution of the
CMOS clock. Since the RTC resolution varies on different machine, writing to the CMOS will cause the system clock to jump either forward or backward to the nearest increment of the RTC, which can mean an
unpredictable jump of 1ms or more in the system time.
As a result, you should leave this switch turned off unless you need to force a CMOS update by manually stopping the Domain Time service.
Use software timestamping (if available and enabled)
As of v5.2.b.20190701, Domain Time can use the Microsoft NDIS software timestamping API to help compensate for network stack delays. Microsoft only offers this function
on its most recent versions of the operating system (i.e. Server 2019 and updated versions of Win10/Win11). This option will be greyed-out if it is not supported on this OS.
Note this checkbox only controls Domain Time's ability to use software timestamping if present. Timestamping must also be enabled at the operating system level.
You can do this by using Microsoft's own PowerShell scripts (see KB article linked below), or you may use the
DTCheck utility. To use DTCheck,
open an elevated command prompt and issue the desired command:
dtcheck -swTimestamps
displays current settings
dtcheck -swTimestamps:Enable
attempts to enable software timestamping
dtcheck -swTimestamps:Disable
attempts to disable software timestamping
dtcheck -stats2
shows statistics for NDIS timestamping
dtcheck -interfaces
shows which interfaces have software timestamping enabled
You'll need to restart the NICs (or reboot the machine) after enabling or disabling timestamping.
You can experiment with this setting to see if it improves your accuracy or not. The stack delay on
most machines is minimal so the overhead of measuring it may outweigh the benefits,
however, you may see improvement on very busy machines.
Enable advance scheduling of leap second corrections
Controls how Domain Time handles upcoming UTC leap second corrections.
NTP and PTP packets can contain a flag to indicate an upcoming UTC leap second. When this checkbox is enabled, Domain Time will apply leap seconds at 23:59:59 UTC on the last
day of the month in which the leap occurs (typically June or December). If unchecked, leap seconds will be applied at the first timecheck following the leap.
Domain Time acquires pending leap second information only from NTP or PTP
time sources. All queried NTP or PTP sources must agree that a leap is pending
in order for Domain Time to schedule the leap. If the sources disagree,
then the leap will be handled at the next timecheck after it occurs, and
a warning notice that the leap indicators are inconsistent will be placed
in the log.
Pending leap information is queried with each timecheck (NTP sources
only), and maintained only while the Domain Time service is running.
Restarting the Domain Time service will clear any pending leap second
corrections. If the leap is still pending when the Domain Time service
is restarted, it will be rescheduled for the appropriate time. If the
leap occurs while the Domain Time service is stopped, the leap will be
applied at the first timecheck after startup.
Signal resync if VM guest resumes from paused or saved state
Allows correction of clocks on virtual machines after resuming from pause/suspension.
Virtual machines are often paused/suspended, causing the clock to be incorrect when resumed. Domain Time may be able to sense a resumption by examining the Time Stamp Counter (TSC) and resync the clock.
This setting is only useful on virtual machine guests. This option will be greyed-out if the machine is not a virtual guest.
Truncate drift status records to milliseconds
Delta values in the drift logs will be reported to the nearest millisecond if this checkbox is checked.
The Domain Time II System Tray applet (DTTRAY.EXE) is a foreground application that can load whenever a user
logs into the system. When loaded, it will display as an icon in the System Tray.
The applet provides a number of very useful functions, including audio alerts and chiming, statistics, drift graphs,
and a quick way to launch the various features of Domain Time installed on the machine.
The settings in this section determine whether or not to load the applet and which audio features are enabled.
Show system tray icon
This checkbox controls whether the Domain Time System Tray applet is loaded during login.
If the icon is present in the System Tray, you can right-click it to choose from many additional features.
Note: The applet will unload if the Domain Time service is stopped. On XP and Server 2003, the applet will reload automatically when the service restarts.
However, beginning with Windows Vista, Microsoft disabled the ability for background services to launch foreground programs, so on those systems you will need
to either log out and back in or relaunch the applet manually. You can restart the applet manually by entering dttray.exe into the
Start -> Run program field or at a command prompt.
Time of Day Chimes
The Time of Day Chimes feature plays sound files at specific times of the day, such as every 15, 30 45 minutes and on the hour.
This option will be unavailable if the Show System Tray icon checkbox on the Advanced tab is unchecked.
There must be a logged-in user and the Domain Time II System Tray icon must be present in the Windows System Tray for the chimes to play.
You must also have installed at least one free Domain Time II Chime Pack
for this feature to work.
See the documentation for the System Tray Applet for complete instructions and
to download free Domain Time II Chime Packs.
Timeset Chime
Plays a sound whenever the Server successfully sets its time from its time source.
If checked, the sound will play whether or not there is a logged-in user.
Sound card plays through the sound card if available PC Speaker plays through the PC speaker
The first two settings in this section control whether Domain Time II Client responds to cascade and/or advisory messages from 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 (see the Server's Broadcasts and Multicasts page for details).
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.
The Enable NTP listener on port 123 checkbox controls whether
Domain Time Client will listen for incoming NTP traffic (such as NTP broadcasts/multicast time packets or other requests from NTP status tools).
IMPORTANT: Only one program or service may own the NTP port on this machine. If this checkbox is checked, Domain Time will attempt to
acquire ownership of the NTP UDP port 123 when the service starts. You must be sure any other time program that listens for incoming NTP requests (such as W32Time)
is disabled before enabling this setting.
Note that this setting does not apply to the outgoing NTP time requests Domain Time makes of its time sources; it only applies to incoming NTP traffic.
When enabled, Client will be able to accept NTP broadcast/multicast time packets (assuming you have chosen that method on the Obtain the Time page).
Client will also be able to respond to a subset of requests from the standard UNIX/Linux ntpq query utility, i.e. ntpq -np.
The settings in this section configure the Windows Time Service to co-exist with Domain Time.
Windows Time mode:
This drop-down box lets you determine how the Windows Time Service should behave on this machine. When the Domain Time II service starts,
it will force the Windows Time service into this mode. The available options are:
Disabled The service startup setting for Windows Time Service is set to Disabled. The Windows Time Service will not be allowed to run.
This is the preferred setting for all machines except domain controllers and machines running Windows Cluster Service (see the NoSync description below).
NoSync This mode makes sure the W32Time Server Provider portion of the Windows Time Service is running, but the W32Time Client Time Provider is disabled.
In this mode, Domain Time II actually obtains the correct time and manages the local system clock; Windows Time merely answers NTP requests.
Note:
This mode is necessary either when Domain Time II Client is installed on a Windows Domain Controller to enable NT5DS mode
to function properly, or on versions of Cluster Server that have a startup dependency on W32Time (see below). This mode will be enabled automatically
during installation of Client on a DC; you will need to manually enable it on Cluster Servers.
Although machines running in NoSync mode will provide NTP to NT5DS-mode machines, the accuracy of the timestamps provided will be constrained by the native inaccuracy of the Windows Time service.
Also, non-Windows systems may have difficulty synchronizing with the machine, since W32Time is not compatible with many NTP daemons. If possible, we recommend you use
the Domain Time II Server on Domain Controllers instead, so that it can provide high-accuracy NTP to all clients.
Cluster Service
Some versions of the Windows Cluster Service (i.e. Win2003 and earlier) have a default startup dependency on the w32Time (Windows Time) service. Cluster Server does not appear to require the time service for any other purpose. Thus,
the simplest recommendation for installing Domain Time on clusters that have the W32Time startup dependency is to set the Windows Time mode: dropdown to NoSync, which allows the W32Time service to be
running to satisfy the dependency, but allows Domain Time to set the cluster's clock.
Although the NoSync setting is sufficient to allow the Cluster Service to start on machines running Domain Time Client, you may replace or remove the startup dependency if you want.
CAUTION: The following registry change is provided for your information. We're not aware of any issues with removing the dependency, but you should defer to Microsoft's guidance.
Be sure to test any changes thoroughly on non-production servers before implementing on production systems.
To remove the W32Time startup dependency (if present):
After installing Domain Time on the cluster, use RegEdit to navigate to the following key:
DependOnService value lists all services on which the Cluster Service startup depends. If the w32Time entry is present in the list, change it to
Domain Time Client and save your changes.
The cluster service will then wait until Domain Time has started before starting the cluster.
If the
w32Time entry is not present in the list, there is no startup dependency on Windows Time in your version of Cluster Server and you do not need to make any changes to this registry value.
Once you have verified there is no startup dependency on W32Time on all nodes of the cluster, you can then set the Domain Time Windows Time mode: dropdown list to Disabled and restart the Domain Time service.
Not Touched The existing configuration of the Windows Time Service is not changed.
In this mode, Windows Time will operate exactly as it is currently configured.
Note: Unless you have disabled all possible Domain Time sources and automatic source discovery, Domain Time will always attempt to set the clock, which will likely conflict with Windows Time.
This option is not recommended.
NT5DS The Windows Service is set to run and it obtains the time from the Active Directory hierarchy in NT5DS sync mode.
Note: Unless you have disabled all possible Domain Time sources and automatic source discovery, Domain Time will always attempt to set the clock, which will likely conflict with Windows Time.
This option is not recommended.
AllSync The Windows Service is set to run and it attempts to obtain the time from the Active Directory hierarchy in NT5DS sync mode and/or using NTP Client mode.
Note: Unless you have disabled all possible Domain Time sources and automatic source discovery, Domain Time will always attempt to set the clock, which will likely conflict with Windows Time.
This option is not recommended.
NTP The Windows Service is set to run and it attempts to obtain the time using Windows Time's NTP Client mode.
Note: Unless you have disabled all possible Domain Time sources and automatic source discovery, Domain Time will always attempt to set the clock, which will likely conflict with Windows Time.
This option is not recommended.
Disable Agent
This checkbox disables the Domain Time II Windows Time Agent.
Note: In version 4.1, the Domain Time II Windows Time Agent was installed by default. In version 5.1 and newer, Domain Time is able to replace Windows Time entirely, so
the agent is not installed and the option defaults to disabled. If you have upgraded from 4.1, the agent is still present but not required. You may use this option to disable it.
This option has no effect if Agent is not installed.
If you would like to use the Agent, you may install it from the distribution files, or by using Manager, or download the software from the website, if desired.
You must close and re-open the Server Control Panel applet after installing the Agent.
If Agent is installed, the button launches the Domain Time II Windows Time Agent to allow you to view and configure the settings for the Windows Time service.
Depending on the settings above, various parts of the Windows Time Agent applet may be disabled. See the full Windows Time Agent documentation for more details.
Advanced
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 Clock Control page
Back to the Status Reports page