Skype for Business Server 2015 and “Hardened” SQL Server
- Date: May 18, 2016
- Author: Marc Wynter
- Comments: no comments
- Tags: Cloud, Cloud Services, Cloud Solutions, Cloud Support, Cloud Support Services, ConQuest, ConQuest Technology Services, Marc Wynter, Microsoft, Microsoft Gold Partner, Office 365, RTC databases, S4B, SfB, Skype for Business, Skype for Business Server, Skype for Business Server 2015, SQL, Support Serivces
- Categories: Managed Services, Microsoft Technology Solutions
I was deploying a Skype for Business Server 2015 environment for a client today and came across an odd issue. During installation of the databases on the back end SQL server I experienced and error which halted the installation:
Although the user I was running the installation as was a sysadmin and local administrator on this SQL server as required, the installation threw this error. Interestingly enough, re-running the database installation task would actually proceed to the next database in the sequence without erroring out on the previous one but erroring on each successive:
I was actually able to re-run the installation a few times and eventually get to a success state. Knowing the Skype for Business installation process, it occurred to me that although it was successful, the script may have just been checking for the existence of the database and not actually re-attempting to change the DB owner to SA each time I re-ran it.
So I confirmed the DB owner of each database and sure enough, it wasn’t the SA:
Just to be sure, I checked the DBO from my lab deployment to confirm:
So with total transparency, I am NOT a SQL expert. So it wasn’t apparent to me why setting the DBO would fail when the installation account had all the rights it needed. So after doing some research on the issue, I came across this TechNet blog post by Jithendranath Reddy which pointed me in the right direction:
Lync Server 2013 – Installing Lync Database Update Failed with Error “Set owner failed for Database ‘rtcxds’
As it turns out, my client renamed the SA account which is why the installer, which references the account by the default “sa” name, was unable to change the DBO. As the blog post implied, disabling the account is satisfactory but the account must be named “sa” for the installer to work. Unfortunately, there is no documented/supported way to manually specify the SA account name for this procedure. So the workaround of renaming the account back to “sa” will suffice in this scenario. Hopefully this post will save someone else a few minutes of head scratching.