WSUS: SUSDB-Datenbank reparieren

Windows Server 2012 - Update Services (WSUS)

Die WSUS-Verwaltungskonsole meldete lediglich einen Verbindungsfehler. In Wahrheit war aber die SUSDB-Datenbank defekt.

 

Fehlersuche

Die WSUS-Verwaltungskonsole präsentierte einen sehr allgemeinen Verbindungsfehler:

WSUS Verbindungsfehler

Da weder WSUS-Dienst-Neustart noch Serverneustart etwas daran änderten, setzte ich meine Recherche in der Windowsereignisanzeige fort. Der dazugehörige Eintrag war zwar etwas ausführlicher, aber auch keine besonders große Hilfe:

Erst die WSUS-Warnung deutete auf vielleicht auf ein Datenbankproblem hin:

Quelle: Windows Server Update Services
Ereignis-ID: 7032
Ebene: Warnung

“Die WSUS-Verwaltungskonsole konnte über die Remote-API keine Verbindung mit dem WSUS-Server herstellen.

Stellen Sie sicher, dass der Update Services-Dienst, IIS und SQL auf dem Server ausgeführt werden…”

 

Die MSSQL-Fehler waren schnell gefunden:

Quelle: MSSQL$MICROSOFT##WID
Ereignis-ID: 3414
Ebene: Fehler

“Fehler bei der Wiederherstellung. Die SUSDB-Datenbank (5:0) kann daher nicht neu gestartet werden…”

 

Quelle: MSSQL$MICROSOFT##WID
Ereignis-ID: 9004
Ebene: Fehler

“Fehler beim Verarbeiten des Protokolls für die SUSDB-Datenbank. Führen Sie nach Möglichkeit eine Wiederherstellung der Sicherung aus…”

 

Quelle: MSSQL$MICROSOFT##WID
Ereignis-ID: 5601
Ebene: Fehler

“Für den Diensthauptschlüssel war die mit der Startoption ‘-F’ angeforderte erzwungene Neugenerierung nicht möglich. Fehlernummer 33094.”

 

Reparatur

Achtung: Die folgende Datenbank-Reparatur kann die Datenbank auch vollständig zerstören!

  • WSUS-Windowsdienst beenden
  • SQL Server Management Studio am WSUS-Server installieren
  • SQL Server Management Studio starten und je nach Windows Server den passenden Servernamen eingeben:
    • WS2016/WS2019: \\.\pipe\MICROSOFT##WID\tsql\query
    • WS2012/WS2012R2: \\.\pipe\MICROSOFT##WID\tsql\query
    • WS2003/WS2008/WS2008R2: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
  • SUSDB sollte mit “(Suspect)” gekennzeichnet sein:
  • New Query öffnen und folgende Befehle ausführen:
    EXEC sp_resetstatus SUSDB;
    ALTER DATABASE SUSDB SET EMERGENCY
    DBCC checkdb(SUSDB)
    ALTER DATABASE SUSDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    DBCC CheckDB (SUSDB, REPAIR_ALLOW_DATA_LOSS)
    ALTER DATABASE SUSDB SET MULTI_USER
  • Nach einer Aktualisierung der Ansicht oder nach einem Neustart des SQL Server Management Studios, sollte das “(Suspect)” verschwunden sein und ein Zugriff möglich sein:
  • Das SQL Server Management Studio kann geschlossen werden.
  • Der WSUS-Windowsdienst kann wieder gestartet werden.
  • Die WSUS-Verwaltungskonsole und der WSUS selbst, sollten wieder ordnungsgemäß funktionieren.

 

Quellen: iconraja.wordpress.com, Microsoft.com