Synchronize Chrony with Windows NTP Server Easily
Introduction
Synchronize Chrony with Windows NTP server is a common requirement in mixed OS environments. When you set chronyd to sync to a Windows NTP source using the default configuration, the server often appears as “unusable.” This blog explains why that happens, and how you can fix it — thereby ensuring your SUSE Linux systems remain synchronized with Windows time servers reliably.
Why the Windows NTP server appears “unusable”?
In many cases, the default Chrony configuration does not allow large time deviations — so even valid Windows NTP servers get rejected. By default, the maximum root distance is 3 seconds, so if the Windows server’s clock has drifted more than that, it’s flagged as unusable.
Furthermore, the server might be disconnected or poorly synced itself, causing dispersion or jitter beyond acceptable limits. Since Chrony enforces strict limits by default, it refuses to accept that server unless settings are relaxed.
Step-by-step resolution: adjust maxdistance
To overcome this, you should edit /etc/chrony.conf and add or adjust the maxdistance parameter. For example:
server win-samba.mydomain.com iburst
driftfile /var/lib/chrony/drift
maxdistance 16.0 # if your NTP is a Windows server, use this as a starting value
makestep 1.0 3
rtcsync
keyfile /etc/chrony.keys
leapsectz right/UTC
logdir /var/log/chronyHere’s what the settings do:
- maxdistance 16.0: raises the maximum allowed root distance threshold, so that the Windows NTP is no longer automatically marked unusable.
- makestep 1.0 3: allows the clock to be stepped if offset exceeds 1 second within first 3 updates.
Other directives remain standard (driftfile, rtcsync, etc.).
After making the change, restart or reload Chrony. Once applied, the Windows NTP server should appear as a valid source rather than ? or unusable.
Why this solution works?
Because the default root distance limit is low (3 seconds), Chrony rejects servers with large dispersion. By increasing maxdistance, you essentially tell Chrony to tolerate larger deviations — thus allowing synchronization with Windows NTP servers whose clocks may not be tightly controlled.
In addition, because many Windows NTP servers may themselves have intermittent connections or accumulate clock drift, this more permissive limit helps maintain time synchronization across mixed systems.
Considerations & tips
- Use cautiously: Don’t set maxdistance too high — that could allow very bad time sources to be accepted.
- Monitor stability: After changing, watch chronyc sources or chronyc tracking to ensure proper behavior.
- Adapt value: The example uses 16.0; your environment may require a slightly higher or lower threshold.
- Fallbacks: If issues persist, verify network connectivity, firewall rules, or inspect your Windows NTP server itself.
Conclusion
When you need to synchronize Chrony with a Windows NTP server, but it is marked as “unusable,” the fix is simple — adjust the maxdistance parameter in /etc/chrony.conf. After restarting Chrony, your Linux system should successfully accept the Windows NTP source.
This approach balances flexibility and control: by increasing the allowed tolerance, you enable cross-platform time sync without completely sacrificing safeguards.
2 thoughts on “Synchronize Chrony with Windows NTP Server Easily”
After applying the recommended changes, the problem we were encountering on our Linux VM related to NTP was resolved. Appreciate the detailed solution — it is very helpful.
Visit My GitHub VARELITE
Thanks for the information. We faced the same issue with an RHEL machine in my environment, and after using this parameter, the issue was resolved.