Domain Time II Installation - 4.x to 5.x Considerations

Domain Time II
Version 5.2

4.x to 5.x Considerations

Please see Changelog for detailed information on all changes and updates.
Review this page for information on important differences from version 4.x and earlier.

Domain Time II Verison v5.x introduces significant performance improvements, new features, and other enhancements to the Domain Time II product line. This document does not cover all of the changes, but it does address important items to be aware of when installing or upgrading to version v5.x from v4.x.

See the online documentation for more complete information on these items.

Notable changes from version v4.x

Version v5.x only runs on Windows XP and above. Win9x, NT, or Win2000 systems should continue using version v4.x.
The three main types of v4.x Windows Client services (Full Client, Thin Client, and Ultra Thin Client) have been combined into a single 5.x Domain Time II Client. Existing v4.x Full, Thin, or Ultra Thin Clients will be converted to v5.x Domain Time Client during upgrade. Existing settings are preserved during the upgrade, so the v5.x Clients will continue to perform the same functions as the v4.x Clients did. EXCEPTION: The Thin client and Ultra Thin Clients may need to be configured via the Control Panel Applet if you weren't using the default settings on those Clients.
Note that v4.x Thin and Ultra Thin Clients did not have Control Panel Applets, but the v5.x Client does. You may delete the domtimec.cpl file from the \System32 folder after installation/upgrade if you do not want the applet to appear.
The v4.x DOMTIME.INI template configuration file is no longer used to determine the installation defaults for Server and Client. Instead, a standard Windows registry file (dtserver.reg for Server or dtclient.reg for Client) holds all the default settings.
The new .reg file can be edited in any text editor. The Control Panel's advanced Import/Export page will read or write the file, making sure that only appropriate entries are loaded or saved. The Import/Export page also checks to make sure the .reg file is the correct version (v5.x) and type (server or client) for the machine.
v5.x introduces the ability to configure many Client and Server options using Windows Group Policies. The distribution folder contains an administrative template file (domtime.adm) that you can use to populate objects in your Group Policy Object Editor. Load the domtime.adm template into the object as a "Computer Configuration" template. See the Microsoft documentation for details on using Group Policy templates.
The Domain Time Windows Time Agent is no longer installed by default during installation of Domain Time Client or Server. The "Windows Time" button on the Advanced property page will only operate if the Windows Time Agent is already present (either from an upgrade from version v4.x or if manually installed from the distribution files).
Version v5.x allows you to disable the Windows Time service entirely in nearly all circumstances, so the additional configuration options the Agent provides for W32Time are not required.
Masters and Slaves
The master server for any given domain may use the following options for obtaining the time:
1. use its own clock (not recommended unless you have a third-party hardware device of some kind maintaining the clock)
2. use a list of time sources
3. use the PDC of another domain (by specifying the domain name on the time source setup dialog; the PDC is looked up dynamically)
  Note that option (c) is not a v4.x-style foreign slave relationship; it merely allows the local PDC to easily obtain the time from another PDC in the forest. The v4.x "foreign slave" relationship where local PDCs would receive slave synchronization signals and replication settings from the foreign PDC does not exist in v5.x.
  Option (c) can also be used by any other server or client, not just the domain master server. Again, using this option does not make the machine a slave; it merely lets you specify the domain without having to specify the PDC. When the PDC-emulator role shifts, machines will automatically start using the new PDC-emulator without additional configuration.
v4.x masters and slaves interoperate with v5.x masters and slaves, but will not replicate security parameters or other v5.x information.
Clients using DHCP Discovery
Option 004 ("Time Servers") is used only for discovering DT2 servers. If a server is listed in option 004 that doesn't support DT2 UDP, it will be ignored.
DHCP Option 042 ("NTP Servers") is used to discover both NTP servers and DT2 servers. If a server is listed in option 042, it will be checked for NTP first. If NTP fails, it will be checked for DT2 UDP. If it does not provide time under either of these two protocols, it will be ignored.
Clients set to match their server's time zone.
v5.x clients will only request timezone information if the server is configured to provide both recommended timings and timezone info. Clients may use either recommended times or timezone (or both or neither), but it won't ask for the server's timezone unless the server is also set to provide recommended timings. This is to cut down on the relatively-expensive timezone calculations needed by both the server and client when sharing timezones. It also reduces unnecessary network traffic.

Obtaining and Serving the time

Domain Time components, except for test programs, only use DT2, PTP, and NTP protocols for getting the time. "DT2" includes the entire DT2 family: DT2 over UDP, DT2 over TCP, and DT2 over HTTP. All versions of NTP (1-4) are supported. Only version 2 (IEEE1588-2008/2019) of PTP is supported. Domain Time II Server can become a master PTP server, but normally operates as a slave, since software-based PTP lacks the accuracy of a proper PTP appliance. Domain Time II Client can only operate as a PTP slave.
Other time protocols (TIME/ITP, Daytime, etc.) are of insufficient resolution for good timekeeping, and are therefore not used for obtaining the time on v5.x. Server continues to provide them, primarily to service legacy devices.
HTTP proxy servers are no longer supported for getting the time via Domain Time over HTTP. You must have a direct connection in order to use this protocol. You may specify a non-standard port number by appending a colon and port to the server's name (e.g. timeserver.mynet.com:91). You may also specify the port in the port number field when editing a time source.
You are no longer limited to four time sources and you may make multiple requests (samples) of each time source, with a configurable delay between samples.
Time sample analysis is much more sophisticated than in version v4.x. Sample averaging and analysis is automatic based on how many servers (and how many samples per server) you select. Averaging is enabled by default, but you may turn it off. You may have multiple samples per server with or without using averaging (the multiple samples will go through the same statistical analysis as if they were individual samples from multiple servers).
Symmetric Key Authentication
Version v5.x supports symmetric authentication (MD5 hash of shared secrets). This type of authentication works between Domain Time v5.x servers and clients, or between Domain Time and any properly-configured NTP v3.x or higher daemon (such as ntpd or xntp on UNIX/Linux machines, hardware GPS clocks, etc.).
Domain Time server supports serving time with symmetric authentication for client-server requests on NTP, DT2-UDP, DT2-TCP, and DT2-HTTP. Domain Time server also supports broadcasting (both NTP and DT2-UDP) with a shared key and MD5 hash. Clients configured with the same key validate the sending server by comparing the computed hash.
Slaves automatically replicate shared secrets from their Master. Masters, Independent Servers and Clients must be provided with a shared secrets list, either by manually entering them into the Control Panel applet, by being upgraded, importing a Domain Time v5.x configuration .reg file, or importing/exporting a standard ntp.keys file. Clients running on domain member machines may also receive their shared secrets from a Windows Group policy.

Interaction with Windows Time (W32Time)

Windows Time clients using NT5DS mode (the default) search the Active Directory hierarchy to find a server. They send a request for the time using their machine RID as the authentication key, and expect the returned timestamp to be authenticated by the server. Only a DC in the client machine's domain can provide this type of authentication.

Domain Time v4.x Servers provided for Windows Time clients by setting the W32Time service's client portion to "NoSync" mode and allowing the W32Time service's server portion to serve NTP directly. Although the quality of the timestamps provided by W32Time is significantly degraded, this approach allowed the DC running Domain Time to continue serving Windows Time clients. This workaround is no longer necessary.

Domain Time v5.x provides integrated Windows authentication natively for both NTP and DT2 protocols. This means that W32Time clients in NT5DS-mode can get their time directly from any Domain Time II Server running on a DC, exactly as if getting the time from the Windows Time Service on that DC.

Additionally, Domain Time v5.x clients can use the same Windows authentication model to obtain NTP time from DCs running either the Windows Time service or Domain Time.

Windows authentication only works on domain member machines. The machine on which the client is running must be joined to the domain (or the forest) from which it gets the time. Windows authentication is automatic; no configuration is necessary. NOTE: While the domain member getting the time may be any kind of machine, the domain member providing the time must be a DC. Only a DC can validate the request. Other servers will not know the shared secrets.

W32Time in NT5DS-mode has distinct disadvantages:

The W32Time NTP Server is inaccurate, so even if the DC's clock itself is well-synchronized, the time being served may not be.
Other ntp clients (such as ntpd or xntp) cannot synchronize with it.

Domain Time's NTP Server has none of these disadvantages. It can provide standard NTP (with or without NTP auth) at the same time it provides NT5DS-mode timestamps, and all at extreme accuracy.

It is therefore highly recommended you install Domain Time II v5.x Server on all DCs. You can install Domain Time v5.x Clients on a DC, but you will then need to enable W32Time in "NoSync" mode to provide NT5DS-mode.

