To understand what we are going to do, it is necessary to clarify some basic concepts along the way, starting with the Lync versions and available "roles".

A Lync deployment is made up of a variable number of servers (depending on the features we are going to use and the level of availability and security we need).

A part of these servers will not even have Lync installed, but it is mandatory to build the basic infrastructure.

The cornerstone for the entire organization is Lync Front End, made up of a Standard Edition server (SE) (a single box with all the features available locally), or by a pool made up of one or more Lync Enterprise Edition server (EE) units connected with three or more Back End Servers units (fundamentally one or more SQL Server databases).

The latter configuration will support scalability and high availability (HA), especially if we decide to use SQL mirroring, which now replaces the SQL clustering we had to use with Lync 2010.

There is no difference in the unified communication features we have with a Standard Edition and with an Enterprise Edition, but SE servers cannot be grouped in a pool; they can just be "paired" with each other (we will talk about Enterprise pools in the course of this chapter, and pairing will be covered in Chapter 2, Understanding Front End Pool Pairing).

From a server-licensing point of view, in Lync 2013 there is only a single "Lync" license, with no distinction between Standard Edition or Enterprise Edition. However, the difference still exists from the point of view of deployment. A Client Access License (CAL) is also required for the Lync users based on the features they will require. For the details on licensing, please refer to Licensing Lync at http://office.microsoft.com/en-us/lync/microsoft-lync-licensing-overview-lync-for-multiple-users-FX103789668.aspx.

A mandatory requirement for any Lync deployment is a pre-existing Active Directory infrastructure; so we take it as given to have a domain with directory services up and running.

In a small company that does not need to publish Lync on the Internet, a single Standard Edition server (and a domain controller) is all we need to be able to deliver Lync to our users, because almost all the services are installed locally (PowerPoint presentation broadcasts require an additional Office Web Apps server. See Web Conferencing Overview at http://technet.microsoft.com/en-us/library/gg425913.aspx for more information).

Reverse proxy

A reverse proxy is required for external access. For more information, you may refer to the previously mentioned Chapter 3, and to the Setting Up Reverse Proxy Servers article at http://technet.microsoft.com/en-us/library/gg398069.aspx.

Continuity for the services published with the reverse proxy requires a specific hardware or software solution, depending on the kind of server we are using to publish Lync.

Also, if there are existing deployments without a reverse proxy, publishing Lync services directly to the Internet will not be a supported solution. In the following diagram, we can see a high-level overview of the previously mentioned scenarios:

To complete the list of Lync roles, we must also consider the following areas:

• Mediation: This can be deployed as a separate server or collocated on a Front End. It is used for IP-PBX, Gateway, and SBC interoperability to provide Enterprise Voice and dial-in conferencing.

• Director: This server enhances the performance of user authentication and adds a security layer.

• Persistent Chat Server: This server is used to create one or more "chat rooms" that can be moderated, and to retain the instant messages of the users for a defined amount of time.

• Monitoring: This role, collocated on a Front End, collects data about the quality of the service with Enterprise Voice and audio/video conferencing.

• Archiving: This role, collocated on a Front End, is used for compliance; it stores IM messages and conference contents.

Persistent Chat Server requires a Back End Server role, and may include an additional role, Compliance Back End, to keep track of the messages published in Persistent Chat Server if required by local regulations or laws.

From the planning point of view, we need to keep the following points in mind:

• Some roles (such as archiving and monitoring) are always collocated on the Front End, while other roles (such as Mediation server) can be collocated depending on the scenario. Edge, and Director always require a dedicated server.

• Archiving, monitoring, and Persistent Chat require a database for each one. For this we could use a dedicated database or instance; collocate the databases on the SQL Express installation that is part of Front End, or collocate the databases on SQL Server that has the Back End role for an existing pool.

Enterprise Edition Front End, Mediation server, Director server, and Persistent Chat Server can be configured in a pool (that is, a group of servers having the same features installed). Pools are an important feature for high availability and load balancing (usually, the mechanism used is DNS load balancing, but hardware load balancing is supported as well).

The previously mentioned list does not include additional servers, such as Exchange and SharePoint. If these servers are present, they will be able to interact with Lync in a native manner to create an additional set of features.

Well-known examples of the integration include the presence of indicators in the Outlook client and Lync meeting integration with calendar (if Exchange is present), or any skill-based search that enables us to search for a person in Lync using the professional expertise recorded in SharePoint as criteria.