Lync 2013 dual homed collocated Mediation server – the problem

First of all apologies for the rather long title, but I felt the need to state the full scenario in one sentence.

I have been struggling a little with this scenario for a while, and although it is briefly described as a supported and “no-brainer” setup in the TechNet documentation you come across it proved much harder than I first anticipated when recommending this design for a small sized customer. It also struck me, in regards to the previous reference to TechNet, how poorly documented this actually is – and inspired me to shed a little light to this dark corner of Lync Server installation.

As this post, as usual, turned out to be longer than I wanted it to be I decided to break it into two: This one being sort of the background or explanation, the next one will elaborate on the how-to’s.

Happy reading!

This topic, or rather the idea or feature, of running a server with separate NIC’s for traffic destined to/from the telephony system and Lync side traffic has been around since OCS 2007R2.
In OCS R2 this was only possible on a dedicated Mediation server, since collocation on the Front End was not supported. Since Lync Server 2010 it has been fully supported to run Mediation as a service on the Front End itself.

The specific scenario with collocated server roles and multiple NIC’s also serves some attention here, as it is not necessarily applicable to everyone.

First of all the collocation of servers/roles, or the “all your eggs in the same basket” approach, is definitely something to consider. However, there are organisations and businesses out there with needs that fall below the capacity or redundancy design of Enterprise solutions. Those customers also tend to be more “economically aware” of the cost/benefit from the more “recommended” solutions – especially since a fully redundant solution needs redundancy in ALL functions/roles from SIP trunks to servers. For some of those, the “redundancy” of a virtualized server falls within the reasonable category, and IMHO the stability I have seen on this kind of “simpler solutions” that I have deployed around for my customers is nothing but impressive. And so it is an alternative to consider, enabling all the fantastic features of Lync with a minimum of servers!

Second, in regards to dual NIC setup, which might also be an alternative on dedicated Mediation servers; when would you want to go with this option when running all services the same NIC works just fine (usually, anyway)? The best answer to that is probably security. SIP trunks, at least in Norway where I live, are often delivered as dedicated WAN links/VPN connections providing QoS/bandwith assurance for your telephony channels. Placing the provider’s LAN NIC directly within your server subnet is not preferrable, or even an option to some. There is the alternative of putting it in a separate subnet and routing it to your Mediation service through a firewall – that will definitely take care of security, since you can rule out anything but allowed SIP and media traffic between Mediation server and provider. Alas, firewalls often lack the ability to prioritize traffic (QoS), and since the same firewall is often taking care of more than just the SIP trunk traffic there will potentially be issues (and yes, I have witnessed it – 15% packet loss is not good for your phone calls).

What I therefore recommend to customers, unless they have an SBC/Voice GW of some kind, is to put their Mediation server’s PSTN NIC in a separate subnet/VLAN along with the service provider’s equipment – and no other hosts. That will vouch for both the security and quality aspects of that interconnection.

Before deciding on such a design I did do some research on how to set up the solution in a supported manner. Technet is quite clear on the support of collocation in Lync. It is also has some basic guidance on how to define how the difference NIC’s or IP addresses will be utilized by the Lync Front End server.

However, should you go with such a design you will most likely (as I did) encounter one or more out of the following:

• Mediation traffic to/from PSTN will fail, and reviewing the logs you will see references of the Primary IP (not the one you selected for your SIP trunk traffic) is being used as source/destination.
• Lync Server Control Panel will not work on the Front End server (at least true for a Standard Edition or in an Enterprise Edition migration scenario before the Simple URL for administration points to the new pool). Using the browser from another machine and providing the LSCP URL will still work, though.
• MCU functionality or synthetic test cmdlets will fail, the latter with reference to the PSTN NIC IP address.

Upon researching these problems I have found some useful blog posts on the subject(s), such as:

• Communications Server Mediation Server: Dual NIC issue. Dated all the way back from R2 days but still applicable, explaining why you need separate VLAN’s for the dual NIC setup
• Dedicated Lync Server 2010 Mediation Server With two NIC’s. Although a 2010 Version and with dedicated Mediation Server, still some good detail on the problem and it’s solution.
• Lync Server Control Panel: Navigation to the webpage was canceled. Although not primarily about the dual NIC setup it was one of the curious symptoms, and it bears some reference to the collocated Mediation scenario as well.

Although these all had some useful points that eventually led me to the solution, they did not give the complete answer. I also chose some other solutions than they provided, regarding both NIC binding order and IP address binding.

As it turns out, this whole problem is about Windows Server and how it handles multiple interfaces and IP addresses. This is a common scenario on Lync Edge server, but in the case of the Collocated Mediation server with dual NIC’s it requires some extra steps which I have never had to deal with on the Edge server.

Continue to the post on how to actually set it up here.

Advertisement