Share via

Recovery Storage Group: It's Not Just For ExMerge

  • Article

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: https://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:

  • 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:

 #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!

Notes:

  • 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: https://msdn2.microsoft.com/en-us/library/ms878582.aspx. 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

  • Anonymous
    February 26, 2008
    The comment has been removed

  • Anonymous
    February 26, 2008
    The comment has been removed

  • Anonymous
    February 27, 2008
    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 {}.

  • Anonymous
    December 15, 2008
    Any chance you might explain the other flags of CreateStoreEntryID? I find some VERY interesting one in the EDK: OPENSTORE_XFOREST_MOVE OPENSTORE_ALTERNATE_SERVER 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' -Eriq

  • Anonymous
    June 15, 2009
    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? Thanks.

  • Anonymous
    June 15, 2009
    The comment has been removed

  • Anonymous
    March 14, 2011
    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.