Most email users are pack rats: They keep as much mail and other items as you'll let them stuff into their Exchange Server mailbox. Because many large Exchange Server implementations allocate each mailbox 50MB by default—mailboxes that hold 1GB or more are not unknown—you can see how the private Information Store (IS) can easily grow to 60GB or larger. Such large databases have extremely long backup times and make getting the server back online quickly after hardware failures a difficult task. A large email repository also worries legal departments around the world because of the information that investigators might find in the messages. The best example of incriminating messages, of course, is the role of email in Microsoft's battle with the US Department of Justice.
You can exert control over the size of the private IS by imposing mailbox quotas. You can also control mailbox size by encouraging users to regularly clean up their mailboxes. Enterprise-style messaging systems have long incorporated tools to help administrators manage mailbox contents. For example, ALL-IN-1, Digital Equipment's office system that dominated email for most of the 1980s and early 1990s, had the Janitor, a background process that deleted any messages older than a set number of days.
In Exchange Server 5.5 Service Pack 3 (SP3) Microsoft has finally introduced an effective email-management tool—Mailbox Manager. Although the utility comes with an Exchange Server 5.5 service pack, you can run it on any Exchange Server 5.0 or 5.5 server. Let's look at how Mailbox Manager evolved and how you install, configure, and use the utility to keep mailbox size manageable.
Microsoft made some earlier attempts to help you control mailbox size, but those tools have been inadequate. The Microsoft Exchange Administrator program's Clean Mailbox option lets you select a group of mailboxes and examine and clean their contents according to set criteria. You can select anything from one mailbox to every mailbox on a server. However, this utility is limited because it performs the process in the foreground; you can't schedule it to occur automatically. And although processing one user's mailbox this way is feasible, selecting and processing all the mailboxes on a large server isn't practical.
An improved utility, Mailbox Cleanup Agent, appeared in the Microsoft BackOffice Resource Kit (BORK). Early releases had many bugs, and even the less buggy later versions had nagging problems such as lack of support for the Alpha platform. Another problem with the agent was that some installations refuse to put any BORK utility into production because BORK tools aren't part of the Exchange product and administrators fear that Microsoft won't support the tools. If you use the Mailbox Cleanup Agent correctly, however, it works fine.
Installing Mailbox Manager
Mailbox Manager's documentation is an HTML file. Although Mailbox Manager is included with Exchange Server 5.5 SP3, the service pack doesn't automatically install the program because the program can run on any Exchange Server 5.0 or 5.5 server. However, because of a memory leak that Mailbox Manager exposes, Microsoft recommends that you run the program only on servers running Exchange Server 5.5 SP2 or later. You can run Mailbox Manager on one server within a site and have the utility process mailboxes on all the site's servers, so you don't have to upgrade every server to SP2. Running a program to process mailboxes on remote servers can generate a lot of network traffic, so you need to make a trade-off. I recommend that everyone upgrade to Exchange Server 5.5 because it's the best version of the software to date.
Mailbox Manager replaces BORK's Mailbox Cleanup Agent; the two programs can't coexist on the same server, so remove the Mailbox Cleanup Agent before installing Mailbox Manager. The installation kit for Mailbox Manager is in the \ENG\SERVER\SUPPORT\MBMNGR\ SETUP\
Microsoft describes Mailbox Manager as a tool that helps enforce corporate message-retention policies. Every company is different and must factor its message-retention policy into the broader landscape of document and knowledge management. The message journaling feature that Exchange Server 5.5 SP2 introduced is another example of a document management extension for Exchange. You need to balance the need to protect confidential messages against the need to preserve important information.
As Screen 1 shows, Mailbox Manager installs into the site's Configuration container. Double-clicking the add-in lets you amend its properties that cumulatively form the message retention policy for Mailbox Manager to obey.
The General Properties page, which you see in Screen 2, contains several important options. First, you must specify the mailbox you want to receive administration reports. Second, you must decide whether you want the program to clean mailboxes or run in audit mode. Audit mode means that the program scans mailboxes to identify items that the program would delete according to the retention policy but the program doesn't take any action. Instead, the program provides a report that shows how effective the policy will be if you put it into effect.
The third important choice is where to move messages that the program deletes. The cleanest approach is to delete messages immediately, but use that option only when you're sure that users understand that the program will permanently delete messages from their mailboxes after a set period. On Exchange Server 5.5 servers, you can always recover deleted messages if you set the deleted-items retention period to more than zero days. The other options are to move items into the standard Deleted Items folder or into a special set of folders in each user's mailbox under a root called System Cleanup (e.g., move items from the Inbox to an Inbox folder under the System Cleanup root). In most cases, the best choice is to simply move items into the Deleted Items folder because users expect to find deleted items there. However, remember that Outlook lets users choose to empty the Deleted Items folder each time they exit; therefore, if Mailbox Manager moves items to the Deleted Items folder, the program might empty the folder before users realize that Mailbox Manager has cleaned their mailbox.
As Screen 3 shows, Mailbox Manager lets you set general policies and per-container policies. General policies include details of the message classes that the program processes and lifetime limits of large items. You can, for example, define a policy to remove all items larger than 5MB that are more than 60 days old. Message classes include IPM.Note (the standard class used for email), IPM.Contact, IPM.Task, and IPM.Appointment. You can choose to process all or none of these classes, and you can incorporate message classes that special applications use.
In most cases, you want to exclude IPM.Contact, IPM.Task, and IPM.Appointment from processing for two reasons. First, these items take up a small proportion of the overall store. Second, users tend to like to keep contacts, tasks, and calendar items until they're ready to remove them. Typically, contacts have a much longer lifetime than messages because users explicitly create contacts so that they can send email to external correspondents.
Screen 4 shows how you can exclude specific mailboxes from processing. Mailbox Manager skips excluded mailboxes when it reads through a recipient container.
Running Mailbox Manager
On the Schedule tab, you specify when to run Mailbox Manager. As Screen 5 shows, you can run the program immediately by clicking Clean Now. This option first checks whether the Mailbox Manager service (i.e., Microsoft Exchange Server Mailbox Manager) is running and whether Exchange Administrator has committed any policy changes to the Exchange Directory Store. You must commit policy details by clicking Apply on each property page. If the service isn't running, you can start it. The service stays running until you shut down the system or stop the service manually.
The Mailbox Manager service runs as a process called mbclean.exe, which doesn't consume many system resources because it waits until a scheduled run comes due and then starts to issue instructions to the IS process (store.exe). Store.exe takes the brunt of the work necessary to navigate through the recipient containers and scan items. During my tests, store.exe peaked at over 50 percent of the CPU and took some extra memory from the system. Dynamic buffer allocation (DBA), a feature Microsoft introduced in Exchange Server 5.5, lets the IS request more memory from Windows NT whenever the IS needs it and return memory to NT when other programs need it. You appreciate the value of DBA's automatic tuning when programs such as Mailbox Manager generate additional load. Finally, Mailbox Manager creates a set of transaction logs at rapid intervals. You expect this behavior because the utility needs to access many folders and items in user mailboxes to decide whether they meet the criteria for deletion. If the utility processes items, it creates transactions that Exchange must log. Because Mailbox Manager generates substantial overhead, schedule it for late at night when the system load is lightest. The utility might take up to 12 hours to process the IS on servers that support thousands of mailboxes or whose priv.edb is larger than 20GB.
Mailbox Manager includes several reporting facilities to inform you about the tasks the program has performed. The utility logs error and informational messages as events in the application event log. These events report when Mailbox Manager begins and completes processing and when the utility encounters errors during a run. It also reports a 1016 event for each mailbox that it processes, which signifies that an account that isn't the primary NT account for the mailbox (i.e., the account that runs mbclean.exe—usually the Exchange site services account) has logged onto the mailbox. Some installations monitor the event log for event 1016 to detect unauthorized attempts to access mailboxes, so expect to see a lot of events logged.
Users receive a message containing details of the work Mailbox Manager has performed in their mailbox. The message informs the user that Mailbox Manager has removed some messages and explains where the deleted messages are. As Screen 6 shows, you can customize some of the message text. You can tell users to call the Help desk if they need assistance to retrieve deleted messages or explain that Mailbox Manager is a scheduled, automatic process. Mailbox Manager processes only server-based mailboxes, so if you want to hide messages from this type of processing, create a personal folders (.pst) file and move the messages there. PSTs are purely personal, and no server-based utility, including system backups, ever processes their contents.
The assigned administrator receives summary information about everything Mailbox Manager has done. This report comes as a text message that contains a brief summary with an attached Comma Separated Values (CSV) file that includes detailed information you can use for analysis and reporting. You can open CSV files with Notepad, but using a program such as Microsoft Excel or Access is easier and more functional. Screen 7 shows an Excel spreadsheet containing Mailbox Manager data edited to remove some columns and make the column headings more understandable. You can write a macro to edit the information every time you receive a report. Screen 7 shows typical data (note that the utility shows no data for mailboxes that it skips) and summary information at the end.
Mailbox Manager is such a useful tool that you might wonder why Microsoft took so long to incorporate it into Exchange. All enterprise-level messaging systems need this functionality to help administrators rein in the insatiable demands for more mailbox quota.
Implementing tools such as Mailbox Manager is easier when an Exchange user community is new, especially if the company has migrated from another email system with similar functionality. Implementing Mailbox Manager for experienced users who have had years to build up a lot of rubbish is more difficult.
For older servers, you can use Mailbox Manager to gradually clean up and remove older items according to a well-publicized schedule (e.g., first you'll remove items 2 years old, then items 1 year old, later those 6 months old). When you've removed the older items, you can implement a long-term cleanup schedule to maintain the mailboxes. For new servers, you need to put the procedure in place from day one.