In part one of this two-part series (http://www.windowsitpro.com, InstantDoc ID 46945), I described the Exchange Server Mailbox Manager utility, which lets you clean users' mailboxes by deleting and moving items, and I explained how to create Exchange recipient policies that manage how Mailbox Manager works within an organization. That article was the appetizer. In part two, I present the main course: how Mailbox Manager processes user mailboxes and helps you comply with your organization's data-retention policies.

Age and Size Checks
Mailbox Manager can examine items based on age, size (in kilobytes), or both. These settings are folder-specific. Figure 1 shows the All Other Mail Folders value set to 365 days and 1024KB (the default values are 30 days and 1024KB); based on these settings, Mailbox Manager examines the folder to find any item that's older than 1 year and larger than 1MB. Being able to establish such criteria for every folder gives you enormous flexibility. For example, you can let users have a special folder that Mailbox Manager never checks and that acts as a dumping ground for large documents or items that users want to keep.

Mailbox Manager checks against three Messaging API (MAPI) properties to determine whether an item exceeds the age limit:

  • PR_Message_Delivery_Time
  • PR_Client_Submit_Time
  • PR_Last_Modification_Time
  • For Mailbox Manager to delete an item, the value of all three properties must exceed the recipient policy's set mailbox limit. (In Exchange Server 5.5, Mailbox Manager assessed the value of PR_Message_Delivery_Time only.) Note that the values of these properties don't change when you use the Exchange Move Mailbox option to move a mailbox between servers. If Mailbox Manager moves items to the System Cleanup folder, it resets the PR_Last_Modification_Time property so that the next time the utility runs it won't delete those items, giving users time to review and recover them, if necessary.

    Notification Messages
    You can define a mailbox's recipient policy so that the System Attendant will generate and send a notification message, indicating what happened during processing, to the mailbox owner. You define the notification message's header and footer, as Figure 2 shows. (Note that the text isn't formatted; the editor doesn't support bold, underline, or other text styles.) It's a good idea to use the header or footer to explain why you're using Mailbox Manager (so that users understand why their mailboxes have been cleaned) and to identify a suitable administrator for users to contact if they're unhappy about the process. These simple steps can help you avoid a flood of calls to the Help desk.

    As it processes each folder, Mailbox Manager notes the number of messages that satisfy the policy, then merges this data with the header and footer information that you created to produce a notification message, which the System Attendant then sends to the mailbox owner. Figure 3, page 12, shows a sample notification message.

    After Mailbox Manager processes all the mailboxes on a mail server, it generates either a detailed message or a summary message (depending on which option the administrator selects) in simple text format. The administrator email account that will receive the report is defined in the mail server's properties; you can select only an individual email-enabled account to be the administrator because Exchange doesn't let you send reports to distribution groups or contacts. (If you want to share this information, however, you can create a rule for the destination mailbox that will autoforward any Mailbox Manager messages to a distribution group.) The detailed message states the start and finish times, the number of mailboxes processed, the number of messages that met the set criteria for removal, and the total size of these messages, whereas the summary message merely notes the total amount of data that Mailbox Manager processed.

    Running Mailbox Manage
    After you've defined recipient policies to dictate Mailbox Manager's behavior, you can run Mailbox Manager by using the Mailbox Management properties of a target Exchange server to create a schedule, as Figure 4 shows. Or you can run the process manually by right-clicking a server in Exchange System Manager (ESM) and selecting Start Mailbox Management process now.

    In general, because it has to check the properties of multiple items, Mailbox Manager's process generates a heavy load on the server, so it's unwise to start or schedule a run during peak usage times. Anecdotal evidence suggests that an active Mailbox Manager process can generate an additional 20 percent load on a server, although your mileage will vary depending on your server configuration, the number of mailboxes, the number of folders and items in the mailboxes, and the load that users generate during a Mailbox Manager session.

    Out of the box, Exchange offers four options for scheduling Mailbox Manager:

  • run Saturday at midnight
  • run Sunday at midnight
  • never run (the default)
  • custom schedule
  • In most cases, running Mailbox Manager at midnight every Saturday or during the day on Sunday are the best options because these times will likely avoid heavy user demand. Remember that Mailbox Manager can generate a lot of updates to mailboxes and therefore increase the number of transaction logs that the Exchange Information Store generates, so it's best to align Mailbox Manager processing with your regular backup schedule, perhaps by running a backup after Mailbox Manager has finished processing. It's also a good idea to avoid those times when Exchange performs background Information Store maintenance. (For more information about this topic, see "Background Maintenance for Exchange Servers," November 2004, InstantDoc ID 43903.)

    If you opt for a custom schedule, be aware that Microsoft designed the Mailbox Manager process so that it wakes up once every 15 minutes as a thread within the System Attendant process. When awake, the process (known as CMBCleanTask) checks to see whether it's time to run and, if it is, starts to process the mailboxes that the policy specifies. Therefore, if you create a schedule that sets aside 2 hours for Mailbox Manager to run, you actually let the thread begin processing eight times (once every 15 minutes in the 2-hour period); Mailbox Manager will process mailboxes eight times and generate eight sets of notifications. You'll end up confusing users and possibly swamping your server with excessive processing. If you create a custom schedule, therefore, select just one 15-minute slot.

    Mailbox Manager uses the Windows NT Local System account to log on to user accounts. If you view the set of mailboxes on a server that Mailbox Manager has processed, you'll see NT AUTHORITY\SYSTEM listed as the last account that logged on to each mailbox.

    Minimizing the Effect on Users
    Users will probably be surprised when you start running Mailbox Manager, especially if you haven't made a great effort in the past to control mailbox quotas. Apart from the notion that a system process can trawl through their mailboxes to arbitrarily (in their minds) select and delete items, people usually don't like sudden changes in their work conditions. Therefore, I suggest you educate users—before you begin running Mailbox Manager—about the benefits of automatically cleaning their mailboxes and how doing so can help them meet the company's data-retention policies. You can then position Mailbox Manager as a way of relieving them from having to sort through old messages themselves. You might, however, have to tell users how to use the Recover Deleted Items option to retrieve messages from the Deleted Items cache or how to navigate through the System Cleanup folder to find messages that were moved from their original folders.

    Start slowly and build toward the type of email-retention policy that you want to achieve. Users will probably protest if you start by deleting every item that's more than 30 days old but are unlikely to worry as much if you begin by looking for items that are at least 6 months old and larger than 1MB. After you run Mailbox Manager for 3 months, it becomes part of your background system maintenance, similar to downtime for planned software upgrades, and you can tighten the retention criteria. Apart from anything else, starting with a loose retention policy reduces the possibility that you'll make a mistake and end up deleting far more than you intended to do (leaving you with clean mailboxes and databases but angry users). I strongly suggest that you run Mailbox Manager in report-only mode first before progressing to a run that deletes items. Because mistakes do occur, it's also a good idea to create a backup before you start the first Mailbox Manager run that will delete items.

    Diagnostics
    As with all Exchange processes, Mailbox Manager usually logs only important events. Mailbox Manager runs under the System Attendant process, so you have to increase the diagnostic logging level for the Mailbox Management component in the MSExchangeSA service if you suspect that Mailbox Manager isn't logging at a high-enough level. Figure 5 shows a server's Diagnostic Logging settings. The active services are listed, and you can select one of the service categories to increase logging. In this example, I've increased logging for the Mailbox Management component to Maximum.

    As is true of most other Exchange processes, turning up logging for Mailbox Manager will greatly increase the number of logged events. With Maximum logging enabled, you'll see the following event IDs:

  • 9214—starts Mailbox Manager processing on a server
    • 9221—starts processing the specified mailbox
    • 9220—applies a recipient policy to the specified mailbox
    • 9224—reports the number of items found in the specified mailbox and their sizes
  • 9225—starts processing a folder
    • 9228—reports the number of items found in the specified folder and their sizes
    • 9303—reports the number of items to be deleted and their sizes
    • 9302—finishes cleaning a mailbox (Figure 6, page 14) shows an instance of event ID 9302)
    • 9215—completes Mailbox Manager processing and reports how many items were removed and their sizes

    You might also see event ID 1022 followed by event ID 9231, which means that Mailbox Manager was unable to log on to a mailbox. The usual reason is because an administrator has email-enabled a user but Exchange hasn't yet created a mailbox for the user (Exchange creates the mailbox when the user logs on for the first time).

    Keeping Users Happy
    You'll gain the maximum advantage if you implement Mailbox Manager as part of a comprehensive data-retention policy. Even when you don't have such a policy, Mailbox Manager is a quick and simple way to implement a level of control over mailbox contents on an Exchange server. However, before you implement the utility, make sure to advise users about how Mailbox Manager will process their mailboxes so that they won't be surprised when they receive notification messages.