Let’s look at an example where two mailbox manager policies have been created within an Exchange organization. Here we’ll use really simple policy examples to explain the troubleshooting process. Imagine there is a default policy that cleans the Inbox folder of messages that are greater than 50KB, which will be applied to all users. Now imagine another separate policy that cleans the Inbox folder of messages that are greater than 100KB. The intention is to apply the latter policy to members of the Managers group, since they have a higher mailbox and message size limit. We’ll cover more about how this policy has been applied to the Managers group later on in this article, since this is actually the reason why the polices are not being applied correctly. Figure 1 shows you how the Mailbox Manager – Inbox >100KB policy looks. The default policy has the same configuration, except that the Size value has been set to 50 instead of 100.

Figure 1: Policy To Clean Inbox Messages Greater Than 100KB

You may remember from your reading that recipient policies are applied in priority order with priority 1 being the highest. The default recipient policy has a priority value of Lowest, meaning it’s evaluated last. Once a match is made, no further processing is performed; only a single policy can be applied. For example, if the policy Mailbox Manager – Inbox >100KB has a priority of 1 and the policy Mailbox Manager – Inbox >50KB has a priority of 2, any user that matches the filter rules applied to the Mailbox Manager – Inbox >100KB policy will not therefore have messages greater than 50KB but less than 100KB cleaned from their Inbox folders. In other words, the Mailbox Manager – Inbox >50KB policy would not be applied to these users. Figure 2 shows how our two policies will look in Exchange System Manager.

Figure 2: Recipient Policy List

You’ll note from Figure 1 that the policies are configured to move the affected messages to the Deleted Items folder as well as sending an informative message to the affected users. The last piece of the jigsaw is to configure the processing schedule for the mailbox manager and send a report to the administrator once the processing has taken place. This is configured on the Mailbox Management tab of the properties of the server object in Exchange System Manager as shown in Figure 3.

Figure 3: Mailbox Manager Schedule

There are two users within this organization, namely User1 and User2. User1 is a normal user and we therefore expect their Inbox to be cleaned of messages greater than 50KB. User2 is a member of the Managers group, so we therefore expect their Inbox to be cleaned of messages greater than 100KB. User2 currently has three unread messages in the Inbox, namely a message with a 2MB log file attached, another message with a 95KB zip file attached and finally a small 1KB message with no attachment. What happens when the mailbox manager process next runs overnight? User2, the Manager, logs in the next morning via Outlook Web Access to see the screen shown below in Figure 4.

Figure 4: Incorrect Mailbox Manager Processing

As you can see, the message from the System Attendant informs User2 that messages greater than 50KB have been moved to the Deleted Items folder. Why is this? User2 is a member of the Managers group so only messages greater than 100KB should have been moved. Obviously the wrong policy is being applied and below I detail a method for confirming which policy is actually taking effect. Admittedly in my example, things are somewhat simple but the principles are the same. The method below uses LDP.EXE. You can find LDP.EXE in the Windows 2003 Support Tools, found on the Windows 2003 CD in the \Support\Tools folder.

Here’s how to use LDP to confirm which mailbox manager policy is being applied to a mailbox.

1. Run LDP.EXE.
2. Choose the Connection menu option, then select Connect from the options displayed.
3. In the resulting Connect window, enter the name of a domain controller to connect to. Leave all other fields at their default settings. Click OK when ready.
4. Back at the main LDP window, you should now see that a connection has been made to the domain controller as the right-hand pane has filled with information. Now choose the Connection menu option again but this time select the Bind option.
5. In the resulting Bind window, enter suitable credentials to bind to the domain controller and then click OK.
6. Again back at the main LDP window, the right-hand pane should reveal that you have successfully authenticated. This should look something like Figure 5.

Figure 5: LDP After a Successful Connect and Bind

1. Now choose the View menu option and select Tree. In the resulting Tree View window, leave the BaseDN field blank and click OK.
2. You should now notice that in the left-hand pane of the main LDP window, the Active Directory hierarchy is now displayed. First expand the domain name by clicking the + symbol next to it. Then proceed to expand the following objects in order until Recipient Policies is reached : Configuration, Services, Microsoft Exchange, your Exchange organization name, Recipient Policies. This should look similar to Figure 6.

Figure 6: LDP Displaying Recipient Policies

1. You can see from Figure 6 that directly under the Recipient Policies container our two mailbox policies are displayed, namely Default Policy and Mailbox Manager – Inbox > 100KB. A handy tip is to now clear the right-hand pane of LDP, since we’ll be getting the useful information displayed in that area shortly. To clear this area, choose the Connection menu option and then select New.
2. Now let’s take each recipient policy in turn. Starting with the Default Policy, just double-click it within the LDP window. The result is that the right-hand pane will fill with lots of information. The key line that we are interested in is the line that references this policy’s objectGUID. This is shown in Figure 7.

Figure 7: Default Policy objectGUID

1. You can see from Figure 7 that the Default Policy’s objectGUID is 9c948cb6-784f-4521-b019-737064461c2a. Another handy tip in LDP is the ability to save the window contents to a text file via the Save As option on the Connection menu. You might like to build up a text file of all relevant objectGUID values for your policies.
2. Now repeat the process in step 10 for the remaining recipient policy. In my case, this reveals another different objectGUID of 307656c9-4a80-41c7-ab33-0ca5da6244e3.
3. Once we have the two objectGUID values of the recipient policies, we now need to confirm which policy is being applied to User2’s mailbox. To do this we now need to examine attributes from User2’s account. Therefore, back in the left-hand pane of LDP, find the Organization Unit (OU) that houses the user account – in my case, it’s the ‘Exchange Users’ OU.
4. Having selected and expanded the Exchange Users OU, the list of user accounts within this OU is now displayed in the left-hand pane. As before, it’s now a good time to clear the right-hand pane via the New option on the Connection menu.
5. Now simply double-click the relevant user account, in my case User2. As before, the right-hand pane of LDP now presents plenty of information for this account. The line that we are interested in is the one that contains the msExchPoliciesIncluded attribute as shown in Figure 8.

Figure 8: msExchPoliciesIncluded Attribute

1. Note from Figure 8 how the objectGUID of the Mailbox Manager – Inbox > 100KB policy (307656c9-4a80-41c7-ab33-0ca5da6244e3) is not shown. The only matching policy GUID is that of the default policy, which confirms that this policy is being applied to User2.

Of course, the question in this particular scenario was why the default policy was being applied in the first place. As it turns out, the answer was simple: the filter rules for the Mailbox Manager – Inbox > 100KB policy weren’t constructed using the distinguished name of the Managers group, something that is sometimes overlooked. In other words, to correctly apply a policy to a group, you must ensure that you reference the full distinguished name of the group and not just type in, say, the display name of the group such as ‘Managers’ in this example. Therefore, in my example, the filter rule would state that the user’s Member Of attribute must exactly match the following distinguished name:

CN=Managers,OU=Exchange Users,DC=ngh,DC=net

Figure 9 shows how things look when using the distinguished name within the filter rules.

Figure 9: Correct Mailbox Manager Filter

Once changed, the policy can be applied and LDP used to re-check the msExchPoliciesIncluded attribute for User2. The result is shown below in Figure 10 where you can see that the highlighted text now contains the objectGUID of the correct Mailbox Manager policy.

Figure 10: Correct Matching msExchPoliciesIncluded Attribute

Summary

Troubleshooting policy application can and should be achieved by examining the filter that has been applied. It can also be beneficial to confirm which policy Exchange is applying by examining the various attributes via LDP as outlined within this article.