About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Lync HLB Edge

Lync Server 2010 has two modes of load balancing:  DNSLB (Domain Name System Load Balancing) and it also support hardware load balancing (HLB).  DNSLB works really well; however, there are some limitations regarding the Lync Edge when it comes to load balancing.  Specifically, because DNSLB is implemented at the client level, if your DNSLB is broken due to a server outage, then the remote users on downlevel clients, federated partners using OCS R2 (or earlier), XMPP clients, etc., may not work because they cannot find the second server; this is especially evident if the first server in the DNS records is the server that fails.  External Exchange UM sessions may also fail to work for the same reason.  Many implementations are therefore done with HLB on the Edge.  In a previous article, I showed how to setup a Kemp Load Balancer to support these two high availability modes for internal operations with Lync Server.  In this article, I will demonstrate HLB for the Lync 2010 Edge.

The Setup

Setting up the Lync Edge HLB is really all about understanding your network and the relationships between NICs on real servers versus IP on HLB VIP, IP on public edges of firewall/routers, and how traffic needs to flow from device to server to device to server.  And where traffic needs to go on the inside versus where the traffic needs to go when headed outside.  Clear as mud?  Excellent!

Kemp publishes a very nice document on “how to” accomplish HLB and Lync with their products.  Just so you can follow along, my lab is setup for the alternate deployment method shown on page 25.  I am using one Kemp VLB for both internal and external HLB functions. I am also using all roles consolidated and there are no directors.


My lab does not have a security issue as I address all security before traffic enters my lab net.  You should evaluate your risk and implement accordingly.  FWIW, I always advise clients to double firewall and use a set of HLB in the perimeter net for Lync (and OCS)(and everything else that needs it) along with internal HLB.  YMMV.

Here is how I have the lab setup for this exercise:


This illustrates what the Kemp documentation refers to as a “one-arm” deployment.

The Kemp documentation, along with the Microsoft Lync Server online documentation for Edge deployments, provides all the guidance you need.  I won’t try to duplicate those instructions here; instead, here is what my Kemp looks like after working through the configuration guide.

LyncEdgePool.tsoorad.net: (Edge internal VIP on VLB)

     LyncEdge.tsoorad.net: (Edge Server1 internal NIC)

     LyncEdge2.tsoorad.net: (Edge Server2 internal NIC)

SIP.tsoorad.net: (VIP on the VLB)

     SIP.tsoorad.net: (Edge Server 1 external NIC)

     SIP.tsoorad.net: (Edge Server 2 external NIC)

WC.tsoorad.net: (VIP on the VLB)

     WC.tsoorad.net: (Edge Server 1 external NIC)

     WC.tsoorad.net: (Edge Server 2 external NIC)

AV.tsoorad.net: (VIP on the VLB)

     AV.tsoorad.net: (Edge Server 1 external NIC)

     AV.tsoorad.net: (Edge Server 2 external NIC)


Observe that I am using the same LB as the previous article; I have added another NIC to the VM, bridged that NIC to the proper subnet, and started configuring.


As with all things, nothing is perfect.  The following items in the Kemp guide are noted for consideration and clarity.

Starting with section 8.2 (page 36) step 15, the guide says “For each Front-End server…”  It should really say Edge Server.  If you refer to the IP addresses given in the guide, and look at page 35, the guide clearly wants Edge server not Front-end, and common sense dictates the same.  This comment is made for each subsequent Real Server setup for Edge Services.

On page 26, section 5.1 (General Configuration – Disable Global SNAT) the option for “enable SNAT” is unchecked.  However, when doing the Edge external services for AV on page 42, in sections 9.6 and 9.7, the guide instructs us to “Select the Use Address for SNAT checkbox” – ooops!  Unless you go back and set the global to “ENABLE SNAT” the option does not show up in the Virtual Server Standard Options.  After enabling that option in the System Configuration | Miscellaneous Options | Network Options, THEN I got the check box for the Virtual Service | Standard Options.



Luckily, in response to my support request, the folks at Kemp support sent me an excellent description of how to find the check box in each location.


All in all, an almost painless evolution.  It literally took me longer to reconfigure my lab to support this exercise than it did to configure the Kemp to provide a full HLB Edge solution.  With the exception of the missing check box for SNAT and the mis-labeling of server IP to use, everything went as advertised.  If you need a high-availability solution for your environment that is fully supported by both the third-party and by Microsoft, this might be a good choice for your deployment.  For what is it worth, Kemp is also on the Exchange OIP, and I could easily use this same VLB for my Exchange deployment.



Anonymous said...

If you still have the info, what did you use as your default gateway on your edge servers? The external IP of the HLB?

tsoorad said...

Lync edge always has the default gateway set to the external nic network. The internal nic is either in the production network or you need to static route for all subnets that have clients, lync servers, or exchange um servers.

rimroot said...

Hi Tsoorad,
what about high port range? Kemp allows only 1024 per VS. Should I create 10 VSs for high port range?

tsoorad said...

I don't know about that specifically. I know that I followed this guide: http://kemptechnologies.com/files/downloads/documentation/7.0/Deployment_Guides/Deployment_Guide-MS_Lync_2010.pdf, and on pp44-45 it shows 10,000 ports. Where did you get the port limit info?

Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...