Changing time zone on AD Domain Controllers

[Jake20]

need to change time zones on a few AD domain controllers. Are there any
risks involved with this, as far as authentication, or replication with
other DC's in different time zones?

thanks!

Jake

 

[Joe Richards [MVP]]

No.

Computers maintain the time in UTC internally. TZ and DST changes do not
have impact on the internal workings; it is simply for displaying the
internal time in a format that a human can comfortably deal with. Now if
you have crappy apps that do everything in localtime, those might have
an issue.

--
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

 

[Herb Martin]

No.

Computers maintain the time in UTC internally. TZ and DST changes do not
have impact on the internal workings; it is simply for displaying the
internal time in a format that a human can comfortably deal with. Now if
you have crappy apps that do everything in localtime, those might have an
issue.

Everything Joe said with one caveat:

As long as you are changing the time zone because of the time zone,
and not because they are set to the wrong time zone and showing what
appears to be the correct time (and thus is WRONG.)

In that case, you would probably also change the time and now we
have to figure out did time just change by HOURS.

Time must be set to agree with the time zone that is also set or the
time will be incorrect (in GMT.)

I regularly take Domain Controllers to class in other cities, change
the time zone, bring them back, and again change the time zone
with no ill effects.

 

[Erik Cheizoo]

One of the crappy applications using local time is Outlook.
Well, in fact, Outlook is doing the right way. If you change time zone,
Outlook appointments will shift in time.

--
Kind regards,

Erik Cheizoo
eXcellence & Difference - we keep your business running
============================================
Always test in a non-production environment before implementing
Guidelines for posting: http://support.microsoft.com/?id=555375
============================================

 

[Jake20]

I am going from Eastern time zone to Central Time Zone , so the time
will be going back an Hour.
So, the actualy time will change by 1 hour.
Is there anything that needs to be done after that?
thanks!

 

[Joe Richards [MVP]]

Again the UTC time will not change. Only the local displayed time.

The computer does its thinking in UTC, regardless of the TZ and DST
changes you make, it doesn't change internally.

UTC and TZ simply manipulate the info displayed to you the user. The
only time that can come into play with the internal time is when you set
the time. If you have a computer set with one TZ value and you think it
has another and set the clock, the internal UTC time will then be wrong
regardless of what the clock says. So the main thing to keep in mind is
don't dork with the actual time of the machine, simply change TZ/DST
settings as needed.

--
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

I am going from Eastern time zone to Central Time Zone , so the time
will be going back an Hour.
So, the actualy time will change by 1 hour.
Is there anything that needs to be done after that?
thanks!

 

[Herb Martin]

I am going from Eastern time zone to Central Time Zone , so the time
will be going back an Hour.
So, the actualy time will change by 1 hour.
Is there anything that needs to be done after that?
thanks!

The "actual" (or GMT or UNIVERSAL) time should never change
more than a few seconds (from now on.)

If the time was improperly set to allow for a mistake in setting the
time zone then you will either find that this machine may be
going to change the time on ALL machines in the domain/forest
(if it is the time master) so any others with the wrong time zone
will likely make this apparent.

IF multiple DCs are at the wrong time (for this or other reasons)
then they will refuse to AUTHENTICATE (Kerberos is time
sensitive) and therefore fail replication. Clients with times that are
off will also be unable to authenticate and thus fail on resource
access, etc.

Set all the time zones correctly THEN set any machine with the
wrong time to the correct time visually AND considering the
time zone that is appropriate -- be careful when setting time
across a Terminal Server/Remote Desktop connection, time zone is
typically "remoted" (at least on the newer machines) but be
careful.

--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)