*This piece was co-authored by New Signature’s Joe Cirillo and Don Young.

Recently we were asked by a customer, who is operating in an Exchange Hybrid configuration, to develop a solution for converting their on-premises Distribution Lists (DLs) to Office 365 Groups. Although it sounds simple, the challenge is that the customer is using the GALSync feature of Microsoft Identity Manager (MIM) to extend their Global Address Book (GAL) to other Exchange organizations. By design, GALSync reads the local DL object and writes it out as a Contact object in the destination Exchange organization.

Since Group membership will now be managed exclusively in the cloud, the local DL object will be deleted as part of the conversion process. Since no local DL will exist, GALSync will not have an object to write out to the external Exchange organizations.

Knowing that we needed an object in the local Active Directory (AD) for GALSync, the question became, do we create an on-premises Contact object to replace the on-premises DLs once converted to an Office 365 Group, or do we use the Azure AD Connect ‘Group Writeback’ feature (in preview) to writeback the Office 365 Groups to the local AD forest.

Before proposing the Group Writeback option, we decided to do some lab testing to fully understand all of its nuances. As expected, many lessons were learned.

Some immediate issues we faced were:

  1. Older versions of Azure AD connect don’t install the ‘Remote Server Administration Tools’ feature which includes the needed DSACLS.exe command-line utility
    1. The ‘Set-ADSyncUnifiedGroupWritebackPermissions’ command calls DSACLS to do its work and will fail if DSACLS is not present
    2. Though we were using the latest version of AAD Connect, we still had to add the ‘Remote Server Administration Tools’ feature manually.
  2. Writeback groups are created as Universal Distribution Groups, but don’t appear in the on-premises Exchange global address list (GAL)
    1. This is a little odd because when you look at the attributes of the object written back from Office 365; it looks like a DL object. It has all the attributes of a DL object yet when you try to find it in Exchange (using the Admin Center or various PowerShell commands), it cannot be found
    2. For the Office 365 Groups to show up in the on-premises Exchange GAL you must run the ‘Update-Recipient’ PowerShell cmdlet against the written back object.
      1. Although the ‘Get-Recipient’ PowerShell cmdlet does not return the Group object, the ‘Update-Recipient’ cmdlet does in fact work

Once the Groups appeared in the on-premises AD, we noted a few other nuances presented here.

  1. B2B (Guest) accounts that are members of an Office 365 Group do not sync back to on-premises AD and, as such, will not show as members of the written back O365 group
  2. For message being sent to an Office 365 Group from on-premises Exchange Server, the SMTP domain being assigned to the Office 365 Group must be configured as an ‘Accepted Domain’ of type ‘InternalRelay’ on the Exchange server, and a ‘Send Connector’ must exist to route messages sent to the SMTP domain to Office 365.

Information regarding the group domain configuration can be found at Configure a group domain

  1. When an email is sent to the O365 Group, the message is routed directly to Office 365 for expansion. This means that even though the on-premises member list may be incomplete, any missing members on-premises (i.e. Guest accounts) will still receive the message
  2. The writeback operation is a ‘push’ down to the local AD and not a two-way sync. Any changes made to the on-premises object will be overwritten by the cloud values on the next sync cycle
  3. The target address (mail forwarding address) of the written back Group will vary based on whether the group is set to ‘Private’ or ‘Public’
    1. ‘Private’ Office 365 groups will use the ‘<tenant>.onmicrosoft.com’ target address
  4. The DL membership can be seen on-premises but can only be modified in Office 365

In our scenario, having the Group objects with the desired mail attributes available locally for GALSync was beneficial. For situations where there are no remaining user mailboxes homed on-premises, thus no one making use of or searching the Global Address List (GAL), Group Writeback would not prove as useful.

Want to learn more about Office 365 and how it can offer you a secure intelligent workplace? Attend our free Office 365 Ensuring Successful Security webinar!

January 30, 2020
10:00 a.m. EST
Register Now!

 

Reference Articles:

Configure Office 365 Groups with on-premises Exchange hybrid

https://docs.microsoft.com/en-us/exchange/hybrid-deployment/set-up-office-365-groups?redirectedfrom=MSDN

More details about features in preview

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-preview#group-writeback