Update 10/6/11: This script has been updated. The new script addresses a minor bug that could cause incorrect users to be added to a DL. It also enables recursive ownership assignment. It will now recursively search thru the owning group and sub groups, to add all mailboxes it finds as owners of the DL.
You've migrated from Exchange 2003 to Exchange 2010. Your users are reporting that they're unable to modify distribution groups that they could in the past. In How to Manage Groups that I already own in Exchange 2010?, we showed you that in Exchange 2010, users had permissions to create new distribution groups and remove the distribution groups they owned.
This did help a few of your users but some are still unable to modify their distribution groups. You need to look into this….
When User1 tries to add a new member to the DistributionGroup1 distribution group, she gets this error:
Changes to the distribution group list membership could not be saved. You do not have sufficient permissions to perform this operation on this object.
In the past, User1 was able to add/remove members to the distribution group by using Outlook and didn't need to call the help desk for assistance. What has changed?
You know that you had previously configured SecurityGroup1 to be able to manage this distribution group. Did someone make a change to User1’s security group membership? You look at ADUC first. No change – the user's still a member of SecurityGroup1.
Next, you check the distribution group configuration in ADUC to verify that DistributionGroup1 is still being managed by SecurityGroup1.
Okay, so what’s the deal here? You know you recently migrated to Exchange 2010. So you take a look at DistributionGroup1 in EMC (which reveals that it's managed by SecurityGroup1, but also displays an 'Object Not Found' error).
This behavior is by design. In Exchange 2010, distribution groups can't be managed by groups - only individual users can manage groups. So it's possible that using Exchange 2003, you used groups to manage a distribution group. Group ownership was handled at a different level. Now that these mailboxes have been moved to Exchange 2010, members of these groups can't modify the group.
We've created a script to work around this limitation. Download Set-DistributionGroupOwners.ps1 (it is attached to this blog post).
The script will allow you to simulate a group having ownership of a distribution group in Exchange 2010. The script can be run in three different modes depending on the switches you pass.
$dn_storage = "CustomAttribute5"Change CustomAttribute5to the custom attribute of your choice.
You're now ready to run the script.
In this mode, run the script with both -DistributionGroup AND –GroupOwner parameters. Specify the distribution group (-DistributionGroup) and the group that you want to manage it (-GroupOwner). This will then set the DN of the owning group from –GroupOwner into the CustomAttribute you specified on the Distribution Group from –DistributionGroup.
In order to have DistributionGroup1 managed by SecurityGroup1, you would run the following:
A dump of the DL above shows that CustomAttribute5 is populated with the DN of SecurityGroup1 and the ManagedBy attribute remains with only SecurityGroup1 listed. Mode 2 is needed in order for members of SecurityGroup1 to be able to modify DistributionGroup1.
Neither Mode 2 nor Mode 3 will work until you have set the value of the customer attribute to the DN of the Owning Group. If you have already run the Script in Mode 1, then Mode 2 will configure the ManagedBy attribute for a single group. To run in Mode 2, simply specify only the –DistrubitionGroup switch and list the DL that you want to have processed.
In our example, we have specified group, DistributionGroup1. This step will then set members of the owning group on the ManagedBy attribute. They are now listed by individual name.
When you run the script with no switches, it will search AD for all Groups that have the defined custom attribute set to a DN. It will then process all of them as in Mode 2.
The script is designed to be run in this mode as either a one off type operation when you know updates are needed or as a scheduled task to keep everything in sync. A key point is that when populating the ManagedBy attribute, it overwrites existing values with the current members of the owning group.
Many special thanks to our scripting genius Matt Byrd, whose motto continues to be “If this needs to be done more than once, it’s getting scripted!”
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.