If you’re an Office 365 Exchange Online customer and currently utilizing Directory Synchronization (DirSync) to synchronize between an on premise Active Directory and the Azure Active Directory you’ll be all too familiar with the limitations that are imposed around the management of distribution group membership. Namely an Exchange online user specified as the owner of a distribution group will not be able to manage the membership of that group through the standard Outlook Address Book interface as detailed here

In the background, if we think about this in relation to DirSync functionality, the group is being pushed from the on premise Active Directory to the Azure Active Directory in a one way sync. Consequently the group object in the Azure Active Directory is read-only which explains the limitations that exist around group modification.

As distribution group self-service functionality has been in place for quite some time in the Exchange landscape, it often comes as a significant blow to businesses when they realize this functionality isn’t available by default in Exchange online. The net result is either an accepted loss of functionality or the prospect of a significant increase in calls to the helpdesk to facilitate the modification of group membership from the on premise Active Directory.

There are however a variety of ways to work around this issue, this is by no means an exhaustive list but gives some guidance/ideas around what’s possible;

Use the ‘Find Users, Contacts and Groups’ tool to allow group modification

For domain connected computers it is possible to run the following command to fire up the built in ‘Find Users, Contacts and Groups’ tool;

%systemroot%\system32\rundll32.exe dsquery.dll,OpenQueryWindow

This will allow an on premise Active Directory group to be searched for and modified by an end user which will in turn be synchronized back up to the Azure Active Directory via DirSync.

Pros

• No changes required to the Exchange/Office 365 configuration
• The source of authority for all directory information remains on premise

Cons

• Only works from domain connected machines
• Represents a change to the existing manner in which distribution group objects are currently modified using the Outlook Address Book interface.

Move the Distribution Group Objects to the Azure Active Directory

It is possible to delete distribution groups from the on premise Active Directory and recreate them in the Azure Active Directory. By doing so the groups created in the Azure AD are writable and can consequently be modified using the standard Outlook Address Book functionality from an Exchange online mailbox user.

Pros

• Allows Distribution Group membership to be modified using the existing Outlook Address Book functionality and consequently means zero change to the way end users are used to working.

Cons

• Requires Distribution Group objects to be moved to the Azure Active Directory. This involves both a level of change, risk and impact which I will touch upon in the points of consideration section below.
• Requires a change in the way that groups are managed moving forward, namely security groups are managed in the on premise Active Directory and Distribution Groups are managed in the Azure Active Directory.

Points of Consideration

• In a typical Dirsync deployment the source of authority for all directory information is on-prem. If distribution groups are moved to the Azure Active Directory, source of authority is split between the on premise Active Directory and Azure Active Directory. Whilst this isn’t necessary a negative aspect of this option, it is a worthy point of consideration, least of all because administration of groups will now be performed in both locations.
• Consideration needs to be given to the implementation timing of this option. Whilst deleting and recreating distribution groups is a relatively straight forward change which can easily be scripted using Powershell, there’s likely to be a period, albeit potentially small between when the on premise group is deleted and recreated in the Azure Active Directory. During this time any email addressed to the group will obviously NDR. This can potentially be mitigated if your organization use a third party solution for AV/AS which can be used to hold inbound email for a short period until distribution groups have been recreated in the Azure Active Directory.
• Consideration needs to be given as to when during the migration that Distribution Groups are moved. Typically this should be performed at the end of a migration after all mailboxes have been migrated to Exchange Online. Obviously any remaining on premise Exchange mailbox users will no longer be able to see/utilize distribution groups once they have been deleted/recreated in the Azure Active Directory.
• Changes made to the Azure Active Directory are throttled by Microsoft which could potentially impact the speed at which distribution groups can be created. Whilst it is possible to request Microsoft to amend the throttle policy this is still likely to be a factor.

Use a ForeFront Identity Manager Management Agent for Office 365 to synchronize Distribution Groups

Use the FIM MA for Office 365 to manage the provisioning and synchronization of groups between the on premise Active Directory and the Azure Active Directory.

Pros

• Allows Distribution Group membership to be modified using the existing Outlook Address Book functionality and consequently means zero change to the way end users are used to working.

Cons

• Requires a FIM sync engine license
• Involves a level of complexity regarding the implementation and management of FIM

Summary

The option you choose here is very much dependent on your organizations requirements and each option carries with it a different set of pros and cons. In scenarios where an organization want to retain the standard self-service functionality provided by the Outlook Address Book, the second option provides a good balance of functionality and low cost of implementation/management moving forward. The points of consideration for this option should however be carefully considered prior to any attempt at implementation.