Off-boarding email from Office 365 to Exchange 2013 (Part 3)

If you would like to read the other parts in this article series please go to:

• Off-boarding email from Office 365 to Exchange 2013 (Part 1)
• Off-boarding email from Office 365 to Exchange 2013 (Part 2)
• Off-boarding email from Office 365 to Exchange 2013 (Part 4)
• Off-boarding email from Office 365 to Exchange 2013 (Part 5)
• Off-boarding email from Office 365 to Exchange 2013 (Part 6)

Introduction

In the previous part of this series we used the export from Office 365 to create matching accounts within our on-premises Active Directory and Exchange organization. In this part of the series we’ll configure the Azure AD Sync Tool and move Exchange Autodiscover from Office 365 to on-premises Exchange.

About Azure Active Directory Sync

Azure AD Sync is installed as a black-box tool with limited configuration available, making it easy to set up and synchronize data with Microsoft cloud services. Under the hood though is a powerful engine. Microsoft Identity Manager (MIM) is used under the hood with the backing of an SQL database, the same engine used by organizations with complex identity requirements throughout the globe.

When delivered as part of Azure AD Sync, MIM is automatically configured with connectors to the local Active Directory and to the Azure Active Directory. The engine synchronizes the local AD and the Azure AD into it’s own database known as the metaverse. After comparing the two, changes are exported to both services. For Azure AD this includes account creation, updates and deletes. For the local AD this is more limited, and is used to write-back Hybrid attributes.

You’ll find a full list of attributes that are synchronized by at this URL.

Now we know a little bit more about what Azure AD Sync is and does, we’ll launch the MIM Synchronization Service Manager on our Azure AD Sync server. You’ll find this GUI-based tool at the following location, assuming you’ve installed Azure AD Sync into the default location, named miisclient.exe:

Figure 1: Azure AD Sync’s Management GUI file system location

After launching the Synchronization Service Manager for the first time, you’ll find it initially looks rather empty. That’s OK, as we’ve not attempted to synchronize anything just yet:

Figure 2: The Operations tab of the Synchronization Service Manager

The two tabs we’re interested in are shown above – the first two. The Operations tab will show the log of actions taken, and allow us to examine previous synchronization jobs. The Management tab, where we’ll look at next, is used to configure each Management Agent and also allows us to initiate execution of each agent:

Figure 3: The Management Agents tab of the Synchronization Service Manager

Reconfiguring the scope for Azure AD Sync

While optional, we’ve chosen to reconfigure the scope for Azure AD Sync to only focus on a specific organizational unit with within our on-premises Active Directory.

On the Management Agents tab of the Synchronization Service Manager, select the Active Directory Connector Management Agent and then choose Properties from the Actions pane as shown above. You’ll then see the Properties for that management agent.

Under the heading Management Agent Designer, select Configure Directory Partitions and then choose Containers:

Figure 4: Properties of the Active Directory Connector Management Agent

You’ll then be prompted for valid Active Directory credentials. By default you’ll be asked for the credentials for the auto-generated sync service account. As Azure AD Sync generates this during setup, you won’t know the account password. Its fine to use another AD account here instead – it’s only used for selecting the Organizational Unit within the GUI and is not stored.

When the Select Containers window opens, we’ll choose the Office365 Organizational Unit we created our matching accounts within in the previous part of this series:

Figure 5: Configuring the Azure AD Sync scope to filter against Organization Units

After making our selection, choose OK to confirm changes within the Select Containers window, then choose OK within the Management Agent Properties window to save changes.

You can read more about the supported scenarios changing Azure AD Sync’s scope in the TechNet article Configuring filtering for directory synchronization.

Verifying the accounts Azure AD Sync will attempt to synchronize

This is another optional step, but it’s a step that will help you ensure that after reconfiguring the scope for Azure AD Sync we have a chance to double check what we’ll be synchronizing to Office 365 is correct.

To accomplish this, we’ll perform a staged import from Active Directory into the local Azure AD Sync server. This won’t make any changes to Office 365 yet as we’ve stopped the Azure Active Directory Sync Service in the previous part of this series.

First, select the Active Directory Connector management agent, and then choose Run from the Actions panel:

Figure 6: Selecting the Run action to initiate a synchronization

The Run Management Agent window should open. Select Full Import Stage Only, then choose OK:

Figure 7: Executing a Full Import, Stage Only against the Active Directory Connector Management Agent

After pressing OK, the management agent’s state should change to Running. Depending upon the size of the organization you’re importing, this could take few minutes to complete; this is because it must download data from Active Directory and insert it into the local SQL Server database that underpins MIM and Azure AD Sync.

