locked
SfB Online users cannot see our on-premises user's presence RRS feed

  • Question

  • Hi there,

    We've setup our Skype for Business environment in a hybrid mode, because we are sharing our SIP domain with the Mail domain that we have in Office 365.

    Federation is working with other on-premises users, two-way.
    Federation is working from on-prem users to Online users (presence information is there)
    Federation is not working from online users to our on-prem users (Presence information is OFFLINE)

    I've already checked our DNS record which is pointing to the access edge (federation with other partners is working, so I don't see a problem with DNS).
    I've also have setup the Hybrid environment for our SfB successful (as to the point I know).
    SIP domain is set as a shared domain.

    I hope anyone can help me out here. I'm stuck.

    Thanks.

    Ronald

    Friday, July 22, 2016 10:41 PM

Answers

  • Guys,

    I've found the solution, sorry for letting you know with a little delay.

    Maybe a little history was needed, that I didn't mention.

    We've had our former local AD synced with this O365 tenant, broke the synchronization, created a whole new AD on-prem with a new SfB infrastructure, and anchored the users back with a new AD Connect deployment. This all went pretty smooth.

    But due to the existing users, these users already were enabled for SfB, so those SfB users were thought to be in the Cloud by all the other O365 tenants.

    After I created the Hybrid SfB environment, this still wasn't solved until I moved all the users to the Cloud and moved them back on premises again. I then could see the list of users in the SfB online mgmt console be removed, and so these users are now to be thought non existing in the Cloud. Therefore, O365 tenants will now use the normal DNS lookups, and find our users through our SRV DNS record.

    This is the simplest explanation I could give to it.

    Thanks for all the help!

    Regards,

    Ronald van Ackooij

    Thursday, July 28, 2016 2:59 AM

All replies

  • Have you enabled Partnerdiscovery in Lync control panel or setup direct federation ?

    Verify if the client certificate has all SAN and the cert enabled for all purposes, go to the properties of the certificate in certificate store and verify if the certificate is enabled for all purpose if not enable it.

    In edge server, edit Local Hosts file to add your FE pool IP and hostname to make sure there are no dns resolution issues.

    NSLOOkUP to verify if there are any issues.

    while you are testing federation functionality, please collect logs from the edge server and see who is actively refusing the connectivity.

    From the edge collect Sipstack and S4 - these logs will reveal exact reason why your online federation is failing.

    You can also take wireshark for understand the network flow.

    -

    Please follow this article which has covered good information regarding federation 

    https://lyncdude.com/2014/05/29/complete-guide-troubleshooting-lync-federation/

    Hope this helps


    Regards, Rajukb | MCSE (Communication ), MCSA (o365) ,Certified "Lync server 2013 depth support engineer"| This posting is providedwith no warranties and confers no rights. If my reply answers your question please mark as answer/helpful if its helpful.


    Saturday, July 23, 2016 6:06 AM
  • Hi Ronald, 

    Addition to Rajus Suggestion could you also verify that you have the domain added to the shared address space as well 

    https://technet.microsoft.com/en-us/library/jj205126.aspx?f=255&MSPPError=-2147217396


    Linus || Please mark posts as answers/helpful if it answers your question.

    Saturday, July 23, 2016 8:16 AM
  • Hi I understand most of what you are saying, but federation with ANY partner is working from our site out. Federation from a non-SfB online partner to us is working just fine.

    Only thing not working is the federation from SfB Online users (partners) to us.

    Domain is set as shared domain.

    DNS lookups are fine (Edge is using internal DNS) internal DNS has the _sipfederationtls._tcp.domain.com dns record and thus federation is working.

    It seems that because of the shared domain in the online world, that the partners (online) are looking the users up in the online space, but they are homed on-prem.

    All the DNS records are pointing to the on-prem edge server!

    Also I can move a user to the cloud and back just fine.

    I will try to look at the logs, which I have enabled yesterday, so there now should be some information. (I've used the AlwaysOn logging scenario in the logger. (please point me to a good blogpost on doing the logs, maybe I'm doing something wrong there).

    Thanks for the effort, appreciate it!

    greets,

    Saturday, July 23, 2016 5:09 PM
  • Guys,

    I've found the solution, sorry for letting you know with a little delay.

    Maybe a little history was needed, that I didn't mention.

    We've had our former local AD synced with this O365 tenant, broke the synchronization, created a whole new AD on-prem with a new SfB infrastructure, and anchored the users back with a new AD Connect deployment. This all went pretty smooth.

    But due to the existing users, these users already were enabled for SfB, so those SfB users were thought to be in the Cloud by all the other O365 tenants.

    After I created the Hybrid SfB environment, this still wasn't solved until I moved all the users to the Cloud and moved them back on premises again. I then could see the list of users in the SfB online mgmt console be removed, and so these users are now to be thought non existing in the Cloud. Therefore, O365 tenants will now use the normal DNS lookups, and find our users through our SRV DNS record.

    This is the simplest explanation I could give to it.

    Thanks for all the help!

    Regards,

    Ronald van Ackooij

    Thursday, July 28, 2016 2:59 AM
  • Thank you for sharing. Good to know its resolved.


    Linus || Please mark posts as answers/helpful if it answers your question.

    Thursday, July 28, 2016 7:45 AM