SCOM 2012 R2 Workflows & Kommunikation

Intensivkurs SCOM - Level 4

System Center Operations Manager 2016 / 2019

- für Enterprise Umgebung - SCOM Hybrid mit OMS Gateway - Upgrade auf SCOM 2019 -

Sollte dieser Kurs aufgrund von (zukünftigen) behördlichen Einschränkungen bezüglich COVID-19 nicht mehr vor Ort stattfinden dürfen, behalten wir uns vor diesen automatisch auf LIVE CLASS umzustellen.

In diesem Intensivkurs lernen Sie den Aufbau und die Administration von System Center Operations Manager 2016 in einer ADS-Gesamtstruktur kennen und auch das Upgrade auf SCOM 2019 praktizieren. Mit der 2019 Version wird der zuvor eingeführte SAC 1801/1807 (Semi-Annual Channel) eingestellt. Es gibt ab jetzt nur noch die SCOM 2019.
Ziel des Kurses ist die Überwachung aller Windows Server und evtl. Clients sowie ausgewählter Anwendungen in einer Enterprise Umgebung.

SCOM Hybrid: Um die On-Premises SCOM Fähigkeit in die Azure Cloud zu erweitern (Extended SCOM), zeigen wir SCOM Hybrid um über das OMS Gateway die OMS Log Analytics und Log Search für die SCOM Events zu nutzen und um Alerts zu generieren, die wiederum Workflows (Runbooks - OMS Automation) triggern. Weitere OMS Solution wie Azure Service Map wird genutzt um die Kommunikation zwischen SCOM und OMS graphisch zu zeigen und zu überwachen.

ESAE Security: Neu ist auch die Behandlung der Tier 0 Server wie Domain Controller nach Microsofts ESAE Modell (Enhanced Security Administrative Environment)

ZIELGRUPPE
Das Seminar richtet sich an Systemmanager, Serveradministratoren, Netzwerkmanager und Support-Ingenieure.
Für die Projektmanager mit fundiertem Fachwissen ist dieser Kurs auch zu empfehlen.

NIVEAU
Level 4 — ziemlich anspruchsvoll

DAUER
5 Tage
4 Tage ab 2021

ORT
NT Systems Schulungszentrum Böblingen (Karte)

TERMINE

Live Class
14.12. - 18.12.2020 ✓ noch Plätze frei
02.03. - 05.03.2021 ✓ noch Plätze frei
 
Präsent (vor Ort)
21.09. - 25.09.2020 ✓ Geschlossen
15.06. - 18.06.2021 ✓ noch Plätze frei

Zur Anmeldung

PREIS
3.750,- € zzgl. Mwst.
Kursbesuch nur gegen Vorkasse möglich!

MINDEST-TEILNEHMERZAHL
Das Seminar findet ab einer Mindestzahl von drei Teilnehmern garantiert statt.

SCHULUNGSZEITEN
Am ersten Tag:   09:00 - 17:00 Uhr
An Folgetagen:   08:30 - 17:00 Uhr
Am letzten Tag:   08:30 - 13:00 Uhr

ZERTIFIKAT
Nach erfolgreicher Teilnahme erhalten die Kursteilnehmer ein Zertifikat von NT Systems.

AUSFÜHRLICHE INFORMATIONEN

Im Folgenden finden besonders interessierte Leser ausführliche Informationen zu den im Kurs behandelten Themen.

Alert Data Management (ab 2016): Mit diesem neuen Feature hat man nun die Möglichkeit, die Alerts schnell zu anlysieren. D.h. von welchem MPack, Monitor oder Rules bzw. Target kommen die Alerts.

Management Pack Updates & Recommendations (ab 2016): SCOM ist in der Lage, die notwendigen Management Packs vorzuschlagen, wenn sie verfügbar sind und benötigt werden. Beispielsweise wird das MP "ServiceManagementAutomation" in der "Updates & Recommendations" vorgeschlagen, weil mindestens auf einem Server SMA (Service Management Automation) installiert ist.

Maintenance Schedules (ab 2016): Endlich kann man nun die Wartungszeit in der Zukunft, also per Zeitplan (Schedule) festlegen. Darüber hinaus ist es möglich, den Maintenance Mode per Filter für bestimmte Classes (Target) bzw. Group zu definieren.

