Exchange: The security principal specified is already on the permission set

Every once in a while you will find customers running in to the following issue. When they try to get mailbox folder permissions or set mailbox folder permissions  a red error message pops up stating:

The security principal specified is already on the permission set.
+ CategoryInfo          : NotSpecified: (:) [Get-MailboxFolderPermission], CorruptDataException
+ FullyQualifiedErrorId : [Server=SU8000006141,RequestId=628b5335-6148-4297-8f06-4c607b029737,TimeStamp=15-2-2017 06:46:24] [FailureCategory=Cmdlet-CorruptDataException] BE7556A,Microsoft.Exchange.Management.StoreTasks.GetMailboxFolderPermission
+ PSComputerName        : localhost

The error message by itself does not seem to be very help full and when you google on the internet you will see some questions about this pop up but most of them remain unanswered. So what is going on here.

Our first clue is the “CategoryInfo” of the error message stating “CorruptDataException” which seems to lead to some kind of corruption in the mailbox. For customer where I have seen this error most of the time there is a custom provisioning system in place or the customer is in some sort of Forest restructure migration.

To provide a mailbox with permissions there are 3 things you need to have to successfully set those permissions.

  1. The right RBAC role in exchange to manage the mailbox permission
  2. A mailbox folder
  3. An AD Object with exchange properties that is ACL able for exchange

Part 3 of these requirements is controlled by the property “msexchrecipientdisplaytype”. The following table shows all the possible value`s of this property: ( Take a look at the ACLable labled properties )

Display Type Value
MailboxUser 0
DistrbutionGroup 1
PublicFolder 2
DynamicDistributionGroup 3
Organization 4
PrivateDistributionList 5
RemoteMailUser 6
ConferenceRoomMailbox 7
EquipmentMailbox 8
ACLableMailboxUser 1073741824
SecurityDistributionGroup 1043741833
SyncedMailboxUser -2147483642
SyncedUDGasUDG -2147483391
SyncedUDGasContact -2147483386
SyncedPublicFolder -2147483130
SyncedDynamicDistributionGroup -2147482874
SyncedRemoteMailUser -2147482106
SyncedConferenceRoomMailbox -2147481850
SyncedEquipmentMailbox -2147481594
SyncedUSGasUDG -2147481343
SyncedUSGasContact -2147481338
ACLableSyncedMailboxUser -1073741818
ACLableSyncedRemoteMailUser -1073740282
ACLableSyncedUSGasContact -1073739514
SyncedUSGasUSG -1073739511

So Only When the mailbox is of type “msexchrecipientdisplaytype=1073741824” or “-1073741818″,”-1073740282″,”-1073739514″ are you able to claim a ACL on it.

So what might cause theses issues and how can we fix it.

One of the things causing this is FIM or other synchronization engine that replicates and converts exchange objects into different states due to multi forest deployment or transition. If this is the case take a good look at the object flow of your sync engines and change the flows accordingly so a mailbox has a ACL able state and the placeholder object in the other forests has a ACLablesynced state.

Sometimes you see this behavior after you disconnect the master account from a  linked mailbox effectively converting the mailbox to a normal user box. if this is the case a simple “update-recipient” is sufficient to have exchange fix the error state. ( it seems that the exchange system attendant is not triggering correctly “set-aduser” command to unlink a  linked mailbox).

The following PowerShell code can help you find affected users that are in the error state after a linked mailbox has been converted.

Get-ADuser -LDAPfilter “(msexchrecipientdisplaytype=0)”

Once the user is corrected you will be able to set the mailbox folder permissions again.

Leave a Reply

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