I hope someone can help here. The basic gist of this is that I think it's a firewall issue but I need help to prove that. I'm not a networking guy at all. I know Exchange fairly well but don't have a clue about Firewalls etc. So, we have an environment consisting of Exchange 2010/2013/Online. There is an issue viewing free/busy information but only in one direction. Exchange Online users cannot view free/busy info of Exchange 2013 users. Free/busy sharing works in every other direction. I had a look at the MS troubleshooting guide; I then noticed that, from the 2013 servers, I cannot connect to powershell online, nor can I successfully run Get-FederationInformation -DomainName <365 tenant>. Both of these work on Exchange 2010.

If I run Get-FederationInformation -domainname <Office 365 Domain> on an Exchange 2010 server I get the repsonse:

RunspaceId            : xxxxxxxxxxxxx
TargetApplicationUri  : outlook.com
DomainNames           : {domain.onmicrosoft.com, domain.mail.onmicrosoft.com}
TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity
TokenIssuerUris       : {urn:federation:MicrosoftOnline}
IsValid               : True

If I run that on an Exchange 2013 server I get:

Federation information could not be received from the external organization.
    + CategoryInfo          : NotSpecified: (:) [Get-FederationInformation], GetFederationInformationFailedException
    + FullyQualifiedErrorId : [Server=MBXSERVER,RequestId=xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx,TimeStamp=26/08/2015
   07:15:37] [FailureCategory=Cmdlet-GetFederationInformationFailedException] D11619D6,Microsoft.Exchange.Management.
  SystemConfigurationTasks.GetFederationInformation
    + PSComputerName        : casserver.domain.com

So, my ultimate questions are:

 - Do you think this is a firewall issue?
 - If so, how can I prove it?
 - What else could cause this behaviour?

Installing Wireshark etc. on the Exchange servers isn't an option.

Thanks...

This is one of the most frustrating things you can run into when setting up a hybrid configuration.  There are lots of suggestions for fixing this on the Internet, which is what I end up doing on the occasions when I run into this.

Hi,

Since Exchange 2010 running well with Get-FederationInformation, it indicate that federation trust works well.

For error message "Federation information could not be received from the external organization", I find an article about it for Exchange 2010, it's caused by missing the svc-Integrated handler mapping in IIS configuration. For your reference: https://support.microsoft.com/en-us/kb/2773628

Meanwhile, here's an blog about Office 365 Insight into the Hybrid Configuration Wizard, it provide more tips for this error: http://blogs.technet.com/b/mikehall/archive/2013/08/21/office-365-insight-into-the-hybrid-configuration-wizard-part-2.aspx

Where are all of the CAS namespaces pointing to for Autodisover EWS,OAB, OWA, ECP etc?

I'm suspecting that if its working for the Exch2010 users, the URLs are all still pointing to CAS10.

Hi,

Thanks for the replies. Firstly, just to mention, I have made a mistake in the original post. The direction that's having a problem is 2013 - Exchange Online. i.e. - 2013 users cannot see Exchange Online calendars but Exchange Online users CAN see 2013 (and 2010) calendars. Sorry for the confusion. Allen, about your comment:

"For error message "Federation information could not be received from the external organization", I find an article about it for Exchange 2010, it's caused by missing the svc-Integrated handler mapping in IIS configuration. For your reference: https://support.microsoft.com/en-us/kb/2773628"

I think the svc-integrated handler mapping is there. I'm guess that, because this is Server 2012 / Exchange 2013, it's normal for this to show as svc-Integrated-4.0. Is that right? Screenshow below:

Rhoderick, thanks. Hopefully you are on to something.

EWS - Points to 2013 on all servers.
OAB - Points to 2010 on 2010 servers, 2013 on 2013 servers.
OWA - Points to 2010 on 2010 servers, 2013 on 2013 servers.
ECP - Points to 2010 on 2010 servers, 2013 on 2013 servers.

So, just to be clear, we have a DNS name email.domain.com that points to 2013 and webmail.domain.com that points to 2010.

Does that look right? Another issue that may be playing a part is that ISA servers are used before the perimiter firewall. These were configured by someone before I joined the company. I have a pretty basic knowledge of them so can't be 100% confident the issue doesn't lie there.

Does the namespace setup look right to you?

Interestingly the free/busy test on the MS test connectivity site passes for this scenario and returns valid appointments for an Office 365 user. What would that indicate?

Thanks.

• Edited by wiggum83 21 hours 10 minutes ago

Hi,

Thanks for the replies. Firstly, just to mention, I have made a mistake in the original post. The direction that's having a problem is 2013 - Exchange Online. i.e. - 2013 users cannot see Exchange Online calendars but Exchange Online users CAN see 2013 (and 2010) calendars. Sorry for the confusion. Allen, about your comment:

"For error message "Federation information could not be received from the external organization", I find an article about it for Exchange 2010, it's caused by missing the svc-Integrated handler mapping in IIS configuration. For your reference: https://support.microsoft.com/en-us/kb/2773628"

I think the svc-integrated handler mapping is there. I'm guess that, because this is Server 2012 / Exchange 2013, it's normal for this to show as svc-Integrated-4.0. Is that right? Screenshow below:

Rhoderick, thanks. Hopefully you are on to something.

EWS - Points to 2013 on all servers.
OAB - Points to 2010 on 2010 servers, 2013 on 2013 servers.
OWA - Points to 2010 on 2010 servers, 2013 on 2013 servers.
ECP - Points to 2010 on 2010 servers, 2013 on 2013 servers.

So, just to be clear, we have a DNS name email.domain.com that points to 2013 and webmail.domain.com that points to 2010.

Does that look right? Another issue that may be playing a part is that ISA servers are used before the perimiter firewall. These were configured by someone before I joined the company. I have a pretty basic knowledge of them so can't be 100% confident the issue doesn't lie there.

Does the namespace setup look right to you?

Interestingly the free/busy test on the MS test connectivity site passes for this scenario and returns valid appointments for an Office 365 user. What would that indicate?

Thanks.

• Edited by wiggum83 Thursday, August 27, 2015 10:16 AM

That's not what is expect to see. For an exchange 2010 to 2013 migration I expect all CAS namespaces to be cut over to 2013. This is what we have in the exchange 2013 deployment assistant.

Ok, thanks Rhoderick. Most of this environment was seutp by my predecessor. Can you think of any negative implications of changing the namespaces to point to 2013? It's something I'd need to do over the weekend anyway...

Cheers.

Hi,

Here's an similar thread about "Things to consider before configuring Autodiscover in Exchange 2010/2013
coexistence scenarios", for your reference:
https://social.technet.microsoft.com/Forums/office/en-US/827b3566-4608-465e-a81e-6376b197455b/exchange-2010-coexistence-urls?forum=exchangesvrdeploy