Procedure for defragmenting and moving Exchange databases without moving the original database files

[This is for my own information primarily, but as I have not found this documented elsewhere on the web, I am placing it here, in lieu of my own non-existent website. Also, no LJ-cut for indexing reasons, sorry.]

Considerations
We recently needed to move databases from SAN storage to local disks, in preparation for the Exchange 2000 mail server being decommissioned in a few months. All of the user mailboxes have been moved to new hardware using the usual Move Mailbox tool. There are a few remaining mailboxes which belong to service accounts that cannot be moved until the application they belong to is upgraded to a version that will support Exchange 2003.

This procedure may be of use in any situation where there as been a marked decrease in the number of mailboxes that a server will handle, or any change to disk configuration of the server concerned (such as moving databases to/from SAN or other network-based storage).

Exchange by default does a database maintenance routine when scheduled (generally overnight), but this online maintenance does NOT reclaim any empty space in the databases concerned. Generally speaking, it is not necessary to do an offline defragmentation--which reclaims free space--unless you're running low on disk space. In theory, the database size will only tend to grow slowly in an organisation where staff levels are reasonably static and there are mailbox quotas in place, as any empty space freed by a staff member leaving will be filled by the replacement mailbox. However, over time, there will be an appreciable amount of space creep. We found when moving our mailboxes to new hardware that the database size was reduced by a factor of 4:1. After moving several hundred mailboxes and only leaving 6 mailboxes on the old server, the database was still in excess of 45GB, which is not a desirably-sized object to move quickly to new storage.

It is quite usual to defragment a database before moving it in order to reduce the amount of wasted "white space" that is going to be copied. When running an offline defrag, by its very nature email services are not available until the defrag has completed and the databases are brought back online. It's obviously desirable to have it completed as soon as possible, so that interruption to email is minimised. The usual procedure is to have the defragmentation running on the actual database file. A temporary database is created on the same disk, which is used to copy the data as it is being processed. It requires that there is sufficient space on the disk for the temporary file to be created; that space is sometimes NOT available. It also takes longer to execute as you are reading and writing data from the same disk subsystem and there are extra processes to delete the "old" database and replace it with the "new" processed one.

The database maintenance utility, ESEUTIL, will allow the temporary database to be created in any area specified. I decided to use this method to create them in the area we wanted to move our databases to. The difficulty is when using the Exchange System Manager to specify the new database path, it will copy the existing (large) database file to the new location. This is precisely the situation we want to avoid. It is necessary to delve "under the hood" to associate the new small "temp" database with the Exchange mailbox stores. This is an unsupported and undocumented procedure. So don't blame me if you screw up your Exchange server.

Procedure

Defragmenting the databases and moving them
Assume that we have an Exchange 2000/2003 server, with an information store located on a disk array (eg. a SAN) in G:\MDBDATA, and we want to shrink and move it to a new disk array (eg. local disks) in the folder E:\MDBDATA. The database files have the default names priv1.edb (MAPI database) and priv1.stm (streaming database).

1. In the Exchange System Manager, dismount the Information Store. Mail is now unavailable.


2. Use ESEUTIL to compress and make a temporary copy of the database in its new location:
   eseutil /d "G:\mdbdata\priv1.edb" /p /t "E:\MDBDATA\priv1.edb"
   The /d switch specifies the defragmentation option, and is followed by the path to the existing database file. If, as is default, the STM file is in the same location, it too will be picked up and defragmented to the new location.
   The /p switch specifies that a temp database is to be created elsewhere and the /t switch needs to follow with the new location.
   The quote marks aren't strictly necessary in that particular example, but they will be if the file paths have any spaces in them, as usual with a command-line utility.


3. While the defragmentation is in progress, a percentage-completed indicator is on screen. As explained above, the defragmentation will be completed MUCH faster than usual.

Making changes in the Active Directory

1. When ESEUTIL completes, we need to go into the Active Directory attributes to change the database location. DO NOT attempt to respecify the path in Exchange System Manager.


2. Run ADSIEDIT and load the Configuraton Container


3. Browse to CN=Services,CN=Microsoft Exchange,CN=,CN=Administrative Groups, CN=[Admin Group name](Exchange Administrative Group, by default),CN=Servers,CN=[Server Name],CN=Information Store,CN=[Storage Group](by default, First Information Store).


4. On the right, you will see the databases making up the Information Storage Group. Double click on CN=[Database Name] to bring up the properties.


5. By default, you will have the Optional attribute properties selected. Find the
   msExchEDBFile attribute, and edit it to point to the new database location (E:\MDBDATA\priv1.edb in our example). Click Set to accept the changes. Find the msExchSLVFile attribute and repeat, specifying the location of the new STM file (E:\MDBDATA\priv1.stm). Click Set and OK to accept the changes.

Configuring the Exchange Server to pick up the changes

1. On the Exchange Server, in Computer Management->Services, stop and restart the MS Exchange Information Store service. This should force the server to reread the configuration in the Active Directory.


2. In Exchange System Manager, browse to the database name, right-click and select Properties. On the Database tab, ensure that the new paths are in place.


3. If the paths look correct, right-click on the database name again, and select Mount Store. With any luck, it will mount correctly.


4. If your storage group has the transaction log files on the old disk ("G:"), you will also need to move them to the new location. You do this with the normal method: right-click on the Storage Group name and select Properties. On the General tab, under Transaction Log File Location browse to or specify the new path, eg. E:\MBDATA\LOGS. This will again take your Information Store temporarily offline until the logs have been copied over. If you've done a backup recently, it shouldn't take too long.


5. When the transaction logs have been copied and the store is online, test by sending and receiving mail from a mailbox located on that store. I generally create a new one for the purpose, thus testing mailbox creation as well. If this is successful, it's now appropriate to tell other interested bods that their mail is now available.


6. Run a FULL backup!!

Remember that the new databases are optimised copies of the old. The old dbs are still in their original location. After ensuring that mail traffic and mailbox access is working as expected (a day, a week, whatever is preferable), you can remove the old EDB and STM files.

The process is then successfully completed.

This is fairly straightforward, but it is never a trivial task to fiddle with your Active Directory. Always ensure that you have a copy of the settings you modified (it's worth using LDIFDE.exe to dump the attributes before the change), and that you have the appropriate backups so that you can roll back in case of a disaster.