> Be aware that if time is out-of-tolerance by more than a certain amount (5 > minutes? an hour? I forget),
5 minutes +/- is the default tolerance required by Kerberos in an AD environment. I imagine that is why that number sticks in your memory. The time service has its own sanity checking about offsets just like NTP, in windows it is configurable and can be somewhat fussy and I don't recommend mucking with it to try to get correction for balky clocks. IME, usually anything over a minute on a domain joined PC will cause the time service to panic. That's where net time /set /yes comes in real handy to get it back in close enough to the DC that the time service will take over. OTOH- There have been some cases where "very bad things happened"[1] and there is now guidance from MS about large offset. We found out about this from our last ADRAP. How to configure the Windows Time service against a large time offset http://support.microsoft.com/default.aspx?scid=kb;EN-US;884776 " The default value for the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries in Windows 2000, in Windows XP, in Windows Server 2003, and in Windows Vista is the following value:0xFFFFFFF This value enables the computer to receive the time that is contained in any time sample, regardless of inaccuracy. In Windows Server 2008, a new default value for the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries has been adopted. This new default value is 48 hours." [1] My characterization. The w32time guys at MS have a different one[2] [2] "The problem, lovingly titled as the "Large Time Jump" issue involves a machine in the domain (usually the PDC) making a large jump in time, either forward or backwards. Regardless of the direction of the jump, the results are equally catastrophic."[3] [3] http://blogs.msdn.com/w32time/archive/2008/02/28/configuring-the-time-service-max-pos-neg-phasecorrection.aspx If you are interested in the workings of w32time, the blog is an invaluable reference. I wish they had it years ago when I struggled with the service in NT/W2K. -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Friday, September 18, 2009 8:27 AM To: NT System Admin Issues Subject: Re: Why is Windows Time service crap? On Fri, Sep 18, 2009 at 10:36 AM, <richardmccl...@aspca.org> wrote: > 1. With multiple domain controllers, does one pick one of them, sync to an > outside time source, then somehow point the other DCs to this DC? As I recall: The DC holding the PDC emulator FSMO role should be the root time source for the entire AD forest. By default, all other DCs should automatically use that DC for time, and all members should automatically use to whatever DC they're using for everything else AD. If you've got multiple sites -- especially if you've got tiered sites -- you may want to override the default behavior. Have DCs at HQ use PDC emulator, DCs at second tier sites use HQ DCs, DCs at third tier sites feeding off second tier DCs, etc. You generally want a hierarchy within your organization, with a single master time source. You can manually maintain that master, or have it sync to outside time servers. I have found the Windows Time service to be somewhat easily perturbed. Our DC used to be set to sync directly to outside stratum two time servers. The time service would log errors and warnings all the time. I put an NTP Project ntpd server on our network, pointed the DC at that, pointed ntpd at the outside world, and all the DC trouble went away. The clients, pointing at the DC, still sometimes give warnings and errors. YMMV. (NTP Project is the reference implementation of NTP. http://www.ntp.org/ Free Software.) > 2. Why do servers and workstations drift off, time-wise? How to stop this? The most common causes are: (1) Failed or marginal battery for the Real Time Clock. When the system (re)boots, it gets system time from the RTC, so if the RTC is wacky you have trouble then. With practically every patch MSFT releases needing a reboot, even servers can expect to reboot often in Windows-land. (2) High interrupt load. Once booted, system time is advanced by interrupts generated by a hardware timer (the IRQ0 system timer by default). If the system is busy servicing other interrupts when the timer interrupt fires, it can miss clock ticks. Be aware that if time is out-of-tolerance by more than a certain amount (5 minutes? an hour? I forget), the time service won't adjust the system time. Radical changes in the system time tend to confuse lots of things (people and programs alike), so it leaves it up to you. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
