If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.
Add Access Rights to a Security or Distribution Group via Management Shell in Exchange 2013
We are in the middle of a conversion to Exchange 2013 Standard from 2007. With the new calendar features in OWA and some other training goals for our staff, we would like them to use their calendars and their associates calendars. The majority of our staff's ONLY interaction is via OWA. I'm trying to automate sharing of the calendar with everybody in a location for them (the associates who have needed this in the past, I have done manually in Outlook for them).
In trying to automate this task, I'm attempting to use Add-MailboxFolderPermissio
In all cases I get output:
Note, I'm still working on this in my test environment and have created both universal distribution groups and universal security groups to test with which mimic the names of my production groups. The difference is the domain is lmplay.com vs my real one.
I have tried a few different versions based on both EE searches and general internet and find some scripts to do this one time.
We regularly have people move between locations, onboard, offboard, etc fairly frequently. Sharing via group membership is key; an iterative or piped script which looks at group membership or OU membership and iterates and makes changes on every mailbox while that would work, it not ideal and not easily supportable.
Therefore, do I have a syntax issue above that I'm doing this wrong, or is the -user parameter of Add-MailboxFolderPermissio
In trying to automate this task, I'm attempting to use Add-MailboxFolderPermissio
[PS] C:\>Add-MailboxFolderPermission -Identity SusieS@lmplay.com:\Calendar -AccessRights ReadItems -User SalesAssociates-Store4@lmplay.com
[PS] C:\>Add-MailboxFolderPermission -Identity SusieS@lmplay.com:\Calendar -AccessRights ReadItems -User "LMPLAY\SalesAssociates-Store4"
[PS] C:\>Add-MailboxFolderPermission -Identity SusieS@lmplay.com:\Calendar -AccessRights ReadItems -User "lmplay.com\SalesAssociates-Store4"
In all cases I get output:
The user "SalesAssociates-Store4@lmplay.com" is either not valid SMTP address, or there is no matching information.
+ CategoryInfo : NotSpecified: (:) [Add-MailboxFolderPermission], InvalidExternalUserIdException
+ FullyQualifiedErrorId : C35EE919,Microsoft.Exchange.Management.StoreTasks.AddMailboxFolderPermission
Note, I'm still working on this in my test environment and have created both universal distribution groups and universal security groups to test with which mimic the names of my production groups. The difference is the domain is lmplay.com vs my real one.
I have tried a few different versions based on both EE searches and general internet and find some scripts to do this one time.
We regularly have people move between locations, onboard, offboard, etc fairly frequently. Sharing via group membership is key; an iterative or piped script which looks at group membership or OU membership and iterates and makes changes on every mailbox while that would work, it not ideal and not easily supportable.
Therefore, do I have a syntax issue above that I'm doing this wrong, or is the -user parameter of Add-MailboxFolderPermissio
Who is Participating?
Are the groups mail enabled? If not then that is the problem. Exchange can only use mail enabled groups for permissions.
Simon.
Simon.
The groups are mail enabled security groups with universal scope but the cmdlet still fails.
[PS] C:\Windows\system32>Get-DistributionGroup SalesAssociates-Bocage
Name DisplayName GroupType PrimarySmtpAddress
---- ----------- --------- ------------------
Sales Associates - Bocage Sales Associates - Bocage Universal, SecurityEnabled SalesAssociates-Bocage@lmp...
[PS] C:\Windows\system32>
Update: A new group worked just fine (that is, created through ECP).
My test group does not have dashes in it, maybe that's a key?
That would be a lot of groups to recreate and / or deal with nested membership properties with not to mention, tracking down what ACL's are applied to those groups (production wise, thinking outside of test). Is there another property that might be lacking somewhere?
My test group does not have dashes in it, maybe that's a key?
[PS] C:\Windows\system32>Get-DistributionGroup SalesAssociates-Bocage
Name DisplayName GroupType PrimarySmtpAddress
---- ----------- --------- ------------------
Sales Associates - Bocage Sales Associates - Bocage Universal, SecurityEnabled SalesAssociates-Bocage@lmp...
[PS] C:\Windows\system32>Get-DistributionGroup TestGroup1
Name DisplayName GroupType PrimarySmtpAddress
---- ----------- --------- ------------------
TestGroup1 TestGroup1 Universal, SecurityEnabled TestGroup1@lmplay.com
[PS] C:\Windows\system32>Add-MailboxFolderPermission -Identity SusieS:\Calendar -AccessRights ReadItems -User "TestGroup
1@lmplay.com"
FolderName User AccessRights
---------- ---- ------------
Calendar TestGroup1 {ReadItems}
[PS] C:\Windows\system32>
That would be a lot of groups to recreate and / or deal with nested membership properties with not to mention, tracking down what ACL's are applied to those groups (production wise, thinking outside of test). Is there another property that might be lacking somewhere?
No spaces in the alias; there are spaces in Display name of the main groups (but not the one I made for the above)
I'll have to try a few more of them and see.
I'll have to try a few more of them and see.
Display name is just that - a display name. It isn't used by Exchange for anything.
Aliases though can cause a problem. Were these groups converted from some other type in the past?
Simon.
Aliases though can cause a problem. Were these groups converted from some other type in the past?
Simon.
They go back to our Exchange 2003 days and used to be Global Distribution Groups. In exchange 2007 we had to migrate them to Universal groups.
Some of the newer ones (newer stores) started as Universal Distribution Groups until recently (last 8 or 9 months) and we changed them to be mail enabled Universal Security Groups.
We operate a single forest, single domain model; all DC's are in one site and all DC's are global catalogs so prior to Exchange 2007 we never used any universal groups but some of these go back.
If I had to recreate and redo them, we are not talking the end of the world ACL wise just some (a lot) of painful time.
Some of the newer ones (newer stores) started as Universal Distribution Groups until recently (last 8 or 9 months) and we changed them to be mail enabled Universal Security Groups.
We operate a single forest, single domain model; all DC's are in one site and all DC's are global catalogs so prior to Exchange 2007 we never used any universal groups but some of these go back.
If I had to recreate and redo them, we are not talking the end of the world ACL wise just some (a lot) of painful time.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
Tried changing the alias on one of the groups and got a bunch of warnings about upgrading the group to the current version and cannot modify it using older management tools.
Let it do that, and then try the Add-MailboxFolderPermissio
Swapping the Alias' around is not ideal but at least now I know it can be done; I just need to find how to (and when) to migrate all the groups to the new format. I missed that step in my research and reading (and oddly, that doesn't seem to be an option in recipient migration that I see easily).
Patricksr1972 - the extra step in the post that you posted / referenced - I think that "hack" works because the new group they are making is the new format and they're adding an old one to it and utilizing group nesting.
On to researching more on groups now (and how group owners and all these new moderator options work)
--ML