Documentation\Technical\Network\Co-existing with Windows Time - (older versions)
The information on this page only applies to Domain Time II Versions 3.2 or earlier running on Windows 2000 or earlier
For information that applies to current versions of Windows and Domain Time II, see the Co-Existing with the Windows Time Service page.
Enabling both Domain Time II and W32Time (in sync mode) simultaneously can result in unpredictable behavior. To avoid this,
Domain Time II (as of Version 2.5) disables the W32Time service on all Client installations. During Server installation, it sets it to NoSync mode.
The W32Time service may be started without conflict when the synchronization functions of W32Time are disabled. This allows
applications which require the presence of the W32Time service (such as Cluster Server) to start, but the actual time
synchronization functions are handled by Domain Time II. Generally, however, the Windows Time service can be disabled
completely when Domain Time is running unless the machine is running Cluster Service or is a Windows 2000/2003 Domain Controller.
Important Note:If both the Domain Time and Windows Time services are running simultaneously, the NET TIME /setsntp command must not
be used on that machine, since this changes Windows Time back to NTP sync mode. See KB2001.002
for more information. Domain Time II Server can be set to force the W32Time State to avoid this issue. See the
Advanced tab of Domain Time II Server for more info.
On Windows 2000 Domain Controllers (DCs), if the W32Time service is running, it will try to be an NTP server and you cannot control
this behavior. If you leave the W32Time service running, you must disable Domain Time's NTP server, since only one process may
listen on the NTP port at a time. See KB2002.101 for more information. You may continue using
Domain Time Server to provide all other protocols, statistics, and control functions, but any request directed at that machine
specifically for NTP will be served by W32Time instead of Domain Time, even if Domain Time is managing the machine's clock.
The necessary registry modifications for co-existence with W32Time are handled automatically by Domain Time version
2.5 and above. The W32Time service is left running for compatibility reasons, but will no longer set the clock. When
Domain Time is removed, the W32Time server is reconfigured with its former settings.
For versions prior to 2.5
If you are running a version of Domain Time prior to 2.5, you will need to manually make a
change in the Registry to disable the W32Time synchronization function before you can safely run W32Time simultaneously:
Modifying Registry entries requires basic familiarity with the Windows Registry and its operations.
Incorrect changes to the Registry can result in unpredictable, perhaps non-repairable, damage, up to and including
a non-bootable system! Have a qualified technician make the changes for you if you are not comfortable with the
process. We cannot be responsible for registry problems.
The W32Time settings are located in:
Disabling W32Time synchronization requires the “type” value be changed from Nt5DS to NoSync.
Default W32Time Registry setting
W32Time Registry setting after modification
Once you've made the registry change, the W32Time service can be started alongside Domain Time II.
Remember to make the necessary changes in the service startup options to run both time services automatically, if desired.
Other Options For Running Both Domain Time II and W32Time Simultaneously (not recommended)
You may configure systems to allow the Windows Time Service to sync all Win2k machines while Domain Time II syncs all other machines.
Note, however, that using this configuration causes you to lose some or all of the most useful benefits of Domain Time,
such as master/slave relationships, cascading time synchronization, and management features on any machines
using Windows Time.
Domain Time and Windows Time masters on separate machines
Using Domain Time II as the network time source
Domain Time II Server should be installed as an Independent Server on at least one NT machine. This machine
is configured to get its time from a trusted external time source. Configure the Win2k FSMO/PDC to
get its time via NTP from the Domain Time Server.
This is usually a better option than having Domain Time get its time from Windows Time (both options below), since Domain Time
is more robust and stays synchronized more closely to the time source than does Windows Time. In either case,
Domain Time II clients that sync to the Domain Time II Independent Server will be significantly better synchronized
than the Win2k machines synchronized by Windows Time.
Domain Time and Windows Time masters on separate machines Using Windows Time as the network time source
If you must have a Windows Time machine as the source, configure the FSMO PDC to get its time from a time source.
Install Domain Time Server on at least one NT machine, configured as an Independent Time Server that gets its
time via NTP or LANManager (not recommended) from the FSMO PDC. Although Domain Time will keep its own clients
well-synchronized, the accuracy of the network will be determined overall by the uncertainty of the Windows Time server.
Domain Time and Windows Time masters on the same machine Using Windows Time as the network time source
If you want the FSMO/PDC to run both Domain Time and for Windows Time as the master machine, you can
re-enable the Windows Time service on the FSMO/PDC after installing Domain Time Server. Using
Domain Time's control panel applet, disable all server protocols except Domain Time II and LanMan,
uncheck the box restricting Domain Time from serving the time until its own clock is set,
and clear all server information, so Domain Time doesn't try to get its time from an external
source. Then re-enable the Windows Time service and reboot.
The FSMO/PDC will now obtain its time using the Windows Time service, and serve the time either via
Windows Time (to Win2K clients that aren't running Domain Time), or via Domain Time II (to the rest of the network).
Note that since Domain Time isn't responsible for setting the master clock, it cannot generate synchronization
notices. Your system, if configured this way, will have all the limitations of W32Time's 2-second
accuracy, and 8-16 hour latency before clients are updated.