Preface

Lync servers provide both local and remote access to enterprise Unified Messaging and Voice workloads such as IM, Conferencing, Voice calls and Application Sharing. When it comes to remotely accessing workloads such as Join a meeting, find local dial-in phone numbers, access to address book and meeting content such as PowerPoint presentations, a reverse proxy is required to provide such functionality. Since Forefront Threat Management Gateway (TMG) was discontinued in 2012, customers have been looking for alternatives. KEMP LoadMaster products can be that alternative which not only acts as a load balancer for your Lync workloads but can also serve as much needed reverse proxy for abovementioned workloads.

Author: Bhargav Shukla - Director – Product Research and Innovation, KEMP Technologies Inc.

Note: KEMP is actively engaged with Microsoft UCOIP team to complete certification process. Upon completion, both load balancing and reverse proxy solutions from KEMP are expected to be approved.

Architecture

Let’s take a look at Lync 2013 architecture with Lync 2013 Front-End Pool, Office Web Apps Server farm and other components deployed (see diagram below). When we consider Reverse Proxy requirements, we can divide incoming Lync traffic into two distinct groups. One group of requests are addressed to Lync Web Services which provides access to Meet and Dial-in functionality, address book downloads and such. Another group of requests are destined to Office Web Apps Server farm, to gain access to PowerPoint presentations being shared by presenter during a Lync meeting. Reverse Proxy is needed to address both workloads and can either use a single Virtual service running on a single IP or two distinct virtual services requiring two public IP addresses. In this article we will deploy two virtual services requiring two public IP addresses.

Configuration

The diagram above shows two separate devices in DMZ; one for load balancing and one for Reverse Proxy functionality. This is logical representation of services which could be physically handled by single device. KEMP LoadMaster ADCs are capable of performing both load balancing and reverse proxy functionality as it pertains to Lync Server workloads.

There are two possible ways you can configure KEMP LoadMaster to perform Reverse Proxy functionality. One is to manually perform configuration steps and second is to use templates. Templates are great way to avoid errors and allows for rapid configuration of required workloads.

Let’s download Lync 2013 template from KEMP Technologies website:

Next, we will import the template to KEMP LoadMaster:

Since both Lync Web Services and Office Web Apps Server use encryption, you have an option to install SSL certificate on Reverse Proxy with benefit of managing certificates from single device and is recommended.

Once you have installed required SSL certificates on the device, the next step is to configure virtual services for reverse proxy functionality.

Reverse Proxy for Lync Web Services

First, let’s create virtual service for Lync Web Services. Lync Server 2013 front-end servers will be servicing the requests coming through this virtual service. Since we are using template, this becomes a simple task. All you need is publishing IP address commonly known as VIP or Virtual IP Address and name of the template “Lync Reverse Proxy 2013” in this case. We will add Lync servers to the virtual service once created.

Once you add the virtual service, you are left with two tasks: add correct SSL certificate to the service and add Lync Front-End servers. All the other parameters such as health check, persistence, scheduling and others are set to recommended configuration. You, however, have complete control over all parameters should you decide to change it for any reason after creating the virtual service.

It’s also important to point out that for Lync Web Services, you need to create two services, one listening on port 80 and one listening on TCP port 443. If you use template, both will be created for you. Don’t forget to create both should you decide to create them manually.

When adding the servers to the virtual service for Lync Web Services, let’s not forget that the clients are external and will be accessing external website on Lync Front-End servers which listens on TCP ports 8080 and 4443. When adding the servers, make sure correct port is used.

Once all Lync Front-End servers from given pool are added to the virtual service, you should see the health check pass for healthy servers and virtual service status change to up and start servicing clients:

Reverse Proxy for Office Web Apps Servers

Next, let’s setup Reverse Proxy for Office Web Apps Servers. While using the template, process is not different, it’s important to draw differences between Lync Web Services and Office Web Apps Server virtual services.

First one is, unlike Lync Web Services, Office Web Apps servers listen to TCP port 443 if configured for HTTPS. You have an option to configure them to listen on TCP port 80 if SSL isn’t used but that’s not security best practice. For this article we will assume the Office Web Apps servers are configured for HTTPS. Only one virtual service needs to be configured for Office Web Apps servers.

Second is health check. For Office Web Apps servers, we can perform health check on /hosting/discovery URL for given farm members. We can send requests from clients to any Office Web Apps server that passes this health check.

With that distinction, let’s create virtual service using the template:

Once created, all you need to do is add your Office Web Apps servers for given farm to the virtual service we just created. Unlike, Lync Web Services, we don’t need to change listening port on real server being added to virtual service:

We will also need to make sure that correct SSL certificate is assigned to the virtual service in order to avoid connectivity issues and certificate warnings on client machines. If you need details steps or would like to manually create these services, you can refer to detailed instructions provided in “LoadMaster Deployment Guide for Microsoft Lync 2013” located here: http://kemptechnologies.com/files/downloads/documentation/7.0/Deployment_Guides/Deployment_Guide-Lync_2013.pdf

Summary

KEMP LoadMaster provides secure, scalable and cost effective way to meet the load balancing needs for your Lync Server 2013 deployment. They also double as reverse proxy solution for Lync Server 2013 as well as Office Web Apps servers required for Lync meetings and presentations.

KEMP LoadMaster products are easy to configure using templates while providing you full control over configuration of given virtual services regardless of method of their creation (template or manual). You can configure KEMP LoadMaster products for your Lync environment using LoadMaster Deployment Guide for Microsoft Lync 2013.

Additional Information

To learn more, check the following resources:

LoadMaster Product Overview

LoadMaster Deployment Guide for Microsoft Lync 2013

Need to talk to someone from KEMP? Call 631-345-5292 or Email info@kemptechnologies.com

Lync Server Resources

Lync Server 2013 Documentation Library

Setting up Reverse Proxy servers for Lync Server 2013

NextHop blog

Lync Server Resources

Thank you to our readers for making NextHop one of the most read blogs on TechNet. The community and engagement have been integral to the success of Lync. However, as Microsoft moves toward frequent updates across all Office products, we’ve decided to consolidate future blog posts to the Office blogs platform (blogs.office.com) and technical content to the Lync library on TechNet. This will make it easier to find news and announcements on Office blogs and pure technical content right in the Lync library most of you frequent already. Thank you and we look forward to reading and responding to your comments on Office blogs!
 
-The Lync Team

Update: Some additional details that we should have included in the post:

• The site will remain accessible for the near future. We cannot commit to a specific amount of time (but perhaps several months), so that folks can archive, copy, etc, articles that they rely on or regularly use without losing the information.
• We will be migrating key articles to the TechNet library. We will not be moving every article published since 2007 though. When articles are published on TechNet, a redirect will be put in place so that links to the posts are not broken. Again, no promises about a flawless implementation or a specific time frame, but we did consider this and are planning to address the issue.
• We'd appreciate hearing from you about the articles you rely on so that we can prioritize those in the migration to TechNet. Also unable to promise that every request will be honored, but any article that has gotten significant traffic is already on the list. You can send requests to NextHop, or post a comment below.

Thanks for the feedback.

To provide the best user experience and prepare for future growth, it is important to use the correct numbering format when assigning phone numbers to users. This article describes how to effectively assign phone numbers to Lync Server 2010 Enterprise Voice users.

Author: Thomas Binder and Doug Lawty

Publication date: November 30, 2011

Product version: Lync Server 2010

When rolling out Enterprise Voice in your organization, use the following best practice recommendations to define your numbering plan and to assign telephone numbers to Enterprise Voice users. Defining the correct numbering plan is a crucial factor in the success of your Enterprise Voice deployment. To provide the best user experience, allow room for future growth opportunities, such as expansion to other countries or merger and acquisitions (M&A).

Telephone Numbering Goals

Design your phone number plan for Lync to take into consideration the following objectives:

• Compliance with Internet Engineering Task Force (IETF) standards.
• Specify a valid caller ID. This enables a callee to quickly return a missed call.
• Define phone numbers with extensions.
• Leverage telephone numbers configured in Active Directory.
• Plan for future growth.
• Avoid common mistakes.

Let’s consider each of these objectives in more detail and provide recommendations for assigning phone numbers in different situations.

Standards-compliance

Lync Server 2010 follows RFC 3966. RFC 3966 prescribes the format of TEL URIs in SIP. The RFC also defines additional parameters – such as extension, phone context, and so forth – to add to the TEL URI. Phone numbers can be either local or global. Global phone numbers must start with a + sign followed by digits that represent an E.164 number. E.164 is the standard for PSTN numbers and specifies country codes. Local numbers – those that are not globally unique – must provide the context in which they are unique. To specify this context, the phone-context parameter is added to the TEL URI. The combination of the phone number and phone context creates a number unique.

The following are valid RFC 3966 TEL URI examples:

• tel:+12125550135.
• tel:+12125550135;ext=135 where the extension is part of the phone number.
• tel:+12125550100;ext=863 where the extension is not part of the phone number.
• tel:135;phone-context=HQ.

All these formats comply with RFC 3966. It is not recommended, however, to assign all formats to users. A phone number is assigned to a Lync user when the Line URI property of the user’s Active Directory account is populated with a string similar to the listed examples. The following sections explain the recommended number format for each Line URI.

Specify valid caller ID

When a private number format (such as tel:135), is used in Lync and an employee places outbound calls, the correct caller ID is not displayed. When a Lync user makes an outbound call, we want the called party to see a valid number so she can return the call. When the user does not have a public telephone number, we want to display the company’s receptionist or auto attendant caller ID, so that the called party can return the call. To accomplish this, we have the following options:

• Direct inward dialing (DID) – sometimes called direct dial-in (DDI) – these numbers are globally unique phone numbers that can be called directly from the PSTN. If the user has a DID assigned, it will be presented as the caller ID for all outgoing calls and no additional configuration is necessary. Use one of the formats where the user’s DID is specified as a global number – for example tel:+12125550135 or tel:+12125550135;ext=135. (The next section encourages the use of the second format.)
• If a user does not have a DID number and can only be reached through an internal extension, configure a DID number as the caller ID so that the callee can return the call. Usually, this number is the company’s receptionist or auto attendant number. Use the format where the call back number is specified as a global number and the user’s internal extension is added – for example tel:+12125550100;ext=863.

Note. Lync Server also provides the ability to suppress the caller’s ID by replacing it with another number (for more information read Voice Routes in the Technical Library).

As a best practice make sure to always provide a caller ID that can be called back when calling outside the enterprise. Specify a Line URI that contains a DID number.

Define Phone Numbers with an Extension

Phone number extensions are used in multiple ways in Lync. If you dial in to a conference and you want to join as an authenticated user, you must provide your extension and PIN. Also if you want to authenticate with your PIN on a Lync qualified phone, your extension and PIN numbers are required. For more information read Device Connection Process in the Technical Library. Users without an extension receive a warning message on the dial-in conferencing page (see Figure 1). This may lead to support calls.

Figure 1. A warning is displayed for users that do not have an extension configured

The user experience is improved when users can authenticate with a short extension instead of a 10-digit phone number. If a user does not have an extension configured, instead of requiring the user to enter their full phone number, Lync attempts to normalize the entered digits to the full E.164 phone number. If it finds a matching normalization rule to map the entered digits into a valid internal phone number, Lync Server is able to authenticate the user. However, the more complex the deployment the more likely it is that this approach will not work. For example, if users are travelling and dial in to conference numbers in other countries with different normalization rules, their extension may not be recognized.

Best practice is to always assign extensions to all users using one of the formats with the ext parameter.

Leverage Telephone Numbers Configured in Active Directory

Phone numbers within a PBX deployment must be unique. In an enterprise with multiple PBXs deployed, it is possible that some of these local numbers may overlap. If a user, whose PBX phone is hosted on one PBX, calls another internal user whose PBX phone is hosted on a PBX with an overlapping number range, the caller needs to use a prefix to differentiate the call and dial out to the other PBX.

By contrast Lync relies on Active Directory services to provide a companywide directory service. Using local extensions or regional number formats in one of the telephone number fields of a global directory does not work. Users from one location are not able to call users in a different location using their local phone number.

As a best practice, populate Active Directory with phone numbers that are globally unique.

Allow for growth

A deployment may begin with a single integrated PBX or gateway. Superficially, it makes sense to build a Lync dial plan that accommodates the dial plan of the PBX. This works when all your users are in a single region. It may also work if you use local extensions in Lync.

However, building a plan based on a local extension limits future growth. When you integrate additional locations, a numbering plan based on a local extension no longer works. This occurs because the expanded deployment is not local to only one location. When you federate with other companies or when you deploy SIP Trunking be sure that all numbers provided are globally unique and routable.

Even when you start with a limited scenario, plan for future growth. Always use globally unique numbers.

Avoid Common Mistakes

There are a number of different configurations that may initially seem like a good idea due to their simplicity. Later they may turn out to be poor decisions that block future growth.

Common mistakes include, but are not limited, to the following:

• Do not include an outside line access code as part of the phone number.
  In a U.S. based company users often have to dial a 9 as the common outside line code, some administrators mistakenly configure phone numbers to be normalized to +912125550135, instead of the actual E.164 number, +12125550135.
• Do not treat private extensions as global numbers.
  When the company does not use DIDs, some administrators mistakenly decide to populate the Line URI with the extension and prefixes a plus, for example +863 instead of the correct +12125550100;ext=863.
• Failure to include the country code.
  Since the company is only active in a single country some administrators mistakenly decide not to include the country code in the phone numbers, for example +2125550135 instead of +12125550135.

This can lead to the following problems in the following situations:

• People cannot dial E.164 numbers using Outlook contacts or through the Lync Browser Helper if normalization rules only allow for your dial plan.
• Federated partners receive the phone number through the Lync contact card but are not able to call the number, because their configuration correctly expects E.164 numbers.
• Because +91 is the international dialing code for India, +912125550135 is routed to India.
• Because +86 is the international dialing code for China, +863 is routed to China.
• Because +212 is the international dialing code for Morocco, +2125550135 is routed to Morocco.
• The company expands to international locations, which requires it to change all existing locally defined phone numbers to globally unique numbers.
• The company wants to integrate SIP Trunking. Because most SIP Trunk providers do not support private numbers, you need to use globally unique numbers.

Using global numbers simplifies your Lync Server dial plan more than is possible with a typical PBX deployment. One could say this is another reason why Lync isn’t an IP-PBX. It’s not a private branch exchange. It’s an enterprise-wide Unified Communications system.

Summary

After defining the goals and best practices for assigning a user’s phone number in the enterprise, the following summarizes how to configure phone numbers for users with DIDs and for those with only internal extensions.

Configuring Users with DIDs

For users with a DID phone number, specify the global number and the extension in the user’s Line URI. After deciding how many digits to use for the extension, append the last number of digits from the user’s DID to the Line URI with the extension parameter. As an example, if the PSTN phone number for a user is +12125550135, specify the Line URI as, tel:+12125550135;ext=135, assuming a 3 digit extension.

Configuring Users with Internal Extensions

For users with private extensions that can only be dialed from within the organization, you must specify the call back phone number displayed as the caller ID and append the user’s extension. For example the Line URI of tel:+12125550100;ext=863 presents as caller ID the number of an auto attendant (+12125550100) while 863 represents the extension of the user.

Note. When you use this format, no other phone number in your Lync deployment can be assigned the number, +12125550100, without an extension. You must configure the auto attendant with an extension (for example tel:+12125551000;ext=0), and create a normalization rule to normalize incoming call for +12125550100 to tel:+12125551000;ext=0. This can be accomplished by creating a pool level dial plan for the gateway receiving the inbound call.

RFC 3966 is flexible in terms of defining phone numbers. It is recommended to use the ext format for all users – those with DIDs and those with private numbers. This provides users with the best PIN authentication experience and always provides a valid caller ID for outbound calls.

Using an E.164 global number in the Line URI at the initial deployment, provides the most flexibility for future growth of your Lync Server environment – whether you deploy additional PSTN gateways in the same or new locations, introduce SIP Trunking, or expand to new locations.

Lync Server Resources

• Lync Server 2010 Documentation Library
• DrRez blog
• NextHop blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail

Keywords: Lync, Enterprise Voice, phone number plan, E.164, extensions, Line URI

There's a new article posted by Richard Schwendiman about High Availability and Disaster Recovery with Lync Server 2013 Persistent Chat: Lync 2013 Persistent Chat HA\DR Deep Dive Pt. 1

Abstract

As everyone knows by now, with the release of Lync Server 2013 we introduced much improved chat functionality, named Persistent Chat (pChat). Not only is it much improved, but it is also an actual role within the topology (no longer standalone application). One thing that I get questioned about a lot regarding pChat is High Availability and Disaster Recovery (HA-DR). Hopefully with this two part article I can help answer some of those questions.

Author: Richard Schwendiman

Technical Review: Sekou Page

Updates to the Lync Server Networking Guide

January 2014 - The .zip file has been updated on the Download Center to include updated queries and a KHI spreadsheet for Lync Server 2013.

November 2013 - We've updated some of the queries to address the issues you identified and posted a new version of the files to download. Look for the 2013 KHIs to be added soon.

An updated version of the Networking Guide is now available here: Lync Server Networking Guide v2. New sections, authored by Andrew Sniderman, Kent Tilger (Appendix D), Brandon Bernier (KHI spreadsheet and PowerShell script), and Jens Trier Rasmussen, include:

• Appendix C: Call Quality Methodology – a practical approach
  This section covers the Lync Call Quality Methodology or CQM.  CQM is a holistic way to systematically define and assert call quality based upon the methods outlined in the Networking Guide. CQM divides a Lync implementation into ten discrete areas that impact quality, defining targets and a remediation plan for each one. CQM is a framework to tackle call quality problems – you can modify or extend it to address the particular conditions on your network.
• Appendix D. Troubleshooting Poor Streams
  This section includes techniques to troubleshoot poor streams that CQM surfaces.

The Networking Guide download also now includes the list of Lync 2010 KHIs to validate server health and the complete set of CQM queries referenced in the guide.

Thanks for all the feedback on CQM - keep it coming!  Thanks to you we've found and fixed a few issues with the queries. Please let us know of anything else you find. We will refine the content and post an updated version to the Download Center in a couple of weeks.  If you would like to get any updates in advance, send us an email at the address listed in the documents.