How to manage groups with groups in Exchange 2010

[The_Exchange_Team]

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….

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 (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.

1. 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.
2. 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.
3. 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?

1. 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.
2. 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.
3. 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 CustomAttribute5to 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.

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!”

Tammy Anthony

set-distributiongroupowner.zip

[#2]

Thanks Tammy, we've had this problem and it's good there's something to help us.

We've got a related problem with group membership.  Before Exchange 2010, you could permission a group so people could add and remove *themselves* using Outlook.  This doesn't seem to work anymore.  You can configure groups to allow this, but users have to add/remove themselves with Exchange Control Panel, it doesn't work using Outlook, they get the same error message as above.  This isn't a great end-user experience.

Has this functionality also been lost in Exchange 2010?  

[#3]

Wow... this phrase kind of stumps me because you don't provide a technical explanation as to why: "In Exchange 2010, distribution groups can't be managed by groups - only individual users can manage groups.".

It is beyond me why this functionality was lost and that Exchange 2010 makes people either script up and forever maintain processes to simulate group based administration, or loose the functionality altogether.

Don't get me wrong, the script sounds really impressive and we are glad you are providing us with something versus nothing, but loosing the ability to do group based administration w/o a technical explanation is somewhat dumbfounding because this change in support is counter-intuitive.

[#4]

Great timing ... we really needed this!  If we want to "chase nested groups" I assume it is as simple as changing the line $Userstoset = Get-ADGroupMember $_.($dn_storage) to $Userstoset = Get-ADGroupMember $_.($dn_storage) -recursive ?

Thanks!

[#5]

How does this effect 2007 groups that have groups that administer permissions?

[#6]

Is this because in previous Exchange versions, Outlook was getting a referral for NSPI and ended up talking straight to a global catalog for directory purposes and now in Exchange 2010 the referral takes it to the Address Book Service running on the Client Access server? With the CAS being unable to enumerate group memberships for some reason... ?

[#7]

This was a major pain for us in upgrading to 2010.  So many great things added yet something so fundamental was removed and caused us months and months of pain.  People changed teams/departments or were hired and we had to write a program as part of the process so can automatically manage their teams groups.  Not to mention the semi-open forum based groups that allowed people who belonged to certain teams/departments join and leave groups as they please.  Way to really think that one through guys.  Remove a feature that has been in place for 10 years or more and make companies who used it eat the cost of development.  What exactly did you achieve by removing this anyway?  I was so astonished when I discovered this new functionality last year that I actually opened a case with MS Premier Support services because I knew it had to be a bug.  Microsoft has always evangelized the benefits of leveraging group based management.  What could possibly have made you want to take such huge step backwards?

[#8]

When Exchange 2010 moved to the new RBAC based model for permissions management, this functionality was lost in translation.  Currently RBAC will only evaluate users who are directly listed as being managers of the Distribution list and will not even look at groups or group membership when determining if you can edit the DL.  

The product group is aware of this limitation and the fact that it is impacting to customers but has determined that it is not feasible to implement this change in Exchange 2010.  They do already have this as an item for consideration against Exchange 15.

[#9]

It won't be fixed with a Service Pack ? That's mean 2-3 years until the fix ? How bad. We are migrating soon from 2003 to 2010 (15 000 users), this gonna be a show stopper.

[#10]

We experienced this problem 6 months ago and it had quite an impact. I was surprised it had not been documented by Microsoft. Sorry but this is unacceptable Microsoft. Such a limitation should have been identified in beta testing.

[#11]

I tried this- but it did not work for me

[PS] C:Windowssystem32>cd c:

[PS] C:>.test.ps1 -DistributionGroup tdl -groupowner tsg

The term '.test.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the

spelling of the name, or if a path was included, verify that the path is correct and try again.

At line:1 char:11

+ .test.ps1 <<<<  -DistributionGroup tdl -groupowner tsg

   + CategoryInfo          : ObjectNotFound: (.test.ps1:String) [], CommandNotFoundException

   + FullyQualifiedErrorId : CommandNotFoundException

Any thoughts?

[#12]

Thank you for your response Tammy, but I'm at a complete loss as to why it's not feasible to work this into Exchange 2010 via service pack?  I wrote a Windows service in C# to handle synchronization of DL managers based on AD group membership in under a month.  All while performing other project related tasks.  You are Microsoft.  You wrote Exchange.  You wrote AD.  You already wrote this functionality before. You have and are the technology.  The functions required all lie within the platform SDK and/or .Net framework to be easily leveraged by even the greenest of programmers.  Almost all other AD integrated Microsoft programs are completely capable of handling group membership based authorization, nesting and all.  Group based based management is a core concept of delegation, reduced administration overhead, and support costs.  What can we do as faithful Microsoft customers to get this functionality bumped up and added to Exchange 2010?  We're just asking for a bit of your time to make Exchange Administrators around the world breathe a little easier.

[#13]

This "problem" was introduced as part of changes made to the RBAC model in Exchange 2010 SP1.  The actual problem is fairly well known, even though Microsoft doesn't like to talk about it.  It is the result of a philsophical shift in the approach to security with regards to "split permissions" between Active Directory and Exchange administrators.  This problem centers around mail-enabled security groups almost exclusively.  There are various workarounds that can be used to adequately manage pure distribution groups, but once you make that group a security principal, RBAC takes over and whacks you on the head.

Microsoft fixed this partially in Update Rollup 3 when they added the -BypassSecurityGroupManagerCheck flag back to the Powershell command that gets executed when you attempt to update security group memberships from within the Exchange 2010 admin console.  The problem is that they DID NOT add this flag to the behind-the-scenes scripting that occurs when you do the exact same thing from OWA (or Outlook, which is probably impossible with the new model).  The fix for this is pretty darn simple.  Just add the -BypassSecurityGroupManagerCheck flag to the scripting that occurs behind the scenes when a properly configured RBAC user is trying to manage a mail-enabled security group.  You did it for the EMC, now do it for the ECP in OWA.  Please.  No waiting for Exchange 2020 or service pack 300.  You could fix this in an update rollup tomorrow.

[#14]

BTW, I should add that I wrote a custom Powershell script to run as a scheduled task that does something very similar to what the script mentioned above does.  Even though it works, it's a very ugly approach to fixing this problem, and God help me when I have to undo this all someday.  It's insane to have to make multitudes of people direct "owners" of a security group just to be able to manage the membership list.  What's worse, you can't even make someone an owner using the ECP unless you're already an owner yourself, so delegating this out to other admins is a challenge unto itself.  This is, by far, my biggest gripe about Exchange 2010.  In order to address the relatively few cases where the Active Directory administrator is a separate function from the Exchange administrator, you turned a decade-old management system on its ears.  This was a very poorly thought out decision.  Just admit it and fix it, and we'll forgive you for it.

[#15]

It's quite obvious that this new breed of developers have zero appreciation for what we AD and Exchange techies regard as normal and SOP. We all know that best practise is to use security groups for things like this but in the face of all this we are forced to specify users directly???

I suppose it's OK. I mean, I dose up on Cola and tell my kids off for doing the same!

[#16]

If you have multiple DGs with some commonality in naming convention, that needs to be managed by a single SG, instead of doing this one by one, you can use the script below( note the wild card and path to the original script):

$DLs = Get-DistributionGroup <DG.*>

$DLs | %{

 c:scriptsSet-DistributionGroupOwners.ps1 -DistributionGroup $_.Name -GroupOwner SG

}

Thanks to Mike Pfeiffer for the script and Bhargav Shukla for the idea :)