locked
Setting permissions on a calendar for the Default user using Set-MailboxFolderPermission RRS feed

  • Question

  • 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.

    Tuesday, February 15, 2011 12:57 AM

Answers

  • 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
    • Marked as answer by Gen Lin Thursday, March 3, 2011 2:18 AM
    Wednesday, February 16, 2011 9:46 AM

All replies

  • 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.

    Peter


    Peter O'Dowd
    Tuesday, February 15, 2011 4:24 AM
  • 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
    • Marked as answer by Gen Lin Thursday, March 3, 2011 2:18 AM
    Wednesday, February 16, 2011 9:46 AM
  • 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 :)

    • Proposed as answer by Bogdan_M Thursday, October 9, 2014 5:33 PM
    • Unproposed as answer by Bogdan_M Thursday, October 9, 2014 5:33 PM
    Tuesday, February 22, 2011 10:38 AM
  • @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...

    • Edited by Luke Maslany Tuesday, February 22, 2011 3:34 PM MFCMAPI to view ACL on 'Freebusy Data' node...
    Tuesday, February 22, 2011 10:56 AM
  • 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?

    Tuesday, February 22, 2011 3:40 PM
  • 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.

     

    Wednesday, March 2, 2011 11:07 AM
  • Did you make sure you've assigned a Delegate to the resource? That seems to be a prerequisite for Resource calendars.

    I've been tackling this same issue recently, and even after discovering this "fix", I can't find any supporting TechNet documentation to suggest I missed a documented configuration step.

    Cheers, Barnaby


    www.computingimprovements.com
    Monday, October 10, 2011 2:52 AM