Using the Hybrid Configuration Wizard in Exchange 2010 Service Pack 2 and 3 (Part 4)

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

Introduction

In parts one to three of this series, we looked at the checks you need to make before beginning your Hybrid Configuration, then looked at what changes will be made to your Exchange environment, before going through the Hybrid Configuration Wizard itself.

For the final two parts of this series, we’ll look at how to troubleshoot issues you might experience with the Hybrid Configuration Wizard itself, and examine the tests worth performing along with common areas to investigate if those tests fail.

Troubleshooting Hybrid Configuration Wizard failures

Even after checking over your environment before running the Hybrid Configuration Wizard, you still might find that it fails.

 


Figure 1: Hybrid Configuration Wizard Failure

Each step of the Hybrid Configuration Wizard is logged as it executes, and this log file is the best place to start investigating the underlying reason for the failure. You’ll find these logs under the Exchange Server installation directory, within the Logging\Update-HybridConfiguration folder – for example:

C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration

Open up the latest log file, and scroll to the end of the file to examine the reason for the failure. Scrolling through log files can be a little daunting therefore we’ll walk through a quick example of how to find and troubleshoot a reason for failure.

A common reason for the Hybrid Configuration Wizard to fail is due to the Get-FederationInformation cmdlet over on the Office 365 side being unable to retrieve federation information from the on-premises Exchange environment, even if everything is already setup correctly. We’ll see the lines in the log file that correspond to this error below:

 


Figure 2: Hybrid Configuration Wizard Log File

These logs show that:

  • The cmdlet executed was Get-FederationInformation -DomainName ‘exchangelabs.co.uk’ indicating that it was run from the Office 365 tenant because it’s looking up our On-Premises accepted domain, rather than our Office 365 service domain.
  • The cmdlet displayed the error ‘Federation information could not be received from the external organization‘ and took 43 seconds to timeout.

We’ll now connect using PowerShell to our Office 365 Exchange Online tenant, and attempt to reproduce the error. You can connect to Exchange Online by opening a new PowerShell session and using the instructions provided by Microsoft and reproduced below:

$session = New-PSSession -ConfigurationName:Microsoft.Exchange -Authentication:Basic -ConnectionUri:https://ps.outlook.com/powershell -AllowRedirection:$true -Credential:(Get-Credential)

Import-PSSession $session

After connecting to Exchange Online PowerShell we’ll retry the same cmdlet that previously failed and examine the output:

 


Figure 3: Hybrid Configuration Wizard Error reproduced in Exchange Online

When executing cmdlets at the Office 365 side, the amount of troubleshooting we can do at the source is limited; however we can do the following on the on-premises Exchange server to attempt to ascertain what the problem might be.

In particular with the cmdlet above, you may find that after retrying the cmdlet a couple of times, it will successfully complete. If it doesn’t then the next steps will be to:

  • Revisit the checks in part one of this article to ensure that Remote Connectivity Analyser test complete successfully – particularly AutoDiscover and Exchange Web Services tests for this accepted domain.
  • Review TMG or Firewall logs to confirm that requests are successfully reaching the edge of your organization from the Exchange Online datacentre IP addresses, listed here.
  • Run the same cmdlet from an On-Premises Exchange Management Shell, but with the -Verbose parameter to confirm it works internally and display detailed information about any error.
  • Review IIS log files, typically located within C:\inetpub\logs\LogFiles, for the date and time that the cmdlet was executed to firstly ensure that requests to /autodiscover/autodiscover.svc are received by the Exchange Server itself.

If the error you’re troubleshooting is different to the one above, similar steps apply – retry the cmdlet from either Exchange Online PowerShell, or the Exchange Management Shell depending upon where it should have executed; however most errors that are likely to occur should be covered by making sure the checks in part one of this article have been performed.

Once the cmdlet in question successfully completes, you can retry the Hybrid Configuration Wizard immediately and it should finish without error.

Tests to perform after the Hybrid Configuration Wizard completes

After you’ve successfully completed the Hybrid Configuration Wizard, it’s now important to perform tests to make sure everything actually functions as intended. We’ll look to perform the following tasks to ensure functionality in key areas works:

  • Creation of test mailboxes in Office 365.
  • Testing Hybrid AutoDiscover and core functionality using the Remote Connectivity Analyser.
  • Testing Client functionality, including OWA, ActiveSync and Outlook Anywhere.
  • Testing Mail Flow.
  • Testing Federated Sharing.
  • Testing Mailbox Moves.

