Ab dem CU3 und auch noch mal mit der Funktionserweiterung von Lync 2010 um Autodiscover und die Lync Mobility Services mit CU4 gab es größere Update des Lync Datenbankschemas. Seitdem steht das Ausführen des Datenbank-Updates immer in den Release Notes als auszuführender Schritt. Mit Recht, denn ab und zu werden doch mal wieder Kleinigkeiten angepasst. So offensichtlich auch mit dem CU vom April 2014.

Neulich bekam ich während des Wartungsfenster für das Lync Cumulative Update eine IM, weil es Problem gab. Also ging es an die Fehlersuche. Das DB-Updateskript hatte einen Fehler geschmissen. Ein Blick ins Log-File offenbarte die 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)
---------------


Was heißt das?
Die Ausgabe ist schlecht formatiert. Gemeint ist, dass es ein Fehler beim Ausführen des SQL Kommandos “alter database [rtcdyn] set restricted_user with rollback immediate” gab, also dem Versuch, die Datenbank in den Restricted User Modus zu setzen. Ein Blick auf die SQL Instanz im SQL Server Management Studio (SSMS) zeigte, dass sich die DB rtcdyn tatsächlich im Single User Modus befand und ein Zugriff auch hier nicht möglich war.

Im Single_User Modus kann nur ein einziger User auf die DB zugreifen, im Restricted_User Modus nur db_owner, dbcreator, or sysadmin und der Multi_User Modus in der Standard Modus, in dem man eine DB im Normalzustand normalerweise haben will.

Was war also passiert?
Die Skripte setzen die DB abhängig von den durchzuführenden Aktionen in den gewünschten Modus. Beispielsweise wird während des Updates die rtcdyn Datenbank gelöscht und neu angelegt. Dazu wird in den Single User Mode geschaltet, um sicherzustellen, dass kein weiterer User Zugriff auf die DB bekommt, für sonstige Änderungen wird auch gerne mal in den Restricted Mode gewechselt. Es wird natürlich nur dann etwas getan, wenn auf das Datenbankschema nicht aktuell ist. Nachzulesen unter anderem unter http://waveformation.com/2012/03/06/lync-server-2010-database-updates-explained-part-2/

Die Lösung
Soweit so gut. Auf der Suche stolperte ich noch über http://exchangeserverinfo.net/2014/03/lync-database-update-fails-error_restrict_database_access/, wo ein paar generelle Ursachen gelistet sind, aber auch bei uns traf nichts davon zu.

Letztlich ist des Rätsels Lösung einfach. Hat man sich an die im TechNet dokumentierte Vorgehensweise gehalten, bekommt man wohl auch kein Problem. Laufen aber die Lync Services auf den Frontend-Servern noch wenn man die DB anfasst, kann es zum beschriebenen Problem kommen. Dann hat sich einer der Server den Single User Zugriff unter den Nagel gerissen und die Update Session kommt nicht mehr an die DB. Also, flugs die Services gestoppt und das DB-Update erneut angeschmissen und alles wurde gut. In unseren eigenen Update-Ablauf hatte sich offensichtlich ein Fehler eingeschlichen. Warum das bisher nie zum Problem geworden war bleibt ein Rätsel, evtl. wurde die DB vorher bei Updates nie in den Single User Modus gesetzt oder es gab einfach nichts entsprechend zu tun, weil sich am DB-Schema nichts geändert hatte.

Merke: Vor einem Update der Lync Datenbanken ein Wartungsfenster einrichten, mit Stop-CSWindowsService auf den Frontend-Servern die Dienste stoppen und nach erfolgreichem DB-Update die Dienste wieder starten. Dann klappt es im Normalfall auch ohne Fehler.