Mailbox sizes are steadily growing—increasing from the 25MB that administrators typically allocated to users in the mid-1990s to today's average of 200MB. Not only do you have to deal with increasingly large mailboxes, you must also deal with the demands of other interested parties, such as HR or your company's legal department. If you aren't already, you'll soon be up to your elbows in compliance requirements. And that means you need the best tools available to manage your users' mailboxes.
The Mailbox Manager utility, which Microsoft first introduced in Exchange Server 5.5 Service Pack 3 (SP3), lets you clean up users' mailboxes by deleting and moving items. Since then, the company has rewritten Mailbox Manager's original Messaging API (MAPI) code to use ADO and OLE DB, integrated the Mailbox Manager GUI into Exchange System Manager (ESM), and re-engineered the utility's code so that it runs as a thread within the Exchange System Attendant. Microsoft shipped the upgraded Mailbox Manager with Exchange 2000 Server SP1 and has gradually improved it in subsequent service packs and in Exchange Server 2003. An out-of-the-box tool such as Mailbox Manager is simpler in scope and capabilities than third-party products, but it can be a good first step to managing user mailboxes on an Exchange server. To get started, let's look at how you begin by creating Exchange recipient policies to manage how Mailbox Manager works within your organization.
Mailbox Manager and Recipient Policies
Mailbox Manager uses recipient policies to deal with mailboxes. Exchange stores recipient policies as objects in the Recipient Policies container (under Recipients) along with other mailbox-related administrative settings such as those that govern the Recipient Update Service (RUS). Like other configuration settings that Exchange uses, the policies are held in Active Directory's (AD's) Configuration naming context (NC). Recipient policies use basic LDAP filters to establish the scope of the AD objects that they process, but you can build complex filters that target specific groups. For example, you might want Mailbox Manager to process all the mailboxes on a server or all the mailboxes that belong to a certain department or regional office.
Recipient policies are commonly used in an Exchange organization to control the generation of proxy addresses for mail-enabled objects. You can edit the policies that control proxy-address generation so that they also control Mailbox Manager, but (for several reasons) I recommend that you use separate policies for these operations. For example, if you use the same recipient policy to control proxy address generation and Mailbox Manager, you can inadvertently make changes to email addresses when you update the Mailbox Manager settings, which could cause Exchange to update every email address in the organization, resulting in a flood of AD replication.
Figure 1 shows a set of recipient policies viewed via ESM. Each policy follows a naming convention that clearly designates its purpose. The Exchange organization in this example is small, so the policies are divided into those that process users who belong to corporate groups and those that process users in other departments. ESM displays recipient policies in priority order. To move a policy up or down in the order, select the policy, right-click All Tasks, then select Move Up or Move Down until the policy is in the desired position in the list. (For more information about how recipient policies work with email proxy addresses, see "The Exchange Recipient Update Service," June 2005, InstantDoc ID 45972.)
To create or edit recipient policies, you must have Administrator privileges at the organization level. When you create a new policy, ESM lets you include property pages for E-Mail Addresses and Mailbox Manager Settings. Older policies created in Exchange 2000 can display only the base property pages used for collecting administrative data (Details), establishing the names of the policy and the target objects (General), and controlling email address generation (E-Mail Addresses). In that case, you can add property pages by right-clicking the policy and choosing the Change Property Page option from the context-sensitive menu. Exchange stores details about the property pages that are enabled for each policy in the policy's msExchPolicyOptionList attribute. This attribute is an octet string; you can use ADSI Edit to view the raw data. Fortunately, the data will be familiar to most Exchange administrators; if you see a string that begins with 0xfc, you know that the policy has an email proxy address property page, whereas a string that begins with 0xec indicates that it has a Mailbox Manager property page, as Figure 2 shows.
Figure 3 illustrates how you define email addresses in a recipient policy (left window) and identify target objects through an LDAP query (right window). The right window shows the LDAP query that Exchange uses to identify AD objects when it applies the policy. In this case, the LDAP query searches for all mailboxes that belong to users in a specific department (department = Corporate). The LDAP query syntax is reasonably complex, but you don't have to build the query manually. Instead, you can click Modify to invoke a dialog box that displays search parameters. To ensure that the search finds the correct objects, you can test the query by clicking Find Now, as Figure 4 shows. When you're happy with your selections, you can save the LDAP query by clicking OK and returning to the recipient policy.
Exchange stores the LDAP query in the policy object's purportedSearch attribute in the AD. If the query UI that Figure 4 shows can't filter the specific objects you want, you can use ADSI Edit to build your own LDAP query and update the policy object. Take care with this approach, however, because it's easy to make a mistake with the somewhat cryptic syntax that LDAP queries use and end up with a query that doesn't work or is inefficient. The best LDAP queries use exact matches against attributes, such as the Is (exactly) match against the Department attribute that Figure 4 shows. Note that this query will find objects with the Department attribute Corporate (uppercase C) and corporate (lowercase c). As with any AD query, you should avoid searches that use wild cards or begins with clauses because these queries will perform poorly.
Defining a Mailbox Management Policy
After you create the LDAP query, you can define the policy you want to implement. A mailbox management policy is divided into four primary parts, as Figure 5 shows:
- The action that Mailbox Manager takes when it processes a mailbox. First, you can generate a report and send it to the mailbox owner, then take no further action to delete items in the mailbox. Second, you can move items that meet the purge criteria to the Deleted Items folder, where the items will either remain or be deleted the next time the user exits the mailbox (the exact action depends on a client setting). Third, you can move the items that meet the purge criteria to a set of folders under the System Cleanup root folder. (Users can later review these items and move selected items into other folders.) Or fourth, you can immediately delete the items that meet the purge criteria. (Deleted items remain in the Deleted Items cache so that users can recover them.)
- The purge criteria that Mailbox Manager uses to check items in each folder. You can define purge criteria for the set of default folders that appear in each user's mailbox (e.g., Inbox, Tasks, Calendar) and add additional folders. Mailbox Manager uses a catch-all setting for all other folders and doesn't process subfolders unless you select the All Other Mail Folders option.
- The notification message that Mailbox Manager sends to each mailbox owner after it finishes processing the mailbox.
- The setting that Mailbox Manager uses to exclude certain messages from processing. Typically, you should select the Exclude specific message classes option only when you use customized message forms for applications such as expense or time reports. (See Table 1 for a list of valid message classes; use the IPM Type name rather than the Outlook Type name to exclude classes from Mailbox Manager processing.)
Table 2 lists Mailbox Manager policy attributes, which Exchange updates in AD after you create or update a policy. After a policy is in place, RUS stamps the policy on the user mailboxes that the LDAP filter identified. Be careful: Exchange can apply only one Mailbox Manager policy per mailbox, and RUS could apply the wrong policy to a mailbox if you create multiple policies by using LDAP filters that can find the same mailboxes. When you create policies this way, RUS applies the policy with the highest priority, which might not be the policy you want to apply. (Exchange 2003 SP1 has a bug that can cause RUS to apply two Mailbox Manager policies to the same mailbox. This bug is described in the Microsoft article at http://support.microsoft.com/?kbid=883351, and a fix is available.)
To determine whether RUS has updated a mailbox with a new policy, you can use ADSI Edit to examine the msExchPoliciesIncluded attribute of the AD account that owns the mailbox. This attribute holds pointers to all the recipient policies that apply to the account. If a Mailbox Manager policy is present, ADSI Edit will list it with the policy object's globally unique identifier (GUID), followed by the common GUID that identifies all Mailbox Manager policies. My account lists three policies, as Figure 6 shows. You can identify the top entry as a Mailbox Manager policy because its identifying GUID begins with \{3B6813EC. The other two entries are email proxy address policies; their identifying GUIDs begin with \{26491CFC. RUS stamped my account with two policies—one that explicitly selected my account through an LDAP search and a second, catch-all default policy that every Exchange organization has.
Now that we've established how recipient policies control Mailbox Manager, we can delve into the details of what actually happens when the utility begins to process mailbox contents. I'll continue that discussion next month.
