How to Manage Groups that I already own in Exchange 2010?
Published Nov 18 2009 04:43 PM 221K Views

 

This one can be a bit counter intuitive for folks coming from any legacy version of Exchange...

Issue

You got your shiny new Exchange 2010 download and excitedly installed it on your 2010 hardware. You have setup all your CAS server settings, your DAG is up and running. Your pilot users have been moved over and everything went well.

Now you move over the executives and not two days later they are in your office complaining that they can't manage the distribution groups that they own. They were able to do it previously but now it isn't working.

A little bit of testing later and you see that they are right. You are hitting an error message in Outlook 2007 when trying to manage groups:

So what does the "Changes to the distribution list membership cannot be saved. You do not have sufficient permission to perform this operation on this object." error mean, when you are connecting to an Exchange 2010 server?

It means Exchange 2010 is doing its job - as designed...

Why is it doing this?

Exchange 2010 has quite a few features built in to allow your users to manage their own accounts and information. One of these features is the ability to manage distribution groups in a much richer format than Outlook 2007 provides.

This allows your users to join existing group, manage some of the properties of groups they own, membership in groups they own, and even create and remove groups. It is that last piece that got our beta customers a bit concerned. The ability to manage your own groups is good... the ability to create and remove groups - not so good.

Also this feature was turned on by default. So by default you would install Exchange 2010 Beta and any users you put on it could create and remove Distribution Groups. With that in mind the Product group decided to turn this feature off by default going forward and in RTM.

Turning it off is very easy... so is turning it on. All you have to do is assign the MyDistributionGroups RBAC role to the Default Role Assignment Policy. We even have the ability to do that in the ECP.

Since all of the built in RBAC roles have to function as parents to any roles that you create the product group had to leave the ability to create and remove distribution groups on this role to ensure that any customers that wanted their users to have that functionality would be able to assign it.

So how do I fix it?

"Fix" isn't really the right word. We need to modify the default solution to meet this specific need. For a number of customers the needs are going to be the following:

  1. I want my users to be able to manage distribution groups they own.
  2. I don't want them to be able to create distribution groups.
  3. I don't want them to be able to remove distribution groups even if they do own them.

To help customers fill these needs we have created a short little script. This script will allow you to make any combination of the above work in your environment.

The Manage-GroupManagementRole.ps1 script is now available as an attachment to this blog post.

How do I run this thing?

To run the script you need to copy the contents of the script to a text file on the machine you are going to run it on. Then save the file as a .ps1... I recommend Manage-GroupManagementRole.ps1 .

To fill all of the above requirements with minimal effort run the following from an Exchange Powershell Prompt:

Manage-Groupmanagmeentrole.ps1 -creategroup -removegroup

This will create everything you need with the correct settings using the default names in the script. If you would like help on the script you can either look in the contents of the file or run it with no switches.

What does the script do?

What the script does is actually rather simple:

  1. Creates a new RBAC role that is a child of the MyDistributionGroups Role
  2. Removes the cmdlets remove-distributiongroup and new-distributiongroup from the new role that was just created.
  3. Assigns the new role to the Default Role Assignment Policy

When complete your users will be able to manage distribution groups but not create or remove them.

Each step the script takes is documented in the script and you are welcome to extract just what you need from it. It is designed to handle more than just the basic scenario to give it a bit more flexibility.

What do I end up with if I take the defaults?

When finished you end up with a new role and a new role assignment. If we look at these in PowerShell we see:

Here is the Role that is created by the script. By default it is named MyDistributionGroupsManagement and is a child of the MyDistributionGroups role.

Here we can see all of the cmdlet that the role authorizes users to use. You can see that remove-distributiongroup and new-distributiongroup are not listed.

This is the piece that glues everything together. The role assignment is created using the name of the role and the name of the policy we are assigning the role too. The Default Role Assignment Policy applies to all users in the org by default. So everyone on Exchange 2010 will now have the ability to manage their own distribution groups.

Conclusion

Hopefully this post and the attached script will help you in getting your 2010 environment up and running where you want it. If you have any questions about the script or this process please feel free to post them here and I will do my best to address them.

- Matt Byrd 

6 Comments
Not applicable
Will this be fixed with a future release/roll-up ?
Not applicable
In those 3 steps, you never removed the old role from the default assignment policy.  Wouldn't you first have to create the new RBAC Role, remove the commands, remove the old role from the default asssignment policy, and then add the new role to the default assignment policy?

Or is it because you have a new role that is a child with less commands, it overides the old role?

RBAC is confusing as hell.
Not applicable
Boyfromcork,

Technially there is nothing broken here.  With the way that RBAC works and the desire to not turn functionality on for people that don't currently have it on, this is operating as designed.

Yes ... the experience could be better I won't argue with that, and we will see what we can do for SP1 but for now it is actually operting very well given the design of RBAC.

Iamme,

We can't remove the old role.  It is one of the default roles in RBAC and cannot be deleted.  The old role is not applying because we didn't create a role assignment for it.  As long as the "My Distribution Groups" box is unchecked in the ECP there is no role assignment linking the Default Role (old role) and the Default Policy.

I recommend that you read my post on RBAC and the Triangle of Power.  I will clear up how RBAC works and will make this article make more sense.

http://msexchangeteam.com/archive/2009/11/16/453222.aspx

-Matt
Not applicable
Oh I get it.  I forgot you left the old role unchecked.  Now when you created the new role, you did assign that so that applies, but not the old one.  Got it, thanks!
Not applicable
Thanks for this....really helped me out! But if I want to make it som that the owner of a distribution group also can create distribution groups within the group he already owns...is it possible. I don't want to give him the permissions to create distribution groups in general.
Copper Contributor

Great article thanks - thanks

 

Version history
Last update:
‎Apr 27 2020 02:29 PM
Updated by: