The time service has not been able to synchronize the system time for 49152 seconds because none of the time providers has been able to provide a usable time stamp. The system clock is unsynchronized.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Windows Time Service cannot synchronize with its time source.
When a computer cannot synchronize with its source for a period of time, it will not provide the time to requesting clients. The local
computer time cannot be updated until successful communication with the time
Usually, this message does not indicate an immediate problem. However, it represents a condition that can cause problems if it continues for an extended period of time.
If the W32Time 36 message appears on a domain controller, verify that the computer can successfully communicate with other domain controllers in the domain. While a domain controller is in this condition, it will not provide the time to requesting clients. If the condition persists, it might result in problems downstream from the domain controller.
The W32Time 36 message is expected on domain controllers that are also PDC emulators for the forest root domain. The PDC emulator in the forest root domain is the root server in the time synchronization hierarchy
and, by default, does not have a time source configured. The PDC emulator will continue to provide the time to clients despite its unsynchronized state. It is recommended that the PDC be configured with a reliable and
secure time source, which normally prevents this condition.
If the W32Time 36 message appears on a computer that is not a domain controller, such as a home computer, business workstation, or member server, no user action is required. By default, these systems do not provide the time to requesting clients and should be the only computers affected by
this event. After connectivity or communication with the time source is
restored, the computer will resume synchronizing with its source.
Windows includes W32Time, the Time Service tool that is required by the Kerberos authentication protocol. The purpose of the Windows Time service is to make sure that all computers that are running Microsoft Windows 2000 or later versions in an organization use a common time.
To guarantee appropriate common time usage, the Windows Time service uses a hierarchical relationship that controls authority, and the Windows Time service does not permit loops. By default, Windows-based computers use the following hierarchy:
â€¢ All client desktop computers nominate the authenticating domain controller as their in-bound time partner.
â€¢ All member servers follow the same process that client desktop computers follow.
â€¢ All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner.
â€¢ All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner.
In this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization. We highly recommend that you configure the authoritative time server to gather the time from a hardware source. When you configure the authoritative time server to sync with an Internet time source, there is no authentication. We also recommend that you reduce your time correction settings for your servers and stand-alone clients. These recommendations provide more accuracy and security to your domain.
"W32Time. Event ID 36. The time service has not been able to synchronize the system time for 49152 seconds because none of the time providers has been able to provide a usable time stamp. The system clock is unsynchronized."
When a user sees this Event ID 36 being thrown, even though the computer is synchronizing regularly and/or manually, it is being caused by a specific application (in my case it was Mozilla Sunbird) calling w32Time directly to try to effect a resynchronization. If that specific synchronization fails, then this error message is thrown. The error message is not truly descriptive or accurate regarding what has actually occurred. The number 49152 quoted is simply an artifact, being derived directly from a calculation based on the value of MaxPollInterval, and the number actually has no bearing on the true amount of time that has expired unsynchronized.
An error message more along the lines of "W32Time was unable to perform the synchronization requested by an application," without mention of any "elapsed time unsynchronized," would be more precise and useful. It appears that the coder simply didn't bother to develop the better error message, instead re-purposing the error message already available. Or perhaps the error is just dropping out of the bottom of the error subroutine, defaulting to this message.
The above-referenced calculation is 2 raised to the MaxPollInterval power x 1.5. The default MaxPollInterval value is 15. 2 to the 15th power = 32,768. 32,768 seconds x 1.5 = 49,152 seconds. Thus the intent is that W32Time should wait no longer than 32,768 seconds to attempt a synchronization. And that 49,152 should be the point at which W32Time throws an Event ID 36 error to the inform the user if no successful synchronization occurs by that time.
However most users do not see Event ID 36 throw in every-day/default usage because MinPollInterval and MaxPollInterval value are being superseded by the value of SpecialPollInterval. Such is the case when the entries for the time servers to be polled (listed in the NtpServer key) are appended with ",0x1". And, indeed, "time.windows.com, 0x1" is, historically, the default entry. (And typical instructions regarding how to adjust the list of time servers include the appending of ", 0x1".) The default entry for SpecialPollInterval is 604,800 (seconds, or exactly 7 days). So, in every-day/default usage, Event ID 36 will not throw unless 10.5 days has passed without a successful synchronization. (If the NtpServer key entries are not appended, then the MinPollInterval and MaxAPollInterval are indeed in force.)
If the computer is not connected to the Internet (ie, not connected to a domain), then the polling interval does not increment at all, as the scenario is such that it is not possible for the computer to synchronize at all.
Again, if a user sees this EventID 36 W32Time error message -- and the computer hasn't actually expired its allotted time limit before the error message ought normally occur, and/or it is known that the computer is regularly and/or manually synching correctly -- then the cause is an application calling W32Time to synchronize and then that specific synchronization failed. So W32Time throws its/this standard "couldn't synch" error message, where the message isn't truly informing what occurred and the number it contains is not accurate.
MaxPollInterval is found at HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\
MinPollInterval is found at HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\
SpecialPollInterval is found at HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
NtpServer is found at HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters