Nasty. That's a good word to use when describing the process of restoring a Microsoft Exchange database. Sure, there are options provided that in theory make the process pretty easy but there are occasions when these options don't do the job by themselves.

I had a situation recently where I was asked to restore a user's mailbox that had been deleted. Their Active Directory account had also been deleted which means that the default restore options don't work properly (they require that the user still exists when the restore is done). I'll try and sum up what I had to do and the steps I took to get the mail back. Note that all this was done without the production copy of the database being taken down, changed or harmed in any way.

The backup software used for this was Symantec's Backup Exec 11d - these steps aren't specific this software and should work with any software capable of backing up and restoring an Exchange database. If you're not familiar with using Recovery Storage Groups (RSG) with Backup Exec, here is a link to an article that describes how to do it. That article describes most of the base-level restore process but in my situation it didn't work afterwards which meant some pretty in-depth troubleshooting.

The restore process completed successfully so I tried to mount the database I had configured within the RSG - no joy. The mount request spat out an error saying "An internal processing error has occurred", accompanied by messages in the Application Eventlog saying:

Information Store (1588) Recovery Storage Group: Attempted to attach database '<path>Mailbox Store.edb' but it is a database restored from a backup set on which hard recovery was not started or did not complete successfully.

Error 0xfffffde0 starting database "Recovery Storage Group\Mailbox Store" on the Microsoft Exchange Information Store.

and

Error 0xfffffde0 starting Storage Group /DC=local/DC=xxx/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=xxx/CN=Administrative Groups/CN=First Administrative Group/CN=Servers/CN=xxx/CN=InformationStore/CN=Recovery Storage Group on the Microsoft Exchange Information Store. MDB failed to start.

Some Google trawling turned up Microsoft article entitled What to Do When an Exchange Store Won't Mount. A quick read through there satisfied me that none of the conditions listed were causing the problem so I turned to the tried and sometimes trusted command-line program :: ESEUTIL (which is found in the C:\Program Files\Exchsrvr\bin folder of a default Exchange Server 2003 installation).

ESEUTIL has a ton of options, the relevant ones in this case being /r for Recovery, /g for InteGrity and /p for RePair. Note that a lot of articles reference a file called Restore.env. It contains information about the log files that relate to the backup you've just restored and can be used with the eseutil.exe option /cc - in this situation the Restore.env file was empty which meant I couldn't use this option.

Important : Run eseutil.exe from the directory that contains the RESTORED database files, not the production ones!

So, I tried to run an integrity check :

eseutil.exe /g "Mailbox Store.edb"

However, I was told the database was in an incomplete state due to some of the log files not being replayed into the database yet and that I needed to run a database recover first (even though I was given the option to skip this if I wanted to, it wasn't recommended). Note that r00 is site-specific and may need to be changed for your configuration. Run eseutil.exe from a command prompt to see the options.

eseutil.exe /r r00

The recover process failed too though. At this point I figured the database was simply in a state where it couldn't be recovered and couldn't be integrity-checked so I decided to run a repair :

eseutil.exe /p "Mailbox Store.edb"

This started and completed fine. Great! For completeness' sake I decided to run an integrity check before trying to mount the database again:

eseutil.exe /g "Mailbox Store.edb"

This time it worked fine, even though towards the end of the process the eseutil.exe process ended up taking up quite a lot of memory and saying "Deleting unicode fixup table". I wouldn't recommend doing a Google search for that because all the results appear to be stories of doom and gloom with one guy even saying I've never been able to repair a database that returned that error. I guess he didn't do enough research or try hard enough because I eventually got it working just fine.

Ok so by this point the RSG copy of the database was mounted within Exchange System Manager and seemed to be working just fine (the database must be mounted before data can be extracted from it). If you're paranoid about mounting an Exchange database with the same name as your production one, good - you should be. Mounting the database within the RSG, even though it has the same name as your production database, IS a safe process however.

After this it's usually a simple matter of using something like the Microsoft utility ExMerge to dive into the restored database and extract the desired mail into a PST file.

In this case however, running ExMerge highlighted a couple of problems. The list of mailboxes was complete, apart from the one I wanted to restore. This was due to the AD account being deleted as well. Assuming your backup is a complete database backup and also assuming the restore process worked ok, you should have a complete copy of the database available, including the deleted mailbox (as long as it was backed up prior to being deleted of course).

Looking through the ExMerge.log file I was able to find the GUID of the mailbox I wanted to restore and that ExMerge couldn't find a corresponding AD account for :: \BCz\D7\87\CAm\A0G\AF\DB\F3X\3E\A7e\DE - doesn't look like a normal mailbox GUID does it? That's ok, you can convert it into a valid GUID.

First, navigate to http://www.asciitable.com/ - you'll need it in a minute. Now, open up a text editor and paste the GUID into it (I just used Notepad).

\BCz\D7\87\CAm\A0G\AF\DB\F3X\3E\A7e\DE

A valid hex value or couplet is always 2 characters long with each part being 0-9 or a-f ... NOTHING else. You need to break out the couplets from the GUID value like the one above, find the ones that aren't valid hex and then convert them to valid hex values using http://www.asciitable.com. The one I was working with turned out as follows :

BC 7A D7 87 CA 6D A0 47 AF DB F3 58 3E A7 65 DE

Note that the ones I had to convert were 'z', 'm', 'X' and 'e' - you must make sure you separate the couplets properly by looking where the slashes appear. EVERYTHING HERE IS CASE-SENSITIVE!

I then used AD Users & Computers to create a temporary mailbox that I could change so that I wasn't messing with any production mailboxes - if you change the GUID for a mailbox that is being used, a new mailbox with the new GUID will be created the next time the mailbox is accessed. Not good because then you'll have to go through this whole restore process again. My temporary AD account was called "Restore Mailbox".

The next part involves using ADSIEdit to change the msExchMailboxGuid property for the "Restore Mailbox" account so that it matches the one I converted above. You can start ADSIEdit by running adsiedit.msc (it comes with the Windows Support Tools which you should download and install if you haven't already).

Using ADSIEdit, navigate to Domain, open your domain (e.g. DC=YourDomain,DC=com), expand the users container (CN=Users) and select the "Restore Mailbox" account from the list (CN=Restore Mailbox). Open the properties of this object and scroll through the list until you find msExchMailboxGuid. Change the value to the completed and valid hex string you converted earlier by clicking the "lEdit" button and pasting the new value into the box provided. There is no need to restart any services for this change to take effect.

Next time you run ExMerge, "Restore Mailbox" (or whatever name you chose) should be an available mailbox that you can export to a PST file.

This is a fairly long process, especially considering the time eseutil.exe can take to run but it's something you will probably have to do during your time as an Exchange Administrator.

Hope it helps someone!

Private Declare Function SetWindowPos Lib "user32.dll" Alias "SetWindowPos" (ByVal hWnd As IntPtr, ByVal hWndIntertAfter As IntPtr, ByVal X As Integer, ByVal Y As Integer, ByVal cx As Integer, ByVal cy As Integer, ByVal uFlags As Integer) As Boolean

Private Declare Function GetSystemMetrics Lib "user32.dll" Alias "GetSystemMetrics" (ByVal Which As Integer) As Integer

Private Const SM_CXSCREEN As Integer = 0
Private Const SM_CYSCREEN As Integer = 1
Private Shared HWND_TOP As IntPtr = IntPtr.Zero
Private Const SWP_SHOWWINDOW As Integer = 64

Public ReadOnly Property ScreenX() As Integer
    Get
        Return GetSystemMetrics(SM_CXSCREEN)
    End Get
End Property

Public ReadOnly Property ScreenY() As Integer
    Get
        Return GetSystemMetrics(SM_CYSCREEN)
    End Get
End Property

Private Sub FullScreen()
    Me.WindowState = FormWindowState.Maximized
    Me.FormBorderStyle = FormBorderStyle.None
    Me.TopMost = True
    SetWindowPos(Me.Handle, HWND_TOP, 0, 0, ScreenX, ScreenY, SWP_SHOWWINDOW)
End Sub