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.