My point was that the time service wouldn't set the clock that far off because of a bad source because it won't accept an offset that large. Kind of like NTPd on a *NIX box will panic if you try to throw it an offset >1000 sec. You can certainly do it with the old date, time, or net time.
It must have been a really interesting case you had with PSS.... From: Webster [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 10:52 AM To: NT System Admin Issues Subject: RE: DC changing time? From: Free, Bob [mailto:[EMAIL PROTECTED] Subject: RE: DC changing time? The time service on the DC wouldn't accept an offset that big. I worked a call back in August where the point-to-point T3 went down for 8 hrs. When the link came back 1 DC on each side of the link each changed their dates from 08/11/08 to 01/02/09. Then 45 minutes later reset back to 08/11/08. On the west coast no one could then authenticate to the network. On the east coast, where the PDCE resided, there were no issues. Took Microsoft support many hours to fix that network. Webster From: Joseph L. Casale [mailto:[EMAIL PROTECTED] Subject: RE: DC changing time? Bad NTP Time source? Enumerate and check them... From: mqcarp [mailto:[EMAIL PROTECTED] Subject: DC changing time? We had a weird issue where apparently a DC rolled back exactly one day in time (6:30PM Monday became 6:30PM Sunday). This wreaked havoc on policy issues. All I can see in the event logs is the change in policy where it was denying log ins all of a sudden. The DC time was updated and we are back on track but I can not see what would cause something like this. No one was at the office in IT when this occurred. The only thing odd was an admin had left himself logged into the server at the end of the day. Has anyone seen this before? AD 2003 2003 Server Standard ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
