In der letzten Woche hatte ich in einer SCOM Umgebung das Problem, dass die SQL-Instanzen eines Clusters von SCOM nicht discovered wurden. Auf anderen Clustern des selben Typs wurden die SQL Instanzen korrekt discovered. Einen Fehler im Eventlog gab es nicht.


Hier kurz die Rahmenparameter:
– SCOM 2012 R2 mit UR7
– SQL MP in der Version 6.6.4.0
– Windows Cluster 2012 mit SQL 2012, 2 Knoten, aktuell gepatcht

Folgendes habe ich während des Troubleshootings geprüft bzw. durchgeführt:

Das Windows Cluster selbst und dessen Resourcen wurden korrekt discovered.
Der Account, welcher im Profil „SQL Server Default Action Account“ unterhalb der RunAs Konfiguration im SCOM hinterlegt war, hatte Rechte auf die SQL-Instanzen (in diesem Falle sogar SYSAdmin).
Testweise wurden die Instanzen auf den anderen Knoten verschoben, was keine Besserung brachte.
Die SCOM-Agents wurden auf den beiden Knoten des Clusters neu installiert, auch dies führte nicht zum Erfolg.
Der Default Action Account der beiden Knoten wurde von Local System auf den Account geändert, welcher schon im Profil „SQL Server Default Action Account“ hinterlegt war, geändert. Auch dies ließ die Instanzen nicht im SCOM ankommen.
Zwischen allen Aktionen ließ ich SCOM ausreichend Zeit, die Instanzen zu discovern.

Nun ja, irgendwann war ich dann mal wieder auf den Knoten und habe der folgenden Meldung im Servermanager meine Aufmerksamkeit geschenkt. Ich muss gestehen, sie war mir während des Troubleshootings schon früher aufgefallen. Aber wie das so ist, habe ich die Meldung erst einmal ignoriert. Das war ein Fehler.

SCOM1

Der Servermanager meldet hier 2 Server, welche nicht erreicht werden können. Ich habe die beiden dann mit Rechtsklick und „Remove Server“ entfernt. Nach einem Refresh waren sie aber wieder da. Eine Recherche nach den Namen ergab, dass es sich um zwei alte SQL-Clusterinstanzen handelte, welche vor einiger Zeit deinstalliert wurden. Ein Blick in den Failover Clustermanager bestätigte aber, dass diese nicht mehr da waren.
Was tut man, wenn es mit der schönen, bunten Windows GUI nicht so klappt? Klar, man geht mit der PowerShell an das Problem heran. Mit dem Befehl

[code lang=“powershell“]Get-Clusterresource[/code]

erhielt ich eine Liste aller Clusterresorcen, und siehe da, hier wurden tatsächlich 4 Clusterresourcen der beiden deinstallierten Instanzen angezeigt, alle 4 Offline. Es handelte sich um den SQL Network Name und die File Server Resource. Scheinbar ging hier beim Rückbau etwas schief.

SCOM222

Mit dem Befehl

[code lang=“powershell“]Get-Clusterresource -Name <Name der Resource> | Remove-Clusterresource[/code]

habe ich dann die 4 Resourcen gelöscht. Ein Refresh im Server Manager bestätigte die korrekte Bereinigung. Und was machte SCOM? Der discoverte danach ganz artig die Instanzen und DBs.

Weiteres