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….
Issue
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.
Figure 1: User gets a permissions error when trying ot modifying a distribution group membership in Microsoft Outlook
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.
Figure 2: The user’s still a member of the security group that’s configured to manage the distribution group
Next, you check the distribution group configuration in ADUC to verify that DistributionGroup1 is still being managed by SecurityGroup1.
Figure 3: The user’s still a member of the security group that’s configured to manage the distribution group
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).
Figure 4: EMC displays the security group with an ‘Object not found’ error
Why is Exchange 2010 doing this?
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.
So are there any workarounds?
We’ve created a script to work around this limitation. Download Set-DistributionGroupOwners.ps1 from the Script Center.
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.
- Mode 1 – Set Ownership for a particular distribution group. Modifications to the ManagedBy attribute are not set at this time. It will simply modify a Custom Attribute to have the information needed later when the script sets the ManagedBy attribute.
- Mode 2 – Modify the ManagedBy attribute of a specific distribution group so the members of either a security group or distribution group can manage it.
- Mode 3 – Is designed to be run as a scheduled task and ensure individual members of a group have ownership of the Distribution Group which they are set to own. This mode is used if you prefer to automate the process and perhaps run it nightly to look for any changes to security group and distribution group membership.
How do I run this thing?
- Windows 2008 R2 is required to run the script. This was needed in order to support Security Groups owning Distribution Groups. This does not have to be run on an Exchange server but the Exchange management tools must be installed.
- Download the script. The Set-DistributionGroupOwners.ps1 script is now available from TechNet Script Center. Download it and change the file extension to .ps1. I recommend Set-DistributionGroupOwners.ps1.
- Decide what CustomAttribute can be used in your environment. The script will populate the Distinguished Name (DN) of the group (specified in the ManagedBy attribute of the distribution group you want to manage) in a custom attribute. By default, this is CustomAttribute5, but this can easily be changed to use one of the fifteen custom attributes in the default schema. Find the following in Set-DistributionGroupOwners.ps1:
$dn_storage = "CustomAttribute5"
Change CustomAttribute5 to the custom attribute of your choice.
You’re now ready to run the script.
Mode 1 – Set Ownership of a Group
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:
Figure 5: The script populates the group owner’s DN in a custom attribute
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.
Mode 2 – Modify the ManagedBy attribute for one Group
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.
Figure 6: The script populates the distribution group’s ManagedBy attribute with (individual) members of the owning group
Mode 3 – Run the Script as a Scheduled Task to look all new modifications to Group Ownership
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.
Note: This script in its current form will NOT chase nested groups. It will only take members of the group that’s listed in the defined custom attribute. There are currently no plans to add nested group functionality to the script.
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!”
Source: Tammy Anthony
Catastrophic Failure 