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.
- The right RBAC role in exchange to manage the mailbox permission
- A mailbox folder
- 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.