Lync CU database update error: ERROR_RESTRICT_DATABASE_ACCESS (English version)
Starting with CU3 and together with the Lync 2010 functionality enhancements for autodiscover and Lync mobility services coming with CU4 the update process included larger modifications of the Lync database schema. Since then the database update is listed as a necessary step in the release notes. This is for purpose because of smaller tweaks that come from time to time. It looks like there have also been some in the CU released in April 2014.
A few weeks ago being online in the evening I received an IM, because there was a problem during the update. So I started the troubleshooting. The DB update script threw an error. Looking into the log files we saw the details:
Running script: C:\Windows\system32\cscript.exe //Nologo "C:\Program Files\Common Files\Microsoft Lync Server 2010\DbSetup\DbSetup.wsf" /sqlserver:sqlserver.fqdn\SQL-Instanz /serveracct:AD-Servergruppe /adminacct:AD-Accounts-Gruppe /roacct:AD-RO-Admins /role:se /verbose
---------------
Installed SQL Server 2005 Backward Compatibility version is 8.05.2312
Connecting to SQL Server on sqlserver.fqdn\SQL-Instanz
SqlMajorVersion : 10
SqlMinorVersion : 50
SqlBuildNo : 1600
SQL version is acceptable: 10.50.1600.1
Default database data file path is N:\MSSQL10_50.Instanz\MSSQL\Data
Default database data file path is N:\MSSQL10_50.Instanz\MSSQL\Data
Default database log file path is N:\MSSQL10_50.Instanz\MSSQL\Data
Opened database rtc
Opened database rtcdyn
Error executing alter database [rtcdyn] set restricted_user with rollback immediate
---------------
Exit code: ERROR_RESTRICT_DATABASE_ACCESS (-21)
---------------
So, what does THAT means?
The output is in a bad format. What it actually means is that there was an error during the execution of the SQL command “alter database [rtcdyn] set restricted_user with rollback immediate", the attempt to set the database to Restricted User Mode. Having a look at the status of the SQL instance in the SQL Server Management Studio (SSMS) it was easy to see that the DB rtcdyn was really in Single User Modus and access to the database was not possible here as well.
In Single_User Mode only one user can access the DB, in Restricted_User Mode db_owner, dbcreator, or sysadmin and Multi_User Mode is the standard mode, in which one will run the DB normally.
What had happened?
The scripts set the DB to the necessary mode depending on the changes that will be made. For example the DB rtcdyn gets deleted and recreated. Doing that you do not want any other connection to the DB during that time, so he script will switch it to Single User Mode. There are other changes where the authors tend to switch even to Restricted User Mode. The database will only be touched if the database schema is not up to date. Amongst other resources you can refer to http://waveformation.com/2012/03/06/lync-server-2010-database-updates-explained-part-2/ for details.
The solution
So far so good. On doing my research I also stumbled across http://exchangeserverinfo.net/2014/03/lync-database-update-fails-error_restrict_database_access/ that lists some general causes, but none of them applied to us.
In the final analysis the answer is quite obvious. If one stuck to the procedure documented in TechNet one will probably not run into this problem. But if the Lync frontend services are running while you try to get hands on the DB this error might occur. One of the servers might got hold of the single user access and the updates session cannot connect to the DB. So, I made sure that all services that normally connect to the DB were stopped and then successfully ran the DB update again. Obviously, a mistake had slipped in our own procedures. Why we never had issues with previous updates stays a secret, probably the DB had not been set to Single User Mode for those changes or there was simply nothing to do at all because that DB schema did not change, who knows?
So keep in mind that before you update the Lync databases make a maintenance window (like you do for all the other stuff :-) ), stop the frontend services with the Stop-CSWindowsService PS-command and restart them (Start-CSWindowsService) after your successful DB update If you stick to the procedure it will normally run without error.
Teile diesen Artikel mit Deinen Freunden, Kollegen und Bekannten:
Leave a comment