locked
Odd Federation Issue Between On Prem and Skype for Biz Online RRS feed

  • Question

  • Two on-prem organisations: contoso.com and acme.com

    acme.com use closed federation. Therefore, for contoso.com and acme.com to federate, they have exchanged "allowed domain" details and it works perfectly. Contoso.com and acme.com can IM each other and so on and everyone is happy.

    Incidentally, contoso.com federate with many other organisations, not just acme.com.

    The problem is this: contoso.com are migrating to Office 365 and therefore are now hybrid. Some contoso.com users have been migrated to Office 365. These migrated users can still federate with everyone except acme.com. Whenever they try to IM acme.com users, they get "Fred Flintstone can't receive IMs right now. Status is unavailable or offline." (acme.com are still 100% on premise.)

    Checking acme.com's setup, Skype for Biz Online is definitely enabled. 

    So in summary:

    contoso.com on prem --> acme.com : works fine

    contoso.com online --> acme.com : doesn't work

    contoso.com on prem --> someotherorg.com : works fine

    contoso.com online --> someotherorg.com : works fine

    I suspect that it's a configuration missing on the acme.com configuration, but everything I've read indicated that once the Skype for Business Online provider is enabled, it should just work. And we know the edge stuff is all OK because they can receive IMs from federated on prem users. Am I just missing a configuration "trick" to allow acme.com to receive IMs from Skype for Biz online?

    TIA

    m


    • Edited by M.a.r.k.T. _ Friday, October 7, 2016 3:36 PM Typo
    Friday, October 7, 2016 3:35 PM

Answers

  • OK, problem solved and it was neither - I found the problem when I stumbled across one user in Acme that could be IMed from Contoso's Online users. In other words, it wasn't a routing issue, comms or anything like that.

    After digging around, it turned out that the users in Acme has once been SFB Online users themselves but ditched it because of the limited SFB Online archiving and monitoring. However, they all had SFB license assigned. The one user that "worked" in Acme was new. When the SFB licenses were switched off in Acme's SFB online environment, it all worked. 

    So, if SFB Online thinks that the sender and recipient are both using SFB online, it doesn't use DNS to check where to route the messages, instead (probably for speed), it does a directory lookup beforehand and then "routes" the messages internally. 

    Problem solved.

    • Proposed as answer by Anthony CaragolMVP Tuesday, October 11, 2016 3:24 PM
    • Marked as answer by jim-xu Friday, October 21, 2016 10:43 AM
    Tuesday, October 11, 2016 2:13 PM

All replies

  • I'm assuming because the federation route Acme is expecting from Contoso isn't matching the route actually taken, and Office365 isn't really trusted as an allowed domain.  If I recall correctly, and I may be WAYYY off here, once you set an Office365 domain as allowed with an on-premises org, you not only allow that Skype Online domain, but just about anyone else in O365 too, so that white listing can get a bit broken.  Could you try adding a Skype Online sip domain to acme's allow list and see if it helps at all?  If you don't know one, you can use caragol.com as a test.


    Please remember, if you see a post that helped you please click "Vote" on the left side of the response, and if it answered your question please click "Mark As Answer". SWC Unified Communications This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, SWC, their employees, or other MVPs.

    Friday, October 7, 2016 5:22 PM
  • I'm assuming because the federation route Acme is expecting from Contoso isn't matching the route actually taken, and Office365 isn't really trusted as an allowed domain.


    I reckon you're right and onto somthing here. The contoso client log does mention something like "no valid route" coming back from Office 365.

    If I recall correctly, and I may be WAYYY off here, once you set an Office365 domain as allowed with an on-premises org, you not only allow that Skype Online domain, but just about anyone else in O365 too, so that white listing can get a bit broken.


    LOL - yes, I can imagine.

    Could you try adding a Skype Online sip domain to acme's allow list and see if it helps at all?  If you don't know one, you can use caragol.com as a test.

    Funnliy enough, I did try that for lync.com though I suspect that's not the actual domain I should be using as it didn't work. Also, as you say, I was rather concerned that if this works, I'm going to have one hell of a meeting with the Head of IT Security explaining that Microsoft's whitelisting isn't quite as granular as they might expect it to be! Oh joy, that's seriously not a meeting I relish... :( Anyway, thanks for the response, I'm away Monday but will try that on Tuesday.

    I don't suppose you know what the Skype Online SIP domain to whitelist is? online.lync.com?

    Cheers!

    Friday, October 7, 2016 6:17 PM
  • first acme doesnt need ot allow office 365, your dns record should still point to your on prem edge and all traffic from acme will go through your on prem edge and next office 365.

    you need ot make sure that acme is configured as allowed in both skype for business online and your on prem environment. acme doesnt need to make any change 

    can you please provide SIP conversation from your edge showing the error. that will help to understand the issue  


    Friday, October 7, 2016 6:44 PM
  • Thanks for the reply.

    When you say "your" do you mean contoso? (Neither are mine, so I am not sure which you mean.)

    If you mean contoso, then the contoso configuration is fine (DNS is fine, it points to Contoso's Edge and everyone on the planet can communicate with Contoso no problem; also Skype Online it doesn't allow whitelists if the default is already to allow everyone; Contoso uses open federation ), it is acme that is rejecting the IMs.

    I can do traces from both edges next week (not sure which one you mean by "your" edge) - I just wondered if there was a simple step in the setup I'd missed.

    Friday, October 7, 2016 7:57 PM
  • OK, problem solved and it was neither - I found the problem when I stumbled across one user in Acme that could be IMed from Contoso's Online users. In other words, it wasn't a routing issue, comms or anything like that.

    After digging around, it turned out that the users in Acme has once been SFB Online users themselves but ditched it because of the limited SFB Online archiving and monitoring. However, they all had SFB license assigned. The one user that "worked" in Acme was new. When the SFB licenses were switched off in Acme's SFB online environment, it all worked. 

    So, if SFB Online thinks that the sender and recipient are both using SFB online, it doesn't use DNS to check where to route the messages, instead (probably for speed), it does a directory lookup beforehand and then "routes" the messages internally. 

    Problem solved.

    • Proposed as answer by Anthony CaragolMVP Tuesday, October 11, 2016 3:24 PM
    • Marked as answer by jim-xu Friday, October 21, 2016 10:43 AM
    Tuesday, October 11, 2016 2:13 PM