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.

1. Launching SQL 2014 PowerShell
   I 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
   
   Or, in SQL Management Studio, right click and choose "Start PowerShell"
   
   Either option will launch the same process, and you will see then that the modules specified are loaded.
   
   
   
2.  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.
   
   
   This one was more due to it having been a while working on Cluster Name Objects (CNOs) - the issue is that the SQLCluster doesn't have permissions to the Computers CN in Active Directory, so you need to either add permissions, or pre-stage the computer object.
   
3. Adding permissions on the second SQL node in the AlwaysOn Cluster
   
   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.

Hope this helps!