Lync 2013: Hybrid configuration would break the OnPrem-Federation
In one of my recent projects where I was involved in On-Prem to Office 365 Migration I experienced Lync 2013 Hybrid deployment would break the On-Prem Sip Federation with federated partners.
Issue:
After we configured our edge serves for Hybrid configures i.e enabledsharedaddressspace TRUE we noticed on-prem users will see presence unknown for federated users as well as users who are migrated in cloud. However federated partners or users in cloud can still see your presence information and if they initiate the communication with you it all works fine. You might notice the same issue if your environment is configured as mine.
Environment
Lync 2010 FE and Lync 2013 FE Co-Existence with Lync 2010 Edge servers. Our environment is configured for hybrid deployment and ready to be migrated on Office 365. We noticed above issue after we migrated first user in cloud.
Troubleshooting:
2- Run following command to verify if Proxy FQDN of Lync online, EnabledSharedAddressSpace and AutodiscoverUrl is set properly.
3- Run following command to verity AllowFederateduser and SharedSipAddressSpace is set to True
Note: – This is O365 side configuration so you need to have admin access to connect remote power shell
In my case above configuration is set properly and On-Prem federation was working fine before we enabledSharedAddressSpace as True in Step 2
4- I changed the EnabledSharedAddressSpace as False and SIP federation started working with onprem federation partner. But this is not the solution as without setting EnabledSharedAddressSpace as true onprem to O365 communication will not work.
5- Based on some errors in client logs (unfortunately I do not have copy of that log) we figured following Internal DNS records are required for Hybrid configuration to support split domain model. Normally these records does not make any sense to be resolved internally. I could not find any MS Document which says these Records are required for Hybrid configuration.
Once we added above records and verified FE and EDGE servers can resolve it internally, our On-Prem Federation started working with other federated partners. But still one side On-Prem to O365 Federation is broken.
6- We noticed following error in client logs which shows that destination server refused the connections
Note:- In our case it was trying to connect to one of the internal video conferencing server. if we try to resolve a user Sipaddress@ourdomain.com and if users does not exist locally on our On-Prem server then that request should go to O365 server in cloud because we are it was going to video conferencing server in on-prem and that’s why on-prem to O365 Federation was not working.
7- We ran Get-CsStaticRoutingConfiguration and figured we had static route exist which was created in past for some unsuccessful attempts to integrate VC with OCS.
Solutions:
We removed the static route and it resolved the issue.
Summary:
-
Federation Issue (on Prem federation will break in hybrid environment if above mentioned internal DNS records are not resolved internally.
-
Unable to send IM: On-Prem to O365 Federation will not work if you have a static route created for your domain which is being shared between On-Prem to O365
Sanjeev Gandhi
Exchange and Lync Architect
Team@MSExchangeGuru
February 22nd, 2014 at 11:17 am
[…] Lync 2013: Hybrid configuration would break the OnPrem-Federation – […]
February 22nd, 2014 at 11:28 am
[…] Lync 2013: Hybrid configuration would break the OnPrem-Federation – […]
September 18th, 2014 at 2:39 am
Thank you so much! Was having the exact same issue and by adding this entry in our internal DNS it has fixed the problem.
Regards,
Mike
November 5th, 2014 at 8:52 am
Question, when you created the internal DNS SRV records above – where do they point to? Front End Pool internal IP?
Is your im.domain.com record your SIP domain?
I am experiencing this issue and followed the steps above, it seems that after enabling the SharedAddressSpace and HostsOCSUsers settings to True, on-premise federation breaks with external partners. I’ve checked DNS resolution from the Lync Edge server, and it seems fine, but I must be missing something.
Thanks.
November 12th, 2014 at 12:01 pm
Rich, Im.domain.com is access edge. So in your case whatever external record you have for your access edge , create the same in internal DNS as well.
Thanks
Sanjeev
November 12th, 2014 at 1:57 pm
Hi Sanjeev, and im.domain.com being the access edge you would just create an internal DNS record pointing to the Public IP (to match external DNS) – correct? Thanks for the reply!
November 12th, 2014 at 4:31 pm
Yes
February 9th, 2015 at 12:17 pm
Hi Sanjeev
Thank you for an informative article.
Does the setting of this record have any bearing on the actual federation routing with external partners? In other words, will federation with externalpartner.com be continued to be routed via the O365 federation servers or always through the on-prem Edge Server?
For a company with 99% users on O365 and a small minority on on-premise Lync using Hybrid Lync, what way will the traffic flow for communication with federated partners?
It would seem that no matter what, there would be an extra hop. For example, if external federation terminated on O365 servers, then for on-premise users it would have to hop back out over the Internet to the on-premise Edge server (or vice versa)
February 11th, 2015 at 11:22 am
Hello Ernest,
Setting this record would not make any change in your current routing. Your federation route will still remain same. I.e outgoing federation for On-Perm users will use your On-Prem Edge server. And yes in a hybrid environment there would always be an extra hope does not matter where the federation is terminated.
Hope it answers your question…
Thanks,
Sanjeev
February 11th, 2015 at 2:51 pm
Hi Sanjeev,
Thank you so much for posting this article. I had this exact issue and your post about the DNS records solve it perfectly.
Thank you again for helping me fix my issue after days of stress!
February 11th, 2015 at 4:38 pm
Hi Toby, Glad to see your issue is fixed. It took real long to figure out what was causing this. And I found it worth writing as it wasn’t documented anywhere else.
Thanks,
Sanjeev Gandhi
July 12th, 2015 at 4:41 am
[…] Lync 2013: Hybrid configuration would break the OnPrem-Federation […]
August 14th, 2015 at 4:20 pm
Wow. I can’t believe that the static route caused this. We use POLYCOM and we have a “matchuri” of @sipdomain.com – and, it breaks hybrid. I can’t believe that I actually found this article. I am not sure what I’m going to do. Dang, I am getting tired of this POLYCOM / Lync integration
October 7th, 2017 at 2:21 am
Hello Sanjeev,
Trying to understand why that internal SRV record is needed to go out to the Edge server and back in again. Is it hairpinning ? Can you please explain ? Strange that this not documented anywhere.