11 Sep 2013
Re-Assigning Permission to “NT Authority\Self” Can Cause an Issue with Outlook Auto-Mapping
Let us assume you have the problem that permissions assigned to a mailbox are somehow “lost”. The settings of the security descriptor property on the mailbox in the information store and the Active Directory (AD) attribute msExchMailboxSecurityDescriptor do not match after some time. Please refer to the Microsoft Knowledge Base article 310866 for a description of the attribute msExchMailboxSecurityDescriptor. So far, you do not know the root cause and you only found out that assigning full access permission to the special user account “NT Authority\Self” is a workaround for this issue. For a short time-period, the permission settings are in sync again. However, do not forget Outlook auto-mapping or you will run into the issue described in this article.
Auto-Mapping is using the AD attribute msExchDelegateListLink and msExchDelegateListBL. As you can see in the previous screenshot these attributes are empty.
MFCMAPI shows that you have a connection to the Public Folder store and to your mailbox. Now you execute the “workaround”: Add-MailboxPermission –Identity <MailboxID> -AccessRights FullAccess -User "NT AUTHORITY\SELF"
The screenshot shows that the attributes used for auto-mapping now contain the distinguished name of the mailbox. The auto-mapping feature points back to the same mailbox. This causes the following issue.
AutoDiscover will tell Outlook that it should also open the same mailbox as Alternative Mailbox. You will see the mailbox twice in Outlook. Once with the primary SMTP address and once with the display name.
MFCMAPI shows that you now have multiple connections to the same mailbox – Test1@Fabrikam.local and Test1.
This issue does not occur if you use the parameter AutoMapping $False as described in this TechNet article.