Mailbox Manager Policy’s in Exchange 2003



Mailbox Management policies can be used through an Exchange Environment to manage the content of users folders.  For instance, you can set a policy to permanently delete all items in a users deleted items folder, older than 30 days, and over 1 MB in size.  What’s the benefit of this?  It allows you, as an administrator, to keep your system in check, and prevent users from storing 90 percent of their mailbox in their deleted items folders.

Okay so where is the downside?  I don’t want to say getting them to work, as starting the policies are very easy, but maintaining them can be a different story.  Their behavior, and application are not always so straightforward.  Let’s start with their theoretical application, and then go into troubleshooting their actual application.

Their are two types of Recipient Policies in Exchange 2003, E-Mail Address Policies, and Mailbox Management Policies.  E-Mail policies are used to define an email domain that the Exchange environment is allowed to accept email for, if it’s authoritative for it or not, and how to assign various email address policies to end users. 

ScreenHunter_01 Dec. 20 22.34

Here, this policy applies the email suffix as the primary, and the @ponzeka.test as an additional alias.  We can filter this out to certain users, to have their addresses applied successfully. 

Mailbox Management Policies are used to control content in users folders.  You can specify what to do, for a group of folders, based on age and size of the items. 

ScreenHunter_04 Dec. 20 22.39

In this policy, we have set the policy to move any item over 1 MB and over 30 days to the deleted items folder for all items except the Inbox, which we have set a tighter schedule of anything over 10 days. 

So now we know what both do.  We should also know this, each user or mailbox can have only ONE of each type of policy apply to them at a time.  This means, once the system finds an email address policy, it stops processing any others, and the same for mailbox management policies.  You can control how each policy applies to each user through filtering who the respective policy applies to, and the priority in which they are applied, the lowest value number has the highest priority, so 1 goes first, then 2 and so on.

This is usually the biggest troubleshooting steps administrators have, is that some rogue policy is applying.  Well, how do you figure it out?  It some cases it can be easy, where a policy that does a specific task, such as delete all email in all folders over 1 day old applies, then you can easily track it down (along with performing a couple of restores from backup!).  But in a big environment it can be much more difficult. 

We are going to use two tools to troubleshoot the application of mailbox management policies, ADSIEDIT and LDP, both of which are available with the Windows 2003 Support Tool Pack. 

Let me tell you the premise.  We are going to check a user, to see which policies he has applied to him/her, which will be represented by the policies object GUID or global unique identifier.  Then we are going to determine the GUID of the policy itself, and see if it applies or not. 

So, lets drill down to our user in ADSIEDIT.  We will be expanding the Domain Partition, finding our user (the layout matches that of Active Directory Users and Computers, as this is literally what Active Directory Users and Computers uses), and right click him/her, in our case the user is John Smith.

ScreenHunter_05 Dec. 20 22.53

Now, we want to scroll down until we find the attribute msExchPoliciesIncluded

ScreenHunter_06 Dec. 20 22.54

Edit the default string:

ScreenHunter_07 Dec. 20 22.55 ScreenHunter_08 Dec. 20 22.56

If you notice in the two screen shots, there is two lines.  Each line has a beginning GUID, a comma, and then a second GUID.  Well, that would mean there was 4 policies applied, did I just lie to you? 

No.  Remember, each user can have a single E-Mail address policy applied to them, and a single Mailbox Manager policy applied to them.  Each line represents one.  Why the four total GUID’s then? 

The first string value in my example is as follows:


The last GUID in the string:

{3B6813EC-CE89-42BA-9442-D87D4AA30DBC} Is the GUID for Mailbox Management Policies.  It’s how the system identifies a particular policy, if it’s an E-Mail Address Policy or not.  That means, this 3B6813EC number is identifying:

{5D24E601-B570-4DD7-9ADE-3BA8FF018923}, as a mailbox management policy.

So the first value is the individual policies object GUID, and the second identifies it as a Mailbox Management Policy.

So the second string:


Means that:

{26491CFC-9E50-4857-861B-0CB8DF22B5D7} is the GUID for how the system identifies an E-Mail Address policy.  This means it is identifying the 7F68244A GUID as an Email Address Policy.

So we have that cleared up.  Okay, lets now figure out which policy these values are!

Now, we could use ADSIEDIT for this, but its not fun, and this is why.  If we expand ADSIEDIT down to Configuration->Services->Microsoft Exchange –>Organization Name (by the way THIS part of the configuration partition, is what Exchange System Manager reports from).

Now click on the CN=Recipient Polices folder, and double click on one of your mailbox manager polices.

 ScreenHunter_09 Dec. 20 23.06

Now, navigate down to the objectGUID value and click edit, this is what you’ll get:

ScreenHunter_10 Dec. 20 23.07

This is the object GUID, however its not in the correct form.  Look closer:

ScreenHunter_11 Dec. 20 23.09

The first part of the string is suppose to be 5D24E601.  If we look, we have to count in 8 digits, and then read that last set left to right, go to the left, and do the same, and we have the same value.  Man, that absolutely is terrible.

There is an easier way, use LDP.exe.

Open the tool, and select connect.  It will ask you for a server to bind to, enter the FQDN of any domain controller.

ScreenHunter_12 Dec. 20 23.13

Now, press the “bind” button.  Enter in a Domain Admin account:

ScreenHunter_13 Dec. 20 23.14

Press okay again.  You should see the output pane on the right tell you successfully authenticated.

ScreenHunter_14 Dec. 20 23.15

Now go to “View-> Tree” and in the left hand pane, the forest root should be listed.

ScreenHunter_16 Dec. 20 23.16

Now, LDP.exe is not as nicely structured as ADSIEDIT, so we have to look more for where we need to go.  It also doesn’t show you if there are any child objects until you double click.  The path should be:

CN=Recipient Policies,CN=Ponzeka,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ponzeka,DC=test

ScreenHunter_17 Dec. 20 23.20

Okay, in the right hand side, in the results pane, there will be a TON of junk.  Lets clear that.  You do this by selecting “Connection –> New”

Now, simply double click on the Mailbox Management Policy that you want:

ScreenHunter_19 Dec. 20 23.23

There it is, their is the object GUID in all it’s glory!  And, we now know that the value:

{5D24E601-B570-4DD7-9ADE-3BA8FF018923}, is typed to the Mailbox Management Policy “Mailbox Management”.  If we check the filtering of this policy, we note that it filters based on the membership of the group “ Users”:

ScreenHunter_20 Dec. 20 23.25

And if we check the user, behold, he is a member of the group!

ScreenHunter_21 Dec. 20 23.26

Bam, that’s why he’s is getting the policy applied to him!  He is a member of a group he shouldn’t be!

In the next article I’m going to go over the behavior of Mailbox Management Policies in how they filter messages based on the criteria you set!

Leave a Reply

Your email address will not be published. Required fields are marked *