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
I ran into a similar problem and am finding your post helpful. What I see is mailboxes moved from our 2003 environment have the non_ipm_subtree\freebusy data however mailboxes created in 2010 do not, and Outlook 2003 users are getting “Unable to Open Free/busy information”
Looking for answers…
Hi,
What is the identity syntax exactly for room resource? I have tryed that same syntax with different variations for identity in Exchange Shell but it allways says that identity could not be found. Resource user account is by default disabled, could this influence on this matter?
You can just use the alias for the identity. The AD cmdlets can be tricky when using identity, but the Exchange ones let you use display name, alias, SMTP address, etc.
Tried to create a new mailbox with powershell, but when I tries to run the “fix” does it state that freebusy data is missing…
Set-MailboxFolderPermission $mailbox”:\non_ipm_subtree\freebusy data\” -User default -AccessRights Reviewer
You won’t be able to set the permission on the Freebusy Data folder until the mailbox has been accessed with Outlook (or, perhaps, when it receives an email message) since the folder structure doesn’t exist until then. I even accessed a new mailbox with MFCMAPI and that alone doesn’t result in the folder’s creation. It wasn’t until I opened the inbox from another profile that MFCMAPI showed the Freebusy Data folder existed).
The idea were to create rooms from a CSV-file and assign “Default” as “Reviewer”. But if I cant assign the correct permissions without opening it manually first, then does it kinda sux (Hope Microsoft will fix this). Guess the next best thing is to assign Full Permission to me, pause the script, open Outlook, close Outlook again, and then continue the script and assign permissions – if I don’t wanna do it 100% manually.
The mailbox folder structure also gets created when a message is sent to it. (I just don’t recall if the FreeBusy Data folder is, too.) So you might be able to have the script send it an email, pause it long enough to ensure delivery has taken place (15 seconds should be more than enough), then assign the permission.
We had the same problem and the commands only worked AFTER we opened the resource in an Outlook client. Opening in OWA didn’t even work.
Pingback: Allow users to view Exchange 2010 Resource calendars in Outlook 2010 | JamesKinnaird.ca