Microsoft Daylight Saving Time & Time Zone Blog : Outlook

Microsoft Daylight Saving Time and Time Zone update now available (December 2008)

atsim — Fri, 30 Jan 2009 01:22:00 GMT

The most recent cumulative updates to daylight saving time (DST) and world time zones (TZ) are now available for supported versions of the following products. For the latest DST updates on each of these products, please visit the following Microsoft Web site: Microsoft Daylight Saving Time Support page.
The cumulative updates can be downloaded as indicated in the same Web page.

Microsoft product teams follow a semi-annual DST and TZ update schedule, which follows the Windows regular schedule for publishing newly legislated DST rules and time zone updates. These annual "Cumulative Daylight Saving Time and Time Zone Updates" will be released in December for the coming calendar year; a semi-annual update will be released in July/August, as needed. Microsoft products that are affected may also schedule updates to accommodate some of these changes.

For more information about all the DST and TZ updates that have been made to date, visit the following Microsoft Web site:
914387 How to configure daylight saving time for Microsoft Windows operating systems.

More details are available at http://support.microsoft.com/gp/dst_hottopics.

Chile announces an extension on their Daylight Saving Time for 2008

atsim — Sat, 08 Mar 2008 22:26:00 GMT

The government of Chile announced on February 7, 2008, that their current daylight saving time will be extended in order to save energy. The new fall back date for the daylight saving period of 2007-2008 is:

Daylight saving time ends: Last Saturday of March at 11:59:59PM

Information is available via our Chilean web site at http://www.microsoft.com/chile/cambiodehora, "Extension del horario de Verano en Chile". Customers and partners will find additional information on this change and manual remediation at http://blogs.technet.com/latam/archive/tags/DST/default.aspx:

The default configuration for the time zone “(GMT-04:00) Santiago” in Windows Operating Systems does not reflect the new final date for the daylight saving time defined by the government. This bulletin summarizes the actions recommended for customers in Chile to address the extension of daylight saving time and mitigate its impacts.

Tags: Microsoft, Daylight Saving Time, Daylight Savings Time, DST.

Questions Regarding /PHYSICALMOVE

atsim — Wed, 19 Sep 2007 19:57:11 GMT

In preparation for a potential time zone move, customers may use the Outlook Time Zone Data Update Tool with the /PHYSICALMOVE switch, which has promoted some questions as noted here:

Q: Are there negative effects from running the tool multiple times on the same mailbox? (i.e., on the first pass, original time zone = Central & new time zone = Eastern; on the second pass, original time zone = Easter & new time zone = Central)

A: There should be no negative side-effects. In the example here, this would make sense if someone moved from the Central to Eastern time zone and then, some time later, moved back.

Q: Will the tool behave differently if there are appointments created using Blackberry, Live Meeting, OWA, etc…?

A: The intention is that all items are updated correctly.

Q: Can this switch be used when running the Exchange version of the tool?

A: Unfortunately, no. This is functionality that we did not include in the most recent release. Customers may run into issues related to new time zones, as may be the case in Venezuela (which is moving to a newly created time zone, -4:30 GMT - see DST Hot Topics and Latest News for more information). The recommended and supported way to move between time zones is using the client-side tool.

Q: I’ve tried researching internally and haven’t found much documentation on the /PHYSICALMOVE switch. Is there a brief overview of how it works?

A: At a basic level, the /PHYSICALMOVE switch is not that much different than rebasing with the Outlook Time Zone Data Update Tool: identify future items targeted at the source time zone and, if we detect that being in the destination time zone would affect their start or end time, update them such that they correctly reflect local time in the destination time zone.

Q: What is the correct syntax when a rebasing a second calendar in a user's mailbox?

atsim — Thu, 13 Sep 2007 06:23:00 GMT

Q: I have had this question come in from a customer around rebasing of calendars:

In the Knowledgebase article KB931667: DST using Outlook TZmove, the following is stated:

You can also rebase calendar items that are stored in additional calendars that may exist in a user's mailbox. For example, a command for rebasing the items in an additional calendar in a user's mailbox may resemble the following:

tzmove.exe -Q \\Mailbox - User\Second Calendar

