One of the best utilities ever created for Exchange is EXMerge. You can get the latest version of this tool here, where it is listed as the Mailbox Merge Wizard:
http://www.microsoft.com/exchange/downloads/2003.asp
What EXMerge does may sound simple and may not seem to be all that generally useful: It can copy (or move) messages, rules and forms from an Exchange mailbox into an Outlook .PST file. And it can copy messages from an Outlook .PST file back to an Exchange mailbox. (If you're new to Exchange and Outlook, a .PST file is a message store you can create in Outlook regardless of whether you use Exchange. You can deliver mail to it from an Internet mail account, or create multiple ones to archive and organize messages. In current versions of Outlook, you can create a .PST file from File, New, Outlook Data File.)
As EXMerge has evolved over the years, it has developed very sophisticated filtering capabilities. You can filter the messages EXMerge operates on by selecting or excluding folders, or by date and time ranges. You can tell it to look for a message in all Exchange mailboxes with a certain subject line or attachment name. When it finds such a message, it can copy it, move or delete it. This can be useful in a variety of situations, including cleaning up email virus messages before naive users act on them.
EXMerge can operate on a single mailbox, selected mailboxes or all mailboxes in an Exchange store. It can also process a batch of .PST files, matching them up correctly with Exchange mailboxes when importing data from .PST files to an Exchange server.
EXMerge is smart about duplicating messages: If you export all the contents of a mailbox twice to the same .PST file, you won't end up with two copies of each message. When going from .PST file to Exchange server mailbox, EXMerge is just as smart about not importing duplicates. One side effect of this excellent duplicate detection is that you can use EXMerge as a "brick backup" solution. A brick backup is a backup of a single mailbox instead of an entire database. Some third party backup solutions provide brick backup capabilities. If your backup solution doesn't, then you can use EXMerge instead. Because it is smart about duplicates, it will only export new messages to an existing .PST file each time you run it, thus providing "incremental" backup capability.
EXMerge is also very scriptable, which makes it easy to use it for backup or automated archiving. To learn how to script EXMerge, consult the thorough documentation that accompanies the utility. It's not just a readme file, but a comprehensive user's manual. EXMerge supports a very sophisticated .INI file that you can use to configure almost all settings, thus allowing you to execute EXMerge for a variety of different uses with a simple command line that points to a particular .INI file. You can even pick settings in the user interface, and have them saved to automatically generate an appropriate .INI file.
EXMerge uses a wizard-style graphical interface. You probably won't need the documentation to figure out how to use it, with one exception: You need to understand the difference between a "one step" and a "two step" merge. To understand that, you should know something about EXMerge's history.
EXMerge was initially developed to assist with disaster recovery of Exchange databases. Its initial purpose was to merge messages between two Exchange databases. It was originally developed in Microsoft PSS by Kali Buhariwalla, who maintained and improved it year after year. Recently, EXMerge was "adopted" by the Exchange product group, and Kali has become a Principal Consultant for Microsoft.
Why should you want to merge data between databases? Suppose an Exchange database has been damaged and can't be mounted without being repaired first. Repair can take hours. In the meantime, you want to restore mail service to users. So you bring up a blank database for them, and take the damaged database to another server for repair. Exchange databases are portable between servers (subject to a few rules), and after repair you can mount the repaired database on the other server. But your problem now is that you have two databases, and users can only connect to one at a time. Users have new messages in the new database and old messages in the old database. To finish the job, you have to get all messages back into a single database.
EXMerge comes to the rescue by extracting messages from database A to a PST file and then importing them to database B. The .PST file is used merely as an intermediary staging area. This is what happens when an administrator selects a "one step" merge. In the "two step" merge, the administrator chooses either to extract data from Exchange mailboxes (Step 1) or to import data from .PST files (Step 2). The steps are separated so that you can preserve the .PST files in case you want them for more than just a staging area (perhaps for a brick backup). Also, what if your test server and your production server are on disconnected networks and you can't reach both the source and destination servers simultaneously? Then you can do Step 1, transport the PST files to the destination server, and then do Step 2 when ready.
Until SP1 of Exchange 2003, the only way to extract mailbox data from a Recovery Storage Group was to use the Exchange 2003 version of EXMerge. In SP1, some of EXMerge's functionality has been integrated into the Exchange System Manager (ESM), and you can now select and right click to merge whole mailboxes between databases--this lets you do a basic "one step" merge, and this is the task you'll most often want to do during a disaster recovery. However, the ESM merge feature lacks filtering and other EXMerge features that administrators have found so useful for purposes other than disaster recovery.
Even if you can't think of a current use for EXMerge, you should download it and familiarize yourself with the way it works. EXMerge should be in every Exchange administrator's toolkit.
- Mike Lee