Verbindung mit OMS (Operation Management Suite): Um den Weg in die Cloud nicht zu verschließen, ist es nun möglich, SCOM mit OMS zu verbinden. Microsoft hat mehrere bestehende Cloud Services wie Azure Automation, Log Analytics, Backup & Disaster Recovery und Security & Compliance in OMS integriert. OMS ist besonders interessant für eine Hybrid SCOM Umgebung, wo einige der Agents in der Azure Cloud sind.

Installation: In einer Enterprise Umgebung installiert und verwaltet nicht unbedingt ein Domain-Administrator die SCOM-Umgebung. Im Kurs arbeiten wir mit delegierten Rechten, so wie in einer Enterprise Umgebung i.d.R. auch praktiziert wird. Der SCOMMan (SCOM Manager) ist nur ein normaler Domänenbenutzer. Er ist der Installateur der Management Server und gehört somit zu den SCOM-Administratoren und hat Vollzugriff auf alle SCOM-Objekte. Um jedoch Zugriff auf die remote SQL-Datenbanken zu erhalten und um überhaupt SCOM installieren zu können, muss der SCOMMan die notwendige Berechtigung von den SQL-Administratoren (SQLMan) bekommen.

ESAE: In einer Enterprise Umgebung sollte SCOM in das ESAE Modell überführt werden, um die Sicherheit der Umgebung zu gewährleisten. Durch dieses Modell kann der SCOM Administrator nur in seinem Tier (0,1,2) arbeiten und nicht in ein anderes ausbrechen. Dabei sollte es auch für jedes Tier eine eigene Management Group geben. Ein
Tier 1 SCOM Admin kann somit keine Tier 0 Server (z.B. DCs) überwachen.

Konfiguration: Wenn die Management Group mit mindestens zwei MS (Management Server), OpsDB (Operations Manager DB), DWDB (Operations Manager Data Warehouse) und Report DB installiert ist, werden die "Settings" (Heartbeats, Web Addresses, etc.) besprochen und konfiguriert. Optional kann die ACSDB (Operations Manager Audit Collection Service) installiert und konfiguriert werden. Im Laufe des Kurses werden wir Notification mit E-Mails konfigurieren. Seit SCOM 2019 gibt es bei den Notifications die Möglichkeit, auch andere Verknüpfungen (auch OR) der Kriterien zu erstellen (bisher nur AND).

Administration: Die Methoden zur Agent-Installation u.a. Active Directory Integration werden besprochen und zum Teil praktiziert. Letztendlich wird die Discovery Push Methode i.d.R. bei allen Firmen praktiziert, weil sie doch am einfachsten ist. Dabei werden zwei Accounts benötigt: Scannen von Active Directory und Installation von Agent. Das Agent Action Account (Default ➔ LocalSystem) wird benötigt, damit später diverse Workflows (Monitor, Rules, Tasks etc.) im MonitoringHost.exe Prozess ausgeführt werden können. Auch der HealthService läuft standardmäßig unter LocalSystem. Die SCOM-Workflows benötigen nicht nur LocalSystem für die lokalen Ressourcenzugriffe, sondern je nach Management Pack auch sehr spezielle Berechtigungen, z.B. SQL Server, Data Warehouse etc. Diese Anforderungen (Berechtigungen, Privilegien) der Management Packs werden in "neutralen" Run As Profile (z.B. SQL Server Monitoring) festgelegt, welche dann einem oder mehreren Run As Accounts zugeordnet werden können. Ein Run As Account muss letztendlich mit einem Windows-Konto (Credentials) gemappt werden. Der Vorteil dieses 3-stufigen Berechtigungskonzepts ist, dass auf unterschiedlichen Instanzen auch unterschiedliche Run As Accounts laufen können: Beispielsweise sollen SQL-Instanz1 und SQL-Instanz2 auf demselben Server SQL01 zwei unterschiedliche Run As Accounts und somit zwei Credentials mit unterschiedlichem Login haben. Dieses ziemlich komplexe Themengebiet wird in einem eigenen Modul mit Übungen behandelt.

PowerShell: Seit SCOM 2012 R2 kann man fast alles mit Operations Manager Cmdlet erledigen. Oft kann man mit den Cmdlets viel mehr Informationen erhalten, als es mit der GUI möglich ist. In der Dokumentation wird neben der GUI immer wieder mit PowerShell bzw. OpsMgr Shell gearbeitet.

