While supporting another amazing Insentron this week, I was called in to help troubleshoot hybrid connectivity issues prior to an Exchange 2010 hybrid migration to Office 365.
The issues experienced included trouble with inbound and outbound mail-flow, Autodiscover and Free/Busy availability. They also had limited access to shared mailboxes across the hybrid boundary.
The customer had set their network up for Exchange Classic Hybrid Topology with a new DNS namespace representing a new Exchange 2016 server acting as the hybrid endpoint. The other Exchange (mailbox) servers were running Exchange 2010 with a hardware load-balancer for CAS roles.
There were some basic connectivity issues to address including – for reference:
- Firewall address lists missing some known Microsoft endpoint ranges for SMTP (25) and HTTPS (443)
- This caused queues on inbound mail-flow destined for Exchange Online for via SMTP
- Reference here:
- Customer’s mail hygiene service not whitelisting the new hybrid endpoint IP
- This blocked outbound mail-flow to the hygiene service
- Solution: Exclude hybrid server from the appropriate Send Connector to ensure correct NAT source addresses.
- AutoDiscover on-premises not resolving migrated mailboxes
- Cause: Mismatched UPNs
- Solution: Ensure matching UPNs between AD and Office 365
At this point, AutoDiscover was working as expected for both on-premises and migrated mailboxes but Free/Busy and shared mailboxes were still not working, and Outlook calendar displayed an error saying “could not be updated”
On further investigation using Remove Connectivity Analyser the test showed AutoDiscover completing successfully but EWS returning authentication error relating to WS-Security.
Next steps
During the Hybrid Configuration Wizard configuration process, Microsoft creates objects to represent organisation relationships between the on-premises Exchange environment and Exchange Online. This Organisation Relationship defines various addresses (URIs) which it will use to cross the hybrid boundary between Office 365 and on-premises Exchange. Some are explicitly populated but others are left to AutoDiscover by default.
Resolution
In the case of this specific environment, AutoDiscover returns the VIP associated with the Exchange 2010 CAS servers. However, as above, this was blocking WS-Security. Since the customer was not in a position to reconfigure the existing load-balancer, the decision was taken to populate the TargetSharingEpr with the EWS address of the Hybrid endpoint.
To do this (in PowerShell)
- Connect to Exchange Online PowerShell
- Find the correct Identity of the correct Organisational Relationship – Get-OrganisationalRelationship
- Find the URI of the Hybrid EWS endpoint – typically “https://<hybrid endpoint namespace>/ews/Exchange.asmx”
- Run Set-OrganizationRelationship -Identity <Identity from #2> -TargetSharingEpr “<Hybrid EWS URI from #3>”
In my experience, this should take effect almost immediately and Outlook or OWA will show Free/Busy and Shared Mailbox/ Calendars for on-premises mailboxes as expected.
This compromise does introduce a single point of failure for Free/Busy integration during migration coexistence, but it is deemed to be a risk worth taking. An additional 2016 server could be introduced to the environment and configured in a new VIP to provide further resilience if required.
I hope this helps someone – or just me when I forget.
