Microsoft always stresses security best practices in Lync environments in general. Taking those concerns into consideration, the Lync environment is separated into different security areas and layers and deployments should always include TLS encryption and certificates using 2048-bit or longer key lengths. There are several key areas that also strengthen security.
In general, these key areas are:
This white paper will focus on Internet directed traffic and communication in Lync 2013 deployments. While relevant and important, security layer area not discussed in the document is Two-Factor authentication.
In order to define context we first need to ask ourselves the question, “Why is this necessary? Our old phone system and methods of communication didn’t leverage encryption and advanced security measures.”
First off though, we need to redefine the word “communication.”
Unified Communication (UC), simply said, is everything beside email. This includes all communication which could possibly be answered immediately, such as Instant Messaging, Voice/ Video Call (Phone Calls), Conferencing as well as others such as Desktop Sharing and Active File Transfer.
With this definition, it’s easier to see why we need additional security. Since these methods of communication can be used with entities outside of the corporate firewall it’s also critical that security measures be applied both internally and externally especially since UC not only allows the transfer of voice as with our traditional telephone systems but also allows the transfer of more sensitive content like files, desktops and application data.
With this understanding let’s discuss 4 different security key areas in Lync 2013 architectures.
Let’s analyze the areas in reverse, from 4 to 1 until we reach the Internet, the most unsecure zone.
The Mediation Server Component can be installed in two different ways, either consolidated on the Front End Server (being part of the Front End Pool), or as a dedicated Pool with Mediation Server functionality only. In both scenarios the audio path between the Mediation Server and Gateway(s) can be secured in different ways. Either the Mediation Server to Gateway network is dedicated, meaning a physically and logically isolated LAN or consolidated, transmitting audio traffic over the production LAN with the use of TLS encryption.
If the Mediation Sever component is installed on the Frontend Pool and has its own network card or, if the Mediation Server is its own Pool with a dual NIC, we have a dedicated LAN between the Mediation Server and the PSTN Gateway (i.e. a dedicated LAN cable to the PSTN.)
Let’s look at restrictions and possibilities with this setup:
Since the LAN is isolated and not routed, we can possibly run IP traffic in this dedicated network segment without encryption, thereby reducing CPU utilization on both the PSTN Gateway and the Mediation Server Pool. The caveat of this is that Media-Bypass is NOT possible in this configuration.
Figure 1 Mediation Server and Gateway (Isolated LAN)
In this topology design, Mediation Server can be consolidated on the Frontend Pool or can be dedicated role. Media-Bypass is possible and therefore audio traffic is routed from/ to all possible clients and is fully traceable on the network. TLS encryption is always used in this configuration.
Figure 2 Mediation Server and Gateway (Consolidated LAN)
Both Web and Session Lync services traffic is encrypted. With this, one obvious question that arises is, if this traffic can reach the Lync servers from external clients, how do we ensure it is legitimate traffic?
The answer isn’t simple but since Microsoft improved IIS and the security of Windows servers in general over the years, we can now segregate the traffic based on its origin and direct it to different targets, internal and external IIS WebSites (e.g. port segregation 443/ 4443). We will cover how it actually works in more detail later in this section.
Lync Web traffic has an interesting characteristic... Until we reach an internal Lync System, either Director or Frontend Server, the Web traffic is NOT authenticated. Authentication can only be carried out by Domain Joined Lync Servers!
SIP, compared to Web traffic, is quite different! Here, even when initiated from external networks, it will be logically seen as internal traffic. We will also cover this behavior in detail later in this section. However, there is the one traffic which cannot be encrypted – internal Phone Update and CRL traffic. It needs to be HTTP rather than HTTPS.
Figure 3 Lync Services Web Traffic Segregation
Lync offers support for larger deployments, offering increased security. This feature is supported by a Server role called the Director Server, a deployment component able to authenticate and then redirect incoming traffic, to its intended destination at point of ingress.
Interestingly, if you have a multi zone security model, you might place Director Servers in an internal DMZ which is in-between the Internet facing DMZ and LAN zone. So to speak a DMZ which can be internally and indirectly, externally, contacted.
Figure 4 Lync external Web Services (Pool Configuration)
Now, let’s discuss the systems directly facing the Internet. As we can guess from the internal service segregation, there must be two systems handling traffic coming from the Internet:
First is the Reverse Proxy component. It is highly recommended to use solutions which are supported, either by Microsoft or from a third-party vendor. Provided by Microsoft are IIS ARR/WAP and TMG.
A non-Microsoft solution example is from KEMP Technologies, the LoadMaster application load balancer equipped with Edge Security Pack (ESP), which we will discuss later along with configuration examples.
Then, there is the Lync Edge Server, one of the most secure servers! While the Reverse Proxy only handles all Web traffic, the Edge Server handles all SIP traffic. This server acts as a real application firewall for Lync deployments.
Figure 5 Lync Reverse Proxy
Most customers require a strict traffic segregation and inspection policy for all traffic coming from and going to the Internet and this is no different for Lync 2013. This traffic must be fully inspected, at least at Layer 7. Layer 7 of the OSI model describe the IP application layer which is in our case HTTP/HTTPS and SIP.
But in case of a Unified Communication solution, this is not enough.
Web traffic is easier to analyze based on Reverse Proxy technologies. But how can we analyze SIP traffic? How do we ensure the enforcement of assigned policies?
Assuming we find a possible way of doing some inspection within this traffic, Lync is a very sensitive communication system, operating with real-time data. Real-time data is time sensitive and it is session aware. What about the Web traffic? Does it have its own uniqueness? It sure does! In Lync we have web session tickets which must be kept intact. Those tickets ensure that your external client will receive the correct buddy list and prevents crossover of user information.
So how can Lync operate in such complex environments, securely?
We identified a handful of systems during the 4 areas of security that must be considered in Lync 2013 deployments. There are two components facing the Internet directly and two components which are internal, LAN based systems. Let’s dive deeper into the first two:
Reverse Proxy, the system which handles all incoming HTTP(S) traffic. This includes traffic generated from services such as address books, distribution group expansion and anonymous traffic for Dial-in and Meet. User connections to these components are fronted with forms based access pages. In total there are three pages offering FBA: dial-in, meet and scheduler.
Dial-In is the landing page for audio conferences. If a conference is planned and the link was sent to possible participants, they are able to access this page and find possible dial-in phone numbers. This web page is accessible anonymously. But with a “sign in” option, Lync users homed on the system can access their own dial-in parameters and preferences.
Meet is the landing page for the Lync Web App. If you try accessing the web page without a valid conferencing ID, Lync provides you with an error page first. If you have submitted a proper conference ID, it will either redirect the connection to a locally installed Lync client or it will present you with the meeting login page. A forms based login page for anonymous users provide only a naming identifier or the second option for Lync system homed user to identify themselves with the Active Directory domain credentials.
Scheduler is the meeting planning landing page. If you do not have an Outlook client installed along with a local Lync client installation, you need this (manually) configured web page accessing and planning Lync meeting/ conferences. It has a forms based login page for Domain authenticated users.
Other web services covers everything else that Lync clients, Mobile Clients, App Store Clients and Rich Client require. Those services can only be accessed by users once they’ve authenticated themselves again Active Directory and have valid session tickets granted. Once we discuss the IIS components in Lync, we will discuss more details of these services and their directories.
Information about Form base authentication
Even though there is forms based authentication, you cannot pre-authenticate the users using reverse proxy. This is not a supported configuration. Lync provided forms based authentication simplifies the deployment, so a simple, but Lync aware web traffic redirect can be used.
The Edge server is the first Lync server in this scenario we are going to discuss. This role provides the following three services:
Access Edge Service: This application component is also called Access Proxy. It controls the remote user communication and pass-through of authentication. Another feature is federation to other UC solutions and infrastructures including other Lync deployments, other versions of Lync or OCS and Public IM Connectivity (PIC) to MSN and Skype. The third component is XMPP which, despite being a dedicated service, is also related to the Access Edge. The main purpose of this service is validating SIP connections between users inside and outside of your internal network.
Web Conferencing Edge Service:
A dedicated service for web conferencing media distribution. The Edge Web Conference service proxies the conferencing data stream between the internal Frontend Server hosting the conference and the external connected Lync client (rich and mobile).
Office Web Application
Office Web Application Server is required for PowerPoint html5 rendering, this is not handled by the conferencing service
Audio/ Video Edge Service:
The third core component in Lync Edge is the A/V component. This service handles not just streams containing A/V content but also proxies application and desktop sharing and file transfer to external users. The AV Edge Service has two functionalities – Audio/ Video Edge Service and Audio/ Video Authentication Service.
Certificate requirements A/V Edge
All Edge server traffic must be encrypted using TLS. It is necessary that public certificates are assigned to Access Edge Service interface and Web Conferencing Edge Services interface. Audio/ Video Edge Service does not require a certificate assigned to its interface, the certificate must be assigned to the A/V Authentication Service. The A/V Edge service does not use the subject name or the subject alternative names entries.
A/V Authentication Certificate Information
The A/V Authentication Service Certificate in Lync Edge Pool must share the same Private Key.
The Edge Services are ignoring the Certificates Subject Name, therefore only the Subject Alternative Names (SAN) are used and important
The question is now, how does Lync Edge for Audio/ Video actually work? The Lync AV Edge Service serves as the MRAS (Media Relay Access Server), allowing for the pass-through of A/V traffic. The AV Authentication Service is an internal Lync component related to the internal deployment, authenticating Media traffic coming from internal and traveling to external destinations.
SRTP (Secure Real time Protocol) is a call leveraged by the AV Edge service and has its own native security within. Essentially, the SRTP protocol exchanges security keys within the SIP protocol first using a Master Key protecting the Session Key. Additional information about SRTP can be found in the related RFC. For Lync it is important to understand the Edge Server Service positioning, either the external interfaces or the internal interface.
Figure 6 Lync A/V Edge Services
This also reveals why the Edge Server requires 2 network interfaces. Since the AV site is segregated into two sites, security must be ensured.
The next component is the internal site of Lync, where we take a look at the Lync Director Server and the Internet Information Server (IIS).
As we have seen in the Edge Server section of this document, the Edge Server segregates SIP traffic but it is not responsible for authentication. We have unauthenticated traffic, like presence status requests and traffic from remote users, which needs to be authenticated. Authentication can only be handled by a SIP Registrar which is the Frontend Server.
Which role does the Director play if not the Registrar? It really is another type of proxy server. It knows where a user is homed and can process the authentication, before passing the authenticated traffic to the user’s home pool.
But can it act also as an additional security layer? Yes it can!
Since traffic flows through Directors before making it to front ends, in case of a denial-of-service attack, the attack will never make it to the internal systems. If the network is flooded with invalid external traffic, it will simply be terminated here with no impact to any other internal and more sensitive systems.
Front End Web Service
Every Lync Frontend Server has its own web services which need to be published via the Reverse Proxy. Those services cannot be redirected via the Director Server.
An essential security mechanism from a Lync 2013 perspective is the ability to segregate web services into internal and external IIS web pages. An added benefit is that if one service or even an entire web page is compromised or crashes, the entire system will not run into issues. Another security opportunity is based on the certificate assignment to the individual web sites, along with dedicated CN assignments and separation with different TCP/IP ports.
Figure 7 Lync external Web Services (Pool Configuration)
The IIS Web Services are listed in the picture below, each of the certificates provide several functions and is split into the “external” and “internal” web sites.
Figure 8 Lync Web Services IIS structure
As mentioned earlier, IIS provides several function along for Lync as listed here:
In addition, the cumulative update for Lync Server 2010: November 2011 installer creates virtual directories in IIS for the following purposes:
In the following table, some of the most common services are addressed and described:
|Lync Web Service||Address||Description|
|Address Book Server||https://<Internal FQDN>/ABS/int/Handler||Location of Address Book Server download files for internal users.|
|Autodiscover Service||https://<Internal FQDN>/Autodiscover||Location of the Lync Server Autodiscover Service that locates mobility resources for internal mobile device users.|
|Client updates||http://<Internal FQDN>/AutoUpdate/Int||Location of update files for internal computer-based clients.|
|Conf||http://<Internal FQDN>/Conf/Int||Location of conferencing resources for internal users.|
|Device updates||http://<Internal FQDN>/DeviceUpdateFiles_Int||Location of unified communications (UC) device update files for internal UC devices.|
|>Meeting||http://<Internal FQDN>/etc/place/null||Location of meeting content for internal users.|
|Mobility Service||https://<Internal FQDN>/Mcx||Location of Mobility Service resources for internal mobile device users.|
|Group Expansion and Address Book Web Query service||http://<Internal FQDN>/GroupExpansion/int/service.asmx||Location of the Web service that enables group expansion for internal users. Also, the location of the Address Book Web Query service that provides global address list information to internal Lync Mobile Microsoft Lync 2010 Mobile clients.|
|Phone Conferencing||http://<Internal FQDN>/PhoneConferencing/Int||Location of phone conferencing data for internal users.|
|Device updates||http://<Internal FQDN>/RequestHandler||Location of the Device Update Web service Request Handler that enables internal UC devices to upload logs and check for updates.|
|Response Group application||http://<Internal FQDN>/RgsConfig
|Location of Response Group Configuration|
Mobile users encounter various mobile application scenarios that require special planning. For example, someone might start using a mobile application while away from work by connecting through a 4G network, then switch to the corporate Wi-Fi network when arriving at work, and then switch back to 4G when leaving the building. You need to plan your environment to support such network transitions and guarantee a consistent user experience. This section describes the infrastructure requirements that you must have in order to support mobile applications and automatic discovery of mobility resources.
Supporting this scenario can only be accomplished if the client stays connected via single entity. This entity is the Reverse Proxy.
Discover URL pointing direction
Although mobile applications can also connect to other Lync Server 2013 services, the requirement to send all mobile application web requests to the same external web fully qualified domain name (FQDN) applies only to the Lync Server 2013 Mobility Service. Other mobility services do not require this configuration. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN
It is important to note that the internal Web service (running on port 443) does not offer mobility services, as the below Microsoft diagram depicts:
Figure 9 Lync Mobility Services (recommended design)
Following are the hardware load balancer requirements for Director and Front End pool Web Services:
|Client/user location||External web services FQDN affinity requirements||Internal web services FQDN affinity requirements|
|Lync web access (internal and external users)
Mobile device (internal and external users)
|None required||Source address affinity|
|Lync web access (external users only)
Mobile device (internal and external users)
|None required||Source address affinity|
|Lync web access (internal users only)
Mobile device (not deployed)
|None required||Source address affinity|
The Edge server itself acts as a highly secure, real Application Proxy and is a NON-Domain Joined system with incoming data replication only. Let’s step through an incoming SIP session.
Arriving at the external Edge Server interface, it terminates external traffic, starts full application inspection, entitlement verification and user policy validation. After this inspection the traffic is sent via the internal network interface to the next network security layer, which is the Lync Director Pool or the Frontend Pool. In our example, we will assume that this additional security layer of a Director Pool is in use. It should be noted that in this scenario user authentication requests will only be performed on a Director Pool and this traffic is redirected to the user’s destination Frontend pool. From there onward, the traffic is treated as authenticated and a VIA (Path) is established between the Edge Pool, Director Pool, Frontend Pool and the internal user client. This information is sent by a NOTIFY SIP command. The same principal is valid even if users are homed on SBA’s (Survival Branch Appliances).
SIP traffic also has the provisioning for VIA (Path) headers and therefore is aware of the context of the traffic flow.
More important is the Web Service traffic. Here we’re referring to the earlier mentioned topic of generic web traffic, such as ‘meet’ or ‘dial-in’ and the web services homed on all Lync Pools, Director Pools as well as on Frontend Pools. The traffic flow for those must be taken into consideration.
Simply put, for Pool Web Services, the Director is NOT an additional security layer. This is where IIS web site segregation comes into play as defined earlier
Let’s now take a look into a minimal deployment with an Edge Server and a Reverse Proxy.
Starting with the initial principals is defining the incoming protocols. Here we have SIP, PSOM, STUN, RTP and HTTPS. We, also during the next topology definition, will not allow any unencrypted traffic, therefore HTTP is not relevant. Additionally, make the illustration easier in understanding, we have consolidated all Edge Server relevant protocols in the word SIP.
The importance of certificates cannot be stressed enough. You must implement the correct public certificates on the Edge and the Reverse Proxy in order to establish a working and secure deployment. The Edge Server additionally requires an internal certificate. Only this ensures the correct proxying, or better said, basic Lync application firewall functionality. The Reverse Proxy also needs a public certificate and must be able to recognize the internal web services assigned certificates. The core essence of this is that you need a correctly configured infrastructure ensuring that encrypted traffic can correctly traverse the entire deployment.
The minimal deployment consists of a single Lync Edge Server and a Reverse Proxy Solution as illustrated below:
Figure 10 DMZ Lync Server 2013 security compliance (minimal deployment)
The Reverse Proxy listens on TCP Port 443 and simply redirects the traffic to the internal IIS server on TCP Port 4443, inspecting the HTTPS stream, repacking and re-encrypt the traffic with the certificate assigned to the external web service web site.
The Lync Edge server acts slightly different. It still needs a valid public certificate, so the incoming and outgoing IP traffic stream can be encrypted. Clients or other Edge Servers need a certificate validation check before accepting TLS traffic encryption.
When Lync has an incoming SIP request, the external client will contact the Access Edge which than terminates the SIP connection on its external Access component. The next step involved is processing this request and validating what its intent is. Assuming it is a user authentication, than the Edge server initiates an outgoing session on its internal Access component, contacting the next hop which was defined in the Lync topology builder at deployment. If anything within this traffic doesn’t match Lync specific traffic (e.g. malformed packages) the Edge Server does not process this request. Visually seen, the Edge Server is a fixed component in this communication path. With the VIA parameter, we see an internal and external (NAT) IP address.
See the following example:
Figure 11 Example NATed Lync Incoming Request Flow
From this we can see the path from the client 172.28.91.102 until 10.11.10.84, which is the NATed Access IP of an Edge Server including an external IP (greyed out). The 10.10.10.128 is the internal Frontend server. This NOTIFY commands were received by the local client (172.28.91.102). The second involved Edge Server is the 172.19.45.67, without a public IP. This is because the log was collected on a Lync client in the internal LAN connecting the internal Edge Access interface and obviously doesn’t need to know any public associated IP address.
We can see that there are two Edge servers involved. As a SIP Proxy should look like another hop in this communication path the Lync topology on both Lync environments provide the Edge server the necessary information to where the incoming SIP traffic should be routed first.
Since the topology information is only replicated in a unidirectional method and the Edge Server deployment should be based on Microsoft best practices, meaning DNS should only be configured on the external NIC and internally a HOSTS file should be used, this scenario is considered as safe. Even if the Edge server should be compromised, no internal network information can be acquired.
In a secure environment Director Servers are recommended. They are the target for mostly all Internet related traffic, with a single exemption – Frontend Server Web Services traffic. This is still acceptable due to the fact that this traffic is only established once the initial SIP authentication is successfully processed.
Since web-based traffic to resources such as MEET and DIALI-IN don’t require authentication and will be redirected to the Director Servers this security model becomes holistically valid.
Figure 12 Director Pool Configuration
Security model and internal DNS targets
If we apply this security model, you need to be aware, that all internal DNS targets will have to point to this Director Pool too.
If you wish to take a step further and separate even this traffic, you can do so by simply applying a second Director Pool and making this the preferred target for internal consolidated access. The DMZ based Director Pool will then be the target defined in the EDGE Server NEXT HOP parameter.
The next illustration offers a solution where the “INSIDE DMZ” zone is treated as second defense zone and is allowed to be accessible from internal clients too. Besides the introduced Director Pool, we also have a Reverse Proxy Chain. A chain is where at least two proxy server are configured in a row and depend on one another.
All external Web Services are published with a listener on the first internet facing reverse proxy server, pointing from there towards its chain member, the second reverse proxy, which then directs all requests to it designated destinations.
The Edge Server works in this scenario as described earlier. It just acts as the NEXT HOP configuration point towards the Director Server, implemented as an additional security layer.
The Director now handles SIP and Web Service traffic and builds another line of defense.
Figure 13 DMZ Lync Server 2013 security compliance (with Director pool)
Difficult in all those design is the Lync Mobility design. The clients need as defined in the prerequisites access to the same Reverse Proxy entry point for internal (WLAN) and external (3G). With a chained proxy it can be difficult. This should be discussed with your internal security officers how internal WLAN client can establish those required connections.
Now we will discuss a highly secure complex design. In this scenario we have an Active Directory Forest with three (3) Domains: The Forest Root Domain CIE.INT and two sub-level Domains, DE and US. Each Domain contains Lync Server components and we have Administrators separated for each security area.
This 4 security areas are:
This is a real life scenario principally designed for a defense corporation with more than 8 Domains, with high secure backbone technologies, full administrative isolations and highly complex requirements in order to satisfy security policies.
Figure 14 DMZ Lync Server 2013 security compliance (real world scenario)
Now let’s configure a Reverse Proxy solution.
It’s always recommended to run Lync in high availability configuration as it often is deployed as a business critical application for subscribed stakeholders. Therefore, the use of an external Load Balancer is required. KEMP’s hardware-based, virtual and bare-metal software LoadMaster Systems all provide you with needed application load balancing and Reverse Proxy services for Lync 2013 deployments. Natively, a Reverse Proxy, the LoadMaster offers additional features in Microsoft’s end-of-life Forefront Threat Management Gateway (TMG) or the Internet Information Server Application Request Routing (IIS ARR) with its integrated Edge Security Pack (ESP).
Figure 15 KEMP LoadMaster Integrated Reverse Proxy Services
Guiding through the configuration of ESP, we need to have the necessary Lync Web Service information compiled first:
|Address (FQDN and Listener IP)||Listener IP||Internal IP||Description|
|Lync external Web Service FQDN
|Lync external Web Service FQDN
|LYNC Mobility Services
|Web Conferencing Landing Page
|Dial-In Information Landing Page
|Web Scheduler for Lync Conferences
In this configuration example we will demonstrate the Direct Setup only. All other service setup follows the same core principals discussed throughout this white paper.
We will now jump straight into the configuration of LoadMaster Virtual Services which are used to publish load balanced Lync deployments with high availability. For all definitions and detailed walkthrough on all prerequisites and steps, see the KEMP LoadMaster deployment guide for Lync 2013:
The virtual service used on KEMP LoadMasters to publish Lync services should not be transparent when enabled ESP, therefore we need a valid public certificate assigned to this Virtual Service.
Figure 16 KEMP LoadMaster TLS (SSL) Certificate Deployment
As we are aware with an Exchange publishing, we have defined a subset of rules. Generally for Lync this is not necessary due to built-in security measures.
We are now ready with the prerequisites fulfilled and continue with the Reverse Proxy Setup. This setup looks quite similar with the setup we are doing internally for the Lync internal Web Services.
We have defined the NATed IP Listener in the DMZ: 192.168.20.5
and the Server Name as : ESPforLYNC. Since this is the external facing site, the listening port must be: 443 (https)
Figure 17 Creating KEMP LoadMaster ESP Virtual Service
The basic options are setup during the initial activation of a new virtual service and we have no other parameter to be set.
The standard options are addressing the mode and principle of access. We have disabled the transparency option.
Figure 18 KEMP LoadMaster Virtual Service Settings
In Lync 2013 cookie persistence is now optional. If you choose to configure cookie persistence, use the following parameters:
Persistence Option/ Mode: Active Cookie
Persistence Option/ Timeout: 20 Minutes
Persistence Option/ Cookie Name: MS-WSMAN
Sharing Method: least connection
Idle Connection Timeout: 1800 sec
Optionally it is also supported to define source IP persistence:
This setting can have a disadvantage, when a remote client is behind a NATed LAN, the external and therefore visible IP address is persistent. Meaning if there are more than one client connecting form the same location, the load balancing mechanism is not as efficient.
Force L7: True
Persistence Option/ Mode: Source IP Address
Persistence Option/ Timeout: 20 Minutes
Sharing Method: least connection
Idle Connection Timeout: 1800 sec
Figure 19 KEMP LoadMaster Virtual Service Standard Options
As this is the Reverse Proxy, SSL is required with the public certificate acquired for external access.
The certificate which was imported during an earlier step will now be assigned to this virtual service.
Figure 20 KEMP LoadMaster SSL Properties
The actual reverse proxy configuration is part of a virtual service and needs to be activated here. As this acts as a security layer, I recommend enabling all logging options for analysis. An SSO (single sign on) domain must not be set since Lync do not support pre-authentication. Only the Allowed Virtual Hosts are required, so the VS is enabled for listening with security activation (ESP).
The host name (FQDN) for the Director are: WS.EXT/ MEET/ DIALIN/ SCHEDULER/ LYNCDISCOVER.MYCLOUD.AG
Figure 21 KEMP LoadMaster Virtual Service ESP Options
The load balancer with activated ESP still needs the information for the basic load balancing functionality such as where and against what it should check to determine whether or not defined servers/services are active and healthy. You can copy your own html file on the external web service (IIS) or you use a Lync define path, e.g. /abs/handler to health check against.
Figure 22 KEMP LoadMaster Real Server Helath Checks
The reverse proxy needs to address the correct internal IIS web page on the assigned port 4443. This is a configuration you have to provide for each real server.
Figure 23 Adding Real Server to KEMP LoadMaster Virtual Service
The result after adding the real servers should look like:
Figure 24 KEMP LoadMaster Virtual Service Real Server List
With this last step, you finished the entire Reverse Proxy setup and the result should display as ‘green’ and ‘up’.
Figure 25 KEMP LoadMaster Virtual Service Status List
Microsoft Lync provides an enterprise-ready unified communications platform for engaging, accessible and interactive collaboration from virtually any location and any device. For IT organizations, the highly secure and reliable Lync architecture allows for seamless integration with existing collaboration tools, reduced management complexity and flexible deployment options. Microsoft Lync 2013 builds on the innovation ushered in by Microsoft Lync 2010, bringing improved scalability and new features such as persistent chat, Lync Web App and a Plug-In specialized for Virtual Desktop Infrastructure. These, along with new client features that provide for a better user experience, enable users to stay connected and stay productive.
KEMP’s LoadMaster fully supports Microsoft’s key solutions and are approved by Microsoft (KEMP is a Microsoft Gold partner). The LoadMaster efficiently distributes user traffic and secures published Microsoft Lync 2013 deployments so that users get the best experience possible.
 At time of write this white paper, Windows Server 2012 R2 Web Application Proxy is NOT officially supported, due to problems handling Lync deployments with multiple SIP Domains.