Recovery Storage Group, Dial-tone, and Outlook 2003 clients in Cached Exchange Mode
WAY back in November, I was giving a presentation at Exchange Connections in San Diego about using the Recovery Storage Group in combination with a dial-tone recovery. Someone from the audience asked me about the behavior of Outlook 2003 clients that are in Cached Exchange Mode (since they have a complete or near-complete copy) of their mailboxes stored locally. I did not have a really good answer and promised to blog this. Well, here we are 3 1/2 months later and I'm finally getting around to this. I did the testing for this back in December, but I'm just now getting around to posting this information.
First some background, a "dial-tone" restore occurs when you start out with empty databases. Exchange 2000/2003 lets you delete the database files and mount the databases; Exchange creates empty databases which allows users to go back to work immediately. Well, they can send and receive messages, but all of their existing data is now gone.
Your users are now back at work, albeit with a no data. But this lets you get them off your back long enough to get their data restored. When the dial-tone database is mounted, any Outlook 2003 user that is currently in Outlook (and working offline) may see a message like this:
"The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook."
When Outlook is reloaded, you may see the following message:
"Exchange is currently in recovery mode. You can either connect to your Exchange server using the network, work offline, or cancel this logon."
However, once the client starts up, Outlook is still working properly. Outlook will not purge the local data in the OST file.
Now you can go about restoring the original database to the Recovery Storage Group (RSG). Here is where the terminology gets tricky if you are going to do a database "swap". The database that is now mounted and in production (the empty one) is the "dial-tone database." It is going to slowly accumulate data as the users start receiving mail. The original production database you going to restore is the RSG database. Create a mailbox store in the Recovery Storage Group and restore the most recent copy of the database to the RSG.
You now have the option of merging the data from the mailboxes in the RSG database in to the dial-tone database. You can do this once the RSG database is mounted, but you will lose some of the mailbox "metadata" may not be transferred and some rules that move messages between folders may no longer work.
The other option (instead of merging from the RSG to the dial-tone database) is to "swap the databases out" and then merge the data from the smaller amount of data in to the database with that was originally restored from backup. This will, of course, require some downtime since the production database needs to be dismounted and there will be some file copying.
To "swap out" the database files, dismount both the RSG and the dial-tone databases. Take note of the RSG database file names and the dial-tone database file names. Rename the dial-tone database files to a temporary file name. Move the RSG database files back in to the original location for the production database files and rename them to the production database. You have moved the RSG database back in to production. On the Database property page of the production database, check the "This Database Can Be Overwritten By A Restore" checkbox and then mount the database.
Copy the "dial-tone" database files to the RSG database location, rename the files to the RSG database file names. On the Database property page of the RSG database, check the "This Database Can Be Overwritten By A Restore" checkbox and then mount the database. The database that is now mounted in the RSG is the database that contains everything that changed (new messages, sent messages, etc...). You can now use the Recover Storage Group's Recover Mailbox Data to merge data from the mailboxes in the RSG to the production database.