Windows 10 - Time Synchronization and Imaging

Windows 10 has a new feature for time synchronization called secure time. The problem is that I haven't been able to find any documentation on it. What secure time seems to do is prevent significant time changes that are considered unreasonable. I believe it's new because there is no documentation at this time and because the registry keys for it don't exist in Windows 8.1, but do in Windows 10.

Here is the problem I ran into with secure time.....

As part of course development, we have a base image of Windows 10 with Office 2016 installed. We use this base as a starting point for differencing drives in course VMs, but this would also apply to an image you deploy to new workstations. This issue occurred even with just the base drive deployed.

When I had a VM using the base drive, it would run fine for about half an hour and then the time would reset back to December 3rd. This is approximately when the base drive was created. Time in the VM would then bounce back and forth between the proper time it obtained from the PDC and December 3rd. If you reboot, it would use proper time again for about half an hour and then the same issue would recur.

If you're reading this post because you have VM time synchronization problems in general, you should also check out this posting for some detailed information about how time synchronization works with Hyper-V:

• https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/

Also, see here for how to enable debug logging for time synchronization:

• http://blogs.msdn.com/b/w32time/archive/2008/02/28/configuring-the-time-service-enabling-the-debug-log.aspx

I tried several things described in these articles:

• Manually configured time synchronization type to domhier.
• Manually configured the PDC as time source.
• Disabled the Hyper-V time synchronization in the guest OS of the VM.
• Configured the PDC to use BIOS clock as a time source instead of time.windows.com (which was unreachable in a isolated environment).

All the time I was doing these things I had debug logging enabled and watched the log. Time synchronization would be done in 1024 second intervals (about 17 minutes). After two synchronization intervals time would reset to December 3rd. Finally, I really paid attention to the message in the debug log:

Setting the system time because it is outside the secure time limits.
Current system time: 18:0:45.622 3/1/2016
Target system time: 19:4:54.231 12/3/2015

The key here is the reference to secure time which I didn't realize existed. However, as I browsed the registry keys for time synchronization at HKLM:\System\CurrentControlSet\Services\W32Time (I'd been reviewing these over and over), it clicked and I noticed the registry key SecureTimeLimits. In SecureTimeLimits were the following:

• SecureTimeConfidence
• SecureTimeEstimated
• SecureTimeHigh
• SecureTimeLow
• SecureTimeTickCount

The values for SecureTimeEstimated, SecureTimeHigh, and SecureTimeLow are all hex values. However, you can convert them to a date format. In my case, I used Windows Calculator to convert 0x1d12dfd7e79669e to decimal 130936430942316190. Then I used PowerShell to covert to a date:

[datetime]$STestimated=130936430942316190
$STestimated

This gave a date of December 3, 0415 7:04:54 PM. When time conversions are done, you need add 1600 to the year. So, this gave us December 3, 2015 7:04:54 PM. Exactly when the time was being reset to. Next question, how do we make it stop?

The key SecureTimeConfidence looks like a likely solution. The current value was 0x6. A quick Google search turned up only a single reference to this value:

• https://social.technet.microsoft.com/Forums/windows/en-US/891bc6c6-eaf6-49da-b4dc-c588c8944fe1/windows-10-conflicting-time-issue?forum=win10itprogeneral&prof=required

Two other people in this thread indicated that setting this value to zero resolved the same issue for them. Unfortunately I've not seen any documentation on this registry value at all and I've been unable to find any. Another installation of Windows 10 Eval that I'm using as a demo has a value of 0x7. My laptop which is upgraded from Windows 7 has a value of 0x8.

However, the important point, is that I can confirm that setting SecureTimeConfidence to a value of 0 resolved the issue in the VM. I believe this will be a required part of preparing Windows 10 images in the future.

UPDATE: There is now a KB article related to this as provided by an anonymous comment below: https://support.microsoft.com/en-us/kb/3160312

ANOTHER UPDATE (Sept 2016): There is another article describing "Secure Time Seeding". This article also indicates that the problem described above in this posting has been fixed in Windows 10 Anniversary Edition. Check it out for more details: https://blogs.msdn.microsoft.com/w32time/2016/09/28/secure-time-seeding-improving-time-keeping-in-windows/