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
4 Tage
ORT
NT Systems Schulungszentrum Böblingen (Karte)
TERMINE
|
|
PREIS
3.750,- € zzgl. Mwst.
Kursbesuch nur gegen Vorkasse möglich!
MINDEST-TEILNEHMERZAHL
Das Seminar findet ab einer Mindestzahl von drei Teilnehmern garantiert statt.
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.
- Operations Manager Database (OpsDB)
- Operations Manager Data Warehouse (DWDB)
- Operations Manager Audit Collection Service (ACSDB)
- Report Database
» 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)
2016 / 2019 Management Group - Aufbau Umgebung
SCOM Workflows & Kommunikation
- Übersicht System Center Operations Manager 2016 / 2019
- Architektur und Topology von SCOM Infrastruktur
- Kleine Topology
- Mittlere Topology
- Große Topology
- Architektur und Topology von SCOM Infrastruktur
- Distributed Applications - verteilte Anwendungen
- Überwachung aus der Perspektive des Endbenutzers
- Client- / Serverüberwachung mit installierten Agenten und "Agentless" - ohne Agenten
- Sichere Kommunikation, benutzerdefinierte Berechtigungen in SCOM 2016 nach internem Rollenmodell
- Active Directory Integration zur Agentenzuweisung und Installation
- Audit Collection Service (ACS) - Security Events mitloggen
- Load Balancing Gateway (GW) und Management Server (MS)
- Service Level Dashboard
- Neue Features von SCOM 2019 gegenüber 2016
- Übersicht über die Kommunikation und Zugriffe in einer SCOM Umgebung
- Kommunikation zwischen den MS, Datenbanken und Agenten
- MOM Channel und Ports
- Datenbanksynchronisation zwischen OpsDB und DWDB.
- Action Accounts, Run As Accounts, Run As Profiles
- Architektur und Topology von SCOM Infrastruktur
- Planung, Installation & Konfiguration von SCOM in einer Enterprise Umgebung - Sicherheit durch ESAE Tiers 0,1,2
- Planung und Vorbereitung: Szenarienabhängig
- Design einer Infrastruktur für SCOM 2016/2019
- Nutzung von Windows Server 2016/2019 mit 10 GBit-Ethernet
- Festlegen der Management Group, Failover Management Group, Management Server
- Sicherheitsaspekte im Hinblick auf Microsofts ESAE Modell (Enhanced Security Administrative Environment)
- Verwaltung der Tier 0 Server inkl. Domain Controller durch T0 SCOM Admins.
- Platzierung der Management Server und SQL-Server (AlwaysOn, Failover Cluster), Report Server
- Anlegen von Sicherheitsgruppen und Service Accounts für SQL Server und SCOM in Active Directory
- Zuweisung der Benutzerberechtigungen
- Installation SQL für SCOM Reporting.
- Installation mind. zweier Management Server (MS)
- Installation SCOM 2019 Reporting Server
- Post-Installation und Überprüfung
- Upgrade SCOM 2016 auf 2019
- Vorbereitung Upgrade 2019
- Durchführung Upgrade 2019
- Post-Installation nach dem Upgrade 2019
SCOM 2019 - Setup
SCOM 2019 - Upgrade
- Enhanced Notifications and Alert
- Email Notifications können ab SCOM 2019 auch im HTML Format versendet werden.
- Notification bieten ab SCOM 2019 mehr Möglichkeiten im criteria builder.
- SCOM 2019 kann nun Alert basierte Monitore erzeugen, bei denen durch ein geschlossenen Alert der Health State angepasst wird.
SCOM 2019 criteria builder (OR Verknüpfung)
- Verwalten von SCOM 2019
- Arbeiten mit Operations-, Web-Console (HTML 5) und PowerShell & Operations Manager Command Shell
- Globale Einstellungen (Heartbeats, Role based Security, Alerts, etc.)
- Konfigurieren des Management Servers
- Konfigurieren von Agenten
- Alarm, Events und Performance Regeln
- Übersicht Administration, Authoring, Reporting, Auditing
- neue Konsolen Features
Die System Center Operations Manager Konsole
HTML 5 basierte Web Konsole
Operations Manager Products Datenbanken (SCOM 2019)
Operations Manager Products (SCOM 2019)
- User Roles - Action Accounts - Run As Accounts - Run As Profiles
- Default Agent Action Account (LocalSystem) und Management Server Action Account (SOMmsa)
- MonitoringHost.exe vs. Health Service
- Vorgegebene und eigen erstellte User Roles
- Run As Accounts, Mapping eines Run As Accounts mit einem Windows Account.
- Run As Profile - Besondere Berechtigungen für einzelne Aufgaben
- Arbeiten mit PowerShell & Operations Manager Command Shell
Zuordnung Workflow ➔ Run As Profile ➔ Run As Account ➔ Distribute an Agents (Quelle: Microsoft)
Default Agent Action Account & Management Server Action Account
HealthService & MonitoringHost.exe ➔ LocalSystem (Default Agent Action Account)
Console Task OLE DB Watcher Test ➔ MonitoringHost.exe nutzt scommsa (Management Server Action Account)
- Agents
- Überblick: Managed Agents, Agentless, Network Devices
- Installation von Agents: Discovery, Manuell, Group Policy incl. Logon Script mit AD Integration
- Agent Internals: AD Cache, Registryeinträge, Health Service, MonitoringHost.exe
- Arbeiten mit PowerShell & Operations Manager Command Shell
Ermittlung des Primary Management Servers eines Agenten
- Management Packs - Updates & Recommendations (ab 2016)
- Updates & Recommendations
- Überprüfen vorgeschlagener Management Packs
- Importieren vorgeschlagener Management Packs
- Updates von Management Packs
SCOM 2016 - Updates und Recommendations
SCOM 2016 - Management Pack Recommendation für SMA
- Installation von Management Packs nach Bedarf und Verfügbarkeit (nicht alle hier genannten MP werden importiert!)
- Active Directory
- SQL Server
- Windows Server 2016 / 2019
- Failover Cluster 2012 R2 / 2016
- Exchange Server 2013 / 2016
- SMA (Service Management Automation)
- Updates & Recommendations
- Administration
- Verwalten / Importieren von Management Packs
- Bedeutung und Anlegen von Overrides
- Konfigurieren von Globalen Settings
- Konfigurieren von Notifications
- Arbeiten mit Operations Manager Command Shell
SCOM Overrides - Benutzerdefinierte Anpassungen
- Monitoring - Collection von Daten & Monitoring von Diensten und Applikationen
- Collection von Computern, Konfigurieren von Collectionsregeln
- Verarbeitung und Behandlung von Ereignissen
- Verarbeitung und Behandlung von Fehlermeldungen
- Verarbeitung und Behandlung von Performancedaten
SCOM Operating System Performance
SCOM Special Process Monitor
- Alert Data Management (ab 2016)
- Konfiguration von Tune Management Packs
- Tuning einzelner Monitoren und Regeln (Rules)
- Ausgabe der generierten Alerts pro Management Pack
SCOM 2016 - Tune Management Packs
SCOM 2016 - Generierte Alerts eines bestimmten Management Packs
- Aggregat Monitors & Dependency Monitor
- Health Rollup Policy
- Aggregat Monitor am Beispiel DC Overall Essential Services
- Dependency Monitor am Beispiel SQL DB Instanz
Überwachung der Core Services von Domain Controller
KDC Service Health
Health Rollup Policy Aggregat Monitor
- Komplexe Monitors, Rules & Diagnostics mit Scripts
- Komplexe bzw. benutzerdefinierte Monitors mit Scripts
- Komplexe bzw. benutzerdefinierte Rules mit Scrips
- Diagnostics von Monitors mit Scripts
SCOM Monitor mit Diagnostic - SendMail
- Special Monitor (Management Pack Templates) - Web Application Transaction & Availability Monitoring
- Überwachen von Webanwendungen/Websites
- Erstellen von Performance Counter für die Webanwendungen/Websites
- Überprüfen der Verfügbarkeit vom Watcher zur Webanwendung/Website
- Special Monitor - OLE DB Datasource
- Überwachung von Datenbanken über OLE DB mittels Watcher
- Überprüfung von Verbindung und Abfrage auf Erfolg und Performance
OLE DB Query vom SCOM Watcher
- Distributed Aplication (DA)
- Modellieren und Überwachen einer 2-Tier Anwendung mit Front-End (Web-Farm) und Back-End (SQL-DB)
- Arbeiten mit dem DA Designer - Component Groups - Relationships
- Health Rollup Policy für Web-Farm
Modellieren einer 2-Tier "Distributed Application"
Health Rollup für Web-Farm
- Service Level Tracking (SLT)
- Konfigurieren SLT für die 2-Tier Distributed Applikation "NT-CourseRating"
- SLO (Service Level Objective) für Monitor State und Collection Rule
- SLT-Dashboard
Service Level Objectives anlegen
Monitor State SLO
Collection Rule SLO
Dashboard Service Level Objective Detail Report
- SCOM Reporting (Berichterstellung)
- Installation und Konfiguration von Reporting
- Berichtskonsole, Webkonsole
- Vordefinierte Berichte
- Interpretieren von Reports
- Abfragen der Reportdatenbank mit SQL Management Studio
SCOM Reporting - Wie verfügbar waren die Server?
- Management Packs
- Export von versiegelten "sealed" Managementspacks
- Struktureller Aufbau von Managementpacks
- Arbeiten mit Tools und Operations Manager Command Shell
Management Pack References
Monitors im Management Pack
- Gateway Server (GWS) in der DMZ
- Einrichten von zwei Gateway Server in einer DMZ
- Konfigurieren der Zertifikatsvorlage für GWS und zwei Management Server (MS)
- Konfigurieren der Firewall für die Kommunikation zwischen GWS und MS
- Konfigurieren der Management Server für die Kommunikation mit GWS
- Konfigurieren der Agents in der DMZ für die Kommunikation mit GWS.
- Konfigurieren Failover von MS für GWS
- Konfigurieren Failover von GWS für Agents
Gateway Failover (für Agents) und Management Server Failover (für Gateway)
- SCOM Hybrid - Operations Management Suite (OMS)
- OMS Log Analytics
- SCOM Hybrid via OMS Gateway - Zusammenarbeit mit OMS Workspace
- Erzeugen Alerts durch Filtern von Events mit Log Search
- Triggern von Workflows (Runbooks) durch Alerts
- OMS Solutions (z.B. Service Map)
Operations Management Suite - Connected Sources
OMS - Service Map Overview
- Backup, Restore & Wartung
- Backup der SQL Datenbanken (Operations Database, Data Warehouse)
- Restore der Datenbanken und Nacharbeiten
- Grooming Data Warehouse und Operations Manager DB
- Datenbank Wartung (Reindex, etc.)

- Vertrauen Sie unserer Kompetenz -