I seem to have encountered an issue while trying to set permissions on a calendar for the 'Default' user using the following command: Add-MailboxFolderPermission -Identity user@domain.local:\Calendar -User Default -AccessRights Author Unfortunately while the permission does appear to be updated when viewing the permissions in Outlook (and using the Get-MailboxFolderPermission cmdlet) if the user attempts to create an appointment in the calendar nothing appears to happen (no errors nor other visible feedback to the user). If the user is granted explicit rights using the Add-MailboxFolderPermission then they can create an appointment without issue. Interestingly if the explicitly defined rights are removed using the Remove-MailboxFolderPermission the user can still create appointments (using the inherited Default permissions I assume). The closest thing I've found on-line so far is http://www.flobee.net/found-a-bug-with-set-mailboxfolderpermission/ This seems to suggest that the process of explicitly defining the permissions to the Calendar may be modifying permissions to a second location - namely a free/busy folder. I have tried to find the 'FreeBusy Data' folder referenced but running Get-PublicFolder -Identity "\NON_IPM_SUBTREE" -Recurse does not list it. The closest I can find is \NON_IPM_SUBTREE\SCHEDULE+ FREE BUSY. I am unclear as to whether the problem is that I am missing the 'FreeBusy Data' folder referenced, whether the presence of this folder is a throwback from an earlier Exchange migration or if I am going down completely the wrong path. Is this an actual bug? Is there a workaround? Am I just being incredibly dense? Answers on a postcard... or preferably just added to the thread below... Many thanks, Scenario Spec: Outlook 2007 on Windows Server 2008 x64 Terminal Server connecting to Exchange 2010 SP1 to a mailbox that was migrated from Exchange 2007 SP2 yesterday. EDIT: So far Gen Lin has confirmed the syntax of the cmdlets and it has demonstrably worked on mailboxes but only if those mailboxes have been logged into at least once. It seems I had misconstrued the content of the blog I'd found and was erroneously pursuing FreeBusy Data in the Public Folder rather than FreeBusy Data in the sharing users' mailbox. This FreeBusy Data node does not seem to be created until the account is logged into for the first time.

It seems that there is an issue if the shared mailbox hasn't been logged on to before. Where this is the case I cannot see the FreeBusy Data folder in the shared mailbox using the MFCMAPI utility. Is there a way to scriptedly force the creation of the FreeBusy Data folder so we can set the ACL on the folder without needing to access the mailbox with each account first?

just to update, it seems i was wrong in my last reply; it worked on that occasion, but other mailboxes still have the issue that Luke states.