SCOM 2012 R2 Workflows & Kommunikation

Intensivkurs SCOM

System Center Operations Manager 2016

- für Enterprise Umgebung -

In diesem Intensivkurs lernen Sie den Aufbau und die Administration von System Center Operations Manager 2016 in einer ADS-Gesamtstruktur kennen.
Ziel des Kurses ist die Überwachung aller Windows Server inkl. 2016 Nano Server und evtl. Clients sowie ausgewählter Anwendungen.
Neu ist 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 IT-Leitung und Projektmanager mit fundiertem Fachwissen ist dieser Kurs auch zu empfehlen.

NIVEAU
★★★★☆ — ziemlich anspruchsvoll

DAUER
5 Tage

ORT
NT Systems Schulungszentrum Böblingen (Karte)

TERMINE

05.02. - 09.02.2018 noch Plätze frei
16.04. - 20.04.2018 noch Plätze frei
09.07. - 13.07.2018 noch Plätze frei

Zur Anmeldung

PREIS
3.450,- € zzgl. Mwst. – inkl. Mittagessen 14,- € / Tag

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

SCHULUNGSZEITEN
Am ersten Tag 10:00 - 17:30 Uhr
An Folgetagen 09:00 - 17:30 Uhr
Am letzten Tag (Freitag) 09:00 - 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.

Nano Server (2016): Gegenüber SCOM 2012 R2 wurde SCOM 2016 um ein paar wichtige Features erweitert: Am wichtigsten ist die Überwachung von 2016 Nano Server, welcher als physischer und auch als VM eine wichtige Rolle spielen wird. Ein Nano Server ist dank des geringen Ressourcenbedarfs u.a. prädestiniert als "compute" Hyper-V Host in einem Hyper-V Cluster. Typischerweise werden in einer modernen Enterprise Windows Server 2016 Umgebung  "compute" Hyper-V Cluster und Scale-Out File Server (SOFS) zusammenarbeiten, indem die Speicherung der VM's VHDX via SMB 3.1.1 und 10 GBit RoCE (RDMA over Ethernet) auf dem SOFS erfolgt.

Alert Data Management (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 (2016): SCOM 2016 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 (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) 2016: Um den Weg in die Cloud nicht zu verschließen, ist es nun möglich, SCOM 2016 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.

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.

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. Wir werden im Kurs neben der GUI immer wieder mit PowerShell bzw. OpsMgr Shell arbeiten.

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 " 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.

Bemerkung zum Kurs: In den "älteren" SCOM Kursen haben wir die Datenbanken auf einem Failover Cluster hochverfügbar gemacht (» großes Bild). Bei den "neueren" SCOM 2012 R2 und nun 2016 Kursen wird die SCOM-Schulungsumgebung zum ersten Mal mit Hyper-V 2012 R2 Replica (später 2016) praktiziert. Die SCOM-Datenbanken OpsDB und DWDB werden auf zwei VMs installiert, die überkreuzt zum anderen Hyper-V Host über 10 GBit Netzwerk replizieren (» mittleres Bild). So kann eine schnelle, kostengünstige und sichere SCOM-Umgebung auch für die Praxis realisiert werden. Am besten ist jedoch SQL AlwaysOn für die SCOM DBs einzusetzen, um sowohl die Hochverfügbarkeit als auch Disaster Recovery zu ermöglichen.

» Wir empfehlen als Ergänzung zu diesem Kurs unseren Deployment-Kurs SC Configuration Manager 1706 und ADS 2016.

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

SCOM 2012 R2 Multimaster Management Server - Resource Pools
SCOM 2012 R2 und 2016 Multimaster Management Server - Resource Pools

SCOM 2012 R2 Workflows & Kommunikation
SCOM Workflows & Kommunikation

Hinweis: Bitte bringen Sie zum Kurs Ihre Evaluation DVD oder ISO mit der gewünschten Sprachversion mit. Wir dürfen keine Volume License für Kurse nutzen!

Zum Seitenanfang

- Vertrauen Sie unserer Kompetenz -