Skip to main content


Office 365 – Allowing Users to Edit Exchange Groups They Manage

Exchange Hybrid and Directory Synchronization provide for the most full-featured integration experience with your on-premises messaging environment. Users, for the most part, are unaware of whether their mailbox is in the cloud or on-premises.
There are, however, a few limitations with Exchange Hybrid and Directory Synchronization.
One of these limitations is around distribution groups that have had managers assigned for administrative purposes. If you have users that manage their own distribution groups via Outlook, you’ll find that this functionality does not work once the group manager has been moved to Exchange Online. This limitation should hopefully not come as a surprise, it’s a topic I discuss with my clients during every Exchange Online engagement. It is also an issue where unfortunately there are not a lot of great options for resolution.
Below are some options that can help mitigate this issue in at least some scenarios.


The basic source of the issue is that when you’re using Directory Synchronization, objects are authored in your on-premises Active Directory. The synchronization to Office 365 is essentially “one-way” such that any change to a distribution group has to be made in Active Directory and then synced to Office 365.
Your Office 365 users are connecting to a cloud copy of the Global Address List (GAL) and as a result, cannot make changes to that copy. Thus, they cannot use Outlook to edit distribution groups that they are the manager of.
Trying to edit a distribution group via Outlook will result in the error below:
Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.
So now that using Outlook to manage on-premises distribution groups is not an option, we either push all that work back to the help desk or Exchange admins or we need to find another way.

Ways to Delegate Distribution Group Management

First, we need to determine how the permissions have been assigned in your environment. There are several ways that you can delegate “self-management” of distribution groups. The way in which the delegation has been made will determine your options for management.
Three common methods of distribution group delegation are:

  • Active Directory delegations by Organizational Unit (OU)
  • Populating the “Managed By” tab on the Active Directory object
  • Populating the Exchange “Managed By” or “Owner” field for the object

Method #1: Active Directory delegations by Organizational Unit (OU)
In this scenario, you perhaps have an OU that you’ve delegated out “Full Control” or other AD permissions to a set of regional admins or departmental admins. As part of this delegation, distribution groups within that OU inherit those AD permissions.
Method #2: Populating the “Managed By” tab on the Active Directory object
This would be assigning a single user on the “Managed By” tab of the Active Directory object and checking the box that says “Manager can update membership list”. This populates the “managedBy” attribute on the group and grants the manager the “Write Members” permission on the group. Keep in mind this field is singular and only one user can be selected as the manager.

Method #3: Populating the Exchange “Managed By” or “Owner” field for the object
Within the Exchange management tools, you can assign multiple users to the “Managed By” (Exchange 2010) or “Owner” (Exchange 2013) fields. These translate to the “msExchCoManagedByLink” attribute on the group object which is multi-valued. Interestingly, when populating multiple users as the group manager, the first one alphabetically is actually populated into the “managedBy” attribute and the rest go into the “msExchCoManagedByLink” attribute. However, the “Manager can update membership list” option is not checked on the group so the managers do not appear on the group’s ACL.

Options for Management

For self-management of distribution groups, it can be done via native Active Directory tools or the native Exchange tools. While there are some third-party tools out there that can assist, there’s not a specific tool I would endorse and they are outside the scope of this article.

If the permissions were assigned via Active Directory (methods #1 and #2 above) and the user is not in the Exchange “Managed By” / “Owner” field, then you will need to use the Active Directory tools.If the user was assigned permission using the “Managed By” / “Owner” field (method #3), then you will need to use the Exchange tools.

Managing via Active Directory Tools
As an Administrator, you’d likely just pop open “Active Directory Users and Computers” but that’s not exactly something your end users are going to do. There’s a Microsoft KB article that covers one of the options for end users: “Owners of an on-premises distribution group that’s synced to Office 365 can’t manage the distribution group in Exchange Online“.
Basically, the article says the user can run the following command:

C:\windows\system32\rundll32.exe dsquery,OpenQueryWindow

This does in fact work and we could probably even make it a bit more user-friendly by creating a shortcut for the user. This method should also work whether the user’s mailbox is in the cloud or on-premises but again, only works for groups where they’ve been delegated the rights in Active Directory.

Managing via Exchange Tools
If your users have previously been using Outlook to manage the groups that they own, this is where issues arise once their mailbox is migrated to Exchange Online. Outlook is no longer an option which leaves us with the Exchange Admin Center (EAC) in Exchange 2013. Through a little bit of Role Based Access Control (RBAC), we can grant users the ability to manage their distribution groups using the on-premises EAC.

Configuring RBAC for the Exchange 2013 EAC

This is dependent upon having an on-premises Exchange 2013 EAC; so it’s suitable in hybrid environments or in environments where you’ve held onto your Exchange 2013 server for management purposes (like this).
At a high-level, we’re going to do the following:

  • Create a new “Manage-MyDGs” role from an existing role
  • Remove any commands that allow actions other than updating existing groups
  • Create a new role group and assign it our new role
  • Change the write scope of the role assignment such that it only applies to groups that the user is set as the owner of in Exchange

This isn’t meant to be a primer on RBAC in Exchange; for more information on RBAC, check out “Understanding Role Based Access Control“.
Here are the commands:

New-ManagementRole -Name "Manage-MyDGs" -Parent "Distribution Groups"
Get-ManagementRoleEntry "Manage-MyDGs\*" | Where {$_.Name -ne "Get-Recipient" -and $_.Name -ne "Update-DistributionGroupMember" -and $_.Name -ne "Add-DistributionGroupMember"-and $_.Name -notlike "Get-*Group*"} | Remove-ManagementRoleEntry -Confirm:$false
New-RoleGroup -Name "Self-Managed Distribution Group Management" –Description "Members of this management role group can update the members of groups they are the managers of." -Roles "Manage-MyDGs"
Set-ManagementRoleAssignment "Manage-MyDGs-Self-Managed Distribution Group Management" -RecipientRelativeWriteScope MyDistributionGroups

Adding a user to the new “Self-Managed Distribution Group Management” in Active Directory will now allow the user to manage any distribution groups that they own via the EAC.
Logging into your on-premises EAC URL (“https://vdir/ECP”), they see the following:

It is important to note that users will actually see all distribution groups, not just the ones they manage. However, if they attempt to manage a group that they are not the owner of, they’ll receive an error that the group “isn’t within your current write scopes” and they “can’t perform save operation”.
While perhaps not as easy as updating groups via Outlook, it does allow you to enable your cloud users to manage their own on-premises distribution groups via a fairly intuitive web interface.

What about the Exchange 2010 ECP?

Unfortunately, I have not been able to reproduce the same functionality in the Exchange 2010 ECP. The RBAC works if the user’s mailbox in on-premises or if they don’t have a mailbox, neither of which solves our issue. Once the mailbox is in the cloud, the user receives an error when trying to access the ECP.

Looking Forward

I would like at some point to see Microsoft add more options when using Directory Synchronization. In particular, for organizations that have never had Exchange but are using Directory Synchronization, it would be nice to be able to author Exchange attributes in the cloud and use the native toolset. It seems like it would be easy enough to have a checkbox in Azure ADSync or the tenant that says “I have no on-premises Exchange or I want to author Exchange attributes in the cloud”.
However, with what we have today, the above is one way that you can help hand the self-management of groups back to your users.


  • Cloud users cannot manage on-premises distribution groups via Outlook
  • The method used to delegate access to the group will determine the options for management
  • Groups assigned management permissions via Exchange can be managed in the EAC
  • RBAC can be used to allow users to access the Exchange 2013 EAC for group management

Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.

Thoughts on “Office 365 – Allowing Users to Edit Exchange Groups They Manage”

  1. I followed the steps in your solution “Configuring RBAC for the Exchange 2013 EAC”, but when I try to test it using the Exchange Online user account I added to the “Self-Managed Distribution Group Management”, I get the message:
    Use the following link to open this mailbox with the best performance:
    According to the article you cannot use Exchange 2013 ECP if your mailbox is in O365. This doesn’t make sense to me since this is the group of users who need the solution you’ve described. I’m hoping you can provide a workaround which allows Exchange Online users to login to E2K13 ECP on-prem to manage the distribution lists.

  2. Joe Palarchio

    I noticed there was an error in how the commands were formatted by WordPress; I’ve corrected that and the steps should include four individual lines.
    Aside from that, make sure that your users go directly to the ECP URL (“https://…./ECP/”) and not the OWA URL (“https://…./OWA/”) otherwise they will get the redirect link.

  3. Is it possible to allow group managers to add/remove other owners (not just members)? How about rename the groups? This use to be feasible via OWA, but doesn’t look possible since we migrated to O365. Thanks!

  4. I just tried the PowerShell commands and it worked for me, but only after I added myself to the Discovery Management admin role group (local ECP – Permissions – Admin Roles) as well as the Exchange security group – Self Managed Distribution Group Management – in Active Directory.
    For me, if I wasn’t added to that Discovery Management group I could log-in to the ECP, but I couldn’t see any tabs (Mailboxes, Groups, Resources, etc).

  5. Joe Palarchio

    The Discovery Management Role should not be necessary. Sometimes there is a delay between the time you add your role and when it is active in Exchange. I did not have the Discovery Role when I tested this.

  6. As far as I can see, the second command needs to be edited to include a filter for the get-distributiongroup CMDLet as I also had the issue that I did not see any type of recipients when logging in with this role assigned.
    Get-ManagementRoleEntry “Manage-MyDGs\*” | Where {$_.Name -ne “Get-Recipient” -and $_.Name -ne “Update-DistributionGroupMember” -and $_.Name -ne “Add-DistributionGroupMember”-and $_.Name -notlike “Get-*Group*” -and $ -ne “get-distributiongroup”} | Remove-ManagementRoleEntry -Confirm:$false

  7. Hi,
    I was wondering if this would work if there are both Exchange 2010 and Exchange 2013 servers on-premises (in a O365 hybrid enviroment).
    I was trying this out and I seem to get an error in the New-RoleGroup command:
    The owner of the group should have the following recipient type details: UserMailbox,LegacyMailbox,SharedMailbox,TeamMailbox,MailUser,LinkedMailbox,User,UniversalSecurityGroup
    The Exchange Admin account’s recipient type is Mail User and it has a mailbox in the cloud.

  8. Thank you very much. This was very helpful. I was able to direct my user to her web interface and she was able to easily manage her members there. This change was an inconvenience, but your page truly help. So thanks again Joe.

  9. This is just what I was looking for now, I just need to do some screen shots to send to our users so they can do it.

  10. In the ECP, now the users are able to see all the groups, even the hidden groups. Is there a way to hide the hidden groups in the ECP?

  11. The option to manage via ECP with a distilled view being presented is interesting and far better than directing them to use ADUC. Thanks for sharing.

  12. Let’s say that I wanted to accomplish self-managed distribution groups via 3rd party tool. What would I search for? I know you said you wont endorse any and that it is not the purpose of this article, but can you point us in the right direction if we wanted to go down that route?

  13. Hi Joe,

    I’m currently working on the same project but the challenge is we are in Exchange Hybrid environment the mailboxes are in cloud and sync happens from On Prem AD/Exchange. The RecipientType is MailUser & RemoteUserMailbox how can we achieve this method to be able to provide the customized RBAC permissions to the users so they access the ECP portal.

    I tested the same in our Model environment and that works just fine because the mailboxes located on-prem and RecipientType is User & UserMailbox.

    Please anyone have knowledge on how to accomplish this.


  14. Although I have configured the RecipientRelativeWriteScope to “MyDistributionGroups”, users who are added to the “Self-Managed Distribution Group Management” role have the ability to edit ALL groups, not just those which they own. Any advise on how to fix would be appreciated.

  15. Hi Joe,

    We have o365 online email in our office and on-premise AD. I m not able to assign permission for certain users to send email to a specific group. It gives error saying that it can be managed by On premise AD object only as its synced for AD. I dont find any place to edit in local AD. Similarly many feature managements point to on premise AD which is unavailable in AD. How do i resolve this?

  16. Hello,

    had to change second command but seems to work perfectly fine:

    Get-ManagementRoleEntry “Manage-MyDGs\*” | Where {$_.Name -ne “Get-Recipient” -and $_.Name -ne “Update-DistributionGroupMember” -and $_.Name -ne “Add-DistributionGroupMember”-and $_.Name -notlike “Get-*Group*”} | foreach {Remove-ManagementRoleEntry -Identity “$($\$($” -Confirm:$false}

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Joe Palarchio

More from this Author

Follow Us