Secure Time Seeding / W32Time Large Time Correction Issue
Hello everyone, I’m investigating an unusual time synchronization issue with Windows 10 IoT Enterprise LTSC involving W32Time and Secure Time Seeding (STS) in a closed network, and I’d appreciate any guidance or insights from the community. In our environment, time.windows.com resolves to our internal IP/NTP server. The server receives NTP requests and returns a valid response with the correct time. Network monitoring confirms that both the request and response are working correctly. However, we observed an unusual behavior: If the system clock is set to 2035 or earlier, W32Time successfully corrects the time. If the system clock is set to a much later date, such as 2056, W32Time receives the correct NTP response but does not update the system clock. This behavior has been observed in both open and closed networks. We have already tried: Configuring MaxPosPhaseCorrection and MaxNegPhaseCorrection to 0xFFFFFFFF. Enabling UtilizeSslTimeData = 1. Unregistering/registering W32Time. Stopping/starting the Windows Time Service. Reconfiguring the NTP peer. Running w32tm /resync. Verifying NTP traffic and responses using network monitoring. We are also trying to understand how Secure Time Seeding (STS) works in this scenario. On an open network, STS appears to obtain and cache trusted time, which may help Windows recover time while offline. However, in our closed network, where time.windows.com resolves to our internal NTP server, STS does not appear to establish trusted time in the same way. Questions: Is there a W32Time or Secure Time Seeding limitation that prevents very large time corrections, even when MaxPosPhaseCorrection and MaxNegPhaseCorrection allow them? Why does synchronization work at 2035 or earlier but fail around 2056? Is the 2035/2056 behavior related to timestamp validation, NTP, STS, certificates, or another Windows limitation? Does STS require Microsoft's actual time infrastructure, or can an internal NTP server participate? Does resolving time.windows.com to an internal IP prevent STS from establishing a trusted timestamp? Is there a supported configuration on Windows 10 IoT Enterprise LTSC to treat an internal NTP server as a trusted time source? Are there specific W32Time event logs, registry settings, Group Policies, or diagnostics we should check when an NTP response is received but not applied? Accurate and trustworthy time is critical because timestamps are used for offline operations. Any guidance on whether this is caused by W32Time large-offset handling, Secure Time Seeding, timestamp validation, or an interaction between these components would be greatly appreciated.
Windows server time going back to past due to time synchronization with the hardware clock
Hi. From the last 2 months, we are facing below issue on our Windows 2016 server every 10 days. Server time is going back by 1 hour with the below message in eventvwr. The system time has changed to 2023-12-27T07:34:29.500000000Z from 2023-12-27T08:34:38.153992100Z. Change Reason: System time synchronized with the hardware clock. It is again getting corrected after 2 hours. The system time has changed to 2023-12-27T09:34:29.500000000Z from 2023-12-27T08:34:29.508436400Z. Change Reason: System time synchronized with the hardware clock. Below are the default settings of the server since very long time. 'Set Time Automatically' is off in 'Date & Time settings'. StartUp type of Windows Time service is Manual(Trigger) and is not running. This is a WorkGroup server & not joined to any domain. How can we avoid the system time being synchronized with the hardware clock. Please help. Thank you.