Mailbox Auto-Mapping in Exchange Server 2010 (Part 2)

If you would like to read the first part in this article series please go to Mailbox Auto-Mapping in Exchange Server 2010 (Part 1).


In part one of this article on the auto-mapping feature of Exchange Server 2010 Service Pack 1 and 2, we identified what this feature does, how it only takes effect when permissions are assigned against individual accounts, and then finished off part one by looking at how the mapping information is presented by the autodiscover process.

In part two, we’ll continue our look at useful troubleshooting information but this time concentrate on the permissions that are assigned when you grant a mailbox full access permission against another mailbox. We will then look at how you can now disable auto-mapping in Exchange Server 2010 Service Pack 2.

Troubleshooting Mailbox Auto-Mapping : Permissions

When you use either the Exchange Management Console or the Exchange Management Shell to grant a user with full access permission against another mailbox, permissions changes are made to allow this as you might expect. Certain Active Directory attributes are also updated to reflect both the Active Directory account of the mailbox being accessed as well as the Active Directory account of the accessing mailbox. Specifically, you can check the contents of the msExchDelegateListLink and msExchDelegateListBL Active Directory attributes to see these details and it is worth checking these if you have any suspicions that things aren’t working correctly.

Let’s look at using LDP.EXE to see the contents of these attributes. To do this, follow these steps:

  1. Run LDP.EXE and then click the Connection menu option. From the Connection menu, click Connect.
  2. In the Connect window now presented, configure the details for one of your domain controllers and then click OK. The right-hand pane of the LDP window will now populate with information as LDP connects to the domain controller.
  3. From the Connection menu, click Bind and you will be presented with the window shown in Figure 2-1. Here you can bind with the necessary credentials but in the example shown in Figure 2-1 I’m already logged on as an administrator and I’ve therefore elected to use the Bind as currently logged on user option.

Figure 2-1: LDP Bind Window

  1. You should now be back at the main LDP window. From here, select the View menu and choose the Tree option from this menu.
  2. You will now be presented with the Tree View window. Leave the BaseDN field blank and simply click OK.
  3. Back at the main LDP window, you should now see that the left-hand pane reveals a connection to the domain information which I have expanded out as you can see from Figure 2-2.

Figure 2-2: LDP Connection Established

  1. You can now perform the search for the required attributes. You can either perform the search across the entire domain or, if you know that a specific Organizational Unit (OU) contains all user accounts, you can search that particular OU. In this example, we will search the entire domain. To do this, right-click the domain name at the top of the tree and choose the Search option from the context menu.
  2. In the resulting Search window, the BaseDN field should be set to the domain since that’s where we invoked the search from. To search for objects in the domain that have the msExchDelegateListLink attribute set, enter (msExchDelegateListLink=*) in the Filter field. Next, set the Scope option to Subtree. Finally, since we’re only really interested in the msExchDelegateListLink attribute, we can prevent LDP from returning all attributes by entering msExchDelegateListLink into the Attributes field. Your Search window should look similar to the one shown in Figure 2-3. Once this window has been populated correctly, click Run to run the search.

Figure 2-3: LDP Search Window

  1. The main LDP window should now reveal the results of the search and in my lab the results are shown in Figure 2-4. Here you can see that two objects match the search criteria, namely the Sales and Info shared mailboxes, and their distinguished names are presented along with the value set in the msExchDelegateListLink Active Directory attribute. It’s quite clear here which mailbox has been assigned the permissions.

Figure 2-4: LDP Completed Search Revealing Delegates

  1. Rather than searching for the msExchDelegateListLink attribute, it is also possible to perform the reverse operation by searching for the msExchDelegateListBL attribute. To do this, right-click the domain name in LDP and choose the Search option as you did earlier in step 7.
  2. In the Search window, ensure that the Filter field is set to (msExchDelegateListBL=*) and the Attributes field set to msExchDelegateListBL before running this search. This is shown in Figure 2-5.

Figure 2-5: LDP Search Window for msExchDelegateListBL

  1. The results of this search are shown in Figure 2-6 where it can be seen that my account object has backlinks for both the Info and Sales account objects.

Figure 2-6: LDP Completed Search Revealing Delegate Backlinks

Auto-Mapping Changes in Service Pack 2

In part one of this article, we discussed the fact that auto-mapping occurs automatically in Exchange Server 2010 Service Pack 1 and autodiscover automatically maps all mailboxes such that they are presented in Outlook 2007 or Outlook 2010. Furthermore, this feature cannot be disabled by the users. The good news is Exchange Server 2010 Service Pack 2 allows the administrator to disable this feature. Let’s have a look at how this is done.

The first thing to note is that you cannot use the Exchange Management Console to disable the auto-mapping feature; this feature must be disabled using the Exchange Management Shell. A new parameter called –AutoMapping has been added to the Add-MailboxPermission cmdlet which is a Boolean parameter; this means it can be set to $true or $false.

Back in part one of this article, we used the following command to grant the mailbox belonging to Neil full access permission to the Sales shared mailbox:

Add-MailboxPermission –Identity Sales –User neilhobson\neil –AccessRights FullAccess

In Exchange Server 2010 Service Pack 2, we can run the same command but additionally set the –AutoMapping parameter to $false to ensure that mailbox auto-mapping is disabled for this particular mailbox.

Add-MailboxPermission –Identity Sales –User neilhobson\neil –AccessRights FullAccess –AutoMapping $false

To confirm this, I have created two shared mailboxes in my lab named Shared1True and Shared2False. For the mailbox called Shared1True, we will set the –AutoMapping parameter to $true and for the mailbox called Shared2False we will set the same parameter to $false. The results of running these commands are shown in Figure 2-7.

Figure 2-7: Using the AutoMapping Parameter in SP2

The test is then to launch Outlook and let autodiscover do its work, the results of which are shown in Figure 2-8. Sure enough, the only mailbox that is automatically mapped is the Shared1True mailbox which clearly means that the Shared2False mailbox has not been automatically mapped as we desired.

Figure 2-8: Only Validated Shared Mailbox is Added


That completes our look at the mailbox auto-mapping feature that you will find in both Exchange Server 2010 Service Pack 1 and Service Pack 2. The ability for the administrator to disable this feature via the Add-MailboxPermission cmdlet is a welcome addition in Service Pack 2 and one that administrators will surely use. Hopefully you have found the troubleshooting information of use in addition to the feature descriptions used within this article.

If you would like to read the first part in this article series please go to Mailbox Auto-Mapping in Exchange Server 2010 (Part 1).

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top