![\"SCOM1\"](\"https:\/\/www.dataone.de\/wp-content\/uploads\/SCOM\/.j\/SCOM1.jpg\")
<\/p>\nIn 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.<\/p>\n
<\/p>\n
Hier kurz die Rahmenparameter:
\n– SCOM 2012 R2 mit UR7
\n– SQL MP in der Version 6.6.4.0
\n– Windows Cluster 2012 mit SQL 2012, 2 Knoten, aktuell gepatcht<\/p>\n
Folgendes habe ich w\u00e4hrend des Troubleshootings gepr\u00fcft bzw. durchgef\u00fchrt:<\/p>\n
Das Windows Cluster selbst und dessen Resourcen wurden korrekt discovered.
\nDer Account, welcher im Profil \u201eSQL Server Default Action Account\u201c unterhalb der RunAs Konfiguration im SCOM hinterlegt war, hatte Rechte auf die SQL-Instanzen (in diesem Falle sogar SYSAdmin).
\nTestweise wurden die Instanzen auf den anderen Knoten verschoben, was keine Besserung brachte.
\nDie SCOM-Agents wurden auf den beiden Knoten des Clusters neu installiert, auch dies f\u00fchrte nicht zum Erfolg.
\nDer Default Action Account der beiden Knoten wurde von Local System auf den Account ge\u00e4ndert, welcher schon im Profil \u201eSQL Server Default Action Account\u201c hinterlegt war, ge\u00e4ndert. Auch dies lie\u00df die Instanzen nicht im SCOM ankommen.
\nZwischen allen Aktionen lie\u00df ich SCOM ausreichend Zeit, die Instanzen zu discovern.<\/p>\n
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\u00e4hrend des Troubleshootings schon fr\u00fcher aufgefallen. Aber wie das so ist, habe ich die Meldung erst einmal ignoriert. Das war ein Fehler.<\/p>\n
<\/p>\n
Der Servermanager meldet hier 2 Server, welche nicht erreicht werden k\u00f6nnen. Ich habe die beiden dann mit Rechtsklick und \u201eRemove Server\u201c 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\u00e4tigte aber, dass diese nicht mehr da waren.
\nWas tut man, wenn es mit der sch\u00f6nen, bunten Windows GUI nicht so klappt? Klar, man geht mit der PowerShell an das Problem heran. Mit dem Befehl<\/p>\n
[code lang=”powershell”]Get-Clusterresource[\/code]<\/p>\n
erhielt ich eine Liste aller Clusterresorcen, und siehe da, hier wurden tats\u00e4chlich 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\u00fcckbau etwas schief.<\/p>\n
![\"SCOM2\"](\"https:\/\/www.dataone.de\/wp-content\/uploads\/SCOM\/.j\/SCOM2.jpg\")
22<\/p>\n
Mit dem Befehl<\/p>\n
[code lang=”powershell”]Get-Clusterresource -Name <Name der Resource> | Remove-Clusterresource[\/code]<\/p>\n
habe ich dann die 4 Resourcen gel\u00f6scht. Ein Refresh im Server Manager best\u00e4tigte die korrekte Bereinigung. Und was machte SCOM? Der discoverte danach ganz artig die Instanzen und DBs.<\/p>\n","protected":false},"excerpt":{"rendered":"
Microsoft Operations Manager SQL-Clusterinstanzen<\/p>\n","protected":false},"author":8,"featured_media":3468,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_expiration-date-status":"","_expiration-date":0,"_expiration-date-type":"","_expiration-date-categories":[],"_expiration-date-options":[]},"categories":[67],"tags":[72],"yoast_head":"\n