Print

Print


Actually, seeing it explained that way simplifies it in my mind, at least
for the domain time synchronization issue. The workstation syncs its time to
the server in UTC time, and then it adjusts that according to its own time
zone setting and time zone rules (such as DST) to get the current local
time. Now that you describe it, it's obvious that this is how it would have
to work, unless Microsoft was going to make the assumption that all
workstations are always in the same time zone as their server. So to keep
the workstation time accurate automatically even in a domain, it is
necessary that each workstation know the correct DST rules.

> -----Original Message-----
> From: Hoort, Brian [mailto:[log in to unmask]] 
> Sent: Friday, February 16, 2007 8:03 PM
> To: [log in to unmask]
> Subject: Re: [MSUNAG] DST 2007 on Windows 2000
> 
> Regarding domain workstations syncing with their DCs for 
> time, we were thinking yes, they will.  But Windows "thinks" 
> in UTC -- and then makes adjustments for your time zone and 
> then again for DST, if applicable.
> So, now that I type this I realize that Kerberos won't break, 
> because I expect the the UTC will be correct, but the time 
> will still be off on the clock, and apps will display 
> incorrect times (Outlook w/ Exchange Calendar's, for 
> instance).  In essence, the computer will believe it is in a 
> different time zone than it is (it will pretend to be 
> residing in Indiana).
> 
> Over the past several weeks, I have repeatedly come to the 
> realization that this topic is far more complicated than it appears.
> 
> Thanks for the input.
> 
> bh
> 
> -----Original Message-----
> From: MSU Network Administrators Group 
> [mailto:[log in to unmask]] On Behalf Of Chris Wolf
> Sent: Friday, February 16, 2007 6:21 PM
> To: [log in to unmask]
> Subject: Re: [MSUNAG] DST 2007 on Windows 2000
> 
> That's pretty funny--I totally forgot about that! Even after 
> you fix it, Windows will then break it again on April 1! 
> 
> I had the same thought about the clock synchronization for 
> domain members.
> Won't that in fact take care of getting the clock set correctly? 
> 
> -----Original Message-----
> From: John Valenti [mailto:[log in to unmask]]
> Sent: Friday, February 16, 2007 6:01 PM
> To: [log in to unmask]
> Subject: Re: [MSUNAG] DST 2007 on Windows 2000
> 
> I read some coverage on this that suggested you will also 
> need to adjust the clock when DST used to change, so four 
> times per year instead of just twice.
> (But you say they are domain members, won't the clock be set 
> automatically wrong whenever they login?)
> 
> I think we are down to about six Win2000 computers too. My 
> plan was to just upgrade them to XP.  I had forgotten about 
> our Win2000 server  
> until now, suppose that will need to be upgraded too.   Ughhh!
> 
> I'm glad we ditched Exchange here. I was reading about the 
> patching strategy for some versions of that: you have to 
> patch W2K, then within an hour patch Exchange. Otherwise it 
> apparently goes thru and modifies meeting times in advance 
> and they can't be easily fixed.
> 
> 
> On February 16, at 4:34 PM February 16, Wolf, Chris wrote:
> 
> > As far as I can tell, we have six Windows 2000 computers left, all 
> > members of our domain, none using Exchange.  Several of them are 
> > rarely used.  My plan was to just have those users set the time 
> > manually to the correct time on (or about) March 11 and September
> > 28 each year until we replace the computers (which probably 
> won't be 
> > that long). Why wouldn't that work? And even if they don't 
> set it, as 
> > long as they aren't using calendar software, how much does 
> it matter 
> > if their clock is wrong?
> >
> 
>