|What's wrong with the Windows Time Service?
Windows networks using Active Directory require that the machine clocks within
a domain be roughly synchronized in order for machines to log in to the domain using Kerberos authentication.
For this reason, versions of Windows (as of Windows 2000) have a basic built-in time synchronization service called the Windows Time Service.
The best you can hope for is 1 millisecond, using
Windows 10 and Windows Server 2016 in a tightly controlled environment. Microsoft's documentation details the requirements for
1-second, 50-ms, and 1-ms accuracies. Older operating systems struggle to stay within a handful of seconds.
In contrast, Domain Time II achieves sub-millisecond provable accuracy, and, when using
IEEE 1588-2008 Precision Time Protocol (PTP), can achieve low double-digit microsecond accuracy.
"Windows Server 2012 R2 and earlier versions of Windows cannot guarantee highly accurate
time because the W32Time service was not a full-featured NTP solution."
—Support boundary to configure
the Windows Time service for high accuracy environments,
Microsoft Corporation KB 939322
But is it Good Enough?
According to Microsoft, Windows Time (W32Time) prior to Windows Server 2016 was never intended to be a time solution
good enough for applications to depend upon. It is usually "good enough" (but not always,
see below) to allow Kerberos authentication to function on most Active Directory networks,
but it does not attempt to address any needs beyond that basic requirement.
Windows Time Service Technical Reference, which states:
"The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs and is not supported by Microsoft as such."
Since most organizations do indeed have applications (such as accounting, transaction systems, SQL, email servers, security logging, firewalls, etc.)
that depend upon their systems always having the correct date and time, the Windows Time service is just not sufficient for
a large percentage of real-world enterprise use. Unfortunately, many firms do not discover this until they have deployed
Active Directory and start to discover issues related to the inherent inaccuracy of the Windows Time Service.
Domain Time II addresses these shortcomings and provides many critical functions and features that
Microsoft's products do not even attempt to deliver. Domain Time II is much more robust and easier to manage
than the Windows Time Service, and it even has special features to co-exist with Windows Time harmoniously for
maximum compatibility and performance.
Problems with Windows Time
The Windows Time (W32Time) service can be difficult to configure and monitor, time-intensive to
administer, and has significant limitations in functionality. Windows Time is (usually) accurate
enough to keep Kerberos working, but is often insufficient for any other synchronization purpose.
Windows Server 2016 introduces many improvements, but still relies on command-line programs and
Event Viewer logs or performance monitoring to determine how well it is working on each machine.
Mixed enviroments with older Windows systems have additional challenges, since they cannot
use the Windows Time service at all (see below). In addition, even when the Windows Time service is available,
the functionality varies among different versions of the operating system (and even from service
pack to service pack), making it more difficult to administer consistently.
This table shows some of the main problems with the Windows Time service and how Domain Time II addresses them:
Domain Time II
Awkward or impossible to know if it's really working, or when it breaks
Prior to Windows Server 2016, Windows Time does not provide any information useful in determining if the time synchronization
is operating correctly. Many people simply resort to see if they can catch the clock in their
system tray change. Also, since there are no logs kept except if configured in the registry, there's no way to know if the
service was ever working in the past.
You cannot query the Windows Time service to determine when the
last time set occurred, who the inbound time partner was, or when the next time set is
scheduled (although some of this information is available from the command-line
on each machine using the w32tm program). You cannot determine the
amount of adjustment applied, or the variance among machines.
Domain Time II provides many methods of feedback on time system health, including visual sync indicators,
network-wide monitoring with out-of-sync alarms, emailed variance reports, central time auditing, historical clock
performance charts, full logging of all time sync activity, a complete suite of diagnostic tools, and more.
By default, admin users can change their own time
Windows Time does not restrict manual date and time changes for administrators. Policy settings may allow ordinary users
to change the date or time, too. This presents obvious security and audit problems,
since date and time stamps in all programs can be doctored.
Domain Time II Clients and Servers have a built-in Clock Change Monitor that catches users who change the time and
set it right back. This information is logged locally, and may be set to forward to syslog or Domain Time II
Audit Server for instant detection. In addition, only administrators can change Domain Time II's settings.
Limited protection against problematic clock corrections and reverses
Many applications depend on the system time progressing steadily forward in order to operate
correctly. If the time on the system changes significantly (or, in the worst case, moves
backwards), the results can be disastrous.
Although the Windows Time Service does have
clock slewing capabilities to prevent large clock jumps when a correction is received, the
inherent inaccuracy and irregular nature of the time distribution on a Windows Time network
can result in the time service continually adjusting the clock. Some customers have even
reported that time on their Windows Time boxes has moved backwards under certain circumstances.
The clock on Domain Time II Clients and Servers never moves backwards (unless you specifically allow it).
The clock slewing rates are completely configurable. The services contain built-in protection against
wild time changes, and can automtically identify and prevent rogue time servers from being used.
Two-second accuracy target, with large clock drifts
Prior to Windows Server 2016, Windows Time only attempted to keep the time on each machine synchronized within two seconds of
its source. The two-second target is not configurable. In practice, the actual time can and does drift dramatically
outside the target range and can stay that way for many hours. Even using Server 2016, special care and configuration
are required to achieve better accuracy.
This means that, at any given time, a pure-mode Active Directory domain with each
machine running Windows Time could have a system-wide variance
of two to four seconds, but still be considered synchronized! In practice, with
eight to sixteen hours between checks, the domain will probably have a variance
in excess of several minutes.
Domain Time has unmatched accuracy capabilities, allowing you to keep your clocks consistently synchronized
to nearly the limits of the operating system. Worst-case drift can be measured in milliseconds instead of seconds or minutes.
Time corrections may take up to 16 hours to propagate to the domain
Prior to Windows Server 2016, no attempt is made to cascade time changes throughout the domain. If the time
is corrected on the PDC, each DC will discover the change up to eight hours later.
Member servers and workstations follow their own schedule when checking with their
designated DC, so the aggregate lapse between when the time changes on the PDC
and when the new time is recognized at a workstation averages eight hours, and
can be as large as 16 hours.
By default, Domain Time II uses an ingenious low-overhead cascading trigger system to ensure that when
corrected time is received by the Master time server, the correct time is propagated
throughout the entire network in seconds.
You can use our FREE
LMCheck utility to find out how synchronized your domain currently is.
No way to trigger a domain-wide sync (or even an immediate local one)
Even if you know the time is wrong and you've fixed it, you cannot trigger a sync of the entire domain, much
less the whole forest. The only way to trigger a sync for a specific machine is to use the w32tm command-line
utility or manually stop and restart the Windows Time service on every machine in your network!
The sync may or may not happen immediately.
To know whether or not it worked, you must watch the clock display and see if it changes or
examine the event log for errors.
Domain Time offers you multiple ways to trigger an immediate time sync both locally and domain-wide (or forest-wide). You
can trigger a sync from Servers and Clients, from Domain Time II Manager, from Domain Time II Audit Server,
or from the command-line using various tools. You can even schedule a time sync at a specific time of day using
Audit Server or by scheduling a job with Scheduled Tasks or any third-party scheduler.
No default time source
The PDC can obtain its time via NTP/SNTP (RFC 1769) from a trusted source,
such as the US Naval Observatory or a local appliance. But by default, it doesn't use a trusted source
at all; it just assumes its own time is correct. You can set the source by using
the NET TIME /SNTP:source command or the W32tm tool in a command window on the PDC -- if you remember.
By default, Domain Time refuses to serve time until it's own clock has been set successfully from a designated trusted time source, avoiding the problem of serving incorrect time inadvertantly.
No propagation of PDC time server settings to other DCs
The time source information is not propagated from the PDC to other Domain
Controllers. If a DC is promoted to PDC, it will continue using whatever
NTP time source was previously set (by default, nothing). An administrator
must manually reconfigure the time source settings before the network
again synchronizes with an external time source.
Domain Time uses a Master/Slave heirarchy, where the PDC (Master) continuously propagates its configuration settings to DCs (Slaves). If a DC is promoted to PDC, it automatically assumes
the Master role, using the same time sources and timing settings. There is no interruption in time sync, and no manual reconfiguration is necessary.
Limited-accuracy SNTP time server
By changing a registry setting, you can set Windows Time to function as an SNTP time source
for interoperation with other programs. However, the time served is only correct to
the level of accuracy of that machine's time service, which as mentioned above is targeted at two seconds, but often fails
to achieve this. Windows Server 2016 provides a full-featured NTP implementation.
Domain Time Server always serves NTP time with the same superb sub-millisecond accuracy it uses to obtain and keep the local time accurate.
NTP server advertises the incorrect NTP Stratum Level during startup
During an extended period immediately after startup, the Windows Time service advertises itself as a Stratum level 0 time server, even if its time is incorrect.
Stratum level 0 is the level reserved for atomic clocks that act as the ultimate network time sources. Clients that determine the likely reliability of a time souce based
on its stratum level can be misled by this advertisement.
Domain Time Server always serves NTP time at the correct stratum level based upon where it obtained its time.
Default NT5DS sync mode magnifies any DC time problems
By default, NTP is only used by the PDC (if you've enabled it to use a time source). Other participating machines
use NT5DS mode, which uses NTP (on Windows 10/Server 2016), or the LAN Manager protocol (the same as NET TIME) on older
operating systems to coordinate with their inbound time partner. The
LAN Manager protocol does not account for system overhead and LAN/WAN latencies, and can therefore be even more wildly off
than the time source. Since DCs use NT5DS to communicate with the PDC as well,
significant additional amounts of time variance can be introduced between a client and the original time source.
Domain Time II Servers and Clients use advanced latency and overhead calculations to ensure that errors are not introduced
into the time by network delays or busy machines, even when that time is repeated by Slave servers. The Domain Time II protocol,
in particular, is and extremely accurate and low-overhead method of communicating time between components. Domain Time II
also supports obtaining the time by NTP or IEEE1 588-2008 Precision Time Protocol (PTP).
Auto-discovery of servers by clients doesn't work in NTP mode
To improve accuracy over NT5DS mode, you can set individual clients to use NTP mode instead, but then you lose
automatic discovery of servers. When operating in NTP mode, machines can only use the servers you specify from
the command line on each machine.
Domain Time in auto-discovery mode can always discover a server and its protocol(s), automatically using
the highest-resolution protocol. The auto-discover mechanism is fully configurable, and can use the domain
hierarchy, multicast/broadcast discovery, DHCP option settings, or the PTP best-master-clock algorithm.
No support for versions prior to Windows 2000 in the time hierarchy
Each machine, at boot time, nominates an "inbound time partner." For DCs, this
is the PDC. For member servers and workstations, this is the DC that authenticated
the machine onto the domain. This behavior is not configurable, and means that
machines that aren't part of a Windows 2000 or higher domain (all Win95/Win98 machines, NT
machines in a workgroup, and NT machines in a domain without a PDC running Active
Directory) cannot participate in domain-wide time synchronization. They must
use the NET TIME command, usually in a logon batch file.
Domain Time (using the v4.1 builds) directly supports the older Win95/Win98/WinME and NT/2000 operating systems
regardless of the OS of the master domain. Domain Time v5.x clients are not restricted to
the domain hierarchy model of time distribution. Multiple time sources can be configured (or auto-discovered),
with multiple samples from each, using sophisticated sample analysis algorithms to derive the best. If using
Precision Time Protocol (PTP), the time source topology is dynamically determined by the hardware appliance(s)
on your network.
What if I still have to use Windows Time on some machines?
Domain Time II Windows Time Agent can be used along with Domain Time or installed a stand-alone freeware utility. It provides visual feedback, server tests,
and configuration tools to ensure the Windows Time service is operating correctly. It can also be audited directly by Domain
Time II Audit Server, so that records of Windows Time activity can be kept and out-of-sync alarms can be raised -
even if Domain Time II Client or Server is not installed.
What about machines that can't run Windows Time?
Since the Windows Time (W32Time) service only works on versions of Windows starting with Windows 2000,
administrators have been forced to use a cumbersome combination of batch files and logon
scripts for WfWG and Win9x (or even NT) machines using NET TIME.
The situation for administrators with mixed NT systems is even more complicated, since NT machines require the logged-in
user have administrative rights to the local machine in order to use NET TIME. Microsoft did introduce the
TimeServ or W32Time for NT4
services for NT machines. However, both are cumbersome to configure, and not suitable for wide deployment
(Do not confuse the W32Time for NT4 with the W32Time that ships with Windows 2000. The original
W32Time for NT4 works like TimeServ. The new one introduced with Windows 2000 has additional features.)
However, there are significant drawbacks to using a pure-Microsoft solution. The
NET TIME command-line tool, required for WfWG, Win95, Win98, and ME, simply does not meet the
requirements for a reliable modern time solution.
Problems with NET TIME
NET TIME is a foreground command-line task that must be manually run (or scheduled) in order to set the time.
In most cases, it requires that each workstation have a batch file or use a login script of some sort to get
the time. This means that the time only gets synchronized if the machine successfully logs in to the NT
domain AND the login script runs correctly. Unfortunately, these are not foregone conditions on all systems
- as you will undoubtably know if you've worked with login scripts before.
In addition, NET TIME suffers from other serious limitations:
- On Windows workstations, the logged-in user must have special rights on the local machine in order to set the time using NET TIME
This is also true of most other time products as well. The local system policies must specifically grant the named user time setting rights or the time sync will fail. Setting and maintaining these rights for Windows workstations is very time-intensive for an administrator.
- Machines without a time service that do not have a logged-in user cannot synchronize their time.
Some PC clocks (even ones right off the assembly-line) gain or lose several minutes a day. If a machine goes even a weekend without a logged-in user,
it can have significant time errors.
- NET TIME users at different locations must use different command lines.
Because NET TIME requires a fixed server name in order to use a local server other than the PDC, moving a user to a different office or even network segment can require a reconfiguration of their login or batch files to ensure they get their time from the correct server. Also, see the time zone issues above.
- NET TIME doesn't know about network delays and PC clocks.
NET TIME uses Lan Manager protocols that do not take network delays and WANs into account. A workstation synchronizing to a remote server over a slow link can be off by several minutes or more.
- NET TIME behaves differently on NT-class and Win3x/95/98 machines in how it handles time zones.
On NT-class machines, if the server that gets contacted is in a different time zone than the client, the server's time is displayed in the time zone of the client (in other words if I'm in Pacific Time on my NT machine, but I happen to authenticate with a server in the Eastern Time zone, the time on my local machine will be set to Pacific time). However, on Win 3.x,95 and 98 machines in the Pacific time zone syncing to an Eastern time zone server would have their time set to Eastern time.
If you are using the /domain option with NET TIME, any other servers running Domain Time Server can service a time request. However, if using a WAN and a local server becomes unavailable (or just slow) for some reason, machines using NET TIME can get their time changed to a different zone if a server in another time zone answers. NET TIME just doesn't know any better.
- NET TIME cannot find or use alternate servers if the specified server is unavailable.
NET TIME is a one-server product (with the exception of Domain Time servers running on DCs). If the server specified on the command-line
(i.e. in a batch file) is unavailable, the time synchronization will fail.
- NET TIME with the /domain option requires the workstation to contact the PDC.
When you run NET TIME without the /domain option, the workstation will iterate
through the list of time sources on the network, and contact the first one encountered.
By default on an NT or 2000 network, only the PDC is a time source. However, if Domain
Time Server is installed on any machine, that machine also becomes a time source. Notice
that the NET TIME client won't use the nearest time source -- it will use the first one
found in the browser list. It also will not move on to the next source if the first one
Regardless of which time source NET TIME uses, it can take an extended period of time
for the NetRemoteTOD call to fail or succeed, and NET TIME does not account for network
latencies. In addition, if the NET TIME client happens to be Win95 or Win98, and the
time source's time zone settings do not match the client's, the client's time will be
- NET TIME doesn't work well with laptops and remote offices.
The login script problems mentioned above are magnified dramatically if you're using a laptop or
workstation remotely, since the workstation may or may not actually authenticate with an NT domain
when dialing in (if you're using a PPP dial-in service, or over the Internet using a third-party
VPN, for example).
Also, a workstation with a NET TIME command scheduled to run on a schedule (such as the NT AT command)
can cause a system using Dial-Up networking to attempt to dial the remote network when it tries to run.