Using the Office 365 Hybrid Configuration Wizard Part 6

In this series, we’ve spent time making sure the environment is ready for Exchange Hybrid before implementing the Hybrid Configuration using the Office 365 Hybrid Configuration Wizard. We then performed a number of post-configuration steps to enable fuller functionality, before beginning core service tests ensuring we can create new Mailboxes and use core Autodiscover services. In this final part of the series we’ll complete our testing.

Basic checks to perform to ensure Hybrid works as expected

We’ve tested mailbox creation and Hybrid autodiscover. We’ll now test mail flow, free/busy, calendar sharing, public folder access and finally test mailbox moves. As mentioned in the previous part of this article, these are just basic tests – it is important to test client connectivity from the clients you’ll use.

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:

clip_image002

Figure 1: Sending a test email to Office 365

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:

clip_image004

Figure 2: Sending a test email to on-premises

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”):

clip_image006

Figure 3: Testing intra-organization mail flow

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 reasons 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 on-premises. Attempt to schedule a new meeting with the Office 365 mailbox. The availability should be displayed correctly.

clip_image008

Figure 4: Testing free/busy to Office 365

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.

clip_image010

Figure 5: Testing free/busy to on-premises

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. Our checks in part one of this article

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:

clip_image012

Figure 6: Sharing a calendar using native functionality

A new Sharing Invite will be displayed. Enter the other test mailbox and then choose to share Full Details, then press Send.

clip_image014

Figure 7: Selecting the level of sharing and who to share with

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.

clip_image016

Figure 8: Accepting the sharing request

After choosing Add Calendar, wait a few moments and then view the mailbox calendar. The other test mailbox calendar should be displayed.

clip_image018

Figure 9: Viewing the shared calendar in OWA

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:

clip_image020

Figure 10: Testing cross-premises Public Folder access

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:

clip_image022

Figure 11: Viewing the Outlook Anywhere connection to on-premises Public Folders

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 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.

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):

clip_image024

Figure 12: Creating a Migration Batch

The New Migration Batch wizard will show. First, select a Remote Move Migration, then choose Next:

clip_image026

Figure 13: Selecting Remote move migration

We’ll then be provided with the opportunity to select mailboxes to migrate using the Global Address List picket by choosing Add (shown below), or by providing a CSV file:

clip_image028

Figure 14: Selecting Mailboxes to migrate

After selecting appropriate mailboxes to test within the batch, choose Next. We’ll then be shown the Migration Endpoint. If we have multiple migration endpoints, for example across multiple regions, then we’ll be able to select an appropriate endpoint. In our example we have a single one, and simply press Next to continue:

clip_image030

Figure 15: Viewing or selecting the migration endpoint to use for this batch

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, if it isn’t populated by default.

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:

clip_image032

Figure 16:Configuring migration batch options

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:

clip_image034

Figure 17: Configuration notification and orchestration settings for the batch

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:

clip_image036

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

In this multi-part series, we’ve completed the basic configuration needed to get a well-functioning Exchange Hybrid up and running, using the Office 365 Hybrid Configuration Wizard.