For each set of tests, we’ll also cover the key areas to see if tests fail; although these troubleshooting tips can’t cover every scenario, they’ll certainly help you look in the right areas to get you on your way to solving most issues that crop up.

Test Mailboxes

In addition to local mailboxes to use during testing, you’ll also benefit from having a number of test mailboxes in Office 365 that have been provisioned through Exchange. Within Exchange, you’ll create Office 365 mailboxes using the On-Premises Exchange Management Console (or Exchange Management Shell) as Remote Mailboxes.

A Remote Mailbox is effectively a mail-enabled user – i.e. a normal user account in Active Directory with Exchange contact attributes, including an External Email Address that corresponds to an alias using the service domain (e.g. <user>@<tenant>.mail.onmicrosoft.com). This object provides the link that allows mail to route correctly through the on-premises Exchange organization to Office 365, and helps AutoDiscover and Free/Busy requests find their target correctly.

To create a test mailbox in Office 365, navigate in the Exchange Management Console to Microsoft Exchange On-Premises>Recipient Configuration>Mail Contact then right click and choose New Remote Mailbox:

 


Figure 4: Creating a New Remote Mailbox

After creating a number of Remote Mailboxes, you’ll then need to wait for DirSync to synchronise your local Active Directory with Office 365 and create the test mailboxes.

After the mailboxes successfully appear in Office 365, you’ll also want to consider assigning licenses to these users, using the Office 365 portal.

If mailboxes don’t appear to be created within Office 365, then check the following:

  • Verify whether the account is present in the Office 365 administration portal via portal.microsoftonline.com
  • Verify the Microsoft Directory Synchronization Service is started on your DirSync server.
  • Check the Office 365’s tenant technical contact’s email account for email from [email protected]. If you’re not sure which email address is the technical contact, visit the Office 365 administration portal and select the tenant name in the top left hand corner.

Testing functionality using the Remote Connectivity Analyser

Before testing real clients with Office 365, we can use the Remote Connectivity Analyser (RCA) to highlight any issues before we encounter them with actual client software; the benefit of using the RCA to test is that when a test fails the troubleshooting information provided will serve as a great starting point to solving the underlying issue.

The following tests are recommended using the RCA against the Office 365 mailboxes created earlier:

  • Test AD FS functionality
  • Test AutoDiscover functionality
  • Test ActiveSync functionality
  • Test EWS functionality
  • Test Outlook Anywhere functionality

Testing Client Functionality

After successful tests using the Remote Connectivity Analyser, we’ll be in a good position to test actual client functionality with a great chance of success.

The tests I would suggest include the following, both from your internal network, and externally:

  • Test OWA login functionality for a remote mailbox by logging into on-premises OWA.
  • Test Outlook 2007 and above full client functionality
  • Test ActiveSync functionality
  • Test IMAP/POP clients, if required

Typically if tests fail from your internal network, but succeed from the Remote Connectivity Analyser or from external clients, internal firewalls or proxy servers may be to blame.

You can exclude the specific URLs listed here from proxy server authentication, or if you want to reduce load on your proxy servers allow traffic to Office 365 and Exchange Online IP address ranges to bypass the proxy server. Note that if you do use a proxy server and wish to use the latter approach, you’ll need to consider changing client settings (either by Group Policy or by altering Proxy AutoConfig Files).

Especially if you’re using Active Directory Federated Services (AD FS), it’s important that when you logon to an Office 365 mailbox via the on-premises OWA logon you get redirected correctly to AD FS logon, rather than a Microsoft Online Services Sign-In page.

You can tell if this is about to happen when you login to on-premises OWA and see your tenant name, rather than one of your Federated domains:

 


Figure 5: On Premises OWA login showing tenant name incorrectly

The above indicates that when the end user clicks the link, they’ll then need to re-enter their entire Microsoft Online Services ID on the Office 365 login page and then click a link to redirect back to on-premises AD FS:

 


Figure 6: User being incorrectly required to sign-in after at Office 365 after OWA login

The good news is this issue is relatively easy to solve by entering the following cmdlet (replacing federateddomain with your federated domain – e.g. exchangelabs.co.uk) using the on-premises Exchange Management Shell:

Set-OrganizationRelationship “On Premises to Exchange Online Organization Relationship” -TargetOwaURL:https://outlook.com/owa/federateddomain

Summary

In the fourth part of this article, we’ve started to look at some of the common areas to test after executing the Hybrid Configuration Wizard, along with some solutions to common problems and guidance with further troubleshooting with issues. In the final part of this series we’ll look at testing and troubleshooting mail flow, federated sharing and mailbox moves.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top