Using Recovery Storage Groups where the primary mailbox has been purged from the store…
This is an interesting little subject (well it was for me anyway), I have been working with a chap called Phil in the MSExchange forums on how to recover data from a recovery storage group (RSG).
Initially Phil was having some problems getting the Store Database to recover to the RSG (this he was doing in a test lab), however after some troubleshooting we managed to get the database to restore to the RSG, however, Phil could then not use the ESM to merge the data back into the users mailbox in the Primary Store by using the “Recover Mailbox Data” task from the ESM or by using EXMERGE
Initially I focused on why EXMERGE could not export the data from the RSG that Phil had, so I asked to post the EXMERGE.log file – upon reviewing the file I saw the following entry:
![]()
I discussed this with Phil as I had already begun to suspect that we were dealing with a mailbox GUID issue (the GUID of the mailbox in the RSG does not match the GUID of the user in AD, therefore neither the ESM or EXMERGE will be able to see the mailbox in the RSG as a recoverable item).
Phil explained to me that the user account in AD had been deleted and the mailbox had been purged from the original store – ah hah! this is why we cannot get any back with either the ESM or EXMERGE.
Before we proceed I think a little explanation is in order;
Exchange Mailboxes normally exist in one of the three states –
- Connected (The mailbox has an associated AD account which contains the correct msExchMailboxGUID)
- Disconnected (The msExchMailboxGUID is not allocated to any Exchange user)
- Purged (The mailbox and all its contents are no longer located in the Database – you can only purge Disconnected mailboxes)
If a mailbox exists in a disconnected state then programs like EXMERGE cannot login and extract (or import) data.
Although technically mailboxes in a RSG are disconnected by default, they are linked to mailboxes in the original store via the msExchOrigMDB attribute and the mailbox GUID if a mailbox exists in the original store with the same Mailbox GUID then EXMERGE will work.
Now if you read a number of Microsoft articles on the web they will tell you that if the Mailbox has been purged from the Original store, then your only option is to restore the database from Backup, or use the recovery storage group to Mount the Database and then perhaps cut over the mounted Database files to the normal and correctly name storage group – all of which is a little messy, so the following is what I worked through with Phil, from now on all examples will be from my home Lab;
Firstly what I did was create an account with a mailbox called “Andy.Grogan” in my lab environment, I then added in some data to the mailbox (an old pst that I had lying around) using EXMERGE.
I then took a backup of the Information Store (using NTBackup) – I then deleted the “Andy.Grogan” account from AD and purged the mailbox from the Information store.
So I am now in the position where I need to recover the mailbox to the Information Store, but I have deleted both the original account and the purged the mailbox (exactly the position that Phil was in).
Step 1 – Restore the backup of your Information Store to the Recovery Storage Group
In order for this step to work you will need to have a freshly created recovery storage group, with the Database that you intend to restore added – this will create a unmounted Database in the location that you specify – do not mount this database until you have completed the restore.
Ensure that you normal mailstore does NOT have the check box “The Database can be overwritten by a restore” checked – this is very important.
The following is the process that I used to restore the IS data to the RSG:
Open NTBackup and select restore (at this point the original store should STILL be online, and the RSG created with the databases added - but this should be off-line (also ensure that the “this database can be overwritten by a restore is set on the RSG Database ONLY).
Select the restore tab (do not worry about the Restore Files to saying original location), and choose your backup set - then click on start restore.
You will be asked where to restore to (leave this as the server you wish to restore to should be configured) then set a path for the transaction logs and patch files If you do not intend to restore addition logs tick the box that says “Last Backup Set” - then click ok.
The restore will then process (you will not be asked anything about the RSG).
When the restore has finished - wait a few minutes then mount the RSG.
If you get an error message when mounting the RSG database, ignore it, wait a couple of minutes then try again (it relies on Directory Replication).
When you have completed the above and mounted the RSG you should see something similar to the example below showing in the ESM:

If you attempt to use the ESM to recover the mailbox data for “Andy.Grogan” using the “Recover Mailbox Data” wizard you will get an error at the end of the process – this is due to the fact that the original mailbox does not exist in the store.
Step 2 – Configure the GUID using EXMERGE
What we need to do now is recreate the “Andy.Grogan” account and Mailbox in the original storage group – do this by using ADUC – please ensure that the account naming (for example, mailbox alias and account name) are the same, you do not need to worry about passwords.
We should now have our account created – but at this stage we are still not in a position to restore data, what we need to do is run EXMERGE against the RSG which will fail – this is expected, because it will create a log file that contains a very important piece of information – the original GUID of the Mailbox.
Run EXMERGE – choose the Extract or Import (Two Step Procedure).
When asked choose step 1 (Extract data from an Exchange Server Mailbox), when ready click next and complete the information about your Exchange Server and Domain Controller.
On the next screen tick the box which corresponds to your RSG – an example is below:

Click on the next button, EXMERGE will then go an enumerate the RSG store – you will receive an error message about some mailboxes not being able to be displayed, the screen will then change again to list the mailboxes that you can export from – you should note that the Andy.Grogan (or the Mailbox that you are working with) is not there – the following is an example of what you might see:

It is at this point that you can click on the cancel button, as enough data will have been written into the EXMERGE log for us to proceed.
Step 3 – Configure the new account in AD with the msExchMailboxGUID of the old account
This is where is gets really cool, what we need to do is open up the EXMERGE.log file (which is located typically in the same directory as EXMERGE).
Scroll down to the bottom of the log and you will see an entry which looks like the following:
Error! Cannot identify the user with the msExchMailboxGuid \A48\1F\2EB\1E\1BB\B8R\B1jO\15\A8f. The legacyExchangeDN is /O=COREGENDYN/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=ANDY.GROGAN.
The part of this that we are interested in is the \A48\1F\2EB\1E\1BB\B8R\B1jO\15\A8f (remember there is chance that this string will be different on your installation) this is the ASCII representation of the GUID, what we need to do here is convert this into readable form for the ADSI edit program.
Firstly remove all of the trailing slashes from the string (but maintain the spaces) – like so: A4 08 1F 2EB 1E 1BB B8R B1jO 15 A8f
Now what you should notice about the above is that we some groups of 2 digits, some groups of 3 and some of 4 – for the groups of 3 digits we need to count in two from the left and place a space between the right most digit and in the case of a group of 4 we need to put a space between the first two most digits and a space between the last two – like so: A4 08 1F 2E B 1E 1B B B8 R B1 j O 15 A8 f
What we have to do now is substitute all of the single spaced digits for their HEX values – so you will need a ASCII to HEX converter (there is a good one here) remember that lower and upper case letters have a different Hex value, therefore case is very important.
Looking at the example above we are going to convert the value for B,B,R,j,O and f – when you have done this your string should look like the following: A4 08 1F 2E 42 1E 1B 42 B8 52 B1 6A 4F 15 A8 66
Just in case you are a little wolly on what we just did, below is an example of the ASCII to HEX conversion that we have implemented:
(B=42,R=52,j=6A,O=4F,f=66)
Now that we have done the conversion we are left with what is the old msExchMailboxGUID of the account that we deleted (cool huh?) what we now need to do is set this attribute on the new account that we created for “Andy.Grogan” (or your account) in AD – for this will will need ADSIEDIT which can be installed from the Support\Tools folder on the Windows 2000/ 2003 CD-ROM or can be downloaded from HERE
When you have ADSI edit installed open it an navigate to the account that you are working with (or the “Andy.Grogan” account) – the following is an example of how to do this:

You should note that in order to change to AD Attribute values for accounts using ADSI edit you will always be in the Domain partition – however the location of the accounts can vary depending on your OU structure – in the example that I have given the user is in the default “Users” container.
When you have found that account that you are working, right click the entry in ADSI edit and select “Properties” and you will be presented with the dialog box which looks like the following:

You can un tick the “Show Mandatory Attributes option” and tick the “Show only attributes that have values” then from the section entitled “Attributes” you will need to find the msExchMailboxGUID entry (see example above) when you have located it click on the “Edit” button and you will be presented with a screen that looks like this:

What you need to do is copy the A4 08 1F 2E 42 1E 1B 42 B8 52 B1 6A 4F 15 A8 66 into the “Value” area that is provided and then click OK, then click Apply and OK again then exit ADSIEdit.
You will now need to Restart the MSExchangeSA service on your Exchange Server (note this will dismount the Recovery Storage Group DB).
Step 4 – Get the Data back to a PST using EXMERGE
After the MSExchangeSA has restarted (you might have to Mount the RSG Store again) open up EXMERGE and run through the process as detailed previously in this article – but when you get to the list of mailboxes in the RSG you will see that our mailbox is now there! (see below):

Select it using EXMERGE and perform a normal export to PST file.
When the export process from EXMERGE is completed we need to configure the “Andy.Grogan” account in AD.
We need to do this because as we changed the msEXCHMailboxGUID it disconnected the account from the mailbox in the store.
Open ADUC (Active Directory Users and Computers) and find the account that you are working with (or the “Andy.Grogan” account in the examples that we have been using) right click on it, select “Exchange Tasks” and then choose the “Remove Exchange Attributes” option (see below for an Example):

When we have done this we will need to recreate the users mailbox – to do this right click on the account and choose “Exchange Tasks” and then choose the “Create Mailbox” option then go through the process of establishing the users mailbox.
When you have done this, open EXMERGE again running through the “Extract or Import” – only this time ensure that you choose “Import data into an Exchange Mailbox” – run through the Wizard for importing the PST into the account that we created earlier – and voila! – data restored.
Add this page to your favorite Social Bookmarking websites
Last Updated (Wednesday, 30 December 2009 13:23)





