After deploying CU4 I attempt to run the Install-CSDatabase -Update and receive error :

Install-CsDatabase :
Command execution failed: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

I suspect I have a permissions problem related to the SQL databases. 

Can someone clairfy exact permision I need on the SQL server/database in order to perform this funtion. Do they need to be exactly the same as if I were creating the database new?  I don't manage the SQL servers so will need an very specific set of requirements to present to them in order to request the accesss.

As well, we have a pool of 6 Front end servers and 2 directors, should these servers (services and W3svc) be stopped during this process?

Hi Steve,

The account you're using to run the cmdlet will need to dbowner rights on the back-end Lync databases.

Hi,

You must be a member of the domain, a member of the RTCUniversalReadOnlyAdmins group, a SQL Server administrator, and a local administrator on the computer where SQL Server is installed in order to run the Install-CsDatabase cmdlet locally.

Thanks all, it appears the local admin on the SQL server was the hang up.  our SQL guys are pretty tight with their rights so I suspect when it comes to the SQL server, the assumed standard rights of the RTC groups are not always accurate in our case.

Thanks again,

Steve

Just got bitten by another possible cause of these errors: database locations. THe error messages all looked like we were missing specific permissions in SQL.

In our case the SQL Default database location had been changed after the Lync databases were installed. Ended up solving the problem by using the -UseDefaultSqlPaths switch with Install-CsDatabase cmdlet and it worked fine. Turned out it was trying to create a new database in the new default location and it had not deleted the original.

Ultimately the databases and default locations will be realigned. Ironically the -UseDefaultSqlPaths switch allows SQL to work out the correct location of the databases, and does not force databases to live in the default database path for that SQL Instance. In our case it detected, deleted and recreated the Lync database in its original location.