Active Directory, Exchange, Windows, Lync, Skype for Business and Office 365 how-to's and tips and tricks as we pick them up. Feel free to pass on anything you see here, and PLEASE subscribe to our RSS feed, and leave comments if you find our posts helpful!

Thursday, June 04, 2015

SQL 2014 AlwaysOn Deployment for Skype for Business Server 2015

Ran through this in production for the first time using the excellent TechNet blog here.Not going to reiterate much of that blog as it is fairly complete, but I hit a few errors along the way that I want to share.

Launching SQL 2014 PowerShellI searched a while for this. Unlike Lync, AD and other PowerShell, there isn't really an import-module sqlps, even though several articles state similar.

To Launch Powershell, you can either make a shortcut (YMMV on path) to:c:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\sqlps.exe

Either option will launch the same process, and you will see then that the modules specified are loaded.

Creating the Availability Group Listener

When creating the Availability listener, I was receiving this error:The WSFC cluster could not bring the Network Name resource with DNS name '<DNS name>'
online. The DNS name may have been taken or have a conflict with
existing name services, or the WSFC cluster service may not be running
or may be inaccessible. Use a different DNS name to resolve name
conflicts, or check the WSFC cluster log for more information.

Within the last section of the linked blog on Technet, they state to run the install-CsDatabase cmdlet with the -update flag. I did this repeatedly and was not seeing any updates applied, nor the permissions being added in SQL Management Studio. After asking some colleagues, Someone recommended running S4B PowerShell as an Administrator. Did this, reran the command and in made all the changes as expected.

Other than the above items, their article is VERY solid. The scripting to do the SQL changes worked perfect and as expected, make sure to edit for your server and instance name! Also, the xCopy steps are a little tedious, if you instead plan on all your databases and logs being in similar directories, you just need to ensure those paths exist on both SQL servers.