A customer I was working with who has an existing on-premises Lync deployment had trouble federating with with certain partner domains. After investigating the issue it was determined that the problem partner domains where using Skype for Business Online. The symptoms where that the users in the partner domain where able to see my customer’s presence information and able to send Instant Messages. However, the customer could not see the partner presence or reply to any communication (one-way federation).
I have come across one-way federation issues before whilst deploying, however, this was different in that the customer could federate with other partners fine, so I knew that the usual suspects such as certificates, DNS and firewall were probably not going to be the culprits here.
So focusing on the fact that the partner domain was in Office 365 this at least gave a starting point. Tracing the communication between the on-premises Edge server and Office 365 I was able to see that indeed the customer’s Edge server was discovering the correct federation SRV record for the partner (sipfed.online.lync.com) and from the Edge server I could establish a connection to Office 365 using Telnet. However, the Edge server received no response from Office 365 federation service and timed-out the connection, which explains why customer users aren’t able to establish a communication stream.
I decided I would perform a couple of DNS lookups against other working partner domains. Then a bombshell! Some of the partner domains the customer had no problems federating with where also Skype for Business Online partners too!
How can it work fine for some Skype for Business Online partners but not others?
I knew the customer had an Office 365 tenant, but the tenant is enabled for Exchange Services only. The domain purpose for Skype for Business Online was not enabled and DNS testing on the tenant confirmed the tenant was configured properly.
Comparing the Skype for Business Online partners who had no issues federating with the customer against a partner who we could not establish a federation route to we stumbled upon an interesting difference. The working partners Office 365 tenants where all homed in a different Office 365 datacenter to that of the customers tenant. While the problem partners tenant where located in the same Office 365 datacenter.
Taking my understanding on how Office 365 handles federation, in that federation happens internally to Office 365 before breaking out to SRV lookup, could this process be affecting the customer? Remember, their tenant is not configured for Skype for Business Online.
Turns out the answer is yes.
If you have a domain which you use for on-premises Skype for Business added to your Office 365 tenant, Even if you don’t use Skype for Business Online services, even if the domain purpose is not enabled for Skype for Business Online, Office 365 will attempt to federate internally within the same datacenter before going out to SRV.
As a result, Office 365 will not send a response out to your edge server’s federation request.
So the solution is that if you have added a domain to your Office 365 tenant and you use that domain for on-premises Skype for Business, regardless of your licenced usage you must configure Skype for Business hybrid in order to federate properly with partner Office 365 tenants located in the same Office 365 AD forest (Datacenter). In addition to this, your allowed and blocked domain lists in Skype for Business Online must match your on-premises domain, and allow federation must be enabled on the Skype for Business Online tenant.
Once hybrid had been configured federation immediately started to work with the problem partner domains.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale