Exchange 2010 - Granting write permission for calendar sharing with OWA 2010
by, 25th February 2012 at 11:34 PM (80663 Views)
Ok - so from Outlook, you've been able to share your calendar with another user for ages. The problem is there haven't really been many options around automating this. Well - enter some handy new features in Exchange 2010.
The calendar sharing feature introduced in Outlook Web App 2010 (OWA) allows a user to grant access to their calendar to another user. To access the option, click on the Share option when in the Calendar and then on Share This Calendar. You’ll then be able to select the user(s) that you want to share your calendar with and define the level of information you want the recipient to be able to see in your calendar. Now, this is all well and good - because as an admin, you can open their mailbox through OWA logged on as you (you do give admins permissions to other users mailboxes right through delegation?) - and do this for them.
The recipients are then sent an email message with a link in it which enables them to create the "OWA" or "Outlook" shortcuts to the calendar. All they have to do is simply click on the Add This Calendar link. OWA will then add the calendar to the list of available calendars and the user can then access your calendar whenever they want by simply clicking on the calendar’s entry to instruct OWA to open it. It breaks it down as My Calendar, and Other Users Calendars.
So far so good right? The user will be able to see the calendar, but they won’t be able to add anything to it or make a change to an existing appointment. In short, they are restricted to “Reviewer” access. You can confirm this by clicking on the Change Sharing Permissions option in the Share menu, when you’ll see something like the screen shot shown below. In this case, just one other user has access to the calendar and all they have is Reviewer access, so it shouldn’t come as a surprise that they won’t be able to add or edit items in the calendar. Now, you will be thinking that you can then click on the "Change Permissions" option and increase those permissions to "Editor" right?
Sadly - wrong! The Exchange team left this out annoyingly - in the same way the pre SP1 version of OWA 2010 didn't have an option for printing the calendar. So...in short - Im hopeful they will get round to this.
In the mean time, you need to get down and dirty with a bit of Powershell to sort this one out. Actually, when you think about it, this is a good thing, as you could Powershell it from the start. There is one gotcha here tho - you can't give a user "Editor" on a calendar without them already having "Reviewer" - which is another annoyance!
What do you need to do then.... well, here we go!
We need the the Set-MailboxFolderPermission cmdlet, which is the underlying command that manipulates folder permissions. The command that we need to run is:
Set-MailboxFolderPermission -Identity alias:\Calendar -User UsertoGetRights -AccessRights Editor
Now, remember I said that you can’t run the Set-MailboxFolderPermission cmdlet to alter a permission on a folder unless a permission has already been granted to the folder for the user. If you want to add Reviewer permission for someone who doesn’t already have access to a calendar, you have to run the Add-MailboxFolderPermission cmdlet with a command like this:
Add-MailboxFolderPermission -Identity alias\Calendar -User UsertoGetRights -AccessRights Editor
To confirm that everything has gone to plan, we can use the Get-MailboxFolderPermission cmdlet to validate the permissions on the folder. This lists out the users who have the various levels of permissions.
Oh, and just for fun - and to prove where the Exchange Team need to do some more work - go back into OWA and take a look at the shared calendar permissions now. You will notice it says "Editor" but it is also all greyed out, and the button to change is also dead. The code to support dealing with this permission level isn't finished - but at least OWA knows about it rather than throwing a complete wobble at it!
Total Trackbacks 0