AD, Win 2000, and new 2007 Daylight savings time

  • Thread starter Thread starter Sean
  • Start date Start date
S

Sean

We've got about 300 W2K Pro, and 350 WXP Pro computers in a domain
(functional level 2k3). We're worried about what will happen to the
300 Win 2000 machines when daylight savings time is changed this year.
We're running WSUS so all the XP machines have the patch Microsoft
released, but we're afraid we'll have to manually change all the 2000
machines (Using Windows Time Zone Editor). My question is, is there
any reason to change each 2000 client? I mean w32time's type is set to
NT5DS (which means it should use the domain hierarchy). When the DC's
change their time for daylight savings, won't w32time pick up the
change and run with it? I'm worried we'll end up with clients that
can't authenticate because of an hour difference in time...

Any suggestions would be appreciated!
 
OK you are living under a huge misunderstanding of how time works in the
computers.

When DST changes, the machine time does not change. Only what is
displayed for local system time. All back end time on clients and
servers is handled via UTC and then the local machine translates that
into a value for humans to view locally based on their local TZ and DST
settings. It isn't like DST will flip and then DCs will start handing
out a new time... The time they will hand out one second before and one
second after the change will be 2 seconds apart, not an hour and 2
seconds. If they didn't, you couldn't run machines across time zones at
all, it would all blow apart.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
Hi Joe,

Its been a long time....

The risk here isn't so much with the operating system and its
understanding of DST -- as you point out all of that works under UTC.
The problems comes when there are applications that have not been coded
correctly and inherit their time settings from the local machine clock.
This happens far more often that you would think.

Additionally, one should consider enterprises that don't have WSUS or
another patch management suite and that are using a distributed
administration model. If machines are in the same time zone and the
admin of one site has updated them and the other has not, there will be
a disparity there. The machines will see the same UTC, the same time
zone, and different local times. So, it seems to be much better to deal
with the patching issue now and make sure your sandbox continues to play
nice.

Ryan Hanisco
FlagShip Integration Services
 
Oh absolutely agree, I guess I was implying by saying "then the local
machine translates that into a value for humans to view locally based on
their local TZ and DST settings" that it is quite important for folks
machines to be properly configured or people (and poorly written apps)
will be screwed up.

Definitely there are bad apps out there that do this stuff wrong, but
there are bad apps for all sorts of reasons. Time handling is just one
of them, this will be a good chance for people to find the bad apps. :)
More than that is custom scripts and batch files, etc that deal with
time as it is almost a certainty that no one is doing things in UTC on
those since there isn't much support for it.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
The clients are synchronizing the UTC time with the DC (after that they are
applying the time zone rules - and this will be the local system time)). So
if you need to modify something in the time zone rules (like the daylight
saving), then you need to do it both on the DC and clients (on all the
computers that needs update to the time zone).

--
Regards,
Andrei Ungureanu
www.eventid.net
Test our new EventReader!
http://www.altairtech.ca/eventreader/default2.asp?ref=au
 
You need to do it on every machine that you locally want displaying the
proper time. If the machine displays the incorrect time, that isn't
really an issue as long as you are aware of it but in most normal cases
that will confuse the crap out of people.

As mentioned, replication and other core functions don't care what the
TZ/DST settings are. It is all about displaying the things properly for
users. A user will never notice that a DC doesn't have the patch as it
will have no impact on users. An Exchange server that runs server side
scripts could have an issue though if the scripts work in localtime
instead of UTC (that would be the norm for scripts - working in localtime).

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm
 
Back
Top