System time changes automatically in Windows Server 2008 R2

What's wrong with the Windows Time Service?

In contrast, Domain Time II achieves sub-millisecond provable accuracy, and, when using IEEE 1588-2008/2019 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.

See the 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. Read more.

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:

Windows Time	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.

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

Why does the time on my server keep changing?

When I restart my computer time changes?

How does domain controller sync time?

What is the Windows Time Server?