0
28. Oktober 2016

System Center 2016 Blogpostreihe – Teil 1: Operations Manager

Haben Sie sich System Center 2016 schon angeschaut? Sind Sie schon in die Planung eines Upgrades eingestiegen? Lesen Sie in dieser Blogpostreihe, was bei einem Upgrade alles schief laufen kann und wie Sie die Probleme lösen können. Heute geht es um das Upgrade des Operations Manager.


In dieser Blogpostreihe möchte ich über meine Erfahrungen bei meinen ersten Schritten mit System Center 2016 berichten. Ich werde jeweils kurz meine Ausgangssituation beschreiben und dann auf meine Erkenntnisse, aufgetretene Probleme und deren Lösungen eingehen. Heute möchte ich mit SCOM 2016 beginnen.

Ausgangssituation

  • Aktuelle SCOM 2012 R2 Umgebung mit einem Server und 12 Agents
  • UR11 ist installiert
  • Managementserver läuft unter Windows 2012 als Hyper-V VM
  • Agents laufen auf Systemen mit Windows Server 2008 R2/2012/2012 R2 und Windows 10 als Hyper-V VMs
  • Als SQL-Instanz verwende ich SQL 2012 ohne Servicepack
  • Funktionierende Anbindung an einen OMS-Workspace ist vorhanden

Zielvorgabe

  • Inplaceupgrade des Managementservers
  • Update aller Agents
  • Alles soll nach dem Upgrade noch funktionieren, bzw. noch besser 😉
  • Einsatz der tollen neuen Features

Vorgehensweise

Hinweis:
Ich möchte an dieser Stelle auf die ausführliche Vorgehensweise zum Upgrade verweisen. Meine verkürzte Beschreibung und hemdsärmelige Herangehensweise sind für eine Lab-Umgebung durchaus OK. Beim Upgrade einer Produktivumgebung sollte aber auf jeden Fall laut Anleitung vorgegangen werden.

Ich habe für die Überwachung des Ugrades den SCOM Upgrade Helper von Wei H Lim verwendet. Dieser ist sehr nützlich, wenn man eine größere SCOM-Umgebung upgraded. Über die einfachen, aber effektiven Dashboards behält man leicht den Überblick.

SCOM Upgrade Helper von Wei H Lim
Dashboards des SCOM Upgrade Helper

Upgrade des Managementserver

Nach dem Start der Setup.exe beschwerte sich das Setupprogramm zunächst, dass meine SQL Version nicht kompatibel sei und Windows Server 2012 nicht unterstützt werde. Die Systemvoraussetzungen können hier nachgelesen werden. Also habe ich SP3 für SQL 2012 installiert und ein Upgrade auf Windows Server 2016 gemacht. Beides verlief problemlos. Danach habe ich das Setup noch einmal gestartet. Nun fehlte lediglich noch die 2015er Version des Reportviewers. Diesen und die SQLSysClrTypes-2014-SP1 also fix installiert und die Prerequisites Checks noch einmal durchführen lassen. Voila, alles OK und das Upgrade lief dann ohne Fehler durch.
Ein Aufruf der SCOM Konsole und Klick auf die Computer View quittierte SCOM mit einem Crash der Konsole. Dies ist ein bekanntes Problem. Ich wusste schon davon, weil meine Kollegen das Problem bei Kunden mit SCOM 2012 R2 auf Windows Server 2012 R2 schon hatten. Allerdings war mir nicht bewusst, dass es auch SCOM 2016 und Windows Server 2016 betrifft und es für die anderen OS-Versionen schon einen Hotfix gibt.
OK, ich hatte ja auf Windows Server 2016 upgegraded und auch die aktuellsten Updates installiert. Bei den im Blogpost verlinken Hotfixes ist bisher leider keiner für Windows Server 2016 dabei. Also habe ich das Update KB3194798 deinstalliert, den Server neu gestartet und die Konsole ging wieder.

Update 29.10.2016:
Es gibt nun auch einen Hotfix für Windows Server 2016. Ich habe diesen installiert und die Konsole funktioniert einwandfrei.

Update 18.11.2016:
Nach dem Upgrade des Managementservers muss noch einmal der Lizenzkey über eine Operations Manager Shell eingespielt und danach die beiden Dienste „System Center Management Configuration“ und „System Center Data Access Service“ neu gestartet werden.

Dies erfolgt mit folgenden Befehlszeilen in einer Operations Manager Shell:


Set-SCOMLicense -ProductId "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
stop-service cshost
stop-service OMSDK
start-service OMSDK
start-service cshost

Upgrade der Agents

