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.
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.
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
I haven’t tried it, but if it’s going to work the security group would need to be Universal.
can security group which is not mail-enabled be added to mailbox calendar permission? I am not able to add that.
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
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?
I guess a nested calendar inherits the permissions of the parent calendar. I’ve never looked into this scenario, but that makes sense to me that it would work like that.
Thank you.
Hi Paul,
In Exchange 2007 – can we use Dynamic Distribution Group to grand access to share a mailbox mailbox folder calendar?
Thanks
No. For permissions you need to use a Universal Security Group (it can be a mail-enabled one but that is not required).
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?
How long did you wait before testing again? Had the users logged off/on after you made the group change?
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!
Group 1 and 2 are in the same OU named Roles.
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 🙂 )
Is Group 2 a universal group?
All groups involved are Universal – Security groups.
Are Group 1 and Group 2 located in the same OU?
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]