Troubleshooting Hybrid Configuration Wizard failures
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 LoggingUpdate-HybridConfiguration folder – for example:
C:Program FilesMicrosoftExchange ServerV14LoggingUpdate-HybridConfiguration
Common Reasons:
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:
- 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:
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:inetpublogsLogFiles, 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.
When troubleshooting remote move requests, check the following:
- Credentials used to request the mailbox move.
- FQDN is correct for the Hybrid Client Access Servers
- Database name entered when moving mailboxes from Office 365 to on-premises
- Ensure that DirSync is correctly running and for moves to Office 365 Mail-Enabled contacts have been created that correspond to the On-Premises mailboxes being moves; and for moves from Office 365, DirSync writeback for Rich Co-existence was enabled when DirSync was configured.
- The MRSProxy is enabled for the Hybrid Client Access Servers. You can verify this with the following command, which should show MRSProxyEnabled as True:
Get-WebServicesVirtualDirectory | fl Identity,MRSProxyEnabled
By: http://wizsystem.co.uk/
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.
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, including OWA, ActiveSync and Outlook Anywhere.
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.
- Testing Mail Flow
Naturally mail flowing back and forth correctly is a key component of any mail system, therefore it’s important to ensure this is the case with your new Hybrid environment.
- As a minimum, test the following features:
- Test mail flow from on-premises to Office 365
- Test mail flow from Office 365 to on-premises and the internet
- Test mail flow to unauthenticated distribution groups from Office 365
- Test mail flow to authenticated distribution groups from Office 365
- Test internal Out of Office set on an on-premises user from Office 365
- Test internal Out of Office set on an Office 365 user from Office 365
- Testing Federated Sharing
The Federated Sharing Features primarily allow free/busy and Calendars to be shared between uses in both on-premise and Office 365 sides of your Hybrid Exchange environment.
Both availability and calendar sharing rely heavily on Exchange Web Services for functionality, and the configuration and testing put in place in the first part of this article should ensure that both work, however it’s important to test these features and at the same time understand how it should be used by end users.
The following tests should be performed to ensure functionality.
- Test availability of on Office 365 user from on-premises
- Test availability of an on-premises user from Office 365
- Test Calendar sharing by creating calendar sharing requests
- If you have a larger organization with Exchange servers in multiple Active Directory sites, test to and from test users in non-internet facing Active Directory sites after testing against users in internet facing sites.
- Testing Mailbox Moves.
The final feature that is important to test, if you plan on moving Mailboxes either to or from Office 365, is Remote Moves. To ensure you can move mailboxes both ways, ensure you test:
- Test mailbox move functionality from on-premises to Office 365
- Test mailbox move functionality from Office 365 to on-premises
To initiate moves, navigate either to your On-Premises or Office 365 organization in the Exchange Management console and expand Recipient Configuration > Mailbox to find the mailbox you want to move to the opposite organization, then right-click and choose New Remote Move Request:
http://cloudxperts.blogspot.co.uk/2016/03/migration-to-office-365-part2-using.html
http://cloudxperts.blogspot.co.uk/2016/03/migration-to-office-365-pre-checks.html
Credit : Microsoft MSDN, exchange.org and Google