Last week I started the setup of an Exchange 2010 Hybrid configuration at a customer, to start a pilot with Office 365/ Exchange Online. The Office 365 Hybrid configuration run without any issues.
We did some tests like the mail flow, by validating the outbound connector, performed a successful migration of a test mailbox etc. Everything went fine so far. It was now time to have a look at the user experience. I was able to set delegates on the mailbox, cross-forest Full Access rights did work as expected. Next thing to check was the calendar sharing, are the on-premises users able to see free/ busy information from online users and vice versa? Well, users with an on-premises mailbox were able to see free/ busy information from mailboxes running on Exchange Online. But users with an online mailbox were not able to see the free/ busy information from the on-premises users. Below a view from the calendar of Test User01, which is already migrated to Exchange Online, trying to see the calendar information from Test User03 (an on-premises mailbox). As you can see, there is no information displayed of the on-premises mailbox.
I first had a look at the Organization Relationship by running Get-OrganizationRelationShip | FL from the local Exchange Management Shell and Exchange Online PowerShell.
Everything looks fine, from the Exchange on-premises and online output.
I had a look at the SharingPolicy to compare the on-premises policy and online policy. I even added the onmicrosoft.com domains to the default on-premises SharingPolicy. It made no difference; the online user was not able to see free/ busy information from a local user.
Because there are a lot of components and settings involved in the Hybrid Exchange setup I switched over to collecting some information from the (online) user side. Using Outlook I am not able to see what is going wrong by requesting the free/ busy information, so I wanted to use OWA. When using IE to open OWA you are able to use the developer tools by pressing F12, which could provide me some more information about the issue. Just logon to OWA, browse to the calendar, create a new a Calendar event and add a on-premises user to the invite. Now press F12 and IE should look like this.
Now click on Scheduling assistant. On the network tab you see a lot of information being collected. Scroll down and search for rules which looks like an Exchange command; GetUserAvailabilityInternal at my example. When you click on that rule and click on the body tab on the right site you see a lot of information which could be helpful in what is going wrong. I scrolled down and found the error Autodiscover failed for email address firstname.lastname@example.org with error System.Web.Services.Protocols.SoapHeaderException; An error occured when verifying security for the message. at System.Web.Services.Protocols.SoapHTTPClientprotocol.ReadResponse.
OK, so we have an Autodiscover issue, but people are not complaining about Autodiscover not working as expected. I run the Remote Connectivity Analyzer from Microsoft which showed nothing is wrong with the Autodiscover. One of the benefits of working at a Microsoft Gold Partner, I can create a service request. So I asked Microsoft for help instead of searching the whole web for a solution.
After discussing the issue and showing the information I already collected, I was asked by the Microsoft engineer to run the Test-OrganizationRelationship command from the Exchange Online PowerShell. By running Test-OrganizationRelationship -Identity “O365 to On-premises*” -UserIdentity email@example.com we received an error: The Autodiscover call failed (AutodiscoverServiceCallFailed)
The output confirmed an issue with Autodiscover and the engineer had a strong indication there was an issue with the EWS and Autodiscover Virtualdirectories. I was pointed to this article.
I run the commands to reset the WSSecurity authentication on both virtual directories, on both CAS Servers.
After resetting the WSSecurity authentication, I refreshed the FedarationTrust metadata on advise by the Microsoft Engineer by running Get-Federationtrust | Set-Federationtrust -Refreshmetadata from the on-premises Exchange Management Shell.