Back when Outlook 2003 shipped, we were looking for ways to reduce the number of calls we made to the server. One optimization we found was to include the FQDN of the server in the entry ID for an Exchange store. In some situations, this eliminated the need to call back to the server to get a referral. However, this also had two side effects:
Now - technically, 2 shouldn't be a concern because we all know you're supposed to use CompareEntryIDs when comparing entry IDs (hence the name of the function). However, wouldn't it be nice if you could get the old style entry ID for scenarios where you're space constrained, or want to avoid the potentially expensive CompareEntryIDs call? Now you can. Whenever you want to ask for PR_STORE_ENTRYID, you can ask for PR_STORE_ENTRYID_EMSMDB_V1 instead. It's defined as follows:
#define PR_STORE_ENTRYID_EMSMDB_V1 PROP_TAG(PT_BINARY, 0x65f6)
This will return the "old style" entry IDs that we used to use back in Outlook XP. They're still valid now, though using them to open a mailbox may incur some additional RPCs if a referral is required. Also note that while you can memcmp two of these style entry IDs to see if they're equal, you should not interpret a difference to mean they point at different mailboxes. To determine that they're truly different you'd still need to use CompareEntryIDs.
Some other things to keep in mind: If you're in cached mode, to ask for PR_STORE_ENTRYID_EMSMDB_V1 you have to bypass the cache using MAPI_NO_CACHE in your GetProps call. Also, in case the property isn't available, your code should fall back to PR_STORE_ENTRYID. Finally, only Outlook 2003 and higher's version of MAPI supports this property.
I picked up a case a few weeks ago that had a simple question in it. "Are MAPI's profile APIs thread safe?" My answer, of course, was "As far as I know - why do you ask?". The reason they asked was because they had built a framework to encapsulate all of their MAPI operations (a very good idea) and they were seeing "issues" when they ran the profile configuration portion of that framework through their multithreaded test harness.
At first, I had a little trouble pinning down what they meant by "issues" - did they mean hangs? Crashes? Random error codes? Actually - it was all of the above. I got some dumps and traces from them and found 2-3 distinct problems with the way MAPI and some of the providers behave in an non thread safe manner during profile configuration/deletion. When I started running my own tests, I found a few more.
Now - I've always understood MAPI and the providers we ship to be thread safe. Sure, there are the occasional issues, but we usually can fix them. We go to a lot of trouble to make sure MAPI behaves correctly across multiple threads. But apparently all of this work, and all of our testing, was under the assumption that the profiles had already been created. I dug back through records of cases I had worked as well as bugs which have been filed against MAPI and found only one case where someone had configured profiles from multiple threads. And on examining that case, I saw that it was from the days before we routinely had multiple processors. Most of the threading issues I was seeing would be much harder to reproduce on a single processor.
I took the list of issues we found back to development to see what they thought we should do about this. The issues we found were in both Outlook and Exchange's implementation of MAPI (they predate the split), meaning we had a long road ahead of us if we started fixing the problems. And even if we assume we fixed every issue we found, we were certain to find that those issues were hiding other, nastier issues.
So we decided that the best course of action here would be to declare MAPI's profile API's not to be thread safe. All MAPI profile configuration should be serialized. This applies to both Exchange and Outlook's implementations of MAPI and all versions, including the MAPI download.
Here are the APIs you'll need to serialize as a MAPI client: