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.
Server 2025 domain controller time sync issues when set as reliable
I wish to make a second domain controller running, Server 2025, a reliable time source for clients at that site. The current configuration of this domain controller is to sync from domain hierarchy ("domhier"). If I set the "reliable:yes" flag with "w32tm", the domain controller will no longer sync it's time and eventually fall out of sync. As soon as the "reliable:no" flag is set, time is synchronized like normal. Is this a bug or expected behavior?