Authoring: Die Grundlagen zu Monitors, Rules, Tasks, Views, Targets, Groups, Discoveries werden zuerst behandelt. Aber bevor das erste Management Pack für Windows Server 2012 R2 bzw. 2016 installiert wird, befassen wir uns intensiv mit dem Thema Target. Um das Targeting und Discovery zu verstehen, werden wir auch ohne Management Pack unser eigenes Target für "Windows Server 2012 R2 od. 2016 bzw. 2019" selbst definieren. Per Registry oder WMI bzw. Script kann ein gewünschtes Target gefunden und definiert werden. Mit dem eigenen Target und Management Pack fangen wir an, die ersten Monitoren und Rules anzulegen und zu konfigurieren. Die Auswahl der zu überwachenden Server innerhalb des Targets geschieht mit Overrides, die im Kurs ausgiebig praktiziert werden.

Monitoring: Mit Monitoren können nicht nur Alerts angelegt, sondern auch die Health States eines überwachten Objekts angezeigt werden. Die Unit-Monitoren bilden die Grundlage der gesamten Überwachung. Für jeden Monitortyp (Events, Performance, Script, Service) werden wir mindestens eine Übung durchführen. Ein Aggregat-Monitor gruppiert mehrere Monitoren (Unit, Aggregat, Dependency) zusammen, um den Gesamt-Healthzustand zu überwachen. Die Health State Rollup Policy (Worst State oder Best State) legt fest, wann der Gesamtzustand gut oder schlecht ist. Am Beispiel der Core Services vom Domaincontroller studieren wir die Aggregat-Monitoren und deren Rollup Policy. Wenn einer dieser Dienste z.B. NETLOGON Service nicht in Ordnung ist, dann ist der ganze Aggregat Monitor "krank" und somit ist der Domaincontroller auch nicht zu gebrauchen. Ein Dependency Monitor verbindet unabhängige Monitoren zu einer logischen Einheit, die als Gesamtes überwacht werden kann. Diese Monitoren bilden die Grundlage für die Überwachung von Distributed Application (DA), die wir am letzten Tag zusammen mit Service Level Tracking noch praktizieren werden. Monitoren bieten optional Diagnostics & Recoveries Methoden an, um per VB-Script oder PowerShell Aktionen bei einem Alert automatisch auszuführen.

Rules: Mit Alert Rules (Event, Performance, Scripting) können auch Alerts generiert werden, die im Gegensatz zu Monitoren nicht unbedingt mit dem Health State eines Objekts zu tun haben. Mit Collection Rules (Event, Performance) können Daten gesammelt und in die Datenbanken OpsMgr und Data Warehouse gespeichert werden.

Authoring: Nun können die ersten "sealed" Management Packs von Microsoft importiert werden. Mit den Tools MPViewer, Authoring Console (2007 R2) oder Silects "MP Author" können die MPacks analysiert werden. Es ist unabdingbar als SCOM-Administrator das Service Model und das Health Model von SCOM zu verstehen. Die SCOM-Classes (Abstract, Singleton) und deren Vererbung (Inheritance) , die Relationships (Hosting, Containment, Reference) und Discoveries (Registry, WMI, Script, PowerShell) sowie Targets bilden das Service Model. Im Health Model geht es darum, wie der Health State eines Objekts mit Monitoren (Unis, Aggregat, Dependency) überwacht werden kann. Diagnostics & Recoveries sind optionale Aktionen, wenn der Health State wechselt. Darüber hinaus ist unter Presentation möglich, die Ergebnisse einer Überwachung über Views (State, Alert, Event, Task Status, Performance, Diagram, Dash Boards) oder Linked Reports zu verstehen. Mit Views werden Daten von der OpsMgr DB gezeigt, während mit Reports die Daten aus dem Data Warehouse Datenbank präsentiert werden.

Special Monitors: Komplexe Monitoren werden als Management Pack Templates mitgeliefert. Es handelt sich in der Tat in so einem Template nicht nur um Monitoren, sondern auch um Rules, Views, Reports, Tasks, etc. Als Vorbereitung für die Überwachung unserer eigenen 2-Tier Distributed Application (DA) werden wir uns mit den zwei Web Application Transaction Monitoring und Web Application Availability Monitoring befassen. Der Zugriff auf eine Datenbank wird mit dem OLE DB Data Source praktiziert. Weitere Templates sind TCP Port und Process Monitoring.

