MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

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:

  1. Federation Issue (on Prem federation will break in hybrid environment if above mentioned internal DNS records are not resolved internally.

     

  2. 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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

14 Responses to “Lync 2013: Hybrid configuration would break the OnPrem-Federation”

  1. NeWay Technologies – Weekly Newsletter #83 – February 20, 2014 | NeWay Says:

    […] Lync 2013: Hybrid configuration would break the OnPrem-Federation – […]

  2. NeWay Technologies – Weekly Newsletter #83 – February 21, 2014 | NeWay Says:

    […] Lync 2013: Hybrid configuration would break the OnPrem-Federation – […]

  3. Mike Says:

    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

  4. Rich Says:

    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.

  5. sanjeev Says:

    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

  6. Rich Says:

    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!

  7. Sanjeev Gandhi Says:

    Yes

  8. Ernest Says:

    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)

  9. Sanjeev Gandhi Says:

    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

  10. Toby Says:

    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!

  11. Sanjeev Gandhi Says:

    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 

  12. Skype for Business Hybrid Deployment (Test Lab) | Vuhondat Says:

    […] Lync 2013: Hybrid configuration would break the OnPrem-Federation […]

  13. @gregseeber Says:

    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

  14. John Smith Says:

    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.

Leave a Reply

Categories

Archives

MSExchangeGuru.com