Exchange Server Tips & Tricks

How can I determine how much unused space I have in my Information Store (IS)?

Exchange Server 5.5 Service Pack 1 (SP1) includes a set of event-log messages that give you information about free space. Every night, the IS logs two information messages with ID 1221; one message shows MSExchangeIS Private as the source and the other shows MSExchangeIS Public as the source. These messages tell you approximately how many megabytes of white space remain in the private and public stores after a defragmentation. The IS can use this space for expansion, or you can reclaim the space by stopping the Exchange Server services and using Eseutil to perform an offline defragmentation. (For information about using Eseutil, see Getting Started with Exchange, "The Sorcerer's Apprentices," May 2000.)

Another way to determine the amount of free space is to use the Eseutil command-line switch /ms, which Microsoft introduced in SP1. (SP1 doesn't update the copy of Eseutil in exchsrvrbin; Microsoft moved the SP1 version of Eseutil to winntsystem32, so you wind up with two copies of Eseutil.) The /ms switch causes Eseutil to count the pages in the IS databases. Each page takes up 4KB of disk space, so to determine total storage, multiply the number of pages by four and convert that total from kilobytes to megabytes. This estimate is higher and more accurate than the event-log estimate.

We're running Exchange Server 5.5, Standard Edition, and our private IS is approaching the 16GB limit. What happens if we surpass the limit?

When the size of either the public or the private IS database surpasses the 16GB limit, the IS service stops and refuses to restart until the database shrinks. Log files preserve any pending transactions. After you shrink the database, you can restart the IS, which will then process the transactions in the log files. This process applies to the standard editions of Exchange 2000 Server, Exchange Server 5.5, and Exchange Server 5.0.

To shrink the database, you have several options. First, you can use Eseutil to perform an offline defragmentation of the oversized store. Afterward, you can use the Mailbox Cleanup Agent (or the Microsoft Exchange Administrator's Tools, Clean Mailbox command) to strip out old junk. If your public store is the problem, consider setting more aggressive age limits for your replicas.

Second, consider upgrading to an Enterprise edition, which permits an IS of unlimited size. Exchange 2000 Enterprise Server also supports multiple storage groups (SGs) on one server. (For information about using Enterprise Server to cluster Exchange 2000, see Jerry Cochran, "Clustering Exchange 2000, Part 1," December 2000 and "Clustering Exchange 2000, Part 2," page 154.)

I want to use Microsoft Exchange Administrator's Directory Export function to export the entire Global Address List (GAL). I tried writing an export options file that specifies the home server and container, but the file exported the contents of the container only.

To include the entire GAL in your output file, you must include two key export-file options. For example, the following file might look correct, but it will yield only one container's data.

[export]homeserver=hqcontainer=recipientsinformation=fullexportobject=mailbox

Syntactically, nothing is wrong with this file, but it doesn't specify a starting point for the export. Compare the previous example with the following file, which includes the keywords basepoint and subcontainers.

[export]basepoint=/o=reallybigcompanyexportobject=mailboxinformationlevel=fullsubcontainers=yes

The basepoint keyword tells Exchange Administrator what to use as the export's basepoint. To get the data you want, include your complete organization name and use the subcontainers keyword to indicate that you want the contents of all the containers in that organization. (For information about Exchange Administrator's import and export tools, see Getting Started with Exchange, "Super Export and Import Tools," August 2000 and "Export and Import Mission: Possible," September 2000.)

I need to move my Exchange Server 5.5 transaction logs to another disk because they keep filling up the partition they're on now. What's the best way to move these logs?

You've hit on the only true drawback of Exchange Server's transaction-oriented architecture. Because each change to the IS databases generates a transaction in the transaction log files, anything that makes a lot of changes to your IS (e.g., a mail loop, moving numerous mailboxes) will make your log files balloon in size. If you don't have enough space on the disk you store the log files on, the IS will shut down, logging a message in the event log as it does so. When that happens, you have a problem—you shouldn't delete the log files manually, but if you don't make more space available, you won't be able to restart the IS.

How can you prevent this problem? Correctly perform regular online backups: The backup process automatically removes log files. (If you're making backups but the log files aren't disappearing, your backup process isn't working properly—check your event logs for errors.) However, after this problem begins, you have three ways to fix the space squeeze.

Clean up unnecessary files. This method might not help if you put your log files on a separate physical disk—the disk might not contain any nonlog files for you to remove. If you choose this route, be extremely careful not to delete any log files. (For information about recommended transaction-log storage, see Tony Redmond, "Exchange Server Transaction Logs," February 1999.)

Move the log files to another drive. If you decide to move the log files, the only safe way to do so is to use the Exchange Performance Optimizer. Don't move the files manually, and don't edit the registry key that shows where the files are. The IS databases contain references to the log-file paths, so you're headed for trouble if you move files manually.

Temporarily extend the log-file disk's partition. Creating a volume set to accomplish this task is a neat trick that I first learned from Exchange Server guru Andy Webb. First, you'll need to install an extra physical disk in your server. (Your IS is stopped anyway, so that installation shouldn't be a problem.) Then, launch Windows NT Disk Administrator. Partition the new disk if you need to, but don't format it. You can build volume sets only on NTFS volumes, so you'll need to convert your transaction log disk if it's still FAT.

Select both the current log disk and the new disk. Using the Partition, Extend Volume Set command, you can specify how much space from the new disk to weld onto your existing log disk's volume.

Now that you have some additional space, you can restart Exchange Server. As soon as Exchange Server comes back up, perform an online backup to remove the log files. While the backup is running, try to determine why the logs are growing so fast. If a mail loop is the problem, you need to fix it or you'll end up with the same problem all over again. After the online backup is complete, shut down the IS and Directory Store, then do a full offline backup for safety's sake. Finally, go back to Disk Administrator and break up the volume set. If the new disk you installed is larger than the old disk, you can use Performance Optimizer to move the log files to the new disk.

How can I determine which service pack a particular Exchange Server machine is running? More to the point, how can I get version information for individual DLLs?

To see which Exchange Server version you're running and which service pack is currently installed, open the server's Site Configuration container. Open the Servers item, right-click the server, choose Properties, and go to the General tab. (Note that this tab doesn't specify whether you're running a Standard or Enterprise edition of Exchange Server.)

Locating version information for an individual DLL is easy if you know the DLL's location. Simply open Windows Explorer, right-click the DLL, and choose Properties. Go to the Version tab; you'll see the file's version number, as well as other information about the DLL's version, build, and history. (This method works for executable files too.)

How can I forward all mail from a particular user to another email address?

The answer depends on your precise goal and the limitations you're willing to accept. The easiest method is to set up a client rule that forwards all incoming mail. I say "easiest" because as the administrator, you don't do anything: The user at the original recipient address sets up the rule. This solution has a drawback—the original user must be logged on to the server before the client can forward messages—but it does ensure that the new recipient receives copies of all incoming mail. You can also add the new destination mailbox as an alternate recipient to the original; however, this method works only if the new destination is another Exchange Server mailbox.

Usually, people ask me how to automatically forward mail because they want messages that come to an Exchange Server mailbox to pass on to an external address, such as a Hotmail account or an email-capable pager. In that case, the proper solution is to create a new custom recipient for the target address, then add that recipient as an alternate recipient to the original mailbox. (For best results, hide the custom recipient from the GAL so that no one sends mail directly to that address.)

When I use the Do not deliver before option to queue email, where do the messages go?

You can queue mail (i.e., mark the mail for later delivery) in two ways. The first method, which most people choose, places a message in your Outbox until an appointed delivery time, at which point the email goes out regardless of whether Microsoft Outlook is running. This method is convenient because you can always delete the message from the Outbox to stop delivery. To use this method, click File, Properties, Send Options from the message window's menu bar. Go to the Microsoft Exchange Server tab. Under Send this item, specify the time to wait before sending the message, then click the option button next to that time.

The second method has the same result (i.e., delayed delivery) but different means: Rather than queue the message on your machine, your client sends the email to your home server's Message Transfer Agent (MTA), which adds the message to its work queue. Because the MTA's work queue is invisible, you can't find or recall that message after it hits the MTA—so be careful with this feature. To use this method in Outlook 97, go to the message window's Options tab, select the Do not deliver before check box, and specify a delivery date and time. To find this check box in Outlook 98, click View on the message window's menu bar, then click Options.

If you're using Exchange Server 5.5, you can use the Performance Monitor's Work Queue Length counter, and the MSExchangeMTA object will monitor the work queue length. This counter tells you how many deferred messages are waiting in the MTA but not which messages are waiting. You can also use Event Viewer to check the Application log; the MTA logs event ID 275 when it processes a deferred message.