When you are assigning shared calendar permissions in Exchange Server 2010 you may encounter situations where users who are members of a group that is nested within the group you grant permissions to still can’t access the calendar.

This can occur when one of the groups in the chain of nested groups is not a Security group. Only Security groups can be used to apply ACLs to objects, Distribution groups can’t be used for this.

In the example below a group has been granted permissions to the calendar, and two users are made members of the parent group through different nested groups.

Exchange 2010 Shared Calendar Permissions and Nested Groups

In this situation the first user will be able to access the shared calendar because only Security groups exist in the chain of nested groups for them. However the second user will not be able to access the calendar because of the Distribution group that is in their chain of nested groups.

The solution is to simply convert any Distribution groups to Security groups. They can remain as mail-enabled Security groups and still be used for email purposes, but will now also be able to be used for granting access to resources as well.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. kartheen

    This is the message i get
    Add-MailboxFolderPermission -Identity “test:calendar” -User “PRODMailbox global_digital_marketing” -AccessRights editor

    The user “PRODMailbox global_digital_marketing” is either not valid SMTP address, or there is no matching information.
    + CategoryInfo : NotSpecified: (0:Int32) [Add-MailboxFolderPermission], InvalidExternalUserIdException
    + FullyQualifiedErrorId : 105F4A23,Microsoft.Exchange.Management.StoreTasks.AddMailboxFolderPermission

  2. kartheen

    can security group which is not mail-enabled be added to mailbox calendar permission? I am not able to add that.

  3. Jake

    Paul thank you, can’t believe I didn’t think of this. Everything is working now. Awesome work by the way. This is my #1 website I like to check for answers to my questions because the website is very clean with screenshots too that you can copy the shell commands right out of. I started as an Exchange Admin about less then a year ago with no Exchange experience and your website has been more then helpful. Thank you

  4. Andrew

    Paul,

    We have something similar (I think!), whereby the NESTED calendars do not allow the user to EDIT the permissions already assigned to other people.

    You can see the permission level there (eg EDITOR), but it’s greyed out.

    The generic “calendar” at the top level works fine, and does allow the user to edit permissions as normal.

    Any ideas what this is?

    1. Avatar photo
  5. Lang

    Thank you.

  6. Lang

    Hi Paul,

    In Exchange 2007 – can we use Dynamic Distribution Group to grand access to share a mailbox mailbox folder calendar?

    Thanks

  7. Cy

    The article described the exact issue but after change the UDG to USG didn’t work. I still had to individually gave users rights to the calendar. Any idea?

      1. Cy

        Well I guess I didn’t wait long enough. I was working on something else and checked again today and it worked fine for those users in the nested groups. Thank you so much!

  8. Hein

    Group 1 and 2 are in the same OU named Roles.

  9. Hein

    I thought i found what i needed but sadly no ;). I have a security group which has Send As rights on a mailbox. Within this security group are two other security groups with users in each group. Group 1 can Send As and Group 2 can’t. All are security groups so it should work.

    If i take the user of Group 2 and place them directly in the security group that has access to the mailbox then they can Send As.. weird? I think so. Solution? Not found yet (kinda hoping you can shed some light on this 🙂 )

      1. Hein

        All groups involved are Universal – Security groups.

    1. Rob

      Hi Hein, Perhaps this would help:
      The RestrictionMethod value determines how the categorizer will process restrictions. If you set the value of RestrictionMethod [on the Exchange Transport] to 2, the transport components on this server that runs Exchange Server will not expand membership of distribution groups when the server checks restrictions.
      [source: https://technet.microsoft.com/en-us/library/aa998498(v=exchg.80).aspx]

Leave a Reply