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:
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