Skip to main content


Lync Edge – Best Practices for Public IP Addresses

This is part seven of  The Twelve Days of Lync’mas, to see an index of all twelve posts click here.
On the seventh day of Lync’mas my UC Team gave to me: 7 public IP addresses
A question that I am often asked when planning Lync Edge servers is “how many public IP addresses do I need…. really?”  While you can provision your Lync Edge servers with a single public IP address each, our best practices here at Perficient are to provision three public IP addresses per Lync Edge server.  Ok, so that accounts for three public IP addresses, where do the other four come from?  Well, you want high availability for your Lync Edge right?  Sure you do, so there’s another three public IP addresses for a second Lync Edge server.  The seventh public IP address is for the load balanced virtual IP of the reverse proxy.  So there you have it, seven public IP addresses for the seventh day of Lync’mas… Merry Lync’mas to all and to all a good night!  But seriously, read on to better understand why we recommend three public IP addresses per Lync Edge server.

So, why three IP addresses per Lync Edge server?
The short answer – always on, always available accessibility of Lync services. 
For the long answer, let’s start with a table of Lync Edge roles and default listening ports:

Role Default Ports (IP per role) Default Ports (IP per server)
SIP Access TCP-443 TCP-5061 TCP-5269 TCP-5061 TCP-5269
Web Conferencing TCP-443 TCP-444
AV TCP-443 UDP-3478 TCP-443 UDP-3478

In order to have multiple services listening on the same port, TCP port 443 in this case, we must have unique bindings.  A unique binding is a combination of an IP address and network port.  Unique bindings are what allow us to have all three Lync Edge roles listening on TCP port 443.   Since we have three IP addresses in the IP per role scenario, we can have each role bound to its own IP address and listening on TCP port 443 on that IP address.  In the IP per server scenario, we only have one unique instance of IP address and network port, so we have the AV role bind itself to TCP port 443 and have the other roles bind to other network ports.
As you can see from the table above, TCP port 443 is highly preferred in the IP per role scenario.  Why?  Because just about everywhere you go, TCP port 443 is going to be allowed through the firewall.  As you probably already know, TCP port 443 is the default port for HTTPS or secure HTTP service.  Since this is the same port that needs to be open to make just about every e-commerce site in the world function (Amazon, eBay, Paypal, etc) then this is a very logical port to run an always on, always available service upon.
Consider a scenario where we have deployed Lync for a professional services firm with a highly mobile workforce that often work from remote locations – customer locations, airports, hotels, Internet cafes, etc.  We have designed our Lync Edge to use a single IP address per server and we are using the default listening ports from the table above.  Since these ports may be considered non-standard they may filtered or not allowed at the firewall.  This may prevent remote users from being able to login to Lync, participate in meetings and/or present meeting content.  In contrast, if we have deployed Lync Edge in the IP per role scenario, with three IP addresses per Lync Edge server, then these roles would all be listening on the standard TCP port 443 (HTTPS) and would have a much higher chance of a successful connection.
When designing a Lync deployment, one of my goals is to make access to Lync services as ubiquitous as possible.  I want Lync users to be empowered wherever they are in the world.  Making Lync services always on, always available, requires careful planning and an understanding of how the services are provided, especially when Lync users are in remote locations.  When it comes to public IP addresses for Lync Edge, my recommendation is don’t skimp on a few more IP addresses, provision Lync Edge with three IP addresses per server and guarantee a Merry Lync’mas for all!
Additional Reading / Resources:
Lync Edge – Choosing a Topology
Scaled Consolidated Edge, DNS Load Balancing with Private IP Addresses Using NAT
Understanding Lync Edge Server Ports

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scott Middlebrooks

I am a Senior Technical Architect within the Microsoft practice at Perficient. In this role, I am responsible for strategy, delivery, operations, and technical sales support aspects of enterprise infrastructure projects, especially Microsoft Unified Communications projects. I have extensive experience in traditional telephony, voice over IP, network design and architecture, systems engineering and infrastructure security. Prior to joining Perficient, I served as the Chief Information Officer at Northridge. Northridge was a leading Microsoft consultancy based in Atlanta, Georgia and was acquired by Perficient in July of 2012. I posses several Microsoft Certifications including: Microsoft Certified Systems Engineer (MCSE) on both the Windows NT 4.0 platform as well as the Windows Server 2003 platform, Microsoft Certified Technology Professional for Lync and Microsoft Certified Technology Specialist for Virtualization. I hold a Bachelor of Business Administration degree in Management Information Systems from the University of Georgia, GO DAWGS! In my time away from the office I enjoy time with my family and friends, UGA football, anything aviation related and I love cooking, especially on my Big Green Egg!

More from this Author

Follow Us