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.