This section describes how to design Lync topologies based on several scenarios. The first question is – can Lync fulfil all of these requirements?

Lync definitely addresses all of these requirements with the Lync Edge server. The Edge server itself acts as a highly secure, real application proxy and is a non-domain joined system with incoming data replication only. The flow of an incoming SIP session is described below.

Arriving at the external Edge Server interface, external traffic is terminated, full application inspection, rights verification and user policy validation is started. After this inspection, the traffic will be sent via the internal network interface to the next network security layer which is the Lync Director Pool or the Front End Pool. In our example, we will assume that this additional security layer (in the form of Director Pool) was integrated.

User authentication requests will only be performed on a Director Pool and this traffic is redirected to the user’s destination Front End pool. From there onwards, the traffic is treated as authenticated and a VIA (Path) is established between the Edge Pool, Director Pool, Front End Pool and the internal user client. This information is sent by a NOTIFY SIP command. The same principal is valid if users are homed on Survival Branch Appliances (SBAs).

SIP traffic is simple – SIP has the provisioning for VIA (Path) headers and therefore it is aware of the traffic flow.

The Web Service traffic is referring to the earlier mentioned topic of generic web traffic, for example meet or dial-in, and the web services homed on all Lync, Director and Front End Pools. The traffic flow for these must be taken into consideration.

The Director is not an additional security layer for Pool Web Services. This is where IIS website segregation comes into play.

The next section discusses the minimal deployment with an Edge Server and a Reverse Proxy.

Note: Starting with the initial principals – we will define the incoming protocols. Here we have SIP, Persistent Shared Object Model (PSOM), Session Traversal Utilities for NAT (STUN), RTP and HTTPS. HTTP is not relevant because, during the next topology definition, all unencrypted traffic will not be allowed. Additionally, in order to make the diagram below easier to understand – all Edge Server-relevant protocols have been consolidated in the word SIP.

High Availability (HA) is not addressed in this document. Moreover, HA runs the Lync server in pools and initiates either Hardware Load Balancing (HLB) or a mixture of HLB and DNS load balancing.

Additionally, XMPP traffic cannot be directed via the Director Server – it is always a Front End – Edge communication.