Full Disclosure mailing list archives
Re: Windows Time Synchronization - Best Practices
From: "Gary E. Miller" <gem () rellim com>
Date: Sun, 24 Oct 2004 18:48:07 -0700 (PDT)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Michael! On Fri, 22 Oct 2004, Micheal Espinola Jr wrote:
You can certainly have multiple time servers specified with Windows Time Service (SNTP). RTM. It has the ability to failover through a list.
Yes you can have multiple time servers, but only one active at a time. With NTP your client polls a number of diverse servers. Routes can flap, servers can go wacko, but your time stays solid.
If you need the full features of NTP, by all means use a third party daemon. However, in keeping my routers, RADIUS, and Kerberos sync'd properly - I have yet to require anything that SNTP is unable to provide.
So I agree it is not always required, but when those devices support native SNTP why not use the best? A lot of services are dependent on linear time. NTP will usually slew the local host time to the correct value, SNTP will in usually jump time to the correct value. This can cause things like cron daemons to miss scheduled events. I have seen this cause problems. BTW, A Cisco router makes a dandy low-latency local NTP time server.
I've never heard of time.microsoft.com, and have never seen any indication in any documentation to ever suggest using it. MS's docs have always suggested US naval observatory sites (since the documentation is US-based).
Just read all the w32time KB articles and the only time server mentioned with a FQDN is time.miscrosoft.com. Even the usno NTP has gone bonkers. Not dead, bonkers. So failover never occured. Folks that synced to it and other servers with NTP had no issues. Those that used it solely were SOL.
I missed something. Why would the requester time sync to Seattle, WA USA if they are in Brazil? That certainly goes against NTP RFC's, regardless of any suggestions of the use of time.microsoft.com.
Cause that is the only time server mentioned by FQDN in the M$ KB.
I have used 3rd party daemons as well as the built-in SNTP. Both work equally well. The built-in tools can work just fine if you understand the components and know how to properly use them. There is more functionality available than what is simply represented by NET TIME. Again, its a matter of RTM.
Well, I RTM the SNTP RFC and it says only to use STNP on local nets at the end nodes. YMMV. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem () rellim com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBfFtb8KZibdeR3qURAje4AKDM9zApW/whinZS1TXtMQxyUOUtIgCgzO0X ujUs6Je71jrYa/PmyTmvuTo= =88X7 -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: Windows Time Synchronization - Best Practices, (continued)
- RE: Windows Time Synchronization - Best Practices James Edwards (Oct 20)
- RE: Windows Time Synchronization - Best Practices Phillip R. Paradis (Oct 21)
- RE: Windows Time Synchronization - Best Practices Todd Towles (Oct 19)
- RE: Windows Time Synchronization - Best Practices Keith Pachulski (Oct 19)
- RE: Windows Time Synchronization - Best Practices Cushing, David (Oct 21)
- RE: Windows Time Synchronization - Best Practices Gary E. Miller (Oct 21)
- RE: Windows Time Synchronization - Best Practices Frank Knobbe (Oct 21)
- Re: Windows Time Synchronization - Best Practices Micheal Espinola Jr (Oct 22)
- Virus/Trojan trying to connect external:445 and 212.175.149.149.6667 Murat Bicer (Oct 22)
- Re: Virus/Trojan trying to connect external:445 and 212.175.149.149.6667 darren windham (Oct 22)
- Re: Windows Time Synchronization - Best Practices Gary E. Miller (Oct 24)
- Re: Windows Time Synchronization - Best Practices Andrew Farmer (Oct 25)
- RE: Windows Time Synchronization - Best Practices Gary E. Miller (Oct 21)
- RE: Windows Time Synchronization - Best Practices joe (Oct 22)