Lync Server 2013: Lync Backend SQL Server Licensing

One of the most frequently asked questions is:

How do we license SQL Server as a Lync Backend Solution correctly.

This is not an very easy question.
But first in general the common SQL licensing applies. This is mainly regarding if you license as per CPU or Server. This question will mainly not have an impact regarding Lync based licensing.

Lync Server Enterprise Deployment requires an SQL Server instance. this is fact, as well as several other Lync Server or Components (e.g. pChat or monitoring and Archiving)

We have a few SQL Backend scenarios:

1. Single SQL Server
This solution do not provide an HA feature, either the Server, nor the database.
But it is possible in adding this server deployment into an mirrored solution(3.)
2. Clustered SQL Server (with a single Database)
This provides only HA for the Server themselves, but the Database is not protected.
Well some solution exists, where the storage is in a mirrored relationship and there provide database HA in another tier. But a storage mirror do not protect your database against an logical database issues, since the database it a clone only.
3. Mirrored SQL Server (with two independent databases)
Finally the recommend solution from Microsoft for maximum HA, both the Server as well as the database is protected.
We have two SQL Server configured in a mirrored relation, therefor the server are redundant and protected
The database itself it part of the mirror, which means, the server a replication via log shipping an independent transaction to its mirror, where this server logically replay this into the database. Only if both transactions a successfully committed, the SQL Server will send an acknowledge to its sender.

SQL Server Licensing

Since we have discussed the possible Lync Enterprise SQL configurations, now we need to have a look into the licensing.

Licensing is seperated into Server and CAL.

First the CAL, a CAL is segregated into User Connection or Device Connection. Therefor in Lync user do not directly conntect to SQL server. The entire access is indriect, so via the Lync server or Lync client.
Also indirect SQL server access requires a CAL.
But there is another possibility, if you license the SQL server based on CPU CORES, you do NOT need CALs.
(There is a breakeven between COREs and CALs close to 50 user, where the server core licensing model is more efficient, but it depending on licesing model/ contract)

Now we see what is required. Keep in mind, that it doesn't matter if we now count either sever or core based, but if it is core base you have to muliply the server count by core. E.g. you need 2 server licenses and have 2 core, in total you need 4 SQL licenses which are core based.

Scenario 1:
Only 1x SQL Server license is required

Scenario 2:
In a cluster we are required having assigned 1x SQL Server each, so in sum we need 2x SQL Server Licenses

Scenario 3:
This will become more complicated, therefor i need to separate this into two sub topics:

3.1: The mirrored SQL Server Instance is used for LYNC ONLY
You only need 1x SQL Server license for the left server, the mirrored instance is FREE of charge.

3.2: The mirrored SQL Server Instance is used for LYNC and OTHER Application
You need 1x SQL Server license each, this means 2x SQL Server license in sum.

Other Lync databases:
Now we sitll have a question regarding other instances we could use, e.g. Monitoring or even Archiving, maybe pChat.
All this SQL databases can be hosted by another SQL INSTANCE, therefor exactly the same principles apply.
So if you use another SQL Instance you need additional SQL Server license as per description above.

In smaller installation you can minimize the number of SQL Server license, if you deploy all databases into a single instance and use a dedicated Lync mirror SQL server free of charge. But remember you need to carefully plan your SQL Server perfomance if you deploy all databases.

Last but not least:
I also have pasted the offical Microsoft reference so we are able to validate my writings:

Failover Basics

For each properly licensed instance of SQL Server, customers can run a supporting passive instance in a separate OSE for temporary support—that is, to synchronize with the primary server and otherwise maintain the passive database instance in a warm standby state in order to minimize downtime due to hardware or software failure. A passive SQL Server instance is one that is not serving SQL Server data to clients or running active SQL Server workloads. This passive failover instance can run on a server other than the licensed server.

The secondary server used for failover support does not need to be separately licensed for SQL Server as long as it is truly passive. If it is serving data, such as reports to clients running active SQL Server workloads, or performing any “work” such as additional backups being made from secondary servers, then it must be licensed for SQL Server. 

Primary server licenses include support for one secondary server only, and any additional secondary servers must be licensed for SQL Server.

Note: The rights to run a passive instance of SQL Server for temporary support are not transferable to other licensed servers for purposes of providing multiple passive secondary servers to a single primary server.”


  1. Is Lync 2013 compatible with SQL Server 2014?

      this is the support article, well by today SQL 2014 is NOT supported


Post a Comment

Popular posts from this blog

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

How to hide users from GAL if they are AD Connect synchronized

MFA with Guest Access and different tenants settings