Windows Time service doesn’t start automatically on a workgroup computer
This article provides workarounds for an issue where the Windows Time service doesn’t automatically start in a stand-alone environment.
Original product version: В Windows 7 Service Pack 1, Windows Server 2012 R2
Original KB number: В 2385818
Symptoms
On a workgroup computer that’s running Windows 7, Windows Server 2008 R2, or a later version, the Windows Time service stops immediately after system startup. This issue occurs even after the Startup Type is changed from Manual to Automatic.
Cause
This issue occurs because the Windows Time service is configured as the Trigger-Start service, and it has been implemented as the default setting in Windows 7 and Windows Server 2008 R2.
Services and background processes have a significant effect on the performance of the system. The Trigger-Start service has been implemented in Windows 7 and Windows Service 2008 R2 to reduce the total number of auto-start services on the system. The goal is to improve the stability of the whole system, including improving performance and reducing power consumption. Under this implementation, the Service Control Manager has been enhanced to handle starting and stopping services by using specific system events.
Whether the Windows Time service starts automatically depends on one of the following conditions:
- Whether the computer is joined to an Active Directory Domain Services (AD DS) domain environment.
- Whether the computer is configured as a workgroup computer.
The Windows Time service on domain-joined computers starts when a trigger event occurs. On workgroup computers that aren’t joined to an AD DS domain:
- The startup value for the Windows Time service is Manual.
- The service status is Stopped.
You can check the Trigger-Start service settings by running the following command:
Workaround
To start the Windows Time service at system startup, use any of the following methods.
Run the sc triggerinfo w32time delete command to delete the trigger event that’s registered as the default setting and to change the Startup Type setting for the Windows Time service from Manual to Automatic:
Run the sc triggerinfo w32time start/networkon stop/networkoff command to define a trigger event that suits your environment. In this example, the command determines whether an IP address is given to a host. Then it starts or stops the service.
Change the Startup Type of the Windows Time service from Manual to Automatic (Delayed Start).
If the Startup Type of the Windows Time service is set to Automatic (Delayed Start), the Windows Time service may be started by the Time Synchronization before the Service Control Manager starts the Windows Time service task. It depends on the startup timing of the Windows operating system in question.
In this situation, the service triggers an automatic stop after the success of the Time Synchronization task. If you use Method 3, you must disable the Time Synchronization to avoid the task to start the Windows Time service task. To do so, follow these steps:
- Start the Task Scheduler.
- Under Task Scheduler Library >Microsoft >Windows >Time Synchronization, select Synchronize Time.
- Right-click, and then select Disabled on the shortcut menu.
Event 142: The time service has stopped advertising as a time source
This article provides a resolution for event 142: The time service has stopped advertising as a time source.
Original product version: В Windows Server 2012 R2
Original KB number: В 2468336
Symptoms
Microsoft-Windows-Time-Service Event 142 is logged with one of four error strings listed in the table below (less the event_ string:
Log Name: System
Source: Microsoft-Windows-Time-Service
Date:
Event ID: 142
Task Category: None
Level: Warning
Keywords:
User: LOCAL SERVICE
Computer: . .
Description:
| Error status | Error string |
|---|---|
| event_0x0038 | The time service has stopped advertising as a time source because the local machine is not an Active Directory Domain Controller. |
| event_0x0039 | The time service has stopped advertising as a time source because there are no providers running. |
| event_0x003A | The time service has stopped advertising as a time source because there are no providers running. |
| event_0x003B | The time service has stopped advertising as a good time source. |
| The local clock is not synchronized |
Cause
| Error string | Cause |
|---|---|
| The time service has stopped advertising as a time source because the local machine is not an Active Directory Domain Controller. | The local machine no longer host the DC role or there is a configuration problem with the local machine. |
| The time service has stopped advertising as a time source because there are no providers running. | The NTP client service has stopped or is non-responsive |
| The time service has stopped advertising as a time source because there are no providers running. | Time on the local computer has fallen out of sync with its peer |
| The time service has stopped advertising as a good time source. | The local DC is unable to locate a time server |
Resolution
The dominant error string logged by Microsoft-Windows-Time-Service Event 142 is the third example:
«The time service has stopped advertising as a time source because there are no providers running.»
Verify that the forest root PDC is online, healthy and that the current root domain PDC is both (1.) correctly configured to sync time with an external time source and (2.) able to reliably source time from that source.
Verify service startup values and service state: automatic + running
Verify that the DC logging the 142 event can discovery a time server using DCLocator
nltest /dsgetdc: /timeserver /force
nltest /dsgetdc: /gtimeserv /force \\workstation1 (joined to the fabrikam.com domain) to \\DC1 in the untrusted contoso.com domain fails with the following error:
Title Bar text: Remote Desktop Connection
Dialog message text: Remote Desktop cannot verify the identity of the remote computer because there is a time or date difference between your computer and the remote computer. Make sure your computer’s clock is set to the correct time, and then try the connecting again. If the problem occurs again, contact your network administrator or the owner of the remote computer
The contoso.com domain contains two virtualized DCs, \\DC1 and \\DC2 running on the same W2K8 R2 Hyper-V host. The Hyper-V host computer for \\DC1 and \\DC2 is a member server in the fabrikam.com domain — that is, the same domain as the RDCP client, \\workstation1 .
The system time on \\workstation1 is reported as being seconds apart from the system time on \\DC1 . The system time on \\DC2.contoso.com domain was reported as being 45 minutes from current time and the time that existed on \\DC1 .
A review of the SYSTEM event log to look for Kerberos and Time-related errors showed the following events.
Microsoft-Windows-Time-Service Event 142 was logged on \\DC2.contoso.com . The primary cause if the 142 error is the inability to locate a time server or sync from a peer server.
Log Name: System
Source: Microsoft-Windows-Time-Service
Date:
Event ID: 142
Task Category: None
Level: Warning
Keywords:
User: LOCAL SERVICE
Computer: DC2.contoso.com
Description:
The time service has stopped advertising as a time source because the local clock is not synchronized.
Event Xml:
https://schemas.microsoft.com/win/2004/08/events/event «>
Microsoft-WIndows-Time-Service event 35 logged on the console of \\DC1.contoso.com indicates that PDC \\DC1 is using the VM IC time sync provider to sync time.
Log Name: System
Source: Microsoft-Windows-Time-Service
Date:
Event ID: 35
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: dc1.contoso.com
Description:
The time service is now synchronizing the system time with the time source VM IC Time Synchronization Provider.
Event Xml:
https://schemas.microsoft.com/win/2004/08/events/event »
Microsoft-WIndows-Time-Service event 37 logged on the console \\DC2.contoso.com indicates that \\DC2 is also sourcing NTP time from \\DC1.contoso.com
Log Name: System
Source: Microsoft-Windows-Time-Service
Date:
Event ID: 37
Task Category: None
Level: Information
Keywords:
User: LOCAL SERVICE
Computer: DC2.contoso.com
Description:
The time provider NtpClient is currently receiving valid time data from jwesth-t1.jwesth.nttest.microsoft.com (ntp.d|[::]:123->[2001:4898:1b:4:6dd6:3c5c:699d:38cd]:123).
Event Xml:
https://schemas.microsoft.com/win/2004/08/events/event «>
Another event, Microsoft-Windows-Kernel-General, which was not logged in this particular case, indicates that the Hyper-V host computer may be changing time on VM guests computers. A sample event is shown below.
Log Name: System
Source: Microsoft-Windows-Kernel-General
Date:
Event ID: 1
Task Category: None
Level: Information
Keywords: Time
User: LOCAL SERVICE
Computer: . .
Description:
The system time has changed to ‎ from.
That Microsoft-Windows-Kernel-General event 1 indicates that time has been changed in the VM. Every time W32time updates the clock, this event is logged. Every time Hyper-V Time Synch updates the clock, Microsoft-Windows-Kernel-General event 1 is logged. This event is not specific to VMs as it is also logged in physical machines when w32time updates the clock.
Problem Summary
The RDP client is believed to depend on SPNego that picks the best authentication mechanism available, and in this case used Kerberos, event though there was no trust between the fabrikam and contoso.com forests. Kerberos auth requires that the clocks of the two machines to be less than 5 minutes apart but does not care about the clock accuracy.
The RDP logon failure is caused by the authenticating DC in the contoso.com domain (DC1) refusing to authenticate the RDP client logon request because the client’s time doesn’t match the server’s time. Either the client, or the server, or both could have an unsynchronized clock.
The time difference in this case was exacerbated by several factors
The RDP Client and KDC / RDP Server existed in two different forests with each forest using different time sourcing configurations
The KDC and RDP Server used by the RDC client are both virtualized domain controllers that require additional configuration changes to accurately source time then DCs running on physical hardware.
The virtual host computer was a domain-joined member server in a different domain than the Hyper-V hosts
Time accuracy on virtual host computers is important because VM guest computers initially derive time from virtual host computer during OS startup.
Two negative factors for \\DC1 and |DC2 is that member computers poll time less frequently by default than domain controllers. Secondly, the Hyper-V host computer was joined to a different domain than the DC guests and was subject to different time source configurations
Finally, the VMICTimeSync was used by \\DC2 to source time that is not recommended for virtualized computers hosting the DC role computers.
The forest root PDC in the contoso.com domain was not configured to source time from an external time source
In this case, the use of multiple time providers in the contoso.com domain ( ntp , VMICTimeSync) was deemed to be the root cause of the inaccurate time that lead to the RDP logon failure.
There are differing opinions about how to configure time in host and guest computers within the AD and Hyper-V teams. Ryan Sizemores recommendation as of 2010.11.22 was to leave VMIC enabled but pay close attention to the configuration and accuracy of time on the host computer. For example, the «Configuring the Windows Time service for Windows Server 2008 and Windows Server 2008 R2» section of «Deploying W2K8 and W2K8 R2 DCs in existing domains» recommends that virtual host computers be configured with «DC-like» polling intervals and max*phase correction settings + an accurate time server, similar to what you’d do on a forest-root PDC.
The use of different time providers and time sources on the virtual host and virtual guest environments can lead to a situation where time on the guest computer will ping pong between the VMIC values passed from the host computer. This condition may exist when virtualized DC guests in one forest are hosted by virtual hosts computers in another forests or even a workgroup computer where each uses a different time source / time configuration and the time samples are different between the two.
The Hyper-V team recommends that you don’t disable VMICTimeSync as it provides protection against time synchronization issues if you used saved state. The key issue here is not the use of VMICTimeSync — but the fact that if you are running a domain controller something needs to be getting accurate time from a remote server. You can do it by either configurating a remote time source inside the virtual machine, or by leaving the VMICTimeSync enabled and configuring the host to use a reliable time source.
By setting up a virtual machine with VMICTimeSync disabled — and no external time source the domain controller will use local time — which is the one thing that is always guaranteed to be wrong in a virtual machine.
Recommendations from the Microsoft Windows time team to correct this environment consisted of:
Configure the forest root PDC with an NTP Server.
Configure a GTIMEServer in the forest root domain as a backup
If using virtualization, disable VMICTimeSync (it is being evaluated
Configure Hyper-V hosts with an external time server
Configure Hyper-V hosts with the same polling intervals as domain controllers
Enable time rollback protection on Hyper-V hosts.
Useful commands (source: Carlos Trueba Salinas)
