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
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.
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.
**NOTE** Step 8 threw me for quite a loop for a few reasons.
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.
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:
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.
*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.
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
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/