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.