Upon completion, the state of the management agent should return to Idle indicating it has finished its staged import.

Figure 8: Monitoring the status of the Active Directory Connector Management Agent

You’ll see below that we now have some interesting data within the Synchronization Statistics – 244 new additions from Active Directory. If you’re wondering why it’s not Updates or Unchanged, this is firstly because these are additions to the local MIM instance, not Office 365. Second, our first run against Office 365 won’t result in immediate matches as we’ll be performing soft matches based on each users’ email addresses.

If the number of additions looks correct, we can go validate these by choosing Search Connector Space within the Actions panel shown above.

After the Search Connector Space window opens, we can view details about objects that have been imported from Active Directory so far by choosing Sub-Tree under the Scope heading and then selecting Search:

Figure 9: Viewing the Active Directory accounts imported into Azure AD Sync

Examine the results here and ensure they match up with what you are expecting to be synchronized – if not double check the scope you’ve set when configuring Azure AD Sync filtering and re-attempt the staged import. If all looks good, it’s time to begin synchronizing Active Directory accounts with Office 365.

Performing the initial synchronization with Office 365

We can initiate Azure AD Sync synchronization using PowerShell. After launching a PowerShell session execute the following commands:

Figure 10: Initiating the first full synchronization job

In the background, this will execute a number of run profiles, very similar to the Full Import Stage Only we performed in the previous section. Returning to the Synchronization Service Manager, select the Operations tab to verify the tasks have executed successfully:

After the first synchronization the local Active Directory account will not be joined to their Office 365 counterparts, so execute the Start-OnlineCoexistenceSync cmdlet a second time. This will use the soft matching technique mentioned earlier to link the accounts together.

If the operation is successful, we’ll expect the latest Active Directory Connector management agent export to perform updates against our on-premises Active Directory objects, as highlighted below:

Figure 11: Using the Operations tab to verify the second delta synchronization job has completed

At this point our Exchange Online mailboxes will be linked to the on-premises Remote Mailboxes created in Exchange 2013. If you’ve chosen to use Directory Sync, users will be prompted to enter their normal Active Directory password over the course of the next few hours.

Configuring Autodiscover

Because all Exchange mailboxes are in the cloud, the Autodiscover DNS record that helps clients find their mailbox will be configured to direct clients to Office 365. Now that we have created our remote mailboxes objects on premise, we should be able to change the DNS entry for Autodiscover to point to on-premises Exchange.

Before switching records it is important to note that the assumption is that Exchange has been set up correctly, including configuration of valid third-party SSL certificate containing the Autodiscover name(s) for your domain and it is published correctly to the Internet.

Changing the Autodiscover record is straightforward and achieved by updating the configured CNAME record. Instead of being set to point at Autodiscover.outlook.com it will be configured to point at our on premises Exchange servers.

The initial Office 365 configuration is shown below within the portal of a sample DNS provider:

Figure 12: Viewing the existing Autodiscover CNAME record

After updating the record to direct traffic to our on-premises primary HTTPS namespace, mail.exchangelabs.co.uk the record is similar to that shown below:

Figure 13: Updating the existing Autodiscover CNAME record to resolve to on-premises Exchange

After making this change, we’ll expect the Autodiscover process to change for users currently in Office 365 as follows:

• A device attempts to discover the server details for [email protected] and sends the Username and Password to https://autodiscover.exchangelabs.co.uk/Autodiscover/Autodiscover.xml
• Exchange 2013 on-premises knows this is a Remote Mailbox and provides details of Olivia’s Office 365 service domain email address [email protected].
• Device re-attempts discovery for [email protected] with the same credentials, attempting authentication against https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml via Autodiscover redirection.
• Device receives details for accessing the Office 365 mailbox.

The caveat to be aware of here is that for Autodiscover to function correctly for users in the cloud, not only must the User Principal Name in AD match the Office 365 Login ID, but the passwords must also match. Because we implemented DirSync Password Hash Sync this should be the case.

Summary

In this part of the series we’ve finished the testing and configuration of Azure AD Sync and our on-premises Active Directory objects are linked to the mailboxes in Office 365. We’ve also performed the first step to link Exchange on-premises to the cloud, by moving the Autodiscover endpoint to direct any new requests to the on-premises Exchange servers.

If you would like to read the other parts in this article series please go to:

• Off-boarding email from Office 365 to Exchange 2013 (Part 1)
• Off-boarding email from Office 365 to Exchange 2013 (Part 2)
• Off-boarding email from Office 365 to Exchange 2013 (Part 4)
• Off-boarding email from Office 365 to Exchange 2013 (Part 5)
• Off-boarding email from Office 365 to Exchange 2013 (Part 6)