This post is a bit different than the other shared mailbox posts out there. A couple articles in regards to shared mailbox permissions include:
As you can see, these articles including adding SendAs and/or FullAccess. But what if you don’t want to provide FullAccess and/or SendAs and just want some basic permissions? This is where we ran into depending on how you create the shared mailbox. We were giving Editor+ permssions on a calendar for another user. This would allow us to create/edit/etc. You can see specifically what it allows by looking at the screenshot below.
So let’s say we have a shared mailbox called Aaron Tiensivu. Yes, I’m sure many of you recognize his name from his blog here. He’s a coworker of mine so I’m using him as an example. I am going to open his calendar from my Outlook client and try to modify his calendar. In order to do this, we need the following permissions:
This allows us me to open the shared mailbox’s calendar by going to File > Open > Other User’s Folder… and choosing the following options:
Again, in the case of my article, just think of Aaron Tiensivu as a shared mailbox here. :)
So I open the mailbox Aaron Tiensivu and verify that his calendar opens.
The Problem: The problem though, is that when you try to create an calendar item, you hear an error beep but no error shows up and you aren’t able to create/modify/etc. to the shared mailbox’s calendar. Turning up Outlook Logging doesn’t reveal any pertinent information. I did find two workarounds though which I don’t really care for and a third workaround which may or may not be considered a workaround to some.
Workaround 1: The first workaround was by giving FullAccess Permissions on Aaron Tiensivu’s Shared Mailbox to Elan Shudnow either via EMC or EMS. You can find out how to do that here.
Workaround 2: The second workaround is to convert the shared mailbox to a user mailbox and start using the shared mailbox concept utilizing a user mailbox (which enables the AD account) using the following command:
Set-Mailbox -Identity “Aaron Tiensivu” -Type User
Now the interesting thing is that this only happens when you create a shared mailbox, not convert it. What I mean by this, is this when you create a shared mailbox using the following PowerShell command, the issue occurs:
new-Mailbox -alias ATiensivu -name “Aaron Tiensivu” -database “Mailbox Database” -org Users -shared -UserPrincipalName firstname.lastname@example.org
What I noticed is that when you create a brand new user mailbox (not shared) using either the Exchange Management Console or the Exchange Management Shell, all the above delegation that previously failed with a brand new shared mailbox works as intended. And even when we convert the user mailbox to a shared mailbox, delegate access works as intended as long as it was first created as a user mailbox instead of a shared mailbox. It’s almost as if there’s some issue when you create a shared mailbox but it’s fine when creating a regular user mailbox and converting it to a shared mailbox.
A fellow MVP, Glen Scales, had recommended I try using a MAPI Editor and/or pfdavadmin to check the local freebusy folder in the NON_IPM_Subtree to see whether the correct permissions are being applied. Glen did point out that the Outlook client should be taking care of this permission. Unfortunately because we see that Shared Mailboxes work after converting them, our team moved onto other things for the remainder of the day due to a tight schedule. If I do find time, I’ll try creating a shared mailbox from scratch and check this out and update this post.
Now of course, you may not encounter this issue as I have. As IT people, we all know that sometimes things work in one environment and not the other. So if you do happen to have this issue and find yourself reading this blog entry, please submit a comment with your findings/information.