Unable to assign Mailbox Folder Permissions to a security group

Question

_{Wednesday, March 21, 2012 10:52 PM}

I'm running Exchange 2010 SP2 and unable to assign Mailbox Folder Permissions to a group.

I'm running the following command:

Add-MailboxFolderPermission -Identity [email protected] -User [email protected] -AccessRights Reviewer

If I use the primary SMTP address the error reads "The user "group@domain" is either not valid SMTP address, or there is no matching information.

If I use domain\group name, the error reads "The user "Group" was found in Active Directory but isn't valid to use for permissions. Try an SMTP address instead."

Anyone have a solution?

DB

All replies (10)

_{Thursday, March 22, 2012 7:49 PM ✅Answered}

I deleted the group and re-created it (the same way I created it the first time) and now it works.  I'm not sure why, but it's resolved!

DB

_{Wednesday, March 21, 2012 11:32 PM}

Is the group mail-enabled?

I honestly don't know if that's a pre-requisite for assigning permissions but might explain the part about it not being a valid smtp address. 

Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

_{Wednesday, March 21, 2012 11:35 PM}

The group is a Universal Security Group that has been mail enabled.  I would except that only a security group would work, but for the fun of it, I created a distribution group and attempted to assign rights.  I get the same error.

DB

_{Wednesday, March 21, 2012 11:54 PM}

Can you assign the permission to a single user?

Here the parameter is -user

http://technet.microsoft.com/en-us/library/dd298062.aspx

But I would think you could use a group instead (???).

Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

_{Wednesday, March 21, 2012 11:56 PM}

Yes, if I replace [email protected] with a user UPN it works.

DB

_{Wednesday, March 26, 2014 9:55 AM | 7 votes}

I had the same issue converting a group created as a Distribution Group to a Security Group.

I compared in ADSIEdit and found the attribute msExchRecipientDisplayType was different from a group orginally created as a Distribution Group vs a group orignally created as a Security Group.

I then found the following link explaining the problem and solution: http://blogs.msdn.com/b/pepeedu/archive/2010/08/26/how-to-upgrade-a-universal-distribution-group-to-a-universal-security-group.aspx

In summary, Exchange will recongise the group conversion if you run the following command:

       Set-DistributionGroup -identity convertedGroupName

_{Friday, November 28, 2014 12:39 PM}

We had the same issue here (EX 2010, 2008R2 DCs).

This is my solution:

I found out that after putting the user into the group that gets full access for the mailbox, I have to log off and log on the user from his/her workstation, then resart the exchange information store and voila -> access granted !

Logging off and back on the user seems logical, because group membership will only change after the next log on.

Restarting the Information Store seems logical, if , as I guess, Exchange only does group expansion on a periodically basis (I didn't had the time to check and wait..)

But if you restart the Information Store before the user has logged off (even with outlook closed) and then log off/on he user, access will not be granted. I really don't understand this behavior.

Maybe there is someone out there with deeper knowledge of Exchange/AD that can explain this.

The solution with "Read Members" didn't work. I think the Exchange Servers already get the "Read Members"-Right through their membership in "Exchange Trusted Subsystem". That group has the right in question.

Hope this helps.

EDIT: Now I found out that it has to do with the Kerberos tickets for that user in question. As long as there is a ticket with the old group memberships, the restart of the Information Store doesn't update the access rights. klist purge (on all clients the user is looged on to) before restarting the information store does the job too. Maybe this is about Exchange SID caching.

_{Monday, January 8, 2018 8:20 PM}

Can confirm Andrew's post is the fix and that this problem still exists in Exchange 2016... 

_{Monday, September 16, 2019 12:53 PM}

Just to freshen up a 5+ year old correct solution - this is still the case with onprem Exchange 2016. Changing the DL to a security group to allow setting Calendar permissions required an extra Set-DistributionGroup -identity groupname to fix things. Really appreciate how we can share the results of what must have been a bit of an investigation, great work Andrew.

_{Thursday, March 12, 2020 8:56 PM}

the msExchRecipientDisplayType property was set to 1 as it was Distribution Group 
that could be solved by changing the property value to 1073741833 using ADSIedit