Distributed Application (DA): Am Ende des Kurses sollten alle Teilnehmer genügend Know-How erworben haben, um nun eine relativ komplexe Überwachung selbst zu konfigurieren. Ziel dieser Übung ist, dass später im Betrieb bestimmte Überwachungsaufgabenstellungen mit dem Wissen vom Kurs durchgeführt werden können. Eine 2-Tier Applikation (Beispiel NTS-CourseRating) mit Web-Frontend (Web Farm) und nachgelagerter SQL-Datenbank soll als eine Einheit (Distributed Application) überwacht werden. Die Kursteilnehmer haben die Möglichkeit, über einen Internet Browser ihre Beurteilung zu den Kursen abzugeben. Die Aufgabe ist, diese 2-Tier Applikation als eine DA mit dem Distributed Application Designer so zu modellieren, dass alle Komponenten der Load-balanced Web-Farm und auch der SQL-Datenbank samt Zugriffe abgebildet werden können. Die Web- und SQL-Komponenten werden in Component Groups (Containment) durch Richtungspfeile (Relationships) verbunden. Die Zugriffe auf die Web-Farm und SQL-Datenbank werden durch Web-Watcher und OLE DB Watcher (Perspective) überwacht. Dabei soll eine Policy für den Health State der gesamten DA entwickelt werden, die bei Problemen ein Warning oder ein Alert (Critical) erzeugt.

Service Level Tracking (SLT): Die eben erstellte Distributed Application "NTS-CourseRating" soll zusätzlich durch ein Service Level Tracking (SLT) überwacht und abgesichert werden, damit ein SLA (Service Level Agreement) garantiert werden kann. Nicht nur SLO (Service Level Objective) für die Verfügbarkeit (Availability), sondern auch für die Performance müssen erstellt und konfiguriert werden. Anhand eines Service Level Dashboards kann beurteilt werden, ob das SLA in einem definierten Zeitraum eingehalten werden konnte.

Gateway: Ganz zum Schluss werden 2x Gateway Server in der DMZ installiert und mit Zertifikat konfiguriert, sodass sie sich mit den internen Management Servern (MS) authentifizieren können. Diese Gateway Server dienen als Brückenköpfe (Gateway) für alle Agents in der DMZ, die von internen MS überwacht werden. Agents werden per OpsMgr Cmdlet (PowerShell) konfiguriert, sodass sie beim Ausfall eines Gateways automatisch den Standby-Gateway Server kontaktieren.

SCOM Hybrid via OMS Gateway: Um die Entwicklung Azure OMS (Opeartions Management Suite) nicht zu verpassen, sollten SCOM Administratoren die Fähigkeit von OMS unbedingt kennenlernen. Die Kombination von On-Premises SCOM via OMS Gateway (On-Premises) mit dem Azure OMS Workspace erlaubt die Nutzung von einigen OMS Solutions wie Service Map und die mächtige Azure Automation. SCOM Hybrid nutzt OMS Log Analytics und Log Search um Automation Runbooks für Workflows zu triggern.

Bemerkung zum Kurs: In den "älteren" SCOM Kursen haben wir die Datenbanken auf einem Failover Cluster hochverfügbar gemacht (» großes Bild). Seit unseren SCOM 2016 Kursen installieren wir unsere Datenbanken auf zwei Hyper-V Hosts, welche je einen SET Switch besitzen und durch zwei 10GBit Netzwerkkarten miteinander kommunizieren. Die VMs bekommen eine physikalische Platte direct Attached. Außerdem ist diese Platte noch aus einem RAID 1 erstellt. Dadurch sind die Datenbanken relativ ausfallsicher (» mittleres Bild). Die SCOM Datenbanken OPSDB und OPSDW liegen auf diesen Platten und laufen in jeweils einer VM. In einer Enterprise Umgebung soll am besten SQL 2016/2017 AlwaysOn für die SCOM DBs eingesetzt werden, um sowohl die Hochverfügbarkeit als auch Disaster Recovery zu ermöglichen.

» Wir empfehlen als Ergänzung zu diesem Kurs unseren Deployment-Kurs Endpoint Configuration Manager und ADS 2019.

SCOM 2007 R2 - Management Groups (Large / Enterprise Scenarios)
SCOM 2007 R2 - Management Groups (Large / Enterprise Scenarios)

2016 Management Group - Aufbau Umgebung
2016 / 2019 Management Group - Aufbau Umgebung

SCOM 2012 R2 Workflows & Kommunikation
SCOM Workflows & Kommunikation

Zum Seitenanfang

- Vertrauen Sie unserer Kompetenz -