Lync Mobility on Dual Homed Front-end and co-located Mediation

One statement in this (http://technet.microsoft.com/en-us/library/hh690037.aspx) article always intrigued me.

Small organizations might elect to deploy single standard edition Front End server with co-located Mediation role and in many cases will have two network interfaces – one bound to Lync registrar services and one – dedicated to PSTN (Mediation). While this is normal (and in many cases preferred configuration), with the introduction of support for Mobile devices, we quickly found that mobility simply does not work as expected.

I was able to replicate this behavior in my Lync 2013 lab as well. My front end server have two interfaces – 10.255.2.101 set in Topology as “Primary” and 192.168.1.101 set as “PSTN”. My goal was to isolate traffic to and from the PSTN gateway on its own subnet.

In the above configuration, the failure of mobility support is obvious – mobile client was able to sign-in, but presence is shown as “Away” and while I can change it from the mobile client (where the new status will be shown correctly to my contacts, mobile client itself will not update. Also, IM works from mobile client to other parties, but not vice versa.

The logical conclusion is that we have one way communication. However, the sign-on is two way process and we were able to sign in, with other words we DO have two way communication. Very confusing, indeed.

Mobile client uses the web services to sign-in and communicate with Lync server. Reverse Proxy forwards external traffic to the HLB VIP, which in return forwards to IIS on the FE pool, which by Topology definition is bound to the Primary (10.255.2.101 in this case). 

Not surprisingly, we have two way communication because the traffic always flows between well-known IPs.

After we are signed to the mobile client, any modality, however, is processed by the SIP Stack. Examining the log from failed IM attempt from federated contact shows something strange:

Hmm, connection was closed? Indeed, because the Peer is… 192.168.1.101 i.e. out interface dedicated to PSTN.

This is not Lync server problem! It is how Windows OS is handling the precedence (Metric) of the network interfaces. While we have INVITE to the pool

…we called the wrong IP.

Using utility named dnstest.exe, we see something very interesting. When use the utility with option –w (wire query only), DNS query for the second member of the pool returns the LAN IP only, which make sense, because DNS have only one A record, pointing to the LAN IP address (PSTN IP is not registered).

Same query for the host itself returns the two IP addresses on the server and note – it NEVER makes DNS wire query (confirmed with Wireshark).

Furthermore, the “wrong” IP is listed first in order, which explains why when the server initiates call to the pool:5087, it does so calling the wrong IP address.

Looking the Network Adapter settings, we note that the two are set to “Automatic Metric”.

Here I set the Primary adapter with Metric 1

…and the PSTN adapter with Metric 99

Now dnstest tool shows the desired order:

Restarted all Lync services on this machine (Stop-CsWindowsService, Start-CsWindowsService), did so on the second server in my EE pool and Mobility worked as expected with all modalities. The Sip service now called the correct IP address:

Conclusion

This example shows that it is possible to configure dial homed Frond end service with co-located mediation role for Lync mobile support. However, this is Lab setup for testing only. There is no official support from Microsoft for this solution and implementing in Production environment is not supported my any means. Use it on your own risk.