Today installing Skype for Business Enterprise Edition, I came across an interesting error. For the backend SQL server I was using SQL clustering farm. To install the databases to a clustered instance, you need to perform this manually using Install-CsDatabase command.
I wasn’t able to run the parameter -ConfiguredDatabases and receiving a name not found error in the create-backend-server log on the front end. However, I was able to install manually the individual databases using the -DatabaseType parameter.
The problem was I was unable to install the RTCXDS database to the backend server, the process would simply time out.
I already had the correct permission to the SQL instance as I was able to install the other databases, so it could not be that. One thing I noticed was that the model database on the Instance was configured for non-standard growth and initial size, presumably configured by a DBA. I performed a shrink on the model database and reverted the growth to the default allow autogrowth by 10%. However, after restarting the instance, the problem was still around.
Naturally I turned to Google (other search engines are available). It is worth noting I am installing Skype for Business on a dedicated apps drive on RAID10 local storage. I found a post that recommended checking folder permissions on the apps drive and CsData folder, adding in CREATOR OWNER to the drive permissions and NETWORK SERVICE to the CsData folder. However, this did not resolve the issue.
Finally, I decided to run the install databases process via the topology builder. This seemed to provide an additional log file in %Temp% directory, create-backend-server.xxxx.xxxx.log
In this log is showed the problem. The problem was that the data drive used within the cluster did not have sufficient free disk space to expand the RTCXDS file to the start size of 4GB.
Simple fix in the end, expand the storage to accommodate this size, I recommend at least 50GB free for the data / log drives for expansion. Once the drive was expanded I was able to install the database using PowerShell.
OK, this is a simple issue, but it caught me out due to the way the customer configured the mount points within the cluster for the data drive, being mounted via NTFS folder. Worth keeping that in mind for the odd time you may come across this issue.