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.
Update bootloader in Win10 Iot Ent LTSC (21H2) applied images?
The product I work on uses Windows 10 IoT Enterprise LTSC (21H2). I am trying to update the bootloader in the extracted and applied images to the version signed in 2023, to work around the issue with the default bootloader signatures expiring in 2026 (see KB5012170). KB5012170 updates the bootloader on an installed system. I can apply this hotfix to an installed device, and the bootloader on the hidden partition indeed gets updated. However, if I sysprep and extract the image from this machine, and apply it to a new machine, after using bcdboot to set the boot image, the new machine ends up with the old expiring bootloader installed. It seems KB5012170 only updates the "live" version of the bootloader on the hidden partition. It does not update the bootloader that ends up in the extracted image? Updating to Windows 10 IoT 22H2 or Windows 11 IoT is not an option for us for now. I do not want to have to require users to always install KB5012170 every time they install our product moving forward. I would like newly created images of our product to contain the updated bootloader by default. But I cannot find a way to do this. KB5012170 seems to be the only way to get the updated bootloader for our edition of Windows. Is there another way to get the updated bootloader I am missing? Is there a tool or trick that I am missing that would allow us to update the bootloader in the extracted, applied image without requiring a subsequent install of KB5012170?
