This is the first part of the draft for a new chapter of Microsoft Lync Server 2013: Basic Administration ( http://gallery.technet.microsoft.com/office/Lync-Server-2013-Basic-0a86824d ). Feedbacks and suggestions are welcome, especially in this early stage.
In Chapter 2 I have shown a DNS configuration with split name resolution, just because it was required to build your Lync 2013 laboratory. Now it is important to clarify some basic concepts.
What is DNS (in Six Lines)
Machines and human beings have a different logic. So, while a computer is comfortable in finding another computer with a 12 digit hexadecimal value (the MAC address) or using another numeric value like the IP address, you and I have to use names to find a computer (or a specific service) among the others. The DNS server keeps a list of hostnames (or services) paired with one (or more) IP address, so that you are able to access network objects and services in an intuitive manner, with a name that is easy to remember.
Why DNS is Fundamental for Lync Server 2013
With the release of Windows 2000, Microsoft decided that DNS was the right (and only) tool to publish the infrastructure of network services. Authentication, access to data and (of course) unified communications with Lync, are all made available using DNS servers. Fully qualified domain name (FQDN) like Apollo.Lync2013.Dom will be required to build your Lync infrastructure, along with the so called Service Records (SRV records) that identify a network service with a FQDN and a port number (for example a public SRV record, _sipfederationtls._tcp.lync2013.org on TCP port 5061 pointing to Access.lync2013.org that is required to enable Lync Dynamic Federation). If a required FQDN or SRV record is misconfigured or not available, a part of the services from Lync Server will not be available.
The Basic Diagram of a Lync Deployment We Will Use in the Chapter
The explanation of Lync requirements will start from a diagram in figure 6.1 (identical to the one shown in figure 2.2), representing the minimal infrastructure required to deploy a Lync server 2013 that is available also for external users
Figure 6.1 A minimal working infrastructure of Lync Server 2013 including external users
To explain the Lync infrastructure, as I said, we will need to add names and network addresses (IPs) to our Lync design. To grant the name resolution we will use the same DNS server that is already required for the Active Directory Domain Services (AD DS).
Note: There will be two different DNS names resolutions required, one for the Internet and one for the internal network. The latter is the one that will take advantage of the existing DNS server.
Lync Server 2013: Internal Network
In figure 6.2 I have added names, network address and Virtual LANs (VLANs) to the schema shown in the Previous figure 6.1
Figure 6.2 The previous Lync diagram, populated with names, IPs and VLANs
Servers located in the LAN
The Domain Controller, Aphrodite will be in charge of user authentication, permissions and DNS service. Lync is built over Active Directory, so the internal deployment will require a Domain with the following requirements:
- All domain controllers have to be at least 32-bit or 64-bit versions of the Windows Server 2003 operating system
- Domain functional level at least Windows Server 2003
- Forest functional level at least Windows Server 2003
Note: see the TechNet post Active Directory Infrastructure Requirements http://technet.microsoft.com/en-us/library/gg412955.aspx for additional information
For a user that is connected to the internal LAN, all the services are available directly on the Front End (Apollo). A part of the aforementioned Lync services (like dialin and meet) will be deployed through the locally installed Internet Information Services (IIS) feature and will be reachable on port 80 and 443 of Apollo.
On Apollo we will have a second group of web services, similar to the aforementioned ones, but listening on TCP port 8080 and 4443. It is easy to distinguish them using the default names Internal Web Site (listening on TCP port 80 and 443) and External Web Site (listening on TCP port 8080 and 4443)
Figure 6.3 The IIS configuration on a Lync Server 2013 Front End
The External Web Site will be used to grant the services to the external users using a reverse proxy
In figure 6.4 I have expanded the Internal Web Site of Lync
Figure 6.4 The IIS “Internal” site on a Lync Server 2013 Front End
As soon as we share a PowerPoint presentation, during a meeting, we will be redirected to the TCP port 443 (or 80) of the Office Web App Server (Demeter).
Note: Lync clients for mobile will always require access to the Lync services as they are coming from the Internet, also if they are connected to an internal network (see next paragraphs)
Servers located in the DMZ
To make Lync Server 2013 available to external users, we will publish the services from the single Front End through two different servers that we will locate in a Demilitarized Zone (DMZ). The servers should be standalone (or, at least, not part of the internal Active Directory Domain). Both servers should have two different network interfaces (NICs), one dedicated to talk with the internal LAN and the other one to be published on the Internet with Network Address Translation (NAT). I have also physically segregated the two logical networks using VLANs, so that communication from one NIC to the other one will never mix. VLAN2 will be connected to the internal LAN through a back-end firewall, while VLAN3 will be connected to the Internet using a front-end firewall.
Web services of the Lync Front End will be published using a reverse proxy (Ares) that will answer on a public Internet IP on TCP port 443 and will proxy the requests to the port 4443 of the Front End (or on TCP port 80 to proxy on port 8080 of the Front End). If we share a PowerPoint presentation in a meeting that contains external users, the reverse proxy will redirect them to the TCP port 443of the Office Web Application Server. ANY reverse proxy solution should work, including Windows Server 2012 R2 Web Application Proxy (I have shown how to configure it for Lync 2013 on this video: http://www.youtube.com/watch?v=iKpi8UomRDo ). Forefront Threat Management Gateway is also a solution that many companies used over the past years (please consider that the whole Forefront family of products is “ending its life”).
All the remaining services will be deployed using a dedicated Lync server role, the Lync Edge Server (Dionysus) that has to be defined and published using the Lync Topology Builder (more details on Edge Server and Topology Builder will be added in further chapters). Three network addresses will be required to publish the Edge services. Lync supports two different configurations on your front-end firewall and Lync Edge Server:
- A single public IP and a single public name for the three services, Access Edge, Web Conferencing Edge and A/V Edge (with three different TCP ports listening)
- A simple deploy with three public addresses, one for each one of the aforementioned network addresses.
In figure 6.5 you can see the option that enable the use of a single public name and IP
Figure 6.5 The “Use a single FQDN and IP address” option in the Topology Builder
In figure 6.6 I have shown the two different configuration you while building the Lync Topology. On the left, the scenario if we selected single IP and single FQDN. On the right scenario with multiple IPs and FQDNs
Figure 6.6 on the left, “Use a single FQDN and IP address” enabled. On the right multiple FQDNs and addresses
Note: It is easy to understand that the solution using a single IP will be less “costly”, but will be more prone to problems with external firewall, moving the services from a “standard” TCP port 443 to a group of custom TCP ports.
