Last Update: Sep 24, 2024 | Published: Jan 06, 2009
How do I use EXMERGE to make Brick-Level backups of Exchange 2000/2003 mailboxes?
One of the most important tasks for an Exchange administrator is the regular, day-by-day, backing up of all the Exchange databases. This can be easily accomplished by use of the built-in NTBACKUP.EXE software found on your Exchange 2000/2003 server.
Note: You can also Backup Exchange 2000/2003 from a Non-Exchange Server.
Some administrators might choose to your 3rd-Party backup tools, such as:
However, as stated above (and in the Backing up Exchange 2000/2003 with NTBACKUP article), you do NOT need to buy expensive 3rd-Party tools just to backup your Exchange server.
Then why bother with expensive 3rd-Party backup tools? The main reasons behind the usage of such tools are their advanced scheduling capabilities, advanced tape drive management, and in some cases – the ability to perform Brick-Level backups of your Exchange mailboxes.
Brick-Level mailbox backup is a method in which the backup program logs on into each mailbox on the store (by using MAPI, just like Outlook does) and then backs-up the contents of the mailboxes to the tape device. Each mailbox is backed up individually, and thus restoring a specific mailbox in case it has been deleted and purged from the database is easier than before.
Note: Read Recover a Deleted Mailbox for more info on how to restore a mailbox that has not been purged from the database.
Not every 3rd-Party backup software does Brick-Level backups, as stated in one of the vendor’s website: The main reasons for the lack of Brick-Level support are that a Brick-Level backup is not designed to fully protect an Exchange server, just one mailbox at a time. It is not an alternative to a monolithic (full) backup/restore. A Brick-Level restore cannot be used to recover the Information Store after a disaster. If used, a Brick-Level backup must be utilized in conjunction with a monolithic backup in order to fully protect the server.
In order for any 3rd-party backup software to be able to do Brick-Level backups, the product would have to backup multiple copies of the same message. In other words, it would have to change the Exchange Single Instance architecture database. Removing the Single Instance architecture is possible but it would mean longer backup time and greater tape usage.
Single Instance architecture is a method used by Exchange to reduce the size of the database and also to minimize disk space fluctuation when users read and delete their mail messages. A case in point is that when a message is being sent to 100 users. If all 100 users were on the same server, then Exchange would store only a single copy in the database, but would create a pointer in each of the 100 mailboxes that the message was being sent. When the user reads and deletes the mail message, only the pointer is deleted. Without the Single Instance architecture, 100 copies of the message would have to be created. More importantly is that when the users read and delete the message, it creates tremendous disk usage fluctuation.
The problem with Single Instance architecture is that when you restore a user’s mailbox, you are only restoring the pointer. Hence, you need to restore the complete database so that mailbox pointer would work. In order to restore a user mailbox, Exchange would have to restore all messages found on each of the mailbox pointers. That is very difficult using tape technology. To accomplish a complete mailbox restore, the backup software would have to remove the Single Instance architecture by replacing the pointer with the message. This requires more time for the backup and also more tapes are used. Furthermore, by replacing the Single Instance architecture, what happens if one needs to restore the whole database? Will the Single Instance Architecture be maintained?
As noted above, Brick-Level backup capabilities rely on MAPI to access each mailbox to re-create all of the mailbox data in the message store. Performance can be as slow as 8MB/min. If studies are to be believed, each message is sent to an average of 4 users. Therefore, the size of the resulting data-file (it’s not an information store) would increase dramatically because the notion of a single-instance does not apply. For example, using the 4:1 ratio, a 30GB Information Store could end up occupying 120GB on 3-4 tapes (assuming 40GB tapes). And that is in addition to the monolithic backups done for disaster recovery!
As you might guess, Brick-Level backups and restores can easily get out of proportion, both in time for the backups to take place, and in space once the database is restored. (An Exchange database that was backed up Brick-Level, when restored, could be about 4 times larger than it was originally!)
Sometimes backing up one or 2 mailboxes via the Brick-Level backup method is still a welcome option, especially in cases where these mailboxes belong to users that have a tendency to mess things up, and especially when they are your boss, and they do not know the meaning of the word “NO!”. 🙂
You can still do Brick-Level backups of specific mailboxes by using a tool called EXMERGE.
We can utilize the power of EXMERGE to backup any mailbox on any server (you can also do it remotely) and you can easily schedule it to run at a specific interval.
First, you need to obtain the correct version of EXMERGE for your Exchange server. EXMERGE first shipped with the Exchange 5.5 Resource Kit and the most recent version can be obtained from the latest Exchange 2000 Service Pack (SP3) and Exchange Server 2003 installation CD.
Note: To write this article I’ve used Exchange Server 2003 and the latest version of EXMERGE, however the procedure is quite the same with previous versions.
After downloading the correct version of EXMERGE, extract the files found in it by using tools like WinZip or WinRAR. You will now need to copy EXMERGE.EXE to the %Program Files%Exchsrvrbin folder of your Exchange server.
Next, you need to configure your user account to have full mailbox rights for the specific mailbox/mailboxes that you want to open. On Exchange 2000/2003 the Exchange Full Administrator permissions does NOT, by default, allow you to open any other user’s mailbox.
The above screenshot is an example of EXMERGE failure due to poorly configured permissions. Read Grant Full Mailbox Rights to an Administrator on Exchange 2000/2003 for more info.
To perform Brick-Level backups of one or more mailboxes found on one Exchange server follow these steps:
Note: In a scenario where you only have one mailbox store you will not be presented with this page.
Click Next.
Click Next.
Hebrew users note: To successfully utilize the power of EXMERGE when using Hebrew enabled servers with Hebrew-titled items and mailbox names you MUST follow the next tip: EXMERGE and Hebrew Fonts. Failing to do so might cause great damage to your exported mailboxes and to the names and titles of items within those mailboxes. Failing to do so will not harm the items that are in the original mailboxes, however items that were exported to the .PST files might turn out to be illegible.
Click Next.
Click Next.
Note: Notice where you save these files. You can later modify the settings of the EXMERGE operation by simply altering some parts of these files.
For example, if you look at the contents of the MAILBOXES.TXT file, you’ll see that you can easily add or remove mailboxes by adding or deleting rows in that file.
Take some time to explore these files, it’s well worth spending a few minutes on them.
Notice an example of a successful process:
If you get a window that states that there were one or more failures, such as this one:
then it’s probably because of wrong permissions on the destination mailboxes. Re-read Grant Full Mailbox Rights to an Administrator on Exchange 2000/2003 and start from the beginning of the article.
You can easily automate the process of exporting the mailboxes to .PST files by running EXMERGE from the command prompt or from a simple batch file.
To perform automated Brick-Level backups of one or more mailboxes found on one Exchange server follow these steps:
EXMERGE.INI MAILBOXES.TXT
For instance, if you want to cause EXMERGE to work on the mailboxes of a user called DANIEL and another user called DAVID, then open the MAILBOXES.TXT file and add the following lines:
/O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=DANIEL /O=FIRST ORGANIZATION/OU=FIRST ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=DAVID
Note that you do need to use the RIGHT syntax for YOUR scenario, this is just an example.
Hebrew users note: To successfully utilize the power of EXMERGE when using Hebrew enabled servers with Hebrew-titled items and mailbox names you MUST follow the next tip: EXMERGE and Hebrew Fonts. Failing to do so might cause great damage to your exported mailboxes and to the names and titles of items within those mailboxes. Failing to do so will not harm the items that are in the original mailboxes, however items that were exported to the .PST files might turn out to be illegible.
EXMERGE -F C:EXMERGEEXMERGE.INI -B
(use your own path to the EXMERGE.INI file)
If you want to get a visual GUI you can add -D to the command, thus causing EXMERGE to display the GUI while running:
EXMERGE -F C:EXMERGEEXMERGE.INI -B -D
Done!
You must be aware of the following issues:
Security – EXMERGE does not password-protect the .PST files it creates. For security reasons, you’ll want to create the .PST files on a secure file system, such as NTFS.
Storage Space – You need to consider how much space is required to store the .PST files and with what frequency you will have to purge the archived .PST files. You might want to add some archiving features to your script, such as zipping all the .PST files after exporting them.
Overwriting .PST files – If there is no corresponding .PST file for the mailbox in the export folder, EXMERGE will create a new .PST file for the mailbox. The .PST file naming convention is <alias>.PST. If a .PST file for the mailbox already exists in the export folder, EXMERGE will export only new message data from the mailbox to the .PST file. Therefore, you may want to purge the .PST files or move them to another directory so that EXMERGE will create new .PST files when it runs next time. Single Instance Architecture – When EXMERGE exports mailbox data to a .PST file, you lose the benefit of the Single-Instance message storage capability, so don’t be surprised if a mailbox’s newly created .PST file is 10 to 50 percent larger than the mailbox itself.
You have several options when you need to restore mail from a mailbox’s .PST file. You can run EXMERGE in normal mode and select the .PST data by a range of dates or other criteria and restore them directly to any production mailbox.
Or you can copy the .PST file to the user’s local disk or make it available on a network share. Then, instruct the user to add Personal Folders to their Outlook Profile and add the .PST file when they do so. The user can then browse through the .PST file’s contents and retrieve the messages they are looking for.
You might also want to read the following related articles: