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 features 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 Microsoft’s 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 server’s 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 it’s 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 certificate’s 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 client’s 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.)