Exchange Resource Manager and Daylight Saving Time Change

The United States Government passed a law to add 3 extra weeks in March and 1 week at the end of October to Daylight Savings Time (DST). This change will affect all applications that provide automated calendar services. Microsoft has released a set of patches for Microsoft server and workstation software, such as Windows, Exchange, and Outlook.

Does ERM need to be updated because of the DST change?

NO. ERM is NOT affected by the DST change. The Exchange server provides time and time zone information to ERM. As a result, ERM does not require any patches or updates related to the DST change. If all the appropriate patches and tools from Microsoft are correctly applied to your organization’s servers and workstations, ERM should continue to process the resource meeting requests properly.

Even though you do not need to do anything to ERM, the process of applying the patches and running the rebasing tools is not a trivial task. Based on our own testing and Microsoft KB articles, we have some suggestions below to help update your resources managed by ERM.

Because Microsoft is continually updating their KB articles, we also recommend that you stay current on their recommendations prior to making the updates in your environment.

Note: If you have previously applied the Microsoft recommended patches and followed this procedure, no further action is required unless your computers exist in a nation, such as New Zealand, Australia that adopted new November DST rules after Microsoft’s initial release of KB931836. Please refer to the following links for updated procedures.

Microsoft DST Information
http://support.microsoft.com/gp/cp_dst

Microsoft DST Patch
http://support.microsoft.com/kb/933360

Rebasing Issue for Resources:

Per Microsoft recommendations, it is necessary to run the rebasing tools to ensure that existing meetings in the extended DST period do not have a start time one hour later than intended.

The rebasing tools will send updates to meetings on user calendars in sequence. As a result, if there are adjacent bookings on a resource calendar from two users, it is possible that the updated meeting request from one of the users will be declined.

Here's an example. UserA and userB have adjacent meetings on the calendar of an ERM-managed resource, confroom1, during the extended DST period.

userA: 8:00 AM – 9:00 AM
userB: 9:00 AM – 10:00 AM

Prior to running the rebasing tool, meetings may appear on the calendar an hour later than they are intended.

userA: 9:00 AM – 10:00 AM
userB: 10:00 AM – 11:00 AM

If the rebasing tools process userB’s mailbox first, meeting request updates will be sent to meetings on userB’s calendar. An update meeting request from userB will be sent to confroom1 for 9:00 AM – 10:00 AM.

However, since userA’s booking has not yet updated on the confroom1’s calendar, ERM will detect a conflict and decline the updated request originating from userB’s calendar.

Solution:

To prevent existing meetings from being declined by ERM-managed resources while they are being updated, set the "Show time as" setting to "Free" for meetings on the resource calendar during the extended DST period. This ensures that ERM accepts updated meeting requests coming from users' calendars. When ERM accepts the updated request, the "Show time as" is reset back to "Busy". Based on testing and Microsoft recommendations we suggest the following steps below while applying patches and rebasing meetings:

1. Apply Server patch KB933360 Replaces (931836)
2. Apply Workstation patch KB933360 Replaces (931836)
3. Apply Exchange CDO patch KB926666
4. You may need to also apply KB932599
5. Ensure that all affected meetings on the ERM-managed resource calendars in the extended DST period have their "Show time as" set to "Free". To help automate this, you can download a free script¹
   Only Bmeetingv4_2.vbs is necessary for the November DST Change.
6. Run the rebasing tool (MSEXTMZ.Exe) against the Exchange server, rather than the Outlook Time Zone Tool (TZMove.Exe), for all events (recurring/single)

These steps complement the Microsoft guidelines for handling the impact of the DST changes. You can find more information about it at:
http://support.microsoft.com/gp/dst_topissues.

You can also find several posts on http://msxechangeteam.com that discuss DST changes. Please note that testing was done with Window 2003, SP2 and Exchange 2003, SP2.

As an alternative to "Step 3", the ExMerge utility can be run on the resource mailboxes in archive mode to clear the resource calendars of meetings in the extended DST period. For more information, reference http://msexchangeteam.com/archive/2007/02/16/435404.aspx

If you feel you would like further assistance with DST issues, Simpler-Webb offers a full range of Microsoft server management and consulting services. We can assist with DST related issues for a fee. Please contact us for availability.

Steps for running the script:

1. Create a domain user account will full control over the Exchange server. This is necessary to ensure that the script is able to update the calendars of all ERM-managed resources.
2. Login to the Exchange server with the newly created account.
3. Create the following folder: C:\Temp.
4. From a command prompt, run the following two commands:

   Examples used - w2k3mbr is the Exchange server and confroom1 is name of the resource.

   bmeetingv4_1.vbs w2k3mbr confroom1 – to change the status of meetings in the March delta period

   bmeetingv4_2.vbs w2k3mbr confroom1 – to change the status of meetings in the October delta period

5. The script will attempt to set the free/busy status of all existing meetings to free on confroom1’ s calendar. For recurring meetings with instances in the extended DST period, the free/busy status will be set to free for all instances including those that fall outside the window. When updates are sent by the rebasing tool, these will reset to appear busy.
6. In order to view the list of all update meetings, a .htm log is created in the C:\Temp directory for each mailbox that is updated.

Process Limitations:

1. Update requests for existing meetings can still be declined if users attempt to send new meeting requests after the patches are applied and before existing meetings are rebased.
2. If certain instances of recurring meetings were originally declined due to conflicts, there is a possibility of these instances getting accepted during rebasing. This can cause meetings originally accepted to be declined during the rebasing process.
3. There still may be issues with meetings as the complexity of the issue has made it very difficult to ensure 100% automated correction.
4. There are other issues with installing the server patches. These are covered in the Microsoft documentation:
   
   1. Issues with msExchMasterAccountSid preventing mailbox stores from mounting
   2. Issues with permissions if upgrading from a version of the Exchange store prior to 7650.23 (see kb 932599)

Note:

Microsoft is in the process of releasing an updated version of the rebasing tool for resource mailboxes.

Credits:

¹Thanks to Glen Scales http://gsexdev.blogspot.com/ for providing the script.

Questions or Comments: Contact us