Danach habe ich das Upgrade der Agents über die SCOM-Konsole durchgeführt. Diese liefen auch alle ohne Fehler durch. Ein Agent war noch manuell installiert gewesen. Also habe ich diesen manuell upgegraded und damit waren alle Agents up to date – wirklich? Ein Blick in das Dashboard des SCOM Upgrade Helpers zeigte für ein System eine kleinere Versionsnummer 8.0.10900.0 als alle anderen 8.0.10918.0. Die Ursache war schnell geklärt. Ich hatte vor ein paar Wochen auf diesem System den OMS-MMA installiert. Die Version von SCOM 2016 war noch einmal neuer. Ein manuelles Upgrade des Agents war allerdings hier nicht möglich. Ich musste den Agent deinstallieren und dann den SCOM 2016 Agent installieren. Danach waren alle Agents auf dem gleichen Stand. Ich habe dann noch geprüft, ob es einen neueren OMS-MMA gibt und tatsächlich, über meinen OMS Workspace konnte ich die Version 8.0.11030.0 herunterladen und damit das Upgrade des SCOM 2016 Agents durchführen. Der Agent lieferte weiterhin Informationen an den SCOM. Die Kompatibilität ist also auch hier gewährleistet. Die restlichen Agents blieben auf der Version 8.0.10918.0.
Damit war das Upgrade grundsätzlich durch.

Prüfung Funktionalität und Ausprobieren der neuen Features

Nun wollte ich gleich die neuen Features ausprobieren. Die Maintenance Schedules finde ich sehr interessant. Damit lassen sich wiederkehrende Schedules definieren, und Gruppen von Systemen in den Maintenancemode setzen. Als ich die View angeklickt habe, gab es gleich einen Fehler:
„The EXECUTE permission was denied on the object ‘sp_help_jobactivity, database ‘msdn’, schema ‘dbo’“
Schnell fand ich mit diesem diesen Blogpost einen Lösungsansatz und setze die Rechte für den Account „NT AUTHORITY\SYSTEM“ (SCOM läuft bei mir unter Localsystem). Danach klappt es auch mit der View für die Maintenenance Schedules. Allerdings kam es dann beim Anlegen eines Schedules zu diesem Fehler:

Fehlermeldung Maintenanceschedules
Fehlermeldung Maintenanceschedules

Im Eventlog fand ich detaillierte Infos:

Fehler Eventlog Maintenanceschedules
Fehler Eventlog Maintenanceschedules

Also habe ich die Query von oben noch einmal für das Objekt „sp_add_job“ laufen lassen. Danach ging es aber immer noch nicht. Die Konsole hing sich beim Abspeichern eines neuen Maintenanceschedules auf und musste über den Taskmanager beendet werden. Ich habe dem Account dann SQL-SYSAdmin Rechte gegeben. Damit ging es, aber natürlich ist es unschön, solch hohe Rechte zu vergeben. Später fand dann diesen Blogpost von Kevin Holman. Nach diesen Anpassungen funktionierten die Maintenanceschedules dann auch ohne SQL-SYSAdmin Rechte.

Dann fiel mir auf, dass ich seit dem Upgrade Alert-Mails von meiner OMS-Subscription bekam. Dort hatte ich einen Alert eingerichtet, der mich alarmiert, wenn ein SCOM/OMS-Agent nicht mehr funktioniert, also keine Heartbeats mehr sendet. Das System, welches er alarmierte war der SCOM selbst. Alle anderen Agents sendeten noch Heartbeats an OMS, allerdings auch nicht mehr über den Connect der SCOM-Managementgroup, sondern nur noch direkt. Details zum OMS-Heartbeatfeature, wie ein Alert für fehlerhafte Agents eingerichtet werden kann und wie die Agents mit OMS kommunizieren sind hier zu finden:

Lange habe ich nach der Lösung gesucht. Im Eventlog gab es Fehler in Bezug auf OMS. Aber ich fand keine Hinweise im Internet zu einer Lösung. Ich habe meine Firewall geprüft, die OMS-Subscription mehrmals neu konfiguriert, und versucht mit dem SCOM-Tracing eine Ursache zu finden – auch ohne Erfolg. Die Lösung war am Ende einfach. Zwei Schritte waren dazu notwendig: Ich musste den SCOM Server aus der SCOM-Gruppe entfernen, welche ich in der Konfiguration der OMS-Anbindung angegeben hatte und wieder neu hinzufügen. Der zweite Schritt war, diese Gruppe aus der Konfiguration der OMS-Anbindung zu entfernen und wieder neu aufzunehmen. Danach schickte der SCOM wieder Daten an OMS.

Im Verlauf des Troubleshootings habe ich noch das UR1 für SCOM 2016 installiert und auf alle Agents verteilt. Allerdings löste dieses bei mir keines der Probleme. Es ist trotzdem wichtig zu wissen, dass das UR1 gleichzeitig mit der GA von SCOM 2016 und weiteren System Center 2016 Komponenten veröffentlicht wurde und laut Microsoft zwingend mit zu installieren ist. SCOM 2016 ohne UR1 ist somit nicht für den produktiven Einsatz geeignet.

Interessant ist, dass der KB-Artikel zum UR1 keinerlei Hinweise gibt, was in dem UR gefixed ist bzw. was an neuen Features damit kommt. Eine Antwort auf die Frage „Warum?“ gibt Kevin Holman in seinem Blogpost mit der genauen Vorgehensweise zur Installation des UR1 für SCOM 2016. Er begründet es damit, dass das UR1 mit der GA von SCOM 2016 herauskam und SCOM 2016 ohne UR1 gar nicht betrieben werden soll.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.