Wednesday, March 11, 2015

Skype for Business Readiness Series (6/15)

Today I joined the sixth session of the Skype for Business Readiness WebCast  Series and the topic for today was SQL Always On Deep-dive. The Webcast was recorded and is available online from the link above.

Bryan Nyce did a good job presenting this topic. Nevertheless, I felt a bit like...

 Check out a good introduction here: SQL Server AlwaysOn for Dummies

SQL Server Always On Availability Groups require SQL Server enterprise edition. The licensing cost for SQL Enterprise to use the SQL Always On feature might even be higher than the licensing cost for a Lync Front-End, unfortunately. However, SQL Mirroring and clustering are still supported just as in Lync 2013 for us with limited funds.

Here comes the QnA, 13 new answers:

New features

Can the Secondary Replica be present in a Different Datacenter (or Geographic region)?

No, this will not be supported at RTM. All replicas in a SQL Always On Availability Group for a S4B pool must be connected to the same subnet.

Can SQL Always On also be used for SQL Server Reporting Services for monitoring reports?
This will not be supported at RTM, Microsoft plans to investigate it sometime post-RTM.

Can SQL Always On be used with a clustered share volume using scale out file server to connect to media?
This has not been tested, so as of now is not supported.

Are SQL Always On availability groups supported between different SQL versions?
Yes it is supported to add backend databases of S4B pools to AO Availability Groups hosted on either SQL Server 2012 SP2 CU2 or SQL 2014.

SQL Always On leverages windows clustering, with an even number of nodes, do we need a file witness?
Yes, a file witness is required.

Are all Databases updated simultaneously?
Yes, if we do a failover (automatic or manual), all databases are failed over together as a group to one of the replicas.

Is the Primary in an Always On the only server than can "vote" in an even numbered Front-end Pool?
Not the Primary, but rather the Active replica that own write access to the databases.

What is the recommendation regarding number of replicas?
1 active + 2 secondary replicas is supported, but only one of the secondary replicas can be an automatic failover target.

From a S4B point of view, what is the benefit of having 2 replicas instead of having only 1 replica?
Having one additional safe copy of the databases. Failover to the third SQL server (second replica) in the event of an outage of both of the other replicas would however not be automatic.

Is there a two-node Always On SQL offering based on SQL Standard Edition?
Yes, it is called Always On Failover Clustering Instance (shared disk). We can have up to two nodes using SQL Standard Edition. This is one of the supported SQL HA solutions for S4B.

Do we need to have the Availability Group Listener FQDN already configured in DNS prior to running the deployment?
Yes, all the required DNS records should be in place prior to deployment.

For SQL Always On Availability Groups, do we need a separate load balancer or does SQL handle that?
This is handled by SQL, no HLB required.

Can a single SQL Always On Availability Groups host multiple pools backend databases?
No, this is not supported.


  1. Hello and thanks for the great posts!
    Regarding SfB AO replicas which have to be on the same subnet, do you happen to know if it is still the case? And do you have any pointer to official MS docs?


    1. The "most official" reference I can find right now is this webinar:

      Listen to the QnA section as transcribed here: