Microsoft's daylight-saving time (DST) patch -- Does it matter to AD?

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.

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 Services. 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:

• Windows computers use NTP to stay synchronized.

• NTP uses UTC as a reference time, ignoring time zones.

• The "local time" you see in the clock in the notification area of your screen is an application that adjusts from UTC time for the time zone you have set in the Date and Time properties.

• Adjusting the local time will, in effect, change the computer's UTC time and cause synchronization to fail.

• Adjusting the computer's time zone will not affect synchronization. For example, if you have your laptop in Atlanta (Eastern U.S. Time Zone) and go to Dallas (Central U.S. time zone), synchronization will be fine. Also, remember that the computer doesn't really know where you are, so you can change the time zone without moving and it will still work.

• You can have DCs, servers and clients in different time zones and they will still authenticate -- assuming they all see the correct UTC time (i.e., your local time is correct for your time zone).

• You can force clock synchronization by using the w32tm utility.

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:

1. Double-click on the clock in the notification area of your screen to bring up the Date and Time properties UI.
2. Change the time zone and click apply.
3. Notice the new local time is adjusted, which does not affect the computer's UTC time. If it did, the offset of the change would alter the computer's UTC time and the local time would remain the same.
4. Now it's time to test the DST change. To see this, you need to move to a different time zone that has DST. In Figure 1, the time zone has been changed from Eastern U.S. to Canberra., with "Apply" then clicked. The local time now shows 1:44 a.m. and the DST adjustment box is cleared. Canberra is on DST now, so if you checked the DST box and clicked apply, as in Figure 2, the time then shows the DST adjustment to be 2:44 am.
5. Note that if you select a time zone that does not use DST, such as Saskatchewan, Canada, the DST check box does not appear.

Figure 1

Figure 2

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:

• Changing a computer's time zone does not affect its UTC time. Thus, it will have no ill effects on authentication or NTP synchronization.
  
• The same goes for changing the DST setting.
  
• Changing the time using the Date and Time Properties UI will change the computer's UTC and will affect authentication and NTP synchronization.
  
• Changing the time zone or DTC properties will affect applications like Outlook.

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.