Outlook 2010 Update Butchers Shared Folder IDs
(Note that this was originally posted June 22nd, 2011)
Earlier this year, I observed a startling change in how Outlook 2010 reports the Entry IDs for shared folders. Providing the value returned for the folder’s Entry ID in any OpenEntry-based method will result in failure; specifically, the MAPI_E_INVALID_ENTRYID error will be thrown at us. Opening MAPI folders based on their Entry ID can be considered to be a very common action taken by software running in Outlook-space, so introducing a breaking change for this functionality is very troubling and jarring in terms of stability. The strangest thing about all of this is that this issue used to not occur with Outlook 2010; rather, it seems to only have started since sometime early 2011. If an update is responsible for introducing this problem, the specific update responsible has not been identified (by myself at least).
In this article I provide some information on this issue, give a theory as to its cause, and present some viable workarounds (I highly doubt this will be fixed).
Setting the Stage
The term “shared folder” is used by this article to refer to another user’s calendar that You are given access to by that user. The access is given a number of ways, one of them being by setting you up to be a delegate for them.
A shared folder, like many other objects in the world of MAPI, exposes an identity-purposed property named PR_ENTRYID. The term “Entry ID”, when used by this article, refers to the value that the folder’s PR_ENTRYID property is set to.
Who Cares About a Shared Folder’s ID?
The Outlook Object Model does not always provide the information we need — this should not be news to any of you.
For example, let’s say we have a Folder object which represents a shared folder we have access to. We want to know what kind of access we have to the server (are we an Editor, an Owner, or something else?), which requires looking at the folder’s Access Control Lists. The Outlook Object Model does not provide us with a folder’s Access Control Lists, forcing us to use a different interface, one that’s closer to the metal of things.
We elect to use Redemption’s RDOFolder. Of course, obtaining an instance of an RDOFolder object requires passing the folder’s entry ID (and store ID — always a good idea although optional) to a Redemption session object. MAPI_E_INVALID_ENTRYID will be returned, because the Entry ID seems to be (admittedly) not normal at all!
So What’s Up with the Shared Folder Entry IDs?
Typically a folder’s Entry ID is not very long — in a normal Exchange environment I wouldn’t expect much more than around 46 double words in size (that number is an empirical conclusion — nothing official on that). Accuracy be damned, the point is that they are not very large. Ever since this issue started appearing however, the Entry IDs being returned are much larger. The one I’m looking at now is 284 double words when it normally is 46 double words in size.
The error we were getting when attempting to use the entry ID (MAPI_E_INVALID_ENTRYID), was very appropriate. Our issue on our hands here is that Outlook 2010 (from our perspective) returns invalid shared folder Entry IDs. Microsoft may have a say on what’s valid and not valid, however the Entry IDs being returned simply don’t work when they’re used as Entry IDs. Simply put, an update to Outlook 2010 has butchered shared folder IDs. To clarify, the shared folder’s Entry IDs are the same and not affected at all by the update, however the values being reported to us by Outlook are.
What is the extra information in these “Entry IDs” that is taking up so much space? Instead of the “Entry ID” just containing the Entry ID, you will find that the MailboxDN for the user that owns the folder is now appended to the “Entry ID”. But that’s not all. We also see a strange rendition of the owning user’s display name (with a single pair of empty words between each letter) appended to the MailboxDN.
Alright — you may be thinking already: “That’s great and all, but can’t we put this all behind us if we separate the MailboxDN and strange display name from the rest of the ‘Entry ID’”?
Nope. Here’s the great part: There appears to be nothing actually resembling the real Entry ID inside this “Entry ID”. If you remove the MailboxDN and display name portions, you will be left with an entry ID that is also invalid. Someone please correct me if they discover this to not be true, or if they figure out a way to use this — it would make “going forward” much easier.
One good thing to note is that this issue doesn’t affect your personal Exchange store. The Entry ID reported for your personal calendar will look and act as folder Entry IDs should and always have.
Why Have Shared Folder Entry IDs Been Reduced to Garbage?
Comparing the way Outlook 2010 now reports Shared Folder Entry IDs to garbage is very appropriate, in my opinion. I can find no official announcement or any update notes relating to this change. At the same time, this does not smell like a bug to me. What it smells like to me is the intentional inclusion of additional information within an existing data field in order to make possible some new internal functionality known only to Microsoft. The fact that this happens to break lots of software being hosted by Outlook is merely a side effect.
I’ve tossed theories back and forth with my peers, and one of the more interesting theories I’ve heard is that perhaps Outlook 2010 performs additional caching and local storage of non-personal messages stores, and that additional identifying information as far as the owner and physical location of the folder on the server are required for proper operation.
Workarounds for this Issue
After some experimentation, I have found a viable workaround for this issue.
Before I present it however, let me tell you right off the bat that the following workaround does not work for any and all sessions that are in online mode. What that means is that this workaround will not work for you if the active account has “Cached Exchange Mode” unchecked in their account settings.
Don’t forget that this also means (since the issue revolves around shared folders) that even if “Cached Exchange Mode” is checked, the “Download Shared Folders” setting must also be checked in Account Settings -> More Settings -> Advanced. If “Download Shared Folders” is not checked, you will be accessing your shared calendars in online mode (even though you’re accessing your personal stores using cached mode).
So, “Cached Exchange Mode” and “Download Shared Folders” must both be checked for this to work. Luckily, both settings are the default settings, but how common are they in the real world? Though I do not have hard data, my experience with many well-known organizations tells me that the default settings are the most common. Cached mode eases the burden on the network as not as much bandwidth is required for a seamless user experience. However, there are real world reasons as to why a large organization would want to disable cached mode. One example is in regards to hardware conservation; disabling cached mode reduces the amount of hard drive space Outlook will consume. It may be more cost efficient for some organizations to use online mode instead, as they can forego large hard drives for their users.
If I discover a solution that supports online mode, I’ll post another article.
So make sure your code takes the proper precautions by not only checking if the current session is using cached mode, but also that “Download Shared Folders” is checked. Checking the status of “Download Shared Folders” is actually not exactly trivial, so I may decide to share with you all how to do this someday.
Get to the Point Man!
Instead of using PR_ENTRYID to get the shared folder’s entry ID, you will want to use an alternative property. I could not find much (or any) official documentation on what this MAPI property actually is meant to do, but I can say that it will return valid and working Entry IDs for you to use to open up those pesky shared folders.
The MAPI property you want to use is PR_PUBLIC_FOLDER_ENTRYID. The hex tag for this property is 0x663C0102.
The reason why you must be in cached mode is because this property is not available in online mode, which is a strange thing by itself. I say that because there is typically a much larger amount of information available for our consumption when retrieving objects in online mode as opposed to cached mode, given the more limited nature of the cached storage provider.
Unfortunately, if you need to support online mode as well — I cannot help you, as no workaround is known to me. If you know of one, please share it; it would be much appreciated. Fortunately, this issue only occurs with Outlook 2010. If it was happening with previous versions, this would’ve been a larger issue since some versions cannot access shared folders in anything other than online mode.