When you rebase a public folder calendar or rebase an additional calendar that may exist in a user’s mailbox, the rebased items use the Sent on Behalf of message in the From field. Therefore, the updates do not change the owner of the calendar item. The updates appear to be from the account that rebased the calendar on behalf of the account that organized the meeting.

My question is about syntax of the command.

Which bit of the command do I change for the second user?

Example, if user Mary holds a second calendar for Joe then:

When Mary is logged in, is the command

tzmove.exe -Q \\Mailbox - User\Joe

tzmove.exe -Q \\Mailbox - Mary\Joe

or some other command string.

Seeing that we have a large number of PAs that have an even larger number of second calendars for bosses, meeting rooms and other resources, getting this command right is imperative.

What is the correct syntax please?

A: If the Calendar “Joe” is in Mary’s Mailbox and as a result is truly a “second calendar” in her Mailbox then the command is:

tzmove –q \\Mailbox – Mary\Joe

You can view the Application Event Log to verify that the command ran successfully by looking at the events that are logged for TZMOVE. You can also view the log file named “Outlook Time Zone Update.log” that is in the users %TEMP% folder to see detailed information about actions that tzmove performed.

[JS]

A previously cancelled Outlook meeting re-appears, and one hour off

atsim — Fri, 20 Apr 2007 17:56:00 GMT

Q: Can anyone explain the re-appearance of a cancelled meeting with a start time one hour off the original scheduled time? A previously cancelled meeting reappeared on my calendar (at the wrong time) and there are no meetings scheduled. I sent cancellation notices for an upcoming meeting that was set up before DST.

A: Sometimes cancelled meetings show up with a start time that is one hour off when a meeting wasn't cancelled correctly, it comes from a corrupted mailbox or from an old, undeleted mailbox. This is a known issue and end users may ignore these meetings.

Calendar appointments showing 1 hour later on recipients' calendar appointments

atsim — Mon, 12 Mar 2007 22:06:00 GMT

Symptom: Any calendaring client may show 1 hour later on a recipients' calendar appointment (Outlook, OWA, Blackberry or Goode devices etc.). The recipient will appear to not follow DST2007 rules. This is true even with OS patches are successfully applied even with rebasing successfully executed. Warning: If the system is not OS-patched or rebased successfully, the symptoms will appear similar to this issue (and the unpatched OS is much more common).

· Explanation: This is caused due to multiple copies of CDO.dll or CDOEX.dll existing on the Exchange and/or BES/Goode servers , and the copy of CDO.dll or CDOEX.dll is not being updated, but the applications (Outlook, OWA, Blackberry, Goode, etc) are using the older version of the dll. This can be created by several applications (unrelated to messaging potentially) which install or copy CDO.dll or CDOEX.dll to a separate directory, then register that rough dll.

· Solution:

o Determine if you have this specific issue,

§ please verify all patches and rebasing issues are successfully applied (for example is the OS clock correct, are meetings the user organized being rebased successfully). If the systems are not properly patched or rebased, the symptoms may appear similar.

§ Verify that if a user who is patched sends an appointment to another user who is patched, that the recipient user is showing that appointment one hour later than originator’s.

§ Search the Exchange server (and BES server etc) for multiple copies of CDO.dll or CDOEX.dll.

1 - Run this: C:\>dir /s cdo.dll

2 - Repeat for all drives.

3 - If there's more than one cdo.dll, you have a problem

Same for cdoex.dll

o Fix:

Exchange 5.5 (CDO.dll only - 5.5 does not use/ship CDOEX.dll)

(note - path to system32 may vary)

1 - c:\winnt\system32\cdo.dll is the correct CDO.dll. Delete all other copies of CDO.dll.

2 - regsvr32 "c:\winnt\system32\cdo.dll"

Exchange 2000/2003 CDO.dll

(again - paths may vary slightly depending on installation)

1 - c:\program files\exchsrvr\bin\cdo.dll is the correct CDO.dll. Delete all other copies of CDO.dll.

2 - regsvr32 "c:\program files\exchsrvr\bin\cdo.dll"

Exchange 2000/2003 CDOEX.dll

1 - c:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.dll is the correct CDOEX.dll. Delete all other copies of CDOEX.dll.

2 - regsvr32 "c:\Program Files\Common Files\Microsoft Shared\CDO\CDOEX.dll"

Time Zones not updating on Windows 2003, Windows XP or Windows 2000

atsim — Mon, 12 Mar 2007 01:31:00 GMT

After applying 931836 time zone changes don’t take effect until you manually change the time zone

Symptom: We have isolated reports that Windows 2000, XP, and 2003 may find that their Windows clocks do not move forward for DST, even with fixes applied from 931836 or 928388.

· Explanation: The root cause of this issue is still under research, but we believe we can attribute the issue to customers manually applying the time zone updates using the TZEdit application, referring to the steps in KB 914387. It appears that the registry appears to have been altered by some other means (this part is under investigation but could include not completing 914387 or modifying TZ parameters with TZEdit, or potentially malware detection software). This will be updated as research advances.

· Solution:

o Determine if you have this specific issue,

§ Is the OS’s system time not advancing for DST?

§ Open the Time/Date control panel applet and changing the time zone to a new time zone; hitting apply, and changing it back to the original time zone will often correct this problem. This provides confirmation the hotfix was applied, but seems to bypass the aspects involved which prevent the application of the hotfix.

Several customers have confirmed the script below addresses the issue, once it is confirmed to be this specific issue.

Detail:

You may see systems that have successfully applied the Windows DST2007 hotfix 931836 but are still operating on old DST rules after March 11. Opening the Time/Date control panel applet and changing the time zone to a new time zone; hitting apply, and changing it back to the original time zone will often correct this problem. If this is the scenario you are seeing, you can run the following script after the hotfix is applied to automate the process of changing the time zone and ensure that the system runs with update DST2007 rules.

Set objSh = CreateObject("WScript.Shell")

'Get the StandardName key of the current time zone

szStandardName = objSh.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardName")

'Enumerate the subkeys in the time zone database

const HKEY_LOCAL_MACHINE = &H80000002

Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

szTzsKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones"

objReg.EnumKey HKEY_LOCAL_MACHINE, szTzsKeyPath, arrTzSubKeys

'Step through the time zones to find the matching Standard Name

szTzKey = "<Unknown>"

For Each subkey In arrTzSubKeys

If (objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & subkey & "\Std") = szStandardName) Then

'Found matching StandardName, now store this time zone key name

szTzKey = subkey

End If

If szTzKey = "<Unknown>" Then

'Write entry to the Application event log stating that the update has failed to execute

objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer. Time zones failed to enumerate properly or matching time zone not found."

Wscript.Quit 0

End If

Dim process, processid, result, strUpdateCommand

Set process = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2:Win32_process")

'Add time change privilege to the process object

process.Security_.Privileges.AddAsString "SeSystemTimePrivilege",True

strUpdateCommand = "control.exe timedate.cpl,,/Z" & szTzKey

'Launch control.exe to refresh time zone information using the TZ key name obtained above

result = process.create(strUpdateCommand,Null,Null,processid)

If result <> 0 Then

objSh.LogEvent 1, "DST 2007 Registry Update and Refresh failed to execute on this computer. Unable to refresh the Timezone database."

Wscript.Quit 0

End If

'Get current display name of refreshed time zone

szCurrDispName = objSh.RegRead("HKLM\" & szTzsKeyPath & "\" & szTzKey & "\Display")

'Write entry to the Application event log stating that the update has executed

objSh.LogEvent 4, "DST 2007 Registry Update and Refresh has been executed on this computer." & chr(13) & chr(10) & chr(13) & chr(10) & "Current time zone is: " & szCurrDispName & "."

On the File menu, click Save As.

Select a destination, and then type refreshTZinfo.vbs in the File name box.

In the Save as type box, click All Files, and then click Save.

Another variation of this problem has been observed on Windows 2000. In that scenario after applying the DST hotfix or using TZEdit and then changing the time zone (manually or with the script above), the time zone still does not update. For that situation we’ve found that making the registry updates described in 914387 followed by running the script above will reliably cause the system to follow the new DST2007 rules. A symptom you may observe is that if you set the clock to the correct time, it will revert back to the incorrect time within one hour.

Additional information for reference:

Hotfix 931836 has three steps during the install:

1) Hotfix adds registry keys for new time zones, dynamic DST, and time zone version number

