Recovery Storage Group: It’s Not Just For ExMerge

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:

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:

  • Log on to an administrator profile

  • Pick MDB/Get Mailbox Table

  • Paste the GUID of the RSG into the "Mailbox Storage GUID" field

  • Pick IID_IExchangeManageStore5 from the drop down

  • Confirm that the statistics reported in the various columns of the table what was restored into the RSG

  • Double-click the mailbox to open it.

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:


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:


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!


  • If you want to read more on CreateStoreEntryID and the ulFlags parameter, take a look at the old 5.5 EDK documentation.

  • The caveats listed in 824126 about when ExMerge can or cannot get into the RSG apply the same to MFCMAPI or your own MAPI code. They are limitations on the store side.

  • I updated MFCMAPI to allow you to specify flags on nearly every code path that uses CreateStoreEntryID. So "Open Mailbox With DN", "Open Other User's Mailbox" and "Open Public Folder Store" all allow you to pass flags. This should simplify experimentation.

  • There's an Exchange 2003 SDK article that claims to explain how to access the RSG: Everything in it is correct except the section titled "Programmatically Accessing a Recovery Storage Group", which is totally wrong. Sorry about that. Consider this post an attempt to correct that article.

  • The RSG can only be accessed by Exchange's MAPI, including the MAPI download. Outlook's MAPI doesn't know about the OPENSTORE_RESTORE_DATABASE flag and will reject it with MAPI_E_UNKNOWN_FLAGS. Outlook (and OWA) cannot be used to access the RSG.

[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]

Comments (7)

  1. Alberto says:

    Thank you Stephen, Great article!

    Would be great if you could explain how exmerge creates that special profile… I would love to be able to access a mailbox in a RSG of a user that does not exists in AD anymore… exmerge cant do it 🙁

  2. Daniel says:

    "Paste the GUID of the RSG into the "Mailbox Storage GUID" field"

    is it the GUID of the RSG or the ObjectGUID of the Information Store?.. I´ve tried with those and the ObjectGUID of the Stores… GUID Invalid :(..  (I got the GUIDs from ADSIEdit)

  3. Alberto – It’s not a limitation of ExMerge – the store won’t let you into the RSG mailbox in that scenario. So knowing how to create the profile won’t help. If you want to learn how to create the profile though, let ExMerge create one and then compare.

    Daniel – it’s the guid of the RSG. If you’re testing with MFCMAPI, make sure you include the {}.

  4. Any chance you might explain the other flags of CreateStoreEntryID?

    I find some VERY interesting one in the EDK:



    OPENSTORE_OVERRIDE_HOME_MDB, more specifically the doc reference to ‘You cannot create multiple mailboxes on different servers for a single user, unless you specify this flag’


  5. Lev says:

    Steve, is there a chance that Outlook MAPI would be aware of RSG?  One might want to be able to access RSG from Outlook MAPI especially if one wants to arhive data to Unicode PSTs.  Would opening a case help?


  6. You could try passing the OPENSTORE_RESTORE_DATABASE flag and see if it works, but I’m pretty sure Outlook’s MAPI will reject the flag as invalid. Edit: Should have said “no – as I said in the article, Outlook doesn’t know the flag”.

  7. Just noticed that Jesper's article is now gone. If anyone knows where it may have been mirrored, let me know and I'll update my link.

Skip to main content