Update 6/28/12: Microsoft has finally fixed this issue as of SP2 Update Rollup 3, as noted in KB 2510607.
While working with conference room calendars at my company, I set the Default user permission to Reviewer so that anyone can open the calendar to see meetings in a layout that is far easier to work with than the scheduling assistant. If you set the permission with Outlook, everything works well. If you use EMS to do it with Set-MailboxFolderPermission (Exchange 2010 SP1), it runs successfully, but not everything works well. The main thing I have noticed is that users can’t print the calendar.
I used MAPI Editor (née MFCMAPI) to see what is different when using Outlook versus PowerShell. The permission set on the Calendar folder is the same with both methods, so I suspected it had something to do with the Freebusy Data folder. I charted what permission is set on this folder with both methods with different users, and also adding a user and changing an existing one.
What I have found is that both Add-MailboxFolderPermission and Set-MailboxFolderPermission work correctly when applying permissions for named users. Setting any permission on the calendar results in the person being granted Editor permission to the Freebusy Data folder. (If you remove the permission on the calendar, the Editor permission remains on the Freebusy Data folder, which isn’t a problem.)
There is an issue, however, when setting the permission for the Default user entry which, of course, is a special user that simply represents any user who isn’t explicitly listed in the ACL. Permission on the Freebusy Data folder is not updated when setting the permission for the Default user entry on the Calendar folder, leaving the entry with a bitmask value of 0 (no rights) as seen in MAPI Editor.
To work around this issue, I looked into using Exchange Web Services and also the EWS Managed API. I ran into problems enumerating the ACL on the Freebusy Data folder (it is listed as empty). While trying to resolve that I ended up finding a much simpler solution which doesn’t need anything more than Set-MailboxFolderPermission. You can access the Non_IPM_Subtree with the cmdlet just by including it as part of the path. The workaround is to manually set the permission on the Freebusy Data folder after you do it on Calendar. This is only necessary when setting the permission for the Default user entry.
Set-MailboxFolderPermission ‘MB Identity:\calendar’ -User default -AccessRights reviewer
Set-MailboxFolderPermission ‘MB Identity:\non_ipm_subtree\freebusy data’ -User default -AccessRights reviewer