If you would like to read the other parts in this article series please go to:
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 1)
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 2)
- Using the Hybrid Configuration Wizard in Exchange Server 2013 (Part 3)
Basic checks to perform to ensure Hybrid works as expected
After executing the Hybrid Configuration Wizard and performing the relevant post-setup steps listed in part three of this series, 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.
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 by navigating to Enterprise, then within Recipients choosing the Mailboxes tab and choosing Add. A new option, Office 365 Mailbox will be shown in the list:
Figure 1: Creating a new Office 365 mailbox using the on-premises admin console
Select the above option and then complete the information required to create a new Office 365 mailbox. An Office 365 mailbox is represented on-premises by what is effectively a Mail-Enabled User with a special indicator to show it is attached to an Office 365 mailbox.
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 2: Configuring options for the underlying AD account
After creating the Office 365 mailbox it should now show alongside other on-premises mailboxes within your Exchange 2013 environment, as shown in the example below. The only obvious indicator is Mailbox Type which shows Office 365 rather than User:
Figure 3: Viewing the Office 365 mailbox on-premises
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 Sync 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 Exchange Admin Center to Office 365 and then choose Recipients>Mailboxes. The new mailbox should show in the list:
Figure 4: Viewing the Office 365 mailbox in the Exchange Online Admin Center
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 5: Viewing on-premises recipients in Exchange Online
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 6: Using the RCA to verify Autodiscover works as expected
The process for a client to connect includes two attempts at Autodiscover:
- 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.
- 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 7: A successful Hybrid Autodiscover test
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.
Testing Mail Flow
Mail flow between Office 365 and the Hybrid servers will attempt direct connections. As part of the pre-requisites the correct firewall rules should have been added, however even with the correct firewall rules in place it is still possible to get caught out.
A number of common issues you might find during testing include:
- Firewalls blocking SMTP headers, often known as “SMTP Fixup” on Cisco devices. This prevents TLS (secure) SMTP communication. You’ll typically see this when troubleshooting via Telnet; the STARTTLS command will be blocked in response to the EHLO command and most visibly the server name will be replaced by a row of asterisk (*) characters.
- The Hybrid Server may be on Microsoft’s private Office 365 Real-Time-Blocklist (RBL). Although fairly uncommon, Microsoft do occasionally block IP ranges that are not listed on other public RBLs. This will cause email to bounce with instructions on removal. Removal typically takes just a couple of hours, but plan for 24-hours.
Testing mail flow itself is simple; using the test mailbox in Office 365 and an equivalent on-premises mailbox attempt to send email both ways.
The first test – Outbound to Office 365 will validate that the Send Connector created by the Hybrid Configuration Wizard functions correctly and Exchange Servers can connect to and deliver email to Office 365:
Figure 8: Sending a test message from on-premises
If you have multiple Hybrid Servers sending outbound email, you may have to send a number of test messages to validate in the received message headers that all servers are able to connect to Office 365.
To validate mail flow from Office 365 to on-premises send (or reply) to the test email:
Figure 9: Sending a test message from Office 365
After validating mail flow between on-premises and Office 365, test mail flow between an Office 365 recipient and an external email address.
In addition to just connecting the two organizations together, the Hybrid Configuration Wizard configures connectors either side to trust the email flowing from each respective environment.
To test mail is trusted, set an Out of Office Automatic reply on both test accounts. Ensure the internal message can be easily distinguished from the external message (for example by setting the message to “Internal OOF”):
Figure 10: Configuring Automatic Replies
After configuring the Out of Office messages, re-send test messages. The expected result will be that on-premises and Office 365 recipients received internal Out of Office replies, and all external recipients receive the respective external message.
If you receive external Out of Office reply messages then it is likely that during the troubleshooting process for mail flow the connectors have been altered; for example you disabled the Outbound connector in Office 365. If changes have not been made then another common reason is that although all custom domains have been registered with the Office 365 tenant, not all were added to the Hybrid Configuration Wizard. This results in mail from Office 365 to those recipients flowing via your existing MX records and anti-spam solutions.
Free / Busy Tests
For many organizations, the ability to check availability is a critical function and must work during co-existence. In part one of this series, much of the pre-requisites were aimed at helping ensure this feature works correctly.
We will perform two tests to verify connectivity in both directions. To prepare, create test appointments in both on-premises and Office 365 test mailboxes.
First log in to Outlook Web Access in Exchange Server 2013. Attempt to schedule a new meeting with the Office 365 mailbox. The availability should be displayed correctly, as shown below:
Figure 11: Testing Exchange 2013 to Exchange Online Availability
If availability is not shown this typically means outbound connectivity from the Exchange Server and Office 365 isn’t working correctly.
Next check availability from Office 365 to on-premises, using the same method. Availability for the on-premises mailbox should be displayed:
Figure 12: Testing Exchange Online to Exchange 2013 Availability
If availability is not displayed then this typically means that there is an issue with either autodiscover, or connectivity to on-premises from Office 365.
Calendar Sharing Tests
Rich access to calendars between on-premises mailboxes and cloud mailboxes uses the same underlying technology as Free / Busy, so testing functionality should be a formality.
You will need to re-share any calendars that are used between accounts on opposite sides of the Hybrid Relationship, though once all calendars are migrated to Office 365 existing permissions set can be used.
To test sharing we’ll need to re-share using the Share functionality in Outlook Web App. Navigate to the test mailbox calendar and select the Share button, as shown below:
Figure 13: Sharing a Calendar
A new Sharing Invite will be displayed. Enter the other test mailbox and then choose to share Full Details, then press Send.
Figure 14: Creating a Sharing Invite
The sharing invitation should be received by the opposite test mailbox. If sharing is not configured correctly (as performed in part three of this series) then an iCal/HTML link will be shown. If sharing is set up correctly then an Add Calendar button should be displayed:
Figure 15: Receiving the Sharing Invitation
After choosing Add Calendar, wait a few moments and then view the mailbox calendar. The other test mailbox calendar should be displayed, showing test events:
Figure 16: Accessing the Shared Calendar
Testing Public Folder Access
Access to Public Folders relies on Client connectivity from Outlook to the on-premises environment. No access to Public Folders is provided in Outlook Web App.
To test access, ensure that permission have been granted to the test Office 365 mailbox to view the Public Folder hierarchy, then expand the tree:
Figure 17: Viewing the Public Folder tree in Outlook
To further verify connectivity, CTRL-Click the Outlook icon in the notification tray area of the Task bar and choose Connection Status. The connection directly to the on-premises server for Public Folder access should be shown alongside the connections to Office 365:
Figure 18: Verification of Public Folder connectivity
Testing Mailbox Moves
The final test we will perform validates we can move mailboxes to (and then from) Office 365.
Migration of mailboxes requires access to a component on Exchange 2013 known as the MRSProxy, or the Mailbox Replication Service Proxy. This runs within the Web Services virtual directory. All mailbox moves either to or from Office 365 are initiated from the cloud and connect to this component.
There are two ways to move mailboxes; the first method is to navigate to Enterprise, then choose Recipients. From the Mailboxes list, select a test mailbox. Under the heading Move Mailbox, you now see the option to move to Exchange Online as well as another Mailbox Database:
Figure 19: Migrating a single mailbox to Office 365
After choosing To Exchange Online it will launch into the Migration Batch wizard shown below.
The second method commonly used to create and initiate Migration Batches. Navigate to Office 365 then choose Recipients, then Migration. Under the Add menu, choose Migrate to Exchange Online (or from Exchange Online to test migrating mailboxes back):
Figure 20: Using the Migration section to add a new Migration Batch
The New Migration Batch wizard will show. Enter an appropriate name for the migration batch. From the Target Delivery Domain menu, select the routing domain (<tenantname>.mail.onmicrosoft.com) from the drop-down list.
We’ll select to move primary and archive mailboxes, and for the test leave the Bad item limit (which refers to corrupt items to discard) and the Large Item Limit (which refers to items over 150MB each) as the default, then press Next:
Figure 21: Entering the Migration Batch name and selecting the Target Delivery Domain
On the final page of the wizard, select an address to send report notifications to. After selecting Browse you can either select a recipient from the Global Address List, or enter an email address.
Options are also available to start and complete the Migration batch.
The option to start simply means we will create the configuration in Exchange Online, then start performing a sync of mailboxes later. The options for completion define what action to take after the initial sync completes; either to perform a final sync and switch – Automatically complete, or to leave the synced mailbox as is until users have been notified they will be switching – Manually Complete.
For the purpose of the test, choose Manually Complete the Batch, then select New:
Figure 22: Selecting notification and automatic completion options
Next, look in the Exchange Admin Center’s Migration tab to view the status of the Migration Batch and ensure it reaches a status of Synced. Finally, verify the synced mailbox can be successfully switched over to Office 365 (or back to on-premises) using the option Complete this migration batch:
Figure 23: Viewing Migration Batch status and completing a synced migration batch
The mailbox should complete moving to Office 365. After successfully testing with a client mailbox, re-test mailbox moves with working clients to ensure the before and after experience works well.
Summary
After successfully testing these areas we have successfully used the Hybrid Configuration Wizard to link our on-premises environment to Office 365. It should be possible to migrate mailboxes to Office 365, pending client testing and other environment design and remediation.
If you would like to read the other parts in this article series please go to:
