Friday, April 08, 2016

Office 365 - Exchange Online - Free/Busy Query from Exchange Online Mailbox to On Premises Exchange Fails

This topic is quite a common one, but in my case, the resolution is not.

So let's start with the environment:


  • Exchange 2010 SP3 RU12
  • TMG 2010 
  • HCW v3

Here is the problem: Exchange Online users cannot get free/busy information of users still on premise Exchange. The other way works fine, i.e. Exchange 2010 users can see free/busy information of Exchange Online mailbox users.

First and foremost, you should run through the following tool and checking everything is in place:


It is a very comprehensive tool, and make sure you don't skip any steps.

In my case, everything checks out in that tool. Even running Office 365 Free/Busy test from Microsoft RCA also returns free/busy data from on premise user:


And the result would be successful, and returns the free/busy data for the on premise user:




As part of the troubleshooting process, you would run the following PowerShell command from Exchange Online:

Test-OrganizationRelationship -UserIdentity onPremMailbox@company.com  -Identity “O365 to On-premises
- 668sscac-01as-41s1-sd21-e5sslsh3d1c5” -Verbose

And the result would be:

STEP 5: Getting organization relationship setting from remote partner…

RESULT: Unable to retrieve organization relationships from remote organization.
RESULT: Error.

LAST STEP: Writing results...

And that's your first indication that something is broken.

If you dig into your Exchange CAS server's IIS log, and search for "testorg", you will see the following entries:

2016-04-07 07:03:12 10.80.5.101 POST /autodiscover/autodiscover.svc - 443 - 10.30.5.47 TestOrganizationRelationship/1.1 200 0 0 109

2016-04-07 07:03:12 10.80.5.101 POST /autodiscover/autodiscover.svc/WSSecurity - 443 - 10.80.5.47 TestOrganizationRelationship/1.1 500 0 0 0

By running the "Test-OrganizationRelationship" PowerShell command, it generates a test against the on premise Exchange server, and although when accessing "/autodiscover/autodiscover.svc" worked (as indicated by HTTP 200 code), but when accessing "/autodiscover/autodiscover.svc/WSSecurity", HTTP error code 500 (internal server error) is record.

OK, we are getting somewhere here. Why is /WSSecurity not accessible?

Let's check our WSSecurity settings on all CAS servers. Go to Exchange Management Shell, run the following commands:

Get-AutodiscoverVirtualDirectory -server | fl *wss*
Get-WebServicesVirtualDirectory -server |  fl *wss*

Notice that the result shows that WSSecurityAuthentication is already set to $true. So what now?

Well, we fixed our problem by setting the flag to $true again.

I know it sounds counter-productive, but apparently setting the flag does something at the backend and actually fixes the problem. 

So execute the following commands from Exchange Management Shell (on premise Exchange):

Get-AutodiscoverVirtualDirectory -server | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $true

Get-WebServicesVirtualDirectory -server | Set-WebServicesVirtualDirectory -WSSecurityAuthentication $true

Next, either do a IISReset or just recycle the following AppPools from IIS Manager:
  • MSExchangeAutodiscoverAppPool
  • MSExchangeServicesAppPool

VoilĂ ! Problem fixed. Run "Test-OrganizationRelationship" from Exchange Online PowerShell and it would work now. And now if you do the free/busy test, it should work.

This took 2 weeks to troubleshoot with 2 different Microsoft engineers, so hopefully this will help someone.


4 comments:

Unknown said...

Thank you so much! We had exactly the same problem!

AndyChips said...

I cannot thank you enough for posting this fix. It worked perfectly for me after I had tried almost everything else.
Thanks!!

Unknown said...

Had the exact same problem in a test environment started from scratch. It's quite stupid that MS has these types of bugs.
Did the steps above, and it was fixed.
Thank you!

Chris said...

Thank you very much for this post, it has resolved an issue we have bee working on for quite some time now! MS were not being very helpful at all for us and this was the solution we needed! Thanks