I wonder if the United States Congress and Canadian Parliament had any idea that expanding the dates of daylight saving time (DST) would cause so many problems for IT administrators.
For example, computers -- from laptops to domain controllers -- probably have the "Automatically adjust clock for daylight-saving changes" box checked that automatically advances or pushes back the time on the appointed date.
This year, though, daylight-saving time will have negative effects on Microsoft Outlook functions such as email time stamping, calendar items and other issues noted by Microsoft in Prepare calendar items for daylight saving time in 2007.
The biggest concern for Active Directory administrators is whether the DST change can also affect domain operations such as AD replication and network authentication.
DST legislation
This new legislation changes the dates for DST implementation. The table here shows the previous dates for DST changes (2006) and what the new changes, starting in 2007, will be.
[TABLE]
Microsoft has released KB 928388, a DST hotfix to address this issue. If you are in a time zone outside the U.S. and Canada that changes, Microsoft provides a way to modify these parameters for your particular time zone in KB914387.
However, the burning question for administrators is, "Can this also affect domain operations such as Active Directory replication and network authentication?" After all, Kerberos requires any two computers authenticating over the network to be within five minutes of each other, though it is configurable in Group Policy. But does it really affect domain controllers if the DST is incorrect? Further more, if you have DCs in Atlanta, Seattle, Sydney and London, all in different time zones with various DST settings, how can they all stay within five minutes of each other?
How Windows time service works
To better understand this issue, let's review some basics on Windows Time Serv
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
ices. Windows 2003 relies on the NTP (Network Time Protocol) to synchronize clocks across a network. NTP is much more accurate than the Simple Network Time Protocol (SMTP) used in Windows 2000 (though SMTP is still available in Windows 2003).
In order to synchronize all clocks on the network, NTP needs a "reference clock" as a reliable time source. In order to eliminate the confusion caused by the many time zones in the world, (such as those shown in Figure 2), NTP uses Coordinated Universal Time (UTC) as the standard. UTC is a standard time that everyone agrees on, regardless of time zones. It is generally considered synonymous with GMT (Greenwich Mean Time).
However, don't confuse GMT with British Standard Time. When the UK goes on "summer time", or DST, BST is changed by an hour -- it does not affect GMT. Bottom line, all computers use UTC to synchronize clocks. Regardless of what the time in the Notification Area says, the computer knows the UTC.
So, even though a client computer in Atlanta says it's 16:00 and a server in the network in Seattle says it's 13:00 (adjusted for time zone), the UTC on both is 21:00. Microsoft could have made things simple and just had all computers report the UTC time and be done with it, but they decided to make it user-friendly and built a utility to convert UTC to "local time" based on the time zone selected. While using UTC time may make it easier when comparing logs from two machines in different time zones, it would render things such as calendar functions useless. For more information on time services in Windows, check out Microsoft's article How Windows Time Service Works. It doesn't answer all questions, but it addresses a lot of them.
Many admins have probably dealt with a time sync problem at one time or another where they have users that try to log in and get time synchronization errors. Or, they may get AD replication errors saying "Access Denied" because the client and server or the two DCs are out of sync by more than the five-minute skew allowed by Kerberos. You can fix that by changing the clock in the UI to the correct time. For instance, say the UTC/GMT time was 13:00. If you were in Atlanta at GMT-5 your local time would be 08:00. However, if you set your local time to be 07:00, conversion to UTC/GMT would put your clock at 12:00. This would put your clock an hour off, and trying to authenticate with a DC that has correct UTC time would fail.
It is easy for computers to get out of sync if they are on a VPN or an otherwise unreliable network link. Microsoft's nifty tool, called W32tm.exe, allows us to synchronize the time with a good time source. While I don't have space to go into details about W32tm.exe (I'll do that in a future article), it is important to note that this tool is available in Windows 2000 and 2003. But the options are completely different. To sync an XP or Windows Server 2003 machine, the command w32tm /resync will usually do the trick. In Windows 2000, the command is w32tm –once. Make sure you study the online help for the command when you use it.
So, here is what we know:
What about DST adjustment?
OK, so now that we have all our clocks synchronized, along comes a daylight-saving time change (called "summer time" in some parts of the world). How does the DST adjustment affect all this?
A utility called tzchange.exe stores all the time zone information in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone> where <zone> is the name of the zone, such as Mountain Standard Time. This is detailed nicely in Microsoft's article, KB 928388. This is loaded on each computer when the operating system is installed, and if the check box "Automatically adjusts clock for daylight savings time changes" is checked. Then, when the appointed date arrives for the daylight-saving time change, the clock moves ahead (spring) or behind (fall) by one hour. When this happens, all workstations, servers and DCs are affected and their clocks (local time) are adjusted.
It is critical to note that, like the time zone change, the DST change only modifies the time setting you see in the notification area and does not affect the computer's UTC time or time zone.
This is readily seen with a simple test:
Figure 1
[IMAGE]
Figure 2
[IMAGE]
The question is -- does it really matter to AD?
So now we can finally answer the question about how it all affects Active Directory. In regard to the DTC patch from Microsoft, will replication and authentication fail? The answer is no, since changing the time zone or the DST adjustment does not change the computer's UTC time that is used for clock synchronization. As mentioned at the start of the article, it does matter to applications like Outlook. So, from that standpoint, the patch is important.
Of course these scenarios are for a mental exercise in time services only. Don't start telling everyone that Gary Olsen said you don't need to apply the DST patch.
What about Windows 2000?
Here is the rub for legacy systems running Windows 2000, which is currently out of mainstream support. Unless you have an extended support agreement with Microsoft, you can't get this hotfix, KB928388.
Sorry about that, but this hotfix is just like any other hotfix, and the policy is clear. However, Microsoft did throw you a rope (just don't hang yourself with it). KB 914387 provides some workarounds that allow you to implement the change without the hotfix. You can use the tzedit.exe utility to make your own changes in the time zone. You can also manually configure one machine with all the proper new settings, then export the registry key and ship it out to all the other machines via a login script, provided in the KB.
Note that Vista has the changes built in, so there is no need to worry about Vista clients.
Obviously there are many issues involving time services in terms of configuration, security, authentication and troubleshooting synchronization problems. Other articles in the near future will cover these issues. Here are the important things to take away from this article:
Joe Richards, Microsoft MVP for Windows Server Directory Services, contributed to this article.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Window Server-File Systems.
