The four steps of this phase (preparing the Active Directory, modifying the DNS, configuring Internal CA, and deploying the SQL database) can be executed in any order because no one is a prerequisite to the other.

We need to extend the Active Directory schema with classes and attributes that are required by Lync Server.

For the previously mentioned operation, our forest and domain have to be at least Windows Server 2003 native level (that is why all domain controllers must have at least the Windows Server 2003 operating system).

There are three different ways to extend the schema:

In text we will follow the most common approach. To streamline the installation process, we will use the deployment wizard on the first Front End Server that we are going to deploy. If we want to use a different method, we can start by referring to Preparing Active Directory Domain Services at http://technet.microsoft.com/en-us/library/gg398607.aspx.

The second part of setting up the infrastructure requires you to manually add Lync records to the internal DNS.

Deploying certificates and DNS

The recent application of a change to the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (http://www.digicert.com/internal-names.htm) implies that it will not be possible in a few years to use internal names in our certificates, so a split-brain DNS configuration (with the public zone published on the internal DNS and the public FQDN related to internal addresses) or pinpointing DNS are the suggested solutions.

Usually, we will deploy two kinds of certificates:

• Certificates from our Internal CA for the internal services and connections
• Third-party certificates for the Internet-facing server, such as a reverse proxy and Edge

The first set of records that we need to add is the one related to the Lync Enterprise Front End pool.

As we said before, the pool can be balanced using DNS load balancing or a hardware load balancer.

The previous choice is not available for Lync's web services; therefore, if we also need to have web services in HA, we have to select a dedicated solution, such as a hardware load balancer paired with the DNS load balancing.

What we just said implies that there are different possible scenarios from a name-resolving point of view. A good part of them is addressed in the document DNS Requirements for Front End Pools at http://technet.microsoft.com/en-us/library/gg412910.aspx.

In our example, we will only have DNS load balancing with a couple of Lync Front End Servers, Lync1 (192.168.70.30) and Lync2 (192.168.70.31). The name of the pool will be Pool. The public domain will be Lync2013.Org.

Our DNS configuration will use the commonly used approach, "split-brain" DNS or "split" DNS, where we create an internal copy of the public DNS zone, replacing the IP addresses for Lync with the internal DNS records.

A drawback of the previously mentioned solution is that we will have to manage two "public" zones, the split-brain one and the zone published to the Internet.

An alternative could be to use a "pinpoint" DNS zone (refer to Determine DNS Requirements at http://technet.microsoft.com/en-us/library/gg398758.aspx), where we need to insert just the DNS records that will be different from the external zone, and point them to the internal network addresses. The rest of the DNS zone remain unchanged, and is referenced from the external, real master.

We need to perform the following steps to create a split-brain DNS:

1. Create a new zone in our internal DNS (the same where the domain zone is hosted, as shown in our example):
   
2. Name the zone as our public SIP domain lync2013.org (so that we have the "split-brain"), as shown in the following screenshot.
3. Add the A records for the Enterprise pool pointing to the IPs of each of the Front End Server units.
   

Now, we have to address another aspect: the DNS records for the web services.

Before we insert the information in the zone, we have to take an important decision regarding the URLs that we will expose to the external users.

Web services of Lync are tied to three different URLs: "meet", "dial-in", and "admin".

• Meet is the base URL for the meeting invitations we send, for example, to people outside our company or to someone who has no Lync client installed on his/her machine (and will participate using the Web App).

  A URI for a Lync meeting is similar to https://meet.lync2013.org/fabrizio.volpe/Y6JTZ98S.

  Launching it, a user with a Lync client installed locally will see the meeting start in the client, while a user without a client will have to access the meeting via the web interface of Lync.

• Dial-in is a record used to give users who will take part in a meeting using a telephone (for example, a traditional PSTN line), an interface where they can manage parameters such as a personal PIN and so on.
• Admin is used to publish the administrative console of Lync.

The only record really needed in Lync is meet, while dial-in is interesting only if we will use Enterprise Voice with dial-in conferencing and admin is something that we have to evaluate for every different deployment.

As we read in the document Planning for Simple URLs at http://technet.microsoft.com/en-us/library/gg398287.aspx, there are various options available.

I prefer to use a common "root" in the URI, because acting this way, we may need a single name in the certificate (let's say meet).

In our test deployment, we will have meet as the common path, and so we will need only two additional A records pointing meet to the Front End Servers that are added, as we can see in the following screenshot:

Note

As we said before, the web services have high availability only if paired with a hardware load balancer. So, the configuration we have seen right now will use round robin to work (that is, in case of a failure, 50 percent of users trying to launch a Lync meeting from the internal network will experience failure).

Depending on the version we are using (Lync 2013, Lync 2010, or Store app), the client will query the DNS for a list of specific records, and as soon as one of them is resolved, the client will use it for authentication.

The following schema should make things clear:

So, we have to add lyncdiscoverinternal, _sipinternaltls._tcp, and sip.

The SIP record will be pointed to the public IP of the Lync Edge server. This is because the configuration, using which we are going to test Lync Edge, will use the internal DNS as its primary DNS (an alternative is to use the hosts file on the server).

While lyncdiscoverinternal requires two A records with the IPs of the two Front End Servers and SIP via a simple A record to create the SRV record for sipinternaltls._tcp, we need to operate it as shown in the following screenshot, launching Other New Records from the DNS manager, and then selecting Service Location SRV (as depicted in Required DNS Records for Automatic Client Sign-In at http://technet.microsoft.com/en-us/library/bb663700(v=office.12).aspx).

The final situation of the DNS zone that we have to create will look like the following screenshot:

The configuration of the certification authority infrastructure is mandatory if our deployment will be based on certificates issued from an Enterprise CA.

The previously mentioned decision implies the limits for our Lync services when we will proceed to allow access to external users. Only clients and servers that accept our Internal CA as a trusted authority will be able to access our services, and that means our typical user will probably be one of our company workers or someone from a trusted partner network. The impact of the "internal" certificate is reduced if all the clients are part of our domain (because they will accept our Internal CA by default).

The other option (using a well-known public certification authority) is for sure easier to manage, but requires money because what we need for Lync is a costly Unified Communication (UC) certificate with multiple Subject Alternative Names (SANs).

A detailed description of the deployment of an Enterprise CA is not included here, although a good starting point to understand it is the Active Directory Certificate Services Step-by-Step Guide article at http://technet.microsoft.com/en-us/library/cc772393(v=ws.10).aspx.

Now, talking about setting up the database, Lync Back End is a SQL deployment (more or less complex) without any Lync component or feature installed, but dedicated to host the Lync Central Management store.

The SQL Server deployment must be completed before creating and publishing the Lync topology by using Topology Builder.

The supported databases (only the 64-bit edition) are: SQL Server 2008 R2 Enterprise, SQL Server 2008 R2 Standard, SQL Server 2012 Enterprise, and SQL Server 2012 Standard.

Some suggestions related to the installation of SQL for Lync are as follows:

Later, the Lync Topology Builder will require a file share during the process of creating mirror databases. We can create the share right now, giving the permissions to the accounts of the SQL servers (for the deployment of SQL1, SQL2, and Witness) as stated in Tim Harrington's blog post Adding a SQL Mirror to an Existing Lync Server 2013 Back-End (http://howdouc.blogspot.it/2012/08/adding-sql-mirror-to-existing-lync.html).

If we are launching Topology Builder, it implies that we have completed the following checklist:

Often, it is the starting point that every company customizes with its parameters (especially from a naming and addressing point of view).

The preceding list is only to say that launching Topology Builder is the closing act of the design part.

After that, all we need to do is simply install Lync on the required servers, and make the whole mechanism work.

In the text, I suggest a staged approach to learn the meaning of the different steps. So we will deploy the internal servers, test them in depth, and then add the Edge and the other Internet-connected features (and test them too, obviously).

In the following paragraphs, we will see a step-by-step installation of a Lync 2013 Enterprise Edition Front End with a SQL Back End enabled to mirroring. An Office Web Apps server will also be deployed (we will not look at the details related to this setup).

To understand the installation process in text, we will have it divided into three phases:

The second phase – preparing the Active Directory

As a requirement to install Lync on our organization, we have to perform the following steps:

• Preparing the schema
• Preparing the forest
• Preparing the domain

The previously mentioned steps require accounts that have the rights to modify the Active Directory schema, forest, and domain, as stated in the Preparing Active Directory Domain Services article at http://technet.microsoft.com/en-us/library/gg398607.aspx.

From the deployment wizard, we will launch Prepare Active Directory and a menu with seven steps will be available:

The first step will be Prepare Schema, the third will be Prepare Current Forest, and the fifth will be Prepare Current Domain.

All the other actions are dedicated to check the operation's result, and (in the last step) the addition of users in the group of Lync administrators, CSAdministrator.

The Prepare Schema screen will warn the user that the preparation of the schema is a "run once" operation. The operation will run, giving us "onscreen" updates on the various passages. When the step is completed, we can examine the log to check for (eventual) errors.

Prepare Current Forest and Prepare Current Domain are really similar to the schema preparation step.

Use the following steps to prepare and publish the Lync topology:

The following steps will now help you to install the components associated with Lync Server:

Now, we will have a look at the following steps to install and assign certificates:

The deployment steps are to be repeated on the second Front End (Lync2.lync2013.dom).

In Chapter 3, Deploying Lync Mobility and External Users Access, we will acquire SSL certificates from a third-party CA for our Edge and reverse proxy. We will have to apply the aforementioned certificate on the Front End servers as well (at least for the web services dedicated to the external users).

We can work on it using the same administrative interface we have seen in step 3 in the previous section.

If we have required public certificates that also include the FQDN related to our internal domain, we can simply replace the certificate released from our internal CA. However, this solution that includes the FQDN that is not reachable from the Internet in a third-party certificate will not be available after November 1, 2015.

What we can do then is use the capability of Lync to use different certificates on the web services dedicated to the internal and to the external users (as you can see in the following screenshot).

So, we are able to apply the certificate from the internal CA on the internal web services interface and the certificate from the third-party CA (containing only the FQDN of our public domain) on the external web services interface.