Managing Distribution Lists/Groups from AD after Office 365 Migration

I encountered a puzzling issue recently where a client who had an On-Premises Exchange server had been migrated to Office 365 and the Exchange server had been decommissioned.  The issue was some designated users were in charge of keeping the Distribution Lists up to date, but found they no longer could through Outlook.  The client uses Azure AD Connect to keep AD synchronized with Office 365. 

The reason for this is because after a migration Outlook is connecting to Office 365, not Active Directory, and Office 365 does not (typically) write back to Active Directory.  Administrators also run into this problem when in the Exchange Admin Center you cannot update the Distribution List because it gets it’s values from Active Directory.  Administrators (Domain Admins) can write to AD so this doesn’t pose much of a problem for them – they can update the groups within Active Directory.  But how to get these designated users to be permitted to update the lists?

The solution is relatively simple if not immediately obvious.

In AD, locate and open the Distribution Group and click on the “Managed By” tab.  Select the user or security group that you have designated as having permissions to make changes.  Check the box that says “Manager can update membership list”.  Apply the changes.

On the user desktop create a new shortcut and direct it to:  “rundll32.exe dsquery,OpenQueryWindow”

Name the shortcut something descriptive, such as “Edit Distribution Lists”

When the user executes the shortcut he or she will be presented with an AD Search exactly like clicking on Find in Active Directory Users and Computers.  Search for the DL to edit the membership of, open, and add/remove members. 

After the next Azure AD sync cycle the DL is updated.  Staff will have to wait for the sync cycle to complete on the schedule as they do not have rights to force a new Delta sync.

This is one of the core reasons Microsoft recommends that you do not decommission your last On Premises Exchange server, though truthfully this issue would persist regardless as the end user normally wouldn’t have access to Exchange Admin either.