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:
- 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).
Setting the system time because it is outside the secure time limits.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:
Current system time: 18:0:45.622 3/1/2016
Target system time: 19:4:54.231 12/3/2015
[datetime]$STestimated=130936430942316190This 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:
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/