If you're just looking to use MFCMAPI to get in to the RSG, head on over to Jesper Bernle's blog where he gives step-by-step instructions. Otherwise, read on.
I promised I'd talk about accessing the Recovery Storage Group (RSG). The RSG is a neat trick we allow starting in Exchange 2003 where you can restore a copy of a database in your production environment without taking your user's mailboxes offline. This allows you to recover e-mails, archive, run discovery, etc. The concept is discussed in depth here: http://support.microsoft.com/kb/824126
Up until the February 2008 update to MFCMAPI, though, you couldn't use MFCMAPI to get into the RSG. In fact, a lot of people were convinced that MAPI couldn't be used to access the RSG at all! Of course, that can't be true, given that ExMerge, which is written entirely in MAPI, has no trouble getting in there. A customer asked Dave and I what the trick is, and that led to this article.
Let's look at what happens when you try to get into an RSG mailbox from MFCMAPI. Assuming you've read Jason's blog on the subject, you might try the following steps:
Sounds great. Doesn't work. When you open the RSG mailbox this way, you get the regular mailbox instead. Why? Because when you do this, MFCMAPI grabs the DN of the mailbox from the PR_EMAIL_ADDRESS column and passes that to CreateStoreEntryID. And PR_EMAIL_ADDRESS for the regular mailbox is the same as the PR_EMAIL_ADDRESS for the RSG mailbox, so we're always going to create the same entry ID.
So how does ExMerge it do it? Is it using secret magic? Yep! It goes through a very complicated procedure to build a MAPI profile that points to the RSG. However, all that work really results in an entry ID that has special flags set on it to tell Exchange that the mailbox we want to open isn't the regular mailbox but instead the RSG version of the mailbox.
I *could* go into the stuff that ExMerge does in building its profile, but it turns out getting into the RSG is much easier than that. Those flags set on the entry ID that ExMerge got can be set by hand using the ulFlags parameter of CreateStoreEntryID! And since using CreateStoreEntryID is always preferable to building a new profile, that's all I'll talk about here. :)
Here's the key flag, already listed in edkmdb.h:
#define OPENSTORE_RESTORE_DATABASE ((ULONG)0x00100000)
When you set this flag, it tells emsmdb32 and the Exchange store you're interested in getting the RSG version of the mailbox. Of course, life isn't ever this simple. You have to set some other flags too, most notably OPENSTORE_USE_ADMIN_PRIVILEGE, which tells the store you want to be treated as an administrator, assuming you have permissions. I have found the following cocktail to work the best:
OPENSTORE_USE_ADMIN_PRIVILEGE | OPENSTORE_TAKE_OWNERSHIP | OPENSTORE_RESTORE_DATABASE |
OPENSTORE_OVERRIDE_HOME_MDB | OPENSTORE_HOME_LOGON = 0x10001D
Now we see what the new feature I added to MFCMAPI allows you to do - instead of double-clicking on the mailbox in the table, we can right click and pick "Open with Flags", enter the flags we wish to use (0x10001D) and we're in like Flynn!
[Update: 2/18 - add note clarifying this is Exchange's MAPI only]
[Update: 6/20 - Added link to Jesper's excellent how to article that puts this information into practice]
The February 2008 Release (build 184.108.40.2064) is live: http://www.codeplex.com/MFCMAPI
Here's the change list - see the Issue Tracker on Codeplex for more details, or look at the code: