Time synchronization on Windows 8+

[UCyborg]

In Windows 7, they changed Windows Time service to be started manually or by the event of computer joining a domain. For non-domain computers, there's a scheduled task setup called SynchronizeTime that syncs time every Sunday at 1:00:00 or as soon as possible if it can't run then.

But starting with Windows 8, SynchronizeTime task lacks the trigger, so it never runs. In addition, ForceSynchronizeTime task is added with custom action and trigger defined, so cannot be inspected in Task Scheduler. Does it ever run by itself? Running it manually does sync time.

There are some clues when exporting ForceSynchronizeTime to XML:

<Actions Context="LocalService">
  <ComHandler>
    <ClassId>{A31AD6C2-FF4C-43D4-8E90-7101023096F9}</ClassId>
    <Data>TimeSyncTask</Data>
  </ComHandler>
</Actions>

According to registry entries, this invokes code in TimeSyncTask.dll.

But the following part is still a mystery:

<Triggers>
  <WnfStateChangeTrigger>
    <Enabled>true</Enabled>
    <Delay>PT1M</Delay>
    <StateName>7510BCA32F018915</StateName>
  </WnfStateChangeTrigger>
</Triggers>

Any ideas?

[HarryTri]

I synchronize the time manually once a month on Windows 8. In the event log I find complaints about the Time Service not being able to contact the Time Server in cases that I don't have the internet connection enabled. That's all I can say.

[dencorso]

Try to use a time server different from the default (which still is time.windows.com). The most obvious altenative is time.nist.gov, but that's also in the US. pool.ntp.org (or ntp.psn.ru) might be better for who's in Europe. A good read on it is this site. Enjoy!

[UCyborg]

Syncing through Date and Time in Control Panel starts the Windows Time service and keeps it running until you fully shutdown or restart, so it should sync at regular intervals according to its registry settings. Might explain the events that occur when it can't reach the NTP server.

The tasks in Task Scheduler start the service, sync time and then stop the service. If sync fails, it will keep running until it succeeds. We have 2 tasks that virtually accomplish the same thing. Editing ForceSynchronizeTime and trying to save changes shows an error unless the custom trigger is deleted (invalid trigger?). Unless there's a catch, the only difference between 2 tasks is the way the time service is invoked.

The funny part is having 2 tasks defined for 1 useful purpose in Task Scheduler that aren't actually being scheduled.  And there's a third way to have the time synced, by keeping time service running all the time, like how it is on Windows XP. Though technically, it's just waiting majority of time consuming little memory. They said they changed it from auto-start to manual in Windows 7 to improve bootup performance, but then added significantly heavier background stuff in newer versions, especially Windows 10.Microsoft logic.

On 7/22/2018 at 12:39 AM, dencorso said:

Try to use a time server different from the default (which still is time.windows.com). The most obvious altenative is time.nist.gov, but that's also in the US. pool.ntp.org (or ntp.psn.ru) might be better for who's in Europe.

I do use pool.ntp.org. Just wrapping my head around the automation part, which the good guys at MS have disabled. Late edit: not really...

Edited March 13, 2022 by UCyborg

[UCyborg]

I don't know when ForceSynchronizeTime is run automatically, but "something" in Windows 8 triggers SynchronizeTime task periodically, hence why time is still synchronized without a trigger. It's done once a week on Windows 8 while Windows 10 does it daily. Still no clue what that "something" that triggers the task is. Are interactions with Task Scheduler logged or how are you supposed to find out what (or who) ran a task?

Windows 7 way of doing this is obviously more logical since Task Scheduler is utilized to actually schedule it while newer versions offload it to another process for some reason. Since checkbox to toggle synchronization is still there, you can still have clever IT guys turn off the auto-sync and then have the users of an application where time is important complain that the time is off, so can't think of why would they just change how it's triggered and hardcode the interval somewhere else.

That "something" could read Windows Time service's sync interval setting at boot, which is actually set to about 8 hours out-of-the-box (SpecialPollInterval setting). One thing that is yet to be tested.

I've read somewhere that users that want custom interval can disable the original SynchronizeTime task and make another one just like it and add a trigger to it with the desired interval.

And one thing about Windows Time service, if it's started when there's no internet connection in a way that the computer is physically disconnected from the network, it'll wait until connection is established and sync time right afterwards, even if the log says it'll wait 15 minutes and connection is established long before that.

[UCyborg]

I'm going to have the Windows Time service run in the background the following week to see how often the task gets triggered after some reconfiguration. According to documentation, there was one important change in Win10 1703; SpecialPollInterval setting, specified in seconds, located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient registry key is since bound by MinPollInterval and MaxPollInterval settings located in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config. The latter two have to be converted to seconds using the following formula:

2^<setting value> = x seconds

Effective defaults are therefore:

MinPollInterval - 2^10  = 1024 seconds = 17 minutes 4 seconds
MaxPollInterval  - 2^15 = 32768 seconds = 9 hours 6 minutes 8 seconds

So eg. changing SpecialPollInterval from the new default value of 32768 seconds to the old default value of 604800 seconds (1 week) won't do anything as effective value will be capped to MaxPollInterval, so the latter has to be upped to 20 (1048576 seconds).

So far I've tested 45 second sync interval with pool.ntp.org with the manually started service running on Windows 10 20H2 using the following settings changed from defaults:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
NtpServer=pool.ntp.org,0x9 (space delimited list of NTP server hostnames/IP addressees with setting flags, in this case one server with 0x8 (client) and 0x1 (use special poll interval) ORed together)

Numeric values that follow are in decimal:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
MinPollInterval=4
MaxPollInterval=6

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
SpecialPollInterval=45

Seems to be working as expected. For the test the following week, I changed MinPollInterval=18, MaxPollInterval=20 and SpecialPollInterval=604800. Service will continue to run in the background, then we'll see if it can be stopped and the "scheduled" task that starts it fires again when it's time to sync again, so at the time after the service is stopped it should only be triggered approximately one week from then.

If setting value in NtpServer is changed to 0x8, then sync is supposed to occur between MinPollInterval and MaxPollInterval. It seems this mode of operation only effectively accepts shorter intervals. This is something I haven't tested. Manually running sync from GUI resets the value to 0x9, so syncing using SpecialPollInterval is re-enabled then. I haven't ruled out the possibility that it could happen only if change is made and settings are not refreshed.

I noticed changing sync interval from default to 1 week like how I wrote above then running w32tm /config /update doesn't postpone the next sync to next week, so next sync runs according to old schedule, but the one afterwards is scheduled after a week. But going from 1 week to default then having service re-read its settings is effective right away. Same in the first scenario if time service is restarted instead of having it refresh its config. Maybe something to do with higher MinPollInterval / MaxPollInterval. Running w32tm /query /status /verbose reads Poll interval as 18 (out of valid range).

[UCyborg]

The scheduled task still runs daily, but the service it invokes was already running, so it returned with code 0x420. This happened at 17:33.

Noticed another funny thing, the Date and Time dialog shows the last successfuly sync at 16:23, which is one hour before system resumed from hibernation, when the system was off.

Looking around, it seems likely that in this instance, the message refers to the event of system time being synchronized with CMOS clock rather than NTP server and showing time in UTC, like the relevant event message. I have RealTimeIsUniversal setting enabled so CMOS clock is interpreted as UTC rather than local time.

[UCyborg]

Test completed, it syncs at specified interval normally when service is running. While daily would is good here in a sense that it keeps the clock relatively accurate, it makes tons of spam in event logs since internet connection is not always available. Interestingly, upping MinPollInterval as I did was actually necessary if I wanted once a week sync, only upping MaxPollInterval is not enough.

The clock lags behind by about 1 second per day. What gives? Do all computers suck at keeping time? My rusty car is better at it than this damn computer. It's not the CMOS battery (depleted and removed few years back), it has constant standby power.

The motherboard (Asus M3N78) was cheap though, so there's that.

Edit: not sure where I got 1 second per day...this week it was about 4,2 seconds behind while previous week it was 5,2.

Edited April 3, 2022 by UCyborg