Creating or migrating the CMS of a SQL 2014 Always on Availability Group for Skype for Business 2015
I think one you get done with your deployment, you get to sit back and Enjoy the Honey of your Efforts. But If you are Migrating a SQL Always On Availability Group, See Below for some steps!
Basic Bullets steps
- Review Prerequisites
- Don’t try this on Lync 2013. This must be done using A fully patched SFB Fe Servers, as well as Fully Patched Server 2012 R2 Machine.
- So point # 2 is the reason for this article. The word is, Lync 2013 is not supported, but it works. Below you may see the gotcha, and be able to set it up.
- Install the Clustering Role on both SQL Servrs with Add-WindowsFeature Net-Framework-Core, Failover-Clustering, RSAT-Clustering-Mgmt,RSAT-Clustering-PowerShell -Source d:\sources\sxs
- Do not try to use SQL 2016. Only use SQL 2014 with SFB 2015 and Server 2012 R2-
- Test-Cluster -Node SQL1, SQL2 and make sure you have pre-requisites correct.
Follow the documentation of your choice to install your Skype for Business on SQL, but please review the notes from my friend in the Field, Timothy E Boudin. His notes may come in helpful, if you’re facing the move, and see no documentation. This is what he ran across, and brought to me. Thank you to Tim , for bringing this issue up so I could write about it:
First Find your Links for the Job
So to summarize, you should basically move the CMS when you do the SQL always on Availability group in my opinion. Otherwise, you are going to have to come back later, and do the second part of this cold. This is just an opinion. Below, Please Find Tim’s, Comments on his Move of the CMS with SQL Always on and Lync 2013, and SFB 2015 Migration.
Skype for Business setup using SQL always on Clustering
This configuration requires some unique settings for the build of the Skype for Business (SFB) support when dealing with the issue of supporting the CMS migration from Lync 2013 or previous versions to SFB 2015.
For this discussion the servers are as follows
Enterprise Front End Servers (3)
FE1, FE2, FE3
Always on SQL Cluster servers (2)
SQLNode1, SQLNode2, SQL Listener
During the process of defining a new Enterprise Front End pool, you provide the names of the Servers that are members of the pool as normal, but when providing the new Back end servers information you have to handle this in a specific way to be able to support fail-over.
Create the new SQL Server Store as follows
Fill in the name of the SQL Listener in the SQL Server FQDN field
Provide the name of the SQL Instance if your using one.
Check the High Availability Settings option
Select SQL Always-on Availability Groups
Fill in the name of the SQL Node1 server
Click OK and complete the Front End pool Wizard. When you Publish the changes to topology you should be prompted to provide details on how you want to establish the tables for the Cluster. If this is setup by a DBA check with them on location of the Data and Log files.
Once publishing is completed, go back and edit the SQL Store settings and change the SQLNode1 setting to SQLNode2 server name.
Publish the change and then do an Install or upgrade a Database
Once publishing is completed, go back and edit the SQL Store settings and change the SQLNode1 setting to the SQL Listener server name. Now publish a finial time. There is no need to do an Install Database for this change.
Once the finial publish is complete you should be able to start services on the Front End Pool servers.
Move the CMS
To move the CMS from the previous location to the Front End pool using the Always-on Cluster use the following process.
- Stop Services on the Front End Pool to be hosting the new CMS location
- Open the Lync Power-Shell and use the following commands:
- Backup the CMS to a file with the following
Export-CsConfiguration –filename c:\media\cmsbackup.zip
Create the new Tables for the CMS on the new Front End pool specifying the node1 of the cluster, when you specify the database paths they are listed by Log file location first and then by Data file location.
Install-CsDatabase –CentralManagementDatabase –SQLServerFQDN SQLNode1.contoso.com -databasepaths g:\RTC_logs,f:\RTC_data -sqlinstancename RTC –verbose
Once the tables have been created, have the DBA verify Mirroring between the nodes is in place.
If replication is good then move the CMS to new server by using the Move command on the Front end server in the target pool.
Once the move is complete, allow for server replication and then Run local Setup in the deployment wizard on all affected Front end servers and reboot them and Monitor replication
I hope this is helpful Documentation, if you have to face this situation.