Overview of the Microsoft Windows Time service
  Problems with Windows Time
  Problems with NET TIME
  Co-existing with the Windows Time service
  The Domain Time II Windows Time Agent

Overview of the Windows Time Service

But is it Good Enough?
According to Microsoft, Windows Time (W32Time) 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.

Microsoft's documentation (Microsoft KB 939322) states:

We do not guarantee and we do not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs. The W32Time service is primarily designed to do the following:

Make the Kerberos version 5 authentication protocol work.

Provide loose sync time for client computers.

.The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. Such tolerances are outside the design specification of the W32Time service.

See also this The Windows Time Service whitepaper, which states:

"W32Time meets the requirements specified by the Kerberos authentication protocol to provide clock values that are 'loosely synchronized' across a network. This service is not designed for use by applications that require greater precision."

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 was introduced to address these shortcomings and provide 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. Read more.

Problems with Windows Time

Click Here to see test results on how W32Time actually performs

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. Mixed enviroments with older Windows systems have additional challenges, since they cannot use the Windows Time service (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:

Windows Time	Domain Time II
No way to know if it's really working, or when it breaks
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, 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. Domain Time II Windows Time Agent, (new with version 4.1) 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.
Users can change their own time
Windows Time does not restrict manual date and time changes. 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 prevents users from changing the time. In addition, only administrators can change the time service 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 limited 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
Windows Time only attempts 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. 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
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, 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. 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 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.	Domain Time Server always serves NTP time with the same superb 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 mislead 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 the LAN Manager protocol (the same as NET TIME) 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.
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 Full Clients in automatic mode can always discover a server, regardless of what time protocol is selected. The other Domain Time automatic-discovery clients always use the highest-resolution Domain Time II protocol. Clients can also use DHCP to auto-discover a specified time server.
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 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 directly supports Win95/Win98/WinME and later regardless of the OS of the master domain. Clients are available for other versions as well.

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

• 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-class 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 fails.

  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 wrong.

• 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.