A quick post is a good post today. Short and sweet issue with mailbox permissions.
I was trying to remove a user from having “Editor” (CreateItems, DeleteAllItems, DeleteOwnedItems, EditAllItems, EditOwnedItems, FolderVisible, ReadItems) on a Mailbox:\Calendar. I had to set folder level permissions over FullAccess due to some issues with FullAccess permissions and mailbox categories.
Sidebar - Mailbox categories were being inadvertently deleted. A Microsoft Premier case and a few days of troubleshooting later, removing FullAccess to the mailbox and setting folder level permissions was advised.
I went back to check the permissions of the problematic mailbox a few weeks later and found that the Add-MailboxFolderPermission which I added as “Reviewer” (FolderVisible, ReadItems) was changed to “Editor” for the majority of the delegated mailboxes. I removed all the permissions, but, for one pesky mailbox.
Remove-MailboxFolderPermission -Identity TargetMailbox:\Calendar -User AnnoyingBrokenUser -Confirm:$false
The problematic mailbox had its data set to in-place hold, and license removed. It was effectively archived off and no longer in use. It seems there is a bug there with “disabled” or “de-provisioned” mailboxes where the folder level permissions are not correctly cleared.
The error I was getting was:
There is no existing permission entry found for user
After not having my second decaf coffee for the day (It’s for the love of coffee and not for the caffeine hit that I drink it these days. Oh, and I know I can’t blame lack of brain function early in the morning on decaf coffee, but, I like to do it anyway to remind me of the time before decaf) I took a break and went for a glass of water. That turned into going downstairs and getting a decaf coffee anyway.
I thought about the other cmdlets that are available for “-MailboxFolderPermission” which include “Get-”, “Remove-” and also ‘Set-". I changed the approach as the permissions were already there. I entered in the following:
Set-MailboxFolderPermission -Identity TargetMailbox:\Calendar -User AnnoyingBrokenUser -AccessRights Reviewer -Confirm:$false
Et voilà! No error this time. I checked the folder permissions on the calendar again and of course they were changed. I’m not sure if the “AnnoyingBrokenUser” may come back to the company one day (that has happened quite allot on this current project) so leaving that in-place for now isn’t going to cause to much drama, as a work around. If the user does come back: then the permissions are there and ready to go again. Otherwise, it’s future Lucian’s problem….