How to Enable Office 365 Group Writeback for a Hybrid Coexistence Environment

I would like to discuss today configuring Office 365 Groups with on-premises Exchange Hybrid. Office 365 Groups is the new type of group that allows its members to collaborate efficiently through a variety of services, such as SharePoint Team Site, Yammer, Shared OneNote Notebook, Shared Calendar, Planner, and SharePoint Document Library.

Office 365 Groups contain all the features of a Distribution Group and all the features of a Shared Mailbox rolled into one, with the added benefit of enabling collaboration across the above-mentioned services. The list will likely expand to include other services in the future.

Unlike other mail-enabled objects in Office 365, Office 365 Groups can be synced back to an on-premises Active Directory environment. In addition, user accounts with mailboxes in the on-premises Exchange can be members of and participate in the Office 365 Group. How cool is that?

I found a nice TechNet article entitled Configure Office 365 Groups with on-premises Exchange Hybrid and thought, "Wow, how nice. A detailed explanation of what I need and how to do this.” What I found as I went through it, though, was that it did not seem as easy as it should.

My goal for this blog is to uncover the gaps I found and hopefully make this procedure a lot easier for you.

So, let's dive into the requirements and properly configuring the Group Writeback feature in a Hybrid coexistence environment.

Requirements

• At least one purchased Azure Active Directory Premium license for one account. This is required to allow for the Group Writeback feature to be enabled in the Azure AD Connect service.
• Azure AD Connect version 1.0.8641.0 (June 2015) or higher.
  • You can check your version of Azure AD Connect by checking on the properties of the miisclient.exe file located in the default install patch of C:\Program Files\Microsoft Azure AD Sync\UIShell. Right-click on the file and select Properties. Click on the Details tab and record the Product Version number.
  • A list of all version releases can be found here: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history.
  • Please note that you will have wanted to follow the instructions for a custom installation of Azure AD Connect per the article Custom installation of Azure AD Connect. This is important as we need to know the custom service account and password needed in Step 8 under Enabling Group Writeback in Azure AD Connect, below.
• A properly functioning Exchange Server Hybrid deployment with Office 365, with either of the following Exchange versions.
  • Exchange 2016 CU1 or higher
  • Exchange 2013 CU11 or higher
  • To check your version of Exchange, you can use the procedures and tables located here: https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

Azure AD Connect configured with either password synchronization or ADFS for single sign-on and properly working.

If you have met all the requirements above, you are ready to move on to Enabling Group Writeback in Azure AD Connect.

Enabling Group Writeback in Azure AD Connect

In the TechNet article Configure Office 365 Groups with on-premises Exchange Hybrid, there is a nice section that discusses how to Enable Group Writeback in Azure AD Connect. The following steps were taken from this TechNet article but I have added notes where it may seem a bit confusing.

1. In the Azure AD Connect wizard, select Customize synchronization options. Click Next.
2. On the Connect to Azure AD page, enter your Office 365 and on-premises credentials. Click Next.
3. On the Optional features page, verify that the options you previously configured are still selected. The most commonly selected options are Exchange hybrid and Password hash synchronization.
4. Select Group Writeback. Click Next.
5. On the Writeback page, select an Active Directory organizational unit (OU) to store objects that are synchronized from Office 365 to your on-premises organization. Click Next.  **NOTE** It is ok if the OU that the Groups are written to are currently in scope of syncing to Office 365. I have tested this and did not see any undesirable effects on the environment.
6. On the Ready to configure page, click Configure.
7. When the wizard is complete, click Exit on the Configuration complete page.
8. Open Active Directory Users and Computers on an Active Directory domain controller and locate the user account that begins with AAD_. Make note of this account's name.

**NOTE** Step 8 threw me for quite a loop for a few reasons.

• The AAD_ account is an account that is created locally on the Azure AD Connect member server and does not have any rights to the Active Directory environment.
• If you use the Express Settings of Azure AD Connect, an account with the prefix of MSOL_ will be created and the password of this account is usually not known.

To make step 8 work, you will have wanted to install Azure AD Connect using the custom installation procedures per the Microsoft article Custom installation of Azure AD Connect and recorded the custom account and password created for the Azure AD Connect installation. When you perform a custom installation, the account you create must have the correct permissions for the Group writeback feature. For your environment, please see the article Azure AD Connect Accounts and Permissions, and the subsection entitled Create the AD DS account. There is a nice table detailing what permissions your service account must have for various features enabled for Azure AD Connect

9. Open the Exchange Management Shell on an on-premises Exchange server, and run the following commands.

$AzureADConnectSWritebackAccount = <Custom Service account name from step 8>

$GroupsOU = <writeback Active Directory OU selected in step 5>

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"

Initialize-ADSyncGroupWriteBack -ADConnectorAccount $AzureADConnectSWritebackAccount -GroupWriteBackContainerDN $GroupsOU

**NOTE** Step 9 also was a bit confusing as I could not understand why I needed to open the Exchange management Shell. Exchange will NOT have the required AdSyncPrep.psm1; only a server with Azure AD Connect installed will have this file.

**NOTE** To complete step 9, please see my notes below on Completing Step 9.

Completing Step 9

You are going to need to install some other PowerShell modules in order to import and execute the all-powerful Initialize-ADSyncGroupWriteBack discussed in the TechNet article in step 9. What worked best for me, and what I highly recommend, is that you install these modules on your Azure AD Connect server.

• On your Azure AD Connect server, install the following modules.
  • Active Directory module for Windows PowerShell
    • This module can be installed by opening Windows PowerShell on your Azure AD Connect server and typing Add-WindowsFeature RSAT-ADDS
  • Microsoft Online Services Sign-In Assistant
    • This module can be downloaded from the following link (I installed the x64 version):
      https://www.microsoft.com/en-us/download/details.aspx?id=41950

After you have installed these two modules you should then be able to successfully import the AdSyncPrep.psm1 in step 9 of Enable Group Writeback in Azure AD Connect in the TechNet article, Configure Office 365 Groups with on-premises Exchange Hybrid. In step 9 the PowerShell commands to run are as follows:

$AzureADConnectSWritebackAccount = "ouredge\oeadmin"

$GroupsOU = "OU=OurEdge Groups,DC=OurEdge,DC=net"

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"

Initialize-ADSyncGroupWriteBack -ADConnectorAccount $AzureADConnectSWritebackAccount -GroupWriteBackContainerDN $GroupsOU

Congratulations if you have made it this far!

Configure a Group Domain

When you initially configure Office 365 Groups, the default accepted domain in the organization is chosen as the Group domain. To find out what the default accepted domain is in your organization, you can either view it in the Office 365 Portal Exchange Admin Center, or in PowerShell.

In the Office 365 Portal, navigate to the Exchange Admin Center, select mail flow on the left and then accepted domains at the top. The default domain will have the (default domain) listed in parentheses next to the name.

If you are connected to Office 365 via PowerShell, you can view the default domain by typing:

Get-AcceptedDomain

And review which accepted domain has Default set to True.

Since in our environment the default domain is the OurEdge.net domain, any Office 365 Group created by a process other than through the Exchange Admin Center or PowerShell will have the OurEdge.net domain set as the primary SMTP address suffix.

I have learned over the years that it is often better to separate processes from the default or templatized version as it allows for more granular control and isolation from outside changes. For this reason, I would recommend setting up a dedicated Groups domain to help keep the configuration isolated and dedicated for enabling the Groups writeback feature.

There is a full TechNet article discussing the support for multiple Groups domain setups and why here:

Multi-domain support for Office 365 groups

For our environment, the dedicated Groups domain we will configure will be groups.ouredge.net

The steps to configuring a Groups domain for our Office 365 Groups are as follows:

1. Add a new domain ouredge.net to the Office 365 tenant.
2. Add the ouredge.net domain as an accepted domain in your on-premises Exchange environment. For our environment, the following was run from the Exchange Management Shell:

New-AcceptedDomain -Name groups.ouredge.net -DomainName groups.ouredge.net -DomainType InternalRelay

*NOTE* The accepted domain on-premises MUST be of type Internal Relay. If it is set to Authorized, on-premises users will not be able to send mail to an Office 365 Group.

3. Add the proper DNS records to your publicly hosted zones. You may also need to add these entries to your on-premises DNS servers if you have a split-brain DNS deployment. (Split-Brain DNS is where the use of the same DNS Zone is managed on both private and public DNS hosts.)

*NOTE* The MX record value is in the format of <DomainKey>.mail.protection.outlook.com.  When you added the domain in step 1, the value for this MX record is listed in your Office 365 tenant. Information on where to find it can be found here: Gather the information you need to create Office 365 DNS records.

DNS Record: groups.ouredge.net

Record Type: MX

Priority: <your choice>

Record Value: groups-OurEdge-net.mail.protection.outlook.com

DNS Record: autodiscover.groups.ouredge.net

Record Type: CNAME

Record Value: autodiscover.outlook.com

*NOTE* You will also need to assign a priority to the MX record.  A value of 0 or 10 will suffice.

4. Modify the send connector in the on-premises environment created by the Hybrid Configuration Wizard. When the Hybrid Configuration Wizard is run in the on-premises environment, it will usually create a send connector named "Outbound to Office 365." If the send connector is not named "Outbound to Office 365" you will need to identify which send connector is your Office 365 send connector and add the Groups sub-domain name to the address spaces of the connector.

Make sure to record all the current address spaces currently assigned to this send connector first, and then when you run this PowerShell command, add your Groups sub-domain name. For our example, we will be adding the groups.ouredge.net name.

a. Record what is currently in your address space by typing the following PowerShell command in the on-premises Exchange Management Shell:

Get-SendConnector

Then record all address spaces identified in the Address Spaces.

For our environment, we only had discoverouredge.mail.onmicrosoft.com.

b. Run the PowerShell command to add the ouredge.net Group domain to the address space.

Set-SendConnector -Identity "Outbound to Office 365" -AddressSpaces "discoverouredge.mail.onmicrosoft.com","groups.ouredge.net"

c. Create an email address policy in your Office 365 tenant that automatically assigns the Group domain to the Office 365 Group when it is created.

*NOTE* Groups will only be automatically assigned this Groups sub-domain if they are created by a process outside of the Exchange Admin Console (EAC) or via PowerShell connected to your tenant. If a Group is provisioned by the EAC or via PowerShell, you will to set the Groups domain manually.

The email address policy we used is below:

New-EmailAddressPolicy -Name Groups -IncludeUnifiedGroupRecipients -EnabledEmailAddressTemplates "SMTP:@groups.ouredge.net" -Priority 1

One of the neat things about the Groups domain is that you can create multiple domains based on department physical location or other segments of your organization. For more information          on how to do this, please see the support article Multi-domain support for Office 365 groups

Testing Office 365 Groups with On-Premises Accounts

We are just about ready to begin testing Office 365 Groups with our on-premises users. Before we begin testing, the following must always occur before an on-premises account can use an Office 365 Group.

- Office 365 Group must be created in tenant

- Must have run a sync cycle on Azure AD Connect

- Must run the Update-Recipient "<group Name>" in the on-premises Exchange Shell.

For this last requirement, each time a new Office 365 Group is created and synced to the on-premises environment, the object will show up as a distribution Group in Active Directory, but will not show up in the on-premises Exchange Admin Center, and will not show up in the Global Address List (GAL) until the Update-Recipient command has been run against it.

When an Office 365 Group is synced to the on-premises environment, it will show up as Group_GUID like number in Active Directory Users and Computers.

I found it a bit difficult to understand which Group was which in this view, so I added the DisplayName column in front to help me out.

To update the GAL with newly synced Office 365 Groups run the Update-Recipient cmdlet as follows from your on-premises Exchange Management Shell.

Update-Recipient -Identity <parameter>

In the above example, you could run a command such as:

Update-Recipient -Identity Group_2c535e6a-f326-4ab5-bc99-9c825261d28e

Of course, as your on-premises list grows, it may be difficult to find or track down which Groups are the newer Groups. In this case, you can create PowerShell script to run through the entire list. You could even schedule the PowerShell script to run once a day, or on any frequency that would be needed for your business. Since all Groups will be written back to the designated OU in your Active Directory environment, I created this simple little command to run through all the Groups in the designated OU.

Get-ADGroup -SearchBase "OU=OurEdge Groups,DC=OurEdge,DC=Net" -Filter * | ForEach-Object {Update-Recipient -Identity $_.Name}

Now you are ready to test your new Office 365 Groups and collaboration with on-premises users.

You can run through the test sequence from the article Configure Office 365 Groups with on-premises Exchange Hybrid in the section near the bottom entitled How do you know this worked?

Please keep in mind that although on-premises users will be able to collaborate with members of the same Office 365 Group, they will not be able to take advantage of all the great features Office 365 Groups provides, such as Teams, OneDrive, or SharePoint, unless they are licensed for them in Office 365.

There are still some known issues that you can review at the bottom of the same TechNet article in the section entitled Known issues.

One final note: If you are still running either DirSync or Azure AD Sync, remember that official support ended April 13, 2017, and you should upgrade to the Azure AD Connect tool that is a requirement mentioned at the beginning of this article. (End of Support for DirSync and Azure AD Sync).

I hope this article has been helpful and until next time, happy collaborating!

Written and composed by our Senior Microsoft Systems Engineer, Alex Levin.

References
Configure Office 365 Groups with on-premises Exchange Hybrid
https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx

Custom installation of Azure AD Connect
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-get-started-custom

Azure AD Connect: Accounts and permissions
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-accounts-permissions#create-the-ad-ds-account

Azure AD Connect: Version release history
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history
Multi-domain support for Office 365 groups
https://support.office.com/en-us/article/Multi-domain-support-for-Office-365-Groups-Admin-help-7cf5655d-e523-4bc3-a93b-3ccebf44a01a?ui=en-US&rs=en-US&ad=US&fromAR=1

Exchange Server Updates: build numbers and release dates
https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

Microsoft Online Services Sign-In Assistant for IT Professionals RTW
https://www.microsoft.com/en-us/download/details.aspx?id=41950

Gather the information you need to create Office 365 DNS records
https://support.office.com/en-us/article/Gather-the-information-you-need-to-create-Office-365-DNS-records-77f90d4a-dc7f-4f09-8972-c1b03ea85a67?ui=en-US&rs=en-US&ad=US

End of Support for DirSync and Azure AD Sync
https://blogs.technet.microsoft.com/enterprisemobility/2017/04/10/end-of-support-for-dirsync-and-azure-ad-sync-is-rapidly-approaching-time-to-upgrade-to-aad-connect/