2) TZChange.exe updates existing time zones, and adds the values for the new time zones.

3) If the time zone being updated is the time zone the system is on, it calls the API function SetTimeZoneInformation() to update the information that the kernel reads at startup in the registry. After this, it updates a structure in the system that contains this information as well as send out a WM_SYSTEMSETTINGSCHANGE message to running applications

The first problem described above seems to be happing during step #3. Reasons for this failure may be related to security rights (this is still under investigation). The first two steps only require write access to HKLM\Software\Microsoft\Windows NT\CurrentVersion which by default is given to Administrators and Power Users. By default these same two groups have the “Change System Time” user right granted which is needed for step #3.

The following problems have been confirmed when installing the DST2007 patch KB931836:

1. Time Zones registry database was modified before the patch was applied. To check for this, export the Time Zones key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones) and compare it to a known unpatched system. The key can also be manually verified by checking the TZI value under an affected time zone subkey. The value is in the following C format.

        typedef struct _REG_TZI_FORMAT
        {
            LONG Bias;
            LONG StandardBias;
            LONG DaylightBias;
            SYSTEMTIME StandardDate;
            SYSTEMTIME DaylightDate;
        } REG_TZI_FORMAT;

The StandardDate and DaylightDate fields can be checked for the old or new DST rules.

2. Update.exe failing to run. In this case check if any Microsoft update package installs correctly. If other update packages also have problem then there is a problem with the update engine. Start with http://support.microsoft.com/kb/906602 to begin troubleshooting this issue.

3. Antivirus software interfering with install. Disable antivirus software on a test client and see if the install then works.

4. Incomplete registry update from TZEdit or OS patch (usually on Windows 2000). This can be permissions related. If following the steps from 914387 resolves the problem, this may be the cause of the failure.

The following problems have been confirmed on patched systems that display the incorrect time:

1. Client/Server based solutions such as Novell and Altiris may synchronize the client local clock with the server local clock. Ensure that the time server has also been updated with DST2007 patches.

2. Some third party applications that manually adjust the time may depend on the C run-time library. Ensure that machines that run such applications have been updated with hotfix KB 932590 (http://support.microsoft.com/kb/932590).

How do I find if an Outlook calendar has been rebased by the tools?

atsim — Wed, 07 Mar 2007 22:02:00 GMT

Q: How is it determined if a calendar update should be made?

A: Here are the steps on how to see if any items in a Calendar have been rebased. This should be done only on any items that the user is the organizer for.

1. Open MFCMapi (aka: MAPIEditor)

2. Expand the store that you are interested in. (This will assume a Mailbox store.)

3. Open Root Container, Top of Information Store, and then open the Calendar to display the list of items.

4. Click on an appointment to display its properties.

5. Scroll to the right of the Properties window and then click on Named Prop Name to sort by that column.

6. Look for:

0x825E (timezone that was used when picking start time)

0x825F (timezone that was used when picking end time)

If those properties are there on a single instance item then you can be sure that the appointment was rebased.

Stephen Griffin has detailed information on these MAPI props here: http://blogs.msdn.com/stephen_griffin/archive/2006/12/06/outlook-2007-timezone-structures.aspx

What do I 'poof' when appointments in OWA are off by one hour?

atsim — Tue, 06 Mar 2007 11:08:00 GMT

Q: We heard about an issue after rebasing where appointments in OWA may be off by 1 hour. He refers to an issue when you need to delete the cached expressions (aka poof the calendar). What is this?

A: Ther are occasions when OWA and Outlook have different ideas of when recurring meetings are in Calendar folder. In this case, one option is to poof the calendar. (For more on this, please see http://blogs.msdn.com/stephen_griffin/archive/2007/02/21/poof-your-calender-really.aspx.)

Poofing is resource-intensive on the server, so you should be careful how many mailboxes you update at one time. The larger the Calendar, the more time and resources it will take. (Please note that the POOF tool is not a supported tool. It is sample source that is provided as is without warranty.)