Should I upgrade SQL? Move to SQL Mirroring? – Microsoft Lync 2013


I have seen this topic brought up quite a bit in organizations looking to upgrade there current Lync 2010 Infrastructure or implementing Lync 2013 in a new environment where by they have not used Unified Communications Products from Microsoft previously.

Microsoft have made some big changes in the Back End Supported¬†Topology’s in Lync 2013 along with many changes in HR/DR (High Availability/Disaster Recovery) and so to benefit from all of the features provided in Lync 2013 it is important that you deploy the infrastructure in a supported scenario and likewise to ensure you are fully supported by Microsoft.

In this post I am going to briefly touch on the SQL Server requirements & HR/DR Features but I will be going into further depth with these at a later date.

These are two questions which have been asked by organizations recently which I have answered simply below:

Q. Can I use my existing Microsoft SQL Server version

A. If you currently use a x64 version of SQL Server then you can use it providing is one of the following versions:

  • SQL Server 2008 R2 Standard & Enterprise Edition
  • SQL Server 2012 Standard & Enterprise Edition

Please Note: x86 SQL Scenarios are NOT supported with Lync 2013 and it is recommended that you do not mix/match your SQL versions in the topology as you don’t want DB Issues.. ūüėģ

Q. Can I use my existing SQL Clustering Topology?

A. You can use your existing SQL Server Cluster although this is not a supported scenario, and so you would be implementing an non-supported back-end topology and so therefore it is recommend you migrate to SQL Mirroring.


SQL Server Back End High Availability РSQL Mirroring / Requirements 

  • Primary Publisher (principal)
  • Secondary subscriber
  • Witness Server is optional but as it provides automatic¬†fail-over¬†it’s worth considering.
  • High-Safety Mode (Synchronous)

It is important that:

  • Primary, Mirror and witness have the same version of SQL Server
  • Primary & Mirror must be running the same edition, so the witness can be different if you so wish.
  • It is not required for you to have the same instance name between the Primary & Mirror but it is recommended for ease of administration.

SQL Mirroring Planned Fail over: (or/ no witness)

First of all lets find out the current state of the mirror by running these two commands:

Get-CsDatabaseMirrorState -PoolFQDN <InsertPoolFQDNhere> -DatabaseType User
Get-CsDatabaseMirrorState -PoolFQDN <InsertPoolFQDNhere> -DatabaseType CMS

Then we need to invoke the fail-over by running the following two commands:

Invoke-CsDatabaseFailover -PoolFQDN <InsertPoolFQDNhere> -DatabaseType User -NewPrincipal mirror -Verbose
Invoke-CsDatabaseFailover -PoolFQDN <InsertPoolFQDNhere> -DatabaseType CMS -NewPrincipal mirror -Verbose

If you had a witness server then this would be done automatically, although it’s good to keep it in mind as you might want to test fail-over.

The user experience during a Back End Failure is anticipated to be as follows:

  • If you use a SQL Witness Server then Little to No¬†Interruption
  • If you do not use a SQL Witness Server then it resiliency mode is invoked and it will await IT Administrator completes manual fail-over.
  • If both the principal and mirror Back End Servers fail then again interruption will be¬†experience¬†until IT Administrator completes manual¬†fail-over/recovery.

I hope this helps, if you have any further questions please feel free to ask.



Comments (0)

Skip to main content