Recommended settings:

For v5.x Server on a DC:

Verify that the "NTP Server Enabled" checkbox is checked on the Domain Time II Server "Serve the Time" property page AND
the "Windows Time mode" dropdown on the "Advanced" property page is set to "Disabled"

For v5.x Client on a DC:

The "Windows Time mode" dropdown on the "Advanced" property page should be set to "NoSync"

Reliable Time Provider
DcDiag and other tools sometimes expect the Windows Time service to be running, even if it's not actually doing anything. This error may be safely ignored as long as your DC is advertising as a time source. You can check your domain using our supplied tool ntpcheck.exe. Use ntpcheck -ad to check the domain for all types of advertised time sources, and then test each source.
Starting with v5.x, Domain Time Server, when installed on a DC, sets the system flags to indicate the machine is serving time and is a reliable time source. The DsGetDcName() function will report Domain Time Server v5.x machines on DCs as both time servers and reliable time sources. Domain Time Server on a non-DC will not change the existing system flags.
You may override this behavior by editing the registry. In HKEY_LOCAL_MACHINE\Software\Greyware\Domain Time Server\Parameters, edit (or create) a REG_SZ (string) value called "Set Reliable Time Provider" and set its value to either "True" or "False" (the English words, without the quotation marks). If this value is present and set to True, Domain Time Server will set the two flags even if it is not running on a DC. This configuration has no meaning for Active Directory, since only DCs are examined for the flags. Other tools, however, may benefit from knowing that a reliable time source is present. If this value is present and set to False, then Domain Time Server will not change the flags.
Cluster Service
The Windows Cluster has a default startup dependency on W32Time. It does not require the time service for any other purpose. Thus, the simple recommendation for installing Domain Time on clusters is to set W32Time to NoSync mode, which allows the service to be running to satisfy the startup dependency, but allows Domain Time to set the clock.
However, you may replace the cluster's startup dependency if you want. After installing Domain Time Client or Server, you can edit the "DependOnService" value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\clussvc key to replace "W32Time" with "Domain Time Client" (or "Domain Time Server"). The cluster service will then wait until Domain Time has started before starting. You can then set the "Windows Time" setting on the Domain Time applet to Disabled.

Network considerations

Domain Time now uses both TCP and UDP port 9909 (DT2) for basic operations. Firewalls will need to pass both types of DT2 traffic, even if NTP (port 123 UDP) is actually being used to synchronize the time.
Version v5.x can use either IPv4 or IPv6 (or both) for obtaining and serving the time. IPv6 requires operating system support, which is present by default in Vista or above, but must be specifically installed/enabled on XP. Domain Time will function in IPv4-only mode if IPv6 is not present. If both are present, you may choose which to use, or let the system figure it out (see the Network property page on the Server or Client Control Panel applet).
Version v5.x does not use the MS Networking "browse list" for primary machine discovery. Functions that formerly only used the browse list now use various methods of automatic discovery and configuration, including broadcast, multicast, and Active Directory enumeration via LDAP. The Browse list remains available as an additional secondary discovery method on some components
Broadcasts and Multicasts
Previous versions of Domain Time depended on directed broadcasts to discover or signal machines on remote subnets. Multicasting is now preferred for signals that are sent to other subnets. Broadcasts are still used on the local subnet, primarily for automatic client/server discovery or signaling of advisories and cascades (see below). Some Domain Time components (such as Monitor and Audit Server) may still allow directed broadcasts for backwards-compatibility, but this is discouraged.
The "Broadcasts and Multicasts" property page on the Server or Client Control Panel applet shows the addresses and hop-count/TTL used for broadcasts and multicasts. These values pertain to the following functions:
- Server uses them to send cascades and advisories
- Server uses them as the listen addresses for IPv4 and IPv6 multicast requests
- Server uses them to send broadcast/multicast time (DT2 heartbeats and NTP time)
- Tools that don't have their own settings (for example, dtcheck.exe) use them for discovery and testing. Clients use them to discover DT2 and NTP sources Clients use them as the listen addresses for IPv4 and IPv6 multicast requests
  If you are trying to control overall broadcasting and multicasting, it is better to enable or disable the particular functions that use the addresses (such as on the Serve the Time property page) rather than disabling them on the Broadcasts and Multicasts page. Enabling or disabling on the Broadcasts and Multicasts page can have unintended consequences -- you may be trying to keep clients from sending multicasts for discovery, but end up preventing servers from communicating with their peers.
