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.

Check out Ilse's blog here that describes how to do it... http://blogs.technet.com/b/ilvancri/archive/2009/11/24/exchange-2010-and-then-there-is-the-long-awaited-cmdlet-add-mailboxfolderpermission.aspx It looks like you're doing it correctly. I have seen delays in permissions that are applied. If you haven't tried waiting for 30 minutes after applying permissions then that is definately worth a try. PeterPeter O'Dowd

Hi, I also reproduced it in my lab. I got a warning from the windows notification area when trying to create a new meeting: I will forward this problem to Exchange product team. The steps in the link you provided can work around this issue. It works for me. Set-MailboxFolderPermission ‘your_mailbox:\calendar’ -User default -AccessRights author Set-MailboxFolderPermission ‘your_mailbox:\non_ipm_subtree\freebusy data’ -User default -AccessRights author Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks Gen Lin-MSFT

thankyou so much for that Gen Lin - that second line fixed it for us too. it's saved me a morning of RSI at the expense of around 8hours research into this issue.... i guess i can use google properly this morning :)

@Gen Lin: Thanks for your reply. To confirm should I be able to see \non_ipm_subtree\freebusy data if I execute the following: Get-PublicFolder -Identity "\NON_IPM_SUBTREE" -Recurse EDIT: I've just realised why our users were getting no visual feedback at all - the group policy applied to the TS supresses baloon notifications!

@Gen Lin: Thanks for your reply. To confirm should I be able to see \non_ipm_subtree\freebusy data if I execute the following: Get-PublicFolder -Identity "\NON_IPM_SUBTREE" -Recurse EDIT: I've just realised why our users were getting no visual feedback at all - the group policy applied to the TS supresses baloon notifications! EDIT 2: A colleague has just pointed out to me that the cmdlet Set-MailboxFolderPermission does not see to be looking for the '\non_ipm_subtree\freebusy data' in the public folder but may be looking for this information in the mailbox of the user to be shared. Is this correct? EDIT 3: Using MFCMAPI I have identified the ACL table for the Freebusy Data node on my own mailbox and can see the default 'Default/Anonymous' accounts listed. Now I just need to figure out how to bind to another users' mailbox using MFCMAPI...