Lync Mixed Mode: Sip Federation issue while remove one Edge Pool
Today I came across this issue and I can’t find any article which has this fix so sharing to help others.
Lync 2013: If you have multiple edge pools and you remove one of them it will break your sip federation.
If you have Lync 2010 and Lync 2013 Co-existence with multiple edge pools, in my case I have 1 Lync 2010 edge pool and 2 Lync 2013 Edge pools in a Single site.
To follow Microsoft recommendation we decided to create another Lync 2013 site with 1 FE and 1 EDGE pool. I won’t go in detail on how to create site and pools. I just want to show how the SIP federation breaks if you remove the Edge pool.
I removed (Lync 2013 edge pool 2) from topology and published the topology. Next morning we noticed presence unknown for federated partners.
Later I ran couple of tests in my Lab and figured some Odd behavior.
My Lab environment
Lync 2010 Edge pool’s next hop pool is Lync 2010 Director pool
Lync 2013 Edge pool 1’s Next hop pool is also Lync 2010 Director pool
Lync 2013 Edge pool2’s Next hop pool is Lync 2013 FE pool
On Enterprise Site SIP federation is enabled and pointing to Lync 2010 Director pool.
Test1- If you delete the Lync 2013 Edge pool2 which has next hop pool as Lync 2013 FE it won’t disable your SIP federation on enterprise site which is what one would expect as we still have other EDGE pool’s which require SIP federation.
Look at the screen shoot below.
After deleting the Edge pool we still have SIP Federation enabled which is what we expect.
Test2- If you delete the Lync 2013 Edge pool1 which has next hop Pool as Lync 2010 Director pool It will disable the Federation route which is really weird as we still have other EDGE pool’s which require sip federation.
Following screen shoot shows after deleting the Lync 2013 pool1 sip federation has been disabled which is unexpected behaviour.
So if you have similar situation in your environment you can enable the sip federation again on Enterprise site and It will solve your presence unknown issue.
I am trying to reproduce the issue in a clean lab environment to see if this is a problem with Lync 2013 or expected behavior. I will keep posting my finding on this.
There is a Microsoft Article on this but that does not match with 2 testes I performed.
Microsoft Exchange / Lync Architect