Prior to Exchange 2007 SP1 an article was published with some specific guidance related to handling time zones in calendar item tasks.  Contrary to Best Practices for Using Exchange Web Services for Calendaring Tasks, specifying just a MeetingTimeZone TimeZoneName when creating a CalendarItem appears to work in Exchange 2007 SP1 and later.  The best practices says not to submit the TimeZoneName in MeetingTimeZone because it will be ignored, though there is a hint that this might not apply to Exchange 2007 SP1:

“Do not supply the optional TimeZoneName element when you create calendar items. In the initial release version of Exchange 2007, the TimeZoneName element is ignored on incoming requests.”

However, take the following request which properly creates a CalendarItem in the Eastern time zone:

        <t:CalendarItem>

          <t:ItemClass>IPM.Appointment</t:ItemClass>

          <t:Subject>Appointment in Eastern Time</t:Subject>

          <t:Start>2009-06-26T09:00:00.000</t:Start>

          <t:End>2009-06-26T09:30:00.000</t:End>

          <t:MeetingTimeZone TimeZoneName="Eastern Standard Time">

          </t:MeetingTimeZone>

        </t:CalendarItem>

From the best practices, the following statement intends to confirm that TimeZoneName is not ignored in Exchange 2007 SP1 and can be used by itself to define a time zone:

“In Exchange Server 2007 Service Pack 1 (SP1), BaseOffset is an optional element, and supports MeetingTimeZones that specify the TimeZoneName only.”

This is quite true in fact, were in Exchange 2007 pre-SP1 specifying the offset elements was a requirement and TimeZoneName was ignored; in Exchange 2007 post-SP1 the TimeZoneName is actually the preferred method for declaring a time zone.  Furthermore, offset and transition values should only be set when specifying a custom time zone.  Otherwise, standard time zones should be specified using TimeZoneName which is the name of the time zone as it appears in the registry key name on the Exchange CAS server.  Then the Exchange server will pull the transition and offset information from the registry for the time zone you specified.  Here is an image showing where the registry keys are:

Bottom line, with Exchange 2007 SP1 don’t specify time zone offset and transition values for known time zones – use the TimeZoneName instead.  This will help your application work seamlessly with any updates to known time zone definitions in the future.

Earlier I linked to a post by Henning Krauses which discusses searching for a meeting using the UID and GlobalObjectId properties.  The point of UID is to provide a unique identifier for a meeting across the calendars each attendee to the same meeting.  Henning gave some expert advise for using GlobalObjectId instead of UID in a FindItem request to locate instances of a recurring meeting in different user’s calendars.  As noted in his article, in Exchange 2007 pre-SP2 the UID property is built from GlobalObjectId – he even shows how to convert from UID to GlobalObjectId.

Using GlobalObjectId poses a problem however…If you were to create a recurring appointment and invite one attendee for only one instance of that recurring appointment that attendee ends up with only the one exception instance of the parent recurring appointment in their calendar.  This is called an “orphaned” appointment.  This type of appointment’s GlobalObjectId has additional information in it related to the exception date (for more information look at PidLidGlobalObjectId in MS-OXOCAL).  The bottom line here is that this orphaned instance in this one attendee’s calendar will have a GlobalObjectId, and therefore UID, which doesn’t match the related appointments in the other attendee’s and organizer’s calendar.  Henning’s code won’t work in this specific scenario…

So what now?  Is this a bug in Exchange?  Is there another property Henning could use?  The answer to both questions is, yes!

There is another property, CleanGlobalObjectId, which was defined just for this scenario.  If you look at the documentation for this property, the remarks confirm that this property specifically addresses the issue described above:

“The format of this property is the same as that of LID_GLOBAL_OBJID ( PidLidGlobalObjectId). The value of this property must be equal to the value of LID_GLOBAL_OBJID, except the YH, YL, M, and D fields must be zero. All objects that refer to an Instance of a recurring series (including an orphan instance), as well as the recurring series itself, will have the same value for this property.”

So all Henning needs to do in his sample is change it to use the CleanGlobalObjectId instead of GlobalObjectId.  Now, it would be logical to assume that Exchange should base the UID property off of the CleanGlobalObjectId too instead of GlobalObjectId.  In fact, we’ve done just that.  In Exchange 2007 SP2 UID is based on the CleanGlobalObjectId instead of GlobalObjectId.  Because SP2 just came out and many customers may wait to install it because of the schema changes you’ll want to keep the workaround above in mind when working with GlobalObjectId and UID in Exchange Web Services.