Lync Edge Server Best Practices

July 25, 2012 by Jeff Schertz Comments (72)

Amazingly enough these topics still comes up daily in technical forums, planning discussions
with customers, and when troubleshooting improper deployments. Although most of this
material is not new and can be found in various places this article is intended as summary
reference for readers new to the elusive concepts of Edge and Reverse Proxy services.
Overview
Firstly the most important concept to understand when dealing with externally publishing Lync
services is exactly what the Edge Server is responsible for handling as well as what it is NOT
designed to do. Throughout the documentation a Reverse Proxy Server will be referred to often
and it still seems like this concept is often glanced over or not clearly understood.
Edge Server
The Edge server is responsible for handling all communications and payloads in Lync Server
which are made available to external and federated users with one exception: anything related to
Web Services. Note that this does not generically mean stuff over ports 80 and 443 as TCP
443 is used throughout Lync for a variety of different communications. More accurately it could
be said that client communications to servers over HTTP and HTTPS are the types of traffic that
are not handled by the Edge server. Everything else (SIP, PSOM, ICE, etc) are all provided by
the Edge server.
Reverse Proxy
The Reverse Proxy server is an optional, external component that is not a Lync Server role and
is not defined in the Lync Topology. The reason this component is considered optional is
because without it deployed an external Lync client can still connect to Lync and most features
will function (IM, Presence, Calls, Desktop Sharing, etc) as will federated communications.
Only the feature listed on this page will not be available to external clients, which although are
important in a fully functional deployment they are not critical. Yet best practice is always to
provide for these features by publishing the internal web services. A Reverse Proxy is also
required to support any external Mobility client connectivity.
Traditionally Microsofts Internet Security and Acceleration (ISA) 2006 Server or Forefront
Threat Management Gateway (TMG) 2010 are used to publish to the Internet the various web
services running on internal Lync Front End and Director servers. But any third-party solution,
be it software or a hardware appliance, which has the capacity to publish the internal IIS
HTTP/HTTPS services can typically be used. A brief search online should reveal a handful of
documents on how to provide access to internal web servers for various other products. Also
simply configuring port-forwarding from the Internet to the internal servers is possible, but not
recommended as a true reverse proxy solution would have the ability to provide traffic inspection
and added security on inbound connections directly from the Internet.
Topologies
The questions asked most often are typically related to designing the topology (e.g. how many
network interfaces are required) and just how badly some corners can be cut. Consistently
deployments will attempt to use unsupported configurations like a single network interface or not
enough unique network subnets, or 4 interfaces with one external interface on an internal subnet
with another external interface connected to an unsupported firewall, and so on.

For the best chance of a functional, supported, happy Lync Edge server the guidelines provided
in the Assumptions section of the official Lync Edge Server Reference Architecture
documentation should be followed as closely as possible. Granted there are production
deployments out there working just fine which do not match some or all of these requirements,
but those can often be the exception to the rule. Also receiving support for problematic
deployments or future production failures can be difficult as although Microsoft will provide
best-effort support in these cases, the further from a supported scenario the longer the resolution
time can be.
For this article two different topologies will be used as examples and the the differences among
them will be highlighted throughout the various sections.
Simple Topology
The simplest, fully featured deployment would consistent of a single internal Standard Edition
Front End server with a single consolidated Edge server and Reverse Proxy server/appliance
located in a perimeter network. This topology contains a single SIP domain and uses the least
amount of hostnames possible to still provides all client functionality.

Complex Topology
Jumping right into the deep-end this sample topology swaps out the Standard Edition server for
two separate Enterprise Edition Front End Pools and introduces the Director role. Every role is
comprised of multiple-computer pools to provide fault-tolerance to every available feature.
Additional SIP domains are also included, as well as the concept of wildcard certificates.

Best Practices
Always use two network interfaces on two separate subnets. The external interface
should include the default gateway and the internal interface should not. Persistent static
routes should be defined on the Edge server to address connectivity to internal subnets.
As stated earlier the Edge server does not handle any web services requests. This means
that without the optional Reverse Proxy then none of the features provided by web
services will be available for external Lync clients and devices (e.g. address book
download, location information, device updates, Lync Web App).
Additionally the Lync mobile client for phones and tablets will also not function without
a Reverse Proxy deployment as these clients are 100% web-based and must be able to
communicate to the mobility IIS web site (Mcx) running on the Lync Front End
server(s). The Edge server does not handle any communication with the mobility clients
themselves as they are not SIP clients, they only leverage HTTP/HTTPS
communications. The only role the Edge server plays in terms of Mobility is that it is
used for establishing Push Notification communications via Federation services.
A Lync Director server is not a required server, even when an Edge server is deployed. It
is an optional server which can be used to offload user authentication processing, create
an additional layer of protection from external user connections, and provide a single
location for internal client connections (per SIP domain) to be proxied through and
redirected from.
A single Reverse Proxy Web Listener can often be used for all published web services
(per internal pool). The official documentation often shows creating unique listeners for

every different URL but this can be costly in terms of IP addresses. When using ISA or
TMG it is possible to use the same Web Listener, IP address, ports, and certificate for
multiple publishing rules by defining the specific URLs in the rule configuration. This
holds true only when all published URLs are from the same internal server, so in a single
Front End server deployment then a single listener can be used. But in a more complex
deployment with multiple Front End server pools and Directors then a unique listener is
required for each source server. For example the Complex Topology depicted below
would require 3 separate listeners and external IP addresses, one for each of the three
pools; the same certificate can be used across all listeners though.
Certificates
Coming in a close second is the amount of clarifying questions surrounding certificate
configuration for the external servers. How many certificates, which certificate authorities can or
should be used, which hostnames go where; the list goes on.
For basic certificate requirements see the TechNet articles for both the Edge server and Reverse
Proxy server. Also the term Common Name is used throughout this article. Although it is often
used interchangeably with Subject Name that is incorrect as technically the Subject Name is a
complete Distinguished Name (DN) string which includes the Common Name (CN) as one of the
fields. When referring to only the Fully Qualified Domain Name (FQDN) then the term
Common Name is most accurate.
Basic Guidelines
The Internal Edge certificate should be a standard SSL certificate and cannot contain a
Subject Alternative Name field. The Common Name field should be set to the Edge
servers defined FQDN (e.g. edge.schertz.local) in a single consolidated Edge
server deployment.

All internally-facing certificates should be issued by an internal Windows Enterprise CA

whenever possible. Although it is possible to use trusted third party certificates for the
internal Edge interface (as well as other internal Lync server roles) the preferred method
which is tested and supported the most is to use an internal CA with a WebServer
template for the certificate request.
The External Edge certificate should be a UCC or SAN certificate which includes a
Subject Alternative Name field. The Common Name field should be the Access Edge
FQDN (e.g. sip.mslync.net) defined in the Lync Topology. The SAN field should
contain both the Access Edge FQDN and the Web Conferencing FQDN (e.g.
webconf.mslync.net) as it is a general best practice to duplicate the Common
Name in the SAN field (specifically as the first SAN entry) since some foreign devices or
systems have been known to (incorrectly) ignore the CN field when a SAN is present.

All externally-facing certificates should be issued by a public trusted certificate

authority. Although it is possible to use internal certificates on either or both the Edge
and Reverse Proxy external interfaces only clients or devices which are manually
configured to trust the private CA will be able to connect. Also Edge federation with
other OCS or Lync deployments would require that the remote Edge server trusts the
same certificate authority. Thus using a certificate issued by a CA which is by default
already in the trusted certificate store of the client, server, or device operating system is
always the best approach.
Although not typically recommended it is possible to use the same external certificate for
both the external Edge server interface and the Reverse Proxy server interface. This is
often done for the purposes of saving money, especially when some third party CAs will
require SAN certificates to be purchased in tiers where a choice of 1, 5, 10, or more
SAN entries will be provided instead of applying an extra cost to each individual SAN
entry. In this case its best to use use the Access Edge FQDN as the Common Name and
then concatenate the list of all SAN entries from both server roles.
As previously explained the Mobility Autodiscover FQDN (e.g.
lyncdiscover.mslync.net) does not go on any Edge certificate, it should be
added to the Reverse Proxy certificate.
Externally-facing certificates should never include any internal hostnames, especially
when using separate DNS zones internally and externally. Broadcasting the internal
namespace and server hostnames is poor practice, and is one reason not to attempt to use
the same certificate across internal and external interfaces.
A/V Edge
The A/V Edge component is actually comprised of two separate services: A/V Edge and A/V
Authentication. Each has a unique function and communication flow which have been updated
since OCS to provide for a simpler certificate configuration. (The previous article
Understanding Lync Edge Ports goes into further detail on these Edge services.)
Only the Access Edge FQDN (e.g. sip.mslync.net) and the Web Conferencing
FQDN (e.g. webconf.mslync.net) are required on the external Edge Certificate.
The A/V Edge FQDN (e.g. av.mslync.net) which is defined in the Lync Topology
for use with the A/V external interface is not required on any certificate. It is not needed
on the external Edge certificates as external clients or servers will not attempt a TLS
connection specifically to the A/V Edge external IP address when using the A/V Edge
FQDN so there is no need for that FQDN to be provided in the certificate.
The A/V Edge FQDN is also not used on the internal Edge certificate. Connections to the
A/V Authentication service are only applicable to the internal Edge interface as these
connections always come from a Front End server (which proxies all internal or external

client A/V authentication requests). The Front-End server will always use the internal
Edge FQDN when connecting to any listening port on the internal Edge server regardless
of which service it is connecting to.
Multiple SIP Domains
When supporting multiple SIP domains there are a couple different considerations to take into
account which can impact the planning phase related to certificate configuration and public DNS
zone records.
The recommended approach for external client Automatic Sign-In when supporting
multiple SIP domains is to include a unique Access Edge FQDN for each domain name in
the SAN field. This is no longer a requirement (it was in OCS) as it is not possible to
create a DNS Service Locator Record (SRV) for each additional SIP domain yet have
them all point back to the same original FQDN for the Access Edge service (e.g.
sip.mslync.net). This approach will trigger a security alert in Windows Lync
clients which can be accepted by the user, but some other clients and devices are unable
to connect when the Automatic Sign-In process returns a pair of SRV and Host (A)
records which do not share the same domain namespace. Thus it is still best practice to
define a unique FQDN for each additional SIP domain and include that hostname in the
external Edge certificates SAN field.
A unique Web Conferencing FQDN (or another other Lync FQDN) is not required for
each SIP domain as once each client is able to connect the original primary FQDNs for
all other services will be passed to the client in-band. Thus a user in the SIP domain of
@domain2.com would utilize the hostname sip.domain2.com to connect but
would be automatically provided an FQDN of webconf.mslync.net to connect to
the Web Conferencing Edge service.
As shown in the Complex Topology it is supported to utilize wildcard entries (e.g.
*.mslync.net) for the SimpleURLs (e.g. meet, dialin) as well as the
lyncdiscover FQDN. But not all clients supports wildcard entries for all usages. For
example, even though a recent update to Lync Phone Edition introduces wildcard support
there still exists the problem of how to upgrade devices on older firmware to the
supported version. Thus it is always recommended to plan for all potential client and
server versions which might need to register to Lync or participate in federated
communications. The key is to avoid placing the wildcard entry in the CN itself and
instead provide it as a SAN entry, making sure to still include specific entries for any and
all external web service FQDNs from Front End and Director servers. Then clients
which are still incompatible with wildcard entries can utilize the specific hostnames
provided in the SAN field as well. In the future there will probably come a time when
wildcards can be used for all communications, providing simple, cheaper certificate
options, especially for hosting providers which need to support a large variety of SIP
domains and large deployments.
Edge Pools
When dealing with multiple Edge servers in the same pool there are some specific requirements
which must be followed otherwise some or all functionality of the Edge servers can be
negatively impacted.

As stated earlier the internal Edge certificate cannot include a SAN entry, and this holds
true even in multiple server pools. The Edge Pool FQDN (e.g.
edgepool.schertz.local) must be defined as the Common Name and the
individual Edge server FQDN is not included in the certificate. The internal Lync
servers, clients, and devices will connect to the pool FQDN and not any of the individual
server FQDNs. For instances when connections need to be opened directly to a specific
Edge server, as in relaying a media session, these communications are not SIP-based and
often times are initiated directly via an IP address, as in ICE/STUN/TURN negotiation).

The exact same certificate must be used on all common interfaces across the pool,
regardless of whether DNS load balancing or hardware load balancing is utilized. This
means that the original certificate request must provide the ability to export the private
key as the exact same certificate and private key pair must be able to be exported from
one Edge server into all other Edge servers. This is required so that in the event of a
failover any existing sessions can be moved to another server in the pool and the data can
still be decrypted by the same certificate that was used to encrypt the session just prior to
the failover. Compare the serial numbers on each certificate to validate they are the same
certificate and not just duplicate requests with the same configuration. This requirement
applies to the internal interfaces as well as the external interfaces, so there will be a single
internal certificate shared across all internal Edge interfaces, and a second external
certificate shared across all external Edge interfaces. (Do not try to use the same
certificate on both internal and external interfaces.)

Filed under Lync Tagged with Certificates, Edge