Taming your Exchange Databases

Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In many companies, e-mail has quickly become a critical application. In fact, it’s not at all uncommon to see private information store files on Exchange servers reach several gigabytes in size. Unfortunately, although Exchange 5.5 is supposed to be a scalable application, it has some inherent problems that you might encounter when Exchange databases grow to extremely large sizes. In this article, I’ll discuss some of these problems. I’ll then go on to explain how to configure Outlook 2000 to relieve some of the burden from your Exchange servers.


Issues with the Exchange Databases

Before you can really understand where the inherent problems lie with large Exchange databases, you need to know a little bit about how these databases work. There are three main Exchange databases: PRIV.EDB, PUB.EDB, and DIR.EDB. The PRIV.EDB file contains the private information store, which contains most of the e-mail messages. Any time someone sends or receives a message, a copy of the message is added to this database. When you consider how many messages a few hundred users can send over the course of a day, and that some of those messages are bound to contain attachments, you can see just how quickly the PRIV.EDB file can grow.

Several problems are related to this rapid growth. For starters, the larger the database is, the longer it takes to back up and restore. For example, I once had a manager who needed a single message restored from a 9 GB private information store. In Exchange, there’s no easy way to restore individual mailboxes or messages (without third-party utilities), so I had to build up a spare Exchange server. After doing so, I had to restore the backup to this new server and extract the one message that my boss needed into a personal folder. I then had to attach this personal folder to an Outlook client and copy the message from the folder to the user’s inbox. The process took all night. Most of that time was spent waiting on the backup tape.

Other problems come into play because the three Exchange databases mentioned earlier must be kept in sync. Occasionally, delays caused by processing extremely large databases can cause the databases to become unsynchronized. In a situation like this, you can use built-in utilities such as ISINTEG and ESEUTIL to repair or resynchronize the databases. However, the Exchange services must be shut down to do so. In the case of large databases, the repair process could take quite a few hours, preventing mail flow for quite some time.

One other problem that you might run into is that large databases can quickly cause your server to run out of disk space. As you’ve probably already figured out, the best way to prevent all these complications that I’ve mentioned is to decrease the size of your Exchange databases. The easiest way to do this is to break the PRIV.EDB into many smaller pieces that can be individually managed. By doing so, you’re not putting all of your information eggs in one basket. If you were to have a massive Exchange server crash, very little information would be lost.


Divvying up PRIV.EDB

The process involves creating personal folders for each user. These personal folders can be stored on the Exchange server; but for performance reasons, I usually prefer to store them on a separate server. You can store the personal folders in the USERS directory under each user’s folder, but users have a tendency to delete files that they don’t recognize. Therefore, I recommend creating a directory structure that’s identical to the one used for the USERS directory in a separate location. You can then use the login script to map a drive to this location.

The next step is to force Exchange to dump its contents into the new locations. The process will vary depending on the client you’re using. For the purpose of this and other articles in the series, I’ll assume that you’re working with Outlook 2000. Regardless of which client you use, you must be sure that your users close their e-mail client at night. If users leave their e-mail clients open during the backup, personal folders won’t be backed up correctly.

Begin by opening Outlook 2000 and selecting New | Personal Folders File (.PST) from the File menu. When you do, you’ll see a dialog box that prompts you for the location of the personal folder. Enter a path that points to the new location that you’ve chosen, followed by a file name that’s unique for the particular user. For example, you might use something like “Q:USERSBrien_PoseyBRIEN.PST”.

Once you’ve created each user’s personal folder, you have to get Exchange to dump messages into it. To do so, select the Services command from Outlook’s Tools menu. When you do, you’ll see the Services properties sheet. Select the Delivery tab and then choose your newly created personal folder from the Deliver New Mail To The Following Location dropdown list. Once you click OK, all future e- mail will be automatically moved to the new personal folder. Depending on your individual configuration, you may have to manually drag and drop existing messages from their present location to the new personal folder.

As you can imagine, reconfiguring each client can be a big job. However, as your work progresses, you should notice your PRIV.EDB file getting smaller. You’ll also notice a much lighter workload the next time that someone asks you to restore a message from the backup. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends, and analysis.

Latest Articles

Follow Us On Social Media

Explore More