In this series, so far, we have examined all the necessary pre-requisites for Office 365 Hybrid Configuration, checked our Exchange organization is ready for Hybrid, spent time understanding exactly what changes Hybrid will make, implemented basic Hybrid functionality and then performed post-Hybrid steps. We will now complete those steps in this last but one in the series, then start giving our environment a test to make sure it functions as expected.
Basic changes to perform manually to complete Hybrid configuration
We’ve already performed some post configuration steps to update sharing policies, created a migration endpoint, updated mailbox email addresses, and configured Public Folder co-existence if required. We’ll now configure on-premises policies.
Re-Create On-Premises Policies and RBAC in Office 365
Finally, it is important to understand that the Hybrid Configuration Wizard does not connect or re-create on-premises policies within Office 365.
The following policies should be re-evaluated to see which features are required after migration to Office 365, then changed if required:
· Outlook on the web (OWA) policies enable features such as the premium client, signatures, access to recover deleted items, the Office 365 Groups and areas of OWA such as the calendar, IM, people and tasks.
· In-place hold policies are used to configure how long mailbox items should be kept, even after changes are made. Most organizations migrating to Office 365 who have compliance requirements will need to create relevant polices here, or configure journal recipient addresses to an on-premises or third-party system.
· Mobile device mailbox policies are primarily used to manage ActiveSync devices, but also manage the OWA App for Devices. The key change most organizations make is to require devices to be locked with a secure PIN code.
· Unified Messaging Mailbox Policies should be configured in combination with UM Dial Plans and modifications to the on-premises Skype for Business, Lync or other environment.
If Role Based Access Control is used to manage delegated rights, or restrict user access to features in Exchange, then equivalent admin roles and user roles should be configured. In a Hybrid Environment it makes sense to use the same synced admin accounts used on-premises to perform equivalent administrative tasks in Office 365.
Basic checks to perform to ensure Hybrid works as expected
After executing the Hybrid Configuration Wizard and performing the relevant post-setup steps, it is essential to perform testing to ensure that the environment works as expected.
The basic tests listed here do not cover environment specific tasks, such as updating clients to the correct version or ensuring your organization has sufficient Internet bandwidth. Instead, we are aiming to test that the Hybrid integration is functional.
We’ll begin in this part of the series by testing Office 365 mailbox creation and Hybrid autodiscover. In the final part of this series, we’ll test sharing, public folder access and mailbox moves.
Testing Office 365 Mailbox Creation
After configuring Hybrid, the on-premises Exchange environment will now expose the correct hooks to allow mailboxes to be created wherever we choose, either on-premises or in Office.
This functionality is exposed within the New-RemoteMailbox cmdlet and also within the GUI administration tools.
In Exchange Server 2013 and 2016, open the Exchange Admin Center and navigate to the Recipients section and select the Mailboxes tab. Under the Add (+) option, choose new Office 365 Mailbox:
Figure 1: Creating a Remote Mailbox in the EAC
When using Exchange 2010, open the Exchange Management Console and navigate to Recipient Configuration > Mail Contact and then choose New Remote Mailbox to create a new Office 365 mailbox:
Figure 2: Creating a Remote Mailbox in the EMC
The reason you need to create the mailbox here, rather than in Office 365 is because an Office 365 mailbox in a Hybrid environment requires on-premises AD users with the correct attributes to allow for full Hybrid functionality to work. As the local AD is the authoritative source, the AD accounts must be created and managed from here. The actual Remote Mailbox isn’t actually a mailbox on-premises though, and is simply a mail-enabled user.
This means it is a standard user account with email-related attributes, including a routing address to ensure all mail flows to the Office 365 tenant.
Figure 3: Entering Remote Mailbox options
After creating the Office 365 mailbox it should now show alongside other on-premises mailboxes within your Exchange 2013 or 2016 environment, as shown in the example below. The only obvious indicator is Mailbox Type which shows Office 365 rather than User:
Figure 4: Viewing Remote Mailboxes in the EAC
For Exchange 2010, the Remote Mailbox won’t show alongside other mailboxes. Mailboxes migrated to Office 365 or created as Remote Mailboxes will show under Mail Contacts as shown below:
Figure 5: Viewing Remote Mailboxes in the EMC
After creating the Office 365 mailbox on-premises we will not expect to immediately see a mailbox in Office 365.
As we are just creating an Active Directory account, Azure AD Connect must run (usually on schedule) to push these changes to the cloud, and once the account is in Office 365 it must be licensed accordingly.
After synchronisation and licensing have taken place, the mailbox should be available. Navigate in the Office 365 Exchange Admin Center to and then choose Recipients>Mailboxes. The new mailbox should show in the list:
Figure 6: Viewing Office 365 mailboxes in the Office 365 EAC
As a side note, you may notice that on-premises mailboxes are not shown in this tab. They are there, and these should be synchronized too. To find the on-premises mailboxes, navigate to Contacts:
Figure 7: Viewing on-premises mailboxes in the Office 365 EAC
The on-premises mailboxes are represented in Office 365 as mail enabled users. This provides a full Global Address List to migrated users and allows each hybrid domain to be configured as an authoritative domain.
Hybrid Autodiscover Tests
Migrated mailboxes need working Autodiscover to ensure that clients, like Outlook, can connect. Use the Remote Connectivity Analyzer to test your new Office 365 test mailbox. The Exchange Web Service test, as shown below, along with Outlook Anywhere and Exchange ActiveSync tests will validate client setup:
Figure 8: Performing a Hybrid Autodiscover test
The process for a client to connect includes two attempts at Autodiscover:
1. The client will attempt to connect to the on premises Autodiscover name. The on-premises Exchange Servers will return the Office 365 mailboxes’ remote routing address to redirect to, in the format <alias>@<tenant name>.mail.onmicrosoft.com.
2. The client will use the remote routing address as the basis for performing a second Autodiscover. The client will perform a DNS lookup against the name autodiscover.<tenant name>.mail.onmicrosoft.com. An initial HTTPS connection will fail, and the client will re-attempt using HTTP, without sending credentials. A redirect to autodiscover-s.outlook.com will be received and the Autodiscover process will successfully complete.
These two Autodiscover attempts are shown in the example below:
Figure 9: Examing the process used to retrieve Autodiscover information
After completing validation of Autodiscover functionality, Exchange related components should be functional. If a client, for example Outlook, struggles to connect to an Office 365 mailbox then it is likely to be firewall restrictions, DNS lookup restrictions or proxy server restrictions similar to the Exchange-related checks performed in part one of this series.
In this part of the series we have finished our post-Hybrid configuration and performed two core tests to ensure Hybrid functions. In the last part of the series we’ll finish testing our Hybrid environment.