Forum Discussion
Secure Time Seeding / W32Time Large Time Correction Issue
The 2035-versus-2056 result shows the response is rejected beyond basic reachability; a successful NTP packet does not prove W32Time accepted it. Microsoft does not document 2056 as a supported correction boundary, so avoid treating it as a guaranteed product limit. On one test device, run w32tm /query /configuration and /query /status /verbose, then use w32tm /stripchart against the internal server to capture the offset. Review the Microsoft-Windows-Time-Service/Operational log and temporarily enable private logging to identify “TOO BIG,” spike, or source-selection decisions. Confirm whether Group Policy overrides MaxPosPhaseCorrection, MaxNegPhaseCorrection, NtpServer, and Type. In a closed network, explicitly configure the trusted internal peer and disable Secure Time Seeding if suitable SSL sources are unreachable; Microsoft requires a reboot after changing UtilizeSslTimeData. Keep correction limits finite. If 2056 still fails, manually set an approximate trusted time, resync, and send the logs to Microsoft support.
Thanks for the suggestions. We ran the requested tests on our isolated subnet and were able to narrow the behavior down further.
The network issue appears to be resolved. w32tm /stripchart now show successful NTPv3 requests and valid responses over UDP 123, so the original 0x800705B4 timeout is no longer occurring.
We tested with larger finite values for MaxPosPhaseCorrection and MaxNegPhaseCorrection, disabled Secure Time Seeding (UtilizeSslTimeData=0) followed by a reboot, and configured the internal NTP peer explicitly using the 0x8 flag without /reliable:yes.
The interesting part is that the behavior is still reproducible specifically when we set the local clock to 2056. The NTP response is received successfully, but W32Time does not apply the correction.
So at this point, the evidence seems to indicate that this is occurring after NTP communication succeeds, rather than being a network reachability problem.
We are continuing to check the W32Time operational/debug logs to determine whether the correction is being rejected because of source selection, offset validation, or another internal W32Time condition.
If there is similar behavior with very large clock offsets, particularly around this date range, I'd be interested in knowing whether there is a documented W32Time validation or timestamp boundary involved.