Note: NTP time broadcasts/multicasts
In order for Domain Time to send or receive NTP time broadcasts or multicasts, the Domain Time service must control the NTP port (123 UDP). If running Domain Time II Server, the Windows Time service must be disabled (this is the recommended configuration anyway). If running Client, the W32Time service must either be disabled (preferred) or set to NoSync mode.
Cascades and Advisories
Cascade signals are use to keep the hierarchy in sync when a server sets its clock. v5.x cascade 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. 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 cascades to cross routers, you must use IPv4 or IPv6 multicast instead.

Clock Control

However, in order to provide for tuning to achieve maximum accuracy (and to deal with the occasional poor-performing clock), v5.x exposes or adds a large number of advanced clock control options. See the online documentation for details.

Leap Seconds
The Windows family of operating systems does not support leap seconds natively. Leap seconds are simply unexpected one-second corrections as far as the operating system is concerned.
Version 4.x of Domain Time applied leap seconds at the first timecheck following the leap, discovering its time was off by one second, and performing a correction. Version 5.x applies leap seconds at 23:59:59 UTC on the last day of the month in which the leap is scheduled. You may disable the new behavior by unchecking the "Enable advance scheduling of leap second corrections" checkbox on the Advanced tab of the Control Panel applet, but we recommend you leave it enabled, since the leap second specification requires that all clocks everywhere in the world should change at exactly the same time (UTC), regardless of time zone or physical location.
Domain Time acquires pending leap second information from NTP, PTP, or other GPS-derived time sources. Once leap second information is acquired, Domain Time Server will advertise the leap second when it serves NTP, PTP, or any of the DT2 protocols. In order for Domain Time to acquire, schedule, and advertise a leap second, all of its queried sources must agree that a leap is pending. 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. GPS-derived time sources acquire knowledge of a pending leap second from satellites well in advance of the event, but each manufacturer is free to decide how long in advance to pass this information to their clients. Most start advertising a pending leap second between 1 and 24 hours prior to the event, although some will advertise it days early, and some (broken) servers will continue to advertise it for some time after the event has occurred. Since leap seconds are to be applied at 23:59:59 UTC on the last day of the month, it doesn't matter if the event is advertised early. However, Domain Time has protection built in to prevent another leap second being scheduled for the following month if a broken source continues to advertise after the event.
Pending leap information is queried with each timecheck, 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. Domain Time also acquires and remembers the current TAI-UTC offset (only available from PTP sources), and this information (if ever acquired) is automatically updated after the application of a leap second.
Clock Corrections vs. Alignments
Domain Time can correct the clock either by "stepping" (immediately changing the time) or "slewing" (changing the time slowly). Stepping and slewing only operate on variances of 1 millisecond or more.
Variances of less than 1 millisecond are "aligned," which is a process very similar to slewing. Aligning involves temporarily speeding up or slowing down the computer to make it match the time source more closely. Sub-millisecond alignments are NOT considered corrections, and will not show as corrections in Audit Server, Domain Time statistics, or the drift graph. Variances of less than 1 millisecond will be reported as zero milliseconds, except in the log file.
If your machine is stepped, the log file will say "Local clock stepped" (followed by details on which direction, by how much, and the protocol used to obtain the time.
If your machine is slewed, the log file will say "Local clock slewed" (followed by the same details as for stepping).
If your machine is aligned, the log file will say "Local clock aligned" (followed by the same details as for stepping or slewing).
Alignments happen automatically as long as slewing is enabled. The only important thing to remember about alignments is that they are not reported as clock corrections.
Never Step
By default, Domain Time will step corrections too large to slew (or if slewing in that direction is disabled), and will also step the very first correction after rebooting. In v4.x, you could change this behavior by enabling the "Never Step Clock" option. In v4.x, "Never Step" really meant "Do not step except on first boot or when triggered by an administrator," which was a bit confusing.
In v5.x, if Never Step Clock is enabled, Domain Time really will never step the clock. The slew limits and direction permissions are not overridden by triggers, the Control Panel applet, or reboot detection. As a result, if you have Never Step Clock enabled, you will probably have to set the clock manually after every boot to get the time within range to begin slewing.
To provide greater control of the stepping process, v5.x introduces the "Allow Stepping" setting. Allow Stepping is a bitmask of reasons to allow stepping. If your v4.x machine had Never Step specified in the registry, the value will be translated to an Allow Stepping value of zero when upgrading to v5.x. In all cases, stepping will only be applied if slewing is disabled or cannot correct the variance.

Wait for first synch

NOTE: Setting your service to have a dependency on Domain Time is not sufficient, because this will only make your service wait until Domain Time is running. Service startup dependencies don't have any way to check to see if Domain Time has finished synchronizing the clock after starting.

v5.x Servers and Clients export a Win32 named event your processes can monitor to determine when the clock is synchronized. If the event is unsignalled, Doman Time could not synchronize the clock (or has not synchronized it yet). If the event is signalled, Domain Time has successfully synchronized the clock at least once since the service started.

To monitor this event in your own application or service, use the Win32 API OpenEvent to obtain a handle to "Global\domtime-sync-status-synchronized" (case-sensitive), and then use any of the Win32 wait functions. For example,


     DWORD WaitForSync()
     {
      HANDLE hHandle = OpenEvent(STANDARD_RIGHTS_READ | SYNCHRONIZE,
                  FALSE,
                  "Global\\domtime-sync-status-synchronized");

      if (hHandle == NULL) return GetLastError();
      WaitForSingleObject(hHandle,INFINITE);
      CloseHandle(hHandle);
      return NO_ERROR;
     }

The code snippet above tries to open the named event. If unsuccessful, it will return the error code. Otherwise, it will wait for the event to become signalled. If the event is already signalled, the wait will complete immediately. As soon as the event becomes signalled, the snippet closes the handle and returns NO_ERROR to let you know that Domain Time has successfully synchronized the clock.

In your own code, you probably want to include more error checking, and allow for a timeout in case Domain Time isn't running or never manages to synchronize the clock.

Other Items

New command-line option on DTServer and DTClient
v5.x adds a command-line option "-reset" or "-re". This option is useful only when combined with the upgrade option "-upgrade" or "-u" -- if specified, the upgrade will read the initialization .reg file as with a fresh install (i.e., overwriting any existing values). If not specified, upgrade will leave any existing values intact, other than necessary housekeeping to convert values to the current version's format.
Service Status Monitor protocol
Version v4.x supported the service status monitor, but it was an undocumented feature used by only a few OEM customers. Version v5.x supports the same protocol unchanged, but exposes it on the Control Panel applet for easier configuration.
The service status monitor is a simple TCP/IP listener to which your own programs can connect to check the status of the Domain Time service. By default, it supports both UDP and TCP on port 9911.
For UDP, use sendto to send an empty (zero length) packet to the target port and then use recvfrom to get the reply. For TCP, use connect and then recv (you do not need to send any data). The service status monitor will reply to either connection with a single text line (CRLF terminated) indicating the status and version.
Audit Server autodiscovery of Linux domtimed clients
Older Linux clients do not send their serial number with a time request, so Domain Time Server does not record them when they get time, and Audit Server does not know of them by examining the ephemera data. Upgrade to the newest Linux client if you need Audit Server to discover your Linux machines automatically.
DTRCPL (DT Remote CPL program)
The x64 version will run only on x64 systems, and can control either x64 or x86 remote systems. The x86 version will run only on x86 systems, but can control either x64 or x86 remote systems. If the architectures of the local system and the remote system match (both x86 or both x64), then DTRCPL will try to load the CPL installed in the remote system32 folder (in case it happens to be an older or newer version of the CPL). If the architectures do not match, or if the CPL was not found on the remote system, DTRCPL will look in the local system32 folder and the Manager folder (if Manager is installed) to find the appropriate CPL.
DTSLEW
This program may produce less precise results on Vista/2008/Win7 than it does on NT4/XP/2003 or newer operating systems. If the imprecision shows, it is only with very small corrections (milliseconds or seconds) over large periods of time (minutes or hours). This is a known limitation arising from Microsoft's virtualization of the timing scheme on those operating systems.

Domain Time II Manager

During remote installation, or during Reset Configuration of a software component from Manager, the contents of the .reg file will be added to the target machine's registry, overwriting any matching values already present. Values present in the registry but absent from the reg file will not be deleted (unless the reg file contains delete instructions for values or keys).

Manager's Reset Configuration procedure doesn't touch the dtserver.reg or dtclient.reg installation defaults files on the target machine; it creates a dtupdate.reg file instead, which the service then imports and renames.