Domain Time II
Version 5.1 |
Release Notes
-----------------------------------------------
Domain Time II Version v5.x Administrator Notes
-----------------------------------------------
5.1 RELEASE
If you have been using beta or Release Candidate versions of the software,
you must upgrade to the 5.1 release. You do not need to remove/reinstall.
All settings will be preserved. Some 5.x functions in the release code will
not interoperate properly with earlier versions. You should not mix and
match pre-release software with the release code.
-----------------------------------------------
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.
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:
(a) use its own clock (not recommended unless you have a third-party
hardware device of some kind maintaining the clock)
(b) use a list of time sources
(c) 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 and NTP
protocols for getting the time. "DT2" includes the entire DT2 family:
DT2 over UDP, DT2 over TCP, and DT2 over HTTP.
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 are no longer limited to four time sources and you may make
multiple requests (samples) of each time source.
* 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 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:
(a) The W32Time NTP Server is inaccurate, so even if the DC's clock
itself is well-synchronized, the time being served may not be.
(b) Other ntp clients (such as 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:
(a) Verify that the "NTP Server Enabled" checkbox is checked on
the Domain Time II Server "Serve the Time" property page AND
(b) the "Windows Time mode" dropdown on the "Advanced" property
page is set to "Disabled"
For v5.x Client on a DC:
(a) 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.
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.
** 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
Domain Time v5.x includes significant improvements and optimization
of all timekeeping functions to maximize the accuracy and precision
of clock synchronization and timestamps. The default timing settings
are usually sufficient to obtain superior synchronization on most
systems.
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. Version 5.x applies them at 23:59:59 on the last
day of the month in which the leap occurs. You may disable the new
behavior by setting "Leap Seconds Enabled" to False in the parameters
key for the Domain Time service. The new behavior is enabled by default.
Domain Time acquires pending leap second information only from NTP
time sources. All queried NTP 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.
* 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
Some third-party time-sensitive applications or services are set to
auto-start when the machine boots, but may need to have the clock
synchronized before providing services. Recall that the CMOS clock chip
may be wildly inaccurate, and therefore the first synchronization after
boot is normally treated specially, allowing jumps in time either backward
or forward.
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. 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 newer operating systems.
--MANAGER
When performing a remote upgrade of a software component using Manager,
the selected template .reg file's contents do not replace the existing
registry contents on the target machine. Only settings present in the
.reg file that do not exist in the registry will be added. Existing
registry values will be unchanged.
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.
 Proceed to the Planning page
 Back to the System Requirements page
|
|
