johannes/biztalk-checkmk-pulse
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Separate BizTalk collection from Checkmk agent

Browse Source
This commit is contained in:
admin
2026-07-30 15:50:42 +02:00
parent e3d7f6a780
commit d15bb6539b
22 changed files with 2051 additions and 988 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Dokumentation.md
+480 -335
View File
@@ -1,110 +1,180 @@
# Dokumentation: BizTalk Checkmk Pulse
# Technische Dokumentation: BizTalk Checkmk Pulse
## Zielbild
## 1. Ziel und Randbedingungen
Ziel ist ein wartbares Monitoring fuer BizTalk Server 2020 in den Umgebungen `ACC`, `DEV`, `TST` und `PRD`. Jede Umgebung besitzt einen BizTalk Server 2020 und einen SQL Server. SQL Server wird mit dem Checkmk-eigenen MSSQL-Plugin ueberwacht; fuer BizTalk liefert dieses Projekt die fehlende fachliche und technische Laufzeitsicht.
Die Anwendung ueberwacht BizTalk Server 2020 auf Windows Server 2019 mit
Checkmk 2.4. Pro Umgebung (`ACC`, `DEV`, `TST`, `PRD`) wird lokal auf dem
BizTalk-Server gesammelt. Das Checkmk-MSSQL-Plugin bleibt fuer die allgemeine
SQL-Ueberwachung zustaendig; BizTalk Checkmk Pulse liefert die
BizTalk-spezifische Laufzeit- und Berechtigungssicht.
Das Monitoring soll:
Verbindliche Randbedingungen:
- auf jeder BizTalk-Maschine lokal laufen
- ohne PowerShell-Abhaengigkeit funktionieren
- keine BizTalk-DLLs im Build erzwingen
- Checkmk-2.4-kompatible Services und Metriken erzeugen
- service-discovery-freundlich und dashboard-tauglich sein
- bei Fehlern gueltige `UNKNOWN`-Services statt kaputter Agent-Ausgaben liefern
- Der Checkmk Windows Agent bleibt `LocalSystem`.
- `LocalSystem` erhaelt keine BizTalk-/SQL-Gruppenmitgliedschaft.
- Ein separates Dienstkonto oder bevorzugt gMSA sammelt minuetlich.
- Der Agentpfad fuehrt niemals WMI- oder SQL-Abfragen aus.
- Fehler muessen als gueltige Checkmk-`UNKNOWN`-Services sichtbar werden.
- Schreiben und Lesen duerfen nie einen halben Snapshot exponieren.
- Laufzeitcode benoetigt keine PowerShell und keine BizTalk-DLL-Referenz.
- Installation, ACL und Scheduled Task muessen reproduzierbar sein.
## Technische Bewertung
## 2. Ausloeser der Architekturanderung
### Option A: Checkmk Local Check mit C#/.NET Framework
Bewertung: empfohlen und umgesetzt.
Vorteile:
- Checkmk 2.4 unterstuetzt Local Checks direkt.
- Windows Server mit BizTalk 2020 bringt .NET Framework in der Regel passend mit.
- `System.Management` kann BizTalk-WMI lesen.
- Keine PowerShell Execution Policy, keine Script-Signing-Frage.
- Kein serverseitiges Checkmk-Python-Plugin notwendig.
- Rollout ist eine einfache Dateiablage unter `%ProgramData%\checkmk\agent\local`.
Nachteile:
- Schwellwerte sind in der `.exe.config`, nicht als Checkmk-Regelsatz in WATO.
- Eigene Graphing-Definitionen sind nicht enthalten; Checkmk zeigt Local-Check-Metriken trotzdem als Performance-Daten und Graphen.
### Option B: Agent Plugin plus serverseitiges Checkmk-Plugin
Bewertung: technisch elegant, aber fuer den ersten produktiven Schritt schwerer.
Vorteile:
- Checkmk-Regeln, Discovery und Metrikdefinitionen koennen sauber zentral modelliert werden.
- Bessere langfristige Erweiterbarkeit als MKP.
Nachteile:
- Checkmk-Check-API-Versionen muessen enger gepflegt werden.
- Server-seitige Installation in jeder Site erforderlich.
- Mehr Aufwand fuer Managed-Services-Betrieb und Updates.
Empfehlung: als Version 2 dieses Projekts denkbar, wenn die Local-Check-Variante stabil in PRD laeuft und zentrale Regelsaetze wirklich benoetigt werden.
### Option C: PowerShell Local Check
Bewertung: nicht empfohlen fuer diese Umgebung.
Vorteile:
- Schnell zu schreiben.
- WMI/CIM-Zugriff ist komfortabel.
Nachteile:
- PowerShell ist in vielen Serverumgebungen eingeschraenkt oder signaturpflichtig.
- Ausfuehrungsverhalten im Checkmk-Agent-Kontext ist haeufiger fehleranfaellig.
### Option D: BizTalk ExplorerOM/OperationsOM
Bewertung: fachlich stark, deployseitig unnoetig schwer.
Vorteile:
- Hoehere BizTalk-Abstraktion als rohe WMI-Klassen.
Nachteile:
- BizTalk-DLL-Versionen muessen beim Build und teilweise zur Laufzeit passen.
- Build-Agenten brauchen BizTalk-Komponenten oder SDK-Dateien.
- Fuer die benoetigten Zustandsdaten reicht WMI aus.
## Architektur
Der ACC-Agent-Dump vom 29.07.2026 bewies:
```text
Checkmk Windows Agent
|
| startet lokale Checks aus %ProgramData%\checkmk\agent\local
v
biztalk_checkmk_pulse.cmd
|
| startet
v
BizTalkCheckmkPulse.exe
|
| liest lokal und prueft im gleichen Sicherheitskontext
+-- WMI root\MicrosoftBizTalkServer
+-- Windows Application Event Log
+-- SQL-Verbindung zu BizTalkMgmtDb/BizTalkMsgBoxDb
|
v
Checkmk Local Check Zeilen nach STDOUT
Lokaler Prozess: NT AUTHORITY\SYSTEM
Netzwerkprincipal: BEW\AV23AGPWBIO1$
Providerfehler: COMException 0x80131904
Innerer Fehler: Login failed for user 'BEW\AV23AGPWBIO1$'
```
Der `.cmd`-Wrapper liefert auch dann fuer alle sechs stabilen Services gueltige `UNKNOWN`-Zeilen mit Massnahme, wenn die EXE fehlt oder bereits der Prozessstart mit einem Exitcode fehlschlaegt. Die EXE selbst faengt Laufzeitfehler ab und schreibt ebenfalls fuer alle stabilen Services `UNKNOWN`, damit unvollstaendige Deployments oder WMI-Probleme in Checkmk sichtbar bleiben.
Lokales `root\MicrosoftBizTalkServer` war erreichbar. Die
datenbankgestuetzten BizTalk-WMI-Klassen scheiterten erst beim Zugriff des
Providers auf den getrennten SQL Server. DCOM-, Firewall- oder pauschale
WMI-ACL-Aenderungen beheben diesen Befund nicht.
## Datenquellen
Eine Berechtigung des Maschinenkontos haette die Netzwerkrolle allen
`LocalSystem`-Diensten des BizTalk-Servers vermittelt. Die jetzt implementierte
Producer/Consumer-Trennung beschraenkt sie stattdessen auf ein dediziertes
Konto.
### BizTalk WMI Namespace
## 3. Architektur
```text
Privilegierte Zone
┌──────────────────────────────────────────────────────────────┐
│ Task Scheduler: "BizTalk Checkmk Pulse Provider" │
│ Konto: DOMAIN\svc_biztalk_cmk$ (gMSA empfohlen) │
│ Intervall: 1 Minute, IgnoreNew, Laufzeitlimit 5 Minuten │
│ │
│ BizTalkCheckmkPulse.exe --collect │
│ ├─ WMI root\MicrosoftBizTalkServer │
│ ├─ integrierter SQL-Test an MgmtDb/MsgBoxDb │
│ ├─ lokales Windows Application Event Log │
│ ├─ Checkmk-Formatierung │
│ └─ atomare Snapshot-Publikation + Provider-Log │
└──────────────────────────────┬───────────────────────────────┘
│ Datei/ACL
v
%ProgramData%\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot
│
v
┌──────────────────────────────────────────────────────────────┐
│ Unprivilegierter Transportpfad │
│ Checkmk-Agent (LocalSystem) │
│ └─ local\biztalk_checkmk_pulse.cmd │
│ └─ BizTalkCheckmkPulse.exe --consume │
│ ├─ Format/Alter/Maschine/SHA-256 validieren │
│ └─ Payload unveraendert nach STDOUT │
└──────────────────────────────────────────────────────────────┘
```
Eine gemeinsame EXE implementiert beide Modi. Das reduziert
Versionsabweichungen. Die zentrale Config unter `%ProgramFiles%` gilt fuer
Provider und Consumer.
### 3.1 Provider-Modus
Aufruf:
```cmd
"%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --collect
```
Ablauf:
1. Config laden und absolute Runtimepfade validieren.
2. Tageslogs gemaess `LogRetentionDays` bereinigen.
3. exklusives Handle auf `<SnapshotPath>.provider.lock` halten.
4. WMI-, SQL- und Event-Log-Probes ausfuehren.
5. sechs stabile und optionale dynamische Checkmk-Zeilen formatieren.
6. Snapshot in einer eindeutigen Temporaerdatei desselben Verzeichnisses
schreiben.
7. `Flush(true)` ausfuehren und Temporaerdatei atomar publizieren.
8. Laufzeit, Zeilen- und Diagnosezahl loggen.
Exitcodes:
| Code | Bedeutung |
| --- | --- |
| `0` | Sammlung und Snapshot-Publikation erfolgreich. |
| `1` | unerwarteter Providerfehler; aktueller `UNKNOWN`-Snapshot wird versucht. |
| `2` | Parallelstart oder Snapshot-I/O-Fehler. |
Fachliche WMI-/SQL-Fehler werden strukturiert in den Snapshot geschrieben und
muessen nicht zwingend einen Prozessfehler verursachen. So bleibt die genaue
Fehlerkategorie in Checkmk sichtbar.
### 3.2 Consumer-Modus
Aufruf:
```cmd
"%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume
```
Ohne Modusargument ist `--consume` der sichere Default. Der Checkmk-Wrapper
setzt es trotzdem explizit.
Der Consumer:
- oeffnet nur den Snapshot,
- begrenzt die Dateigroesse vor dem Einlesen,
- validiert striktes UTF-8,
- validiert Formatversion und Header,
- fordert die lokale Maschinenkennung,
- berechnet SHA-256 ueber den exakten Payload,
- prueft Zeilenanzahl und Checkmk-Zeilenform,
- verwirft Zeitstempel mehr als fuenf Minuten in der Zukunft,
- verwirft Snapshots nach `SnapshotMaxAgeSeconds`,
- gibt bei Erfolg ausschliesslich den validierten Payload aus.
Er gibt immer Exitcode `0` zurueck, damit ein Fehler die komplette
Checkmk-Agentsektion nicht zerstoert. Jede Ablehnung erzeugt sechs
`UNKNOWN`-Zeilen und einen Eintrag im Consumer-Log.
## 4. Snapshot-Vertrag
Version 1:
```text
BIZTALK_CHECKMK_PULSE_SNAPSHOT_V1
generatedUtc=2026-07-30T12:34:56.1234567Z
machineBase64=QVYyM0FHUFdCSU8x
identityBase64=QkVXXHN2Y19iaXp0YWxrX2NtayQ=
payloadLines=6
payloadSha256=<64 hex characters>
0 "BizTalk Platform" - ...
...
```
Maschine und Identitaet sind Base64-kodiert, um Zeilenumbrueche und
Trennzeichen im Header auszuschliessen. Base64 ist hier keine Verschluesselung.
Die SHA-256-Pruefung schuetzt vor unbemerkter Teil-/Fehlschreibung, nicht vor
einem lokalen Administrator.
### 4.1 Atomare Publikation
Die Temporaerdatei liegt zwingend im Snapshotverzeichnis. Dadurch findet der
Ersatz auf demselben Volume statt. Existiert bereits ein Snapshot, wird
`File.Replace` verwendet; beim ersten Lauf `File.Move`. Bis zum erfolgreichen
Ersatz bleibt der letzte vollstaendige Snapshot erhalten. Seine Alterspruefung
verhindert unbegrenztes Weiterreichen alter Daten.
### 4.2 Keine direkte Checkmk-Spooldatei
Checkmk kann zwar Dateien aus seinem Spoolverzeichnis direkt anhaengen, prueft
deren Inhalt aber laut eigener Dokumentation nicht. Ein fehlerhafter Spool kann
nachfolgende Agentsektionen beeinflussen. Deshalb liegt der Provider-Snapshot
in einem eigenen Verzeichnis und wird erst durch den validierenden Consumer in
die Local-Check-Ausgabe uebernommen.
## 5. Datenquellen
### 5.1 BizTalk WMI
Namespace:
@@ -112,286 +182,361 @@ Namespace:
root\MicrosoftBizTalkServer
```
Genutzte Klassen:
Pflichtklassen:
| Klasse | Zweck |
| --- | --- |
| `MSBTS_GroupSetting` | BizTalk-Gruppe, Management-DB und Master-MessageBox (`SubscriptionDB*`). |
| `MSBTS_HostInstance` | Host-Instance-Zustand; Ergebnis wird clientseitig auf den ueberwachten Server begrenzt. |
| `MSBTS_ServiceInstance` | Suspended service instances. |
| `MSBTS_ReceiveLocation` | Receive-Location-Zustand. |
| `MSBTS_SendPort` | Send-Port-Zustand. |
| `MSBTS_Orchestration` | Orchestration-Zustand. |
| `MSBTS_ReceivePort` | Optionales Best-Effort-Application-Mapping, nur wenn per-Application-Services aktiviert sind. |
| `MSBTS_GroupSetting` | Gruppe, Read-Only-/Operator-Gruppe, Management- und Master-MessageBox-Ziel. |
| `MSBTS_HostInstance` | lokale Host-Instance-Zustaende. |
| `MSBTS_ServiceInstance` | suspendierte Instanzen. |
| `MSBTS_ReceiveLocation` | Receive-Location-Zustaende. |
| `MSBTS_SendPort` | Send-Port-Zustaende. |
| `MSBTS_Orchestration` | Orchestration-Zustaende. |
Die Plattformabfrage verwendet absichtlich keine vermeintliche Klasse `MSBTS_MessageBoxSetting`: Sie ist nicht Bestandteil des dokumentierten BizTalk-WMI-Schemas. Auch die vorhandene Klasse `MSBTS_MsgBoxSetting` ist fuer die Zielermittlung nicht erforderlich. `MSBTS_GroupSetting` liefert mit `SubscriptionDBServerName` und `SubscriptionDBName` bereits das Ziel der Master-MessageBox. Dadurch entfallen eine Providerabfrage und eine unnoetige Berechtigungs-/Schemaschnittstelle.
`MSBTS_GroupSetting` wird mit den dokumentierten Properties
`MgmtDbServerName`, `MgmtDbName`, `SubscriptionDBServerName`,
`SubscriptionDBName`, `BizTalkReadOnlyUserGroup` und
`BizTalkOperatorGroup` gelesen. Eine nicht dokumentierte
`MSBTS_MessageBoxSetting`-Klasse wird nicht abgefragt.
### Windows Application Event Log
Hostnamen werden clientseitig verglichen. Sonderzeichen und FQDN-/Kurzname
gelangen nicht in dynamisch erzeugte WQL-Filter.
Der Check liest standardmaessig das lokale Application Log fuer die letzten 60 Minuten und filtert auf Quellen wie:
### 5.2 SQL-Zugriffsprobe
- `BizTalk Server`
- `XLANG/s`
- `ENTSSO`
- `BizTalk Server Application`
- `BizTalk Server EDI`
Der Provider oeffnet fuer Management- und Master-MessageBox-Datenbank eine
kurze `System.Data.SqlClient`-Verbindung mit integrierter
Windows-Authentifizierung, fuehrt `SELECT 1` aus und schliesst sie. Keine
BizTalk-Tabelle wird direkt gelesen oder veraendert.
Die Liste ist ueber `EventLogSources` konfigurierbar.
Die Ausgabe `execution_identity=` zeigt deshalb das Provider-Konto, nicht mehr
`NT AUTHORITY\SYSTEM`. Der Check beweist, dass genau das Scheduled-Task-Konto
die Ziele erreichen kann.
### SQL-Zugriffsprobe
### 5.3 Event Log
Nach erfolgreicher oder teilweise erfolgreicher Plattformabfrage uebernimmt der SQL-Probe die per `MSBTS_GroupSetting` ermittelten Management- und Master-MessageBox-Ziele. Fuer jedes eindeutige Ziel wird mit `System.Data.SqlClient` eine Verbindung mit integrierter Windows-Authentifizierung geoeffnet und `SELECT 1` ausgefuehrt. Die Verbindung wird unmittelbar danach geschlossen; es werden keine BizTalk-Tabellen gelesen oder veraendert.
Der Provider liest das lokale Application Log im konfigurierten Zeitfenster
und filtert Quellen wie `BizTalk Server`, `XLANG/s`, `ENTSSO`,
`BizTalk Server Application` und `BizTalk Server EDI`.
Der Test laeuft unter derselben Identitaet wie der Checkmk Local Check. Damit wird sichtbar, ob `LocalSystem` beziehungsweise das Maschinenkonto des BizTalk-Servers das SQL-Ziel tatsaechlich erreichen und die Datenbank oeffnen kann. Die Probe ist mit `ProbeSqlConnectivity=false` deaktivierbar und verwendet `SqlConnectionTimeoutSeconds` mit dem Default 5 Sekunden je Ziel als Timeout.
## 6. Berechtigungsmodell
Im produktiven Betrieb sollte der komplette Local Check asynchron mit 300 Sekunden Cache ausgefuehrt werden. So fuehren fehlende SQL-Rechte nicht bei jedem Checkmk-Abruf zu weiteren fehlgeschlagenen Login-Ereignissen. Der Trade-off ist eine Zustandsverzoegerung von maximal fuenf Minuten.
### 6.1 Bevorzugte BizTalk-Rolle
## Berechtigungsmodell
BizTalk Server 2020 fuehrte die `BizTalk Server Read Only Users`-Gruppe ein.
Sie darf Artefakte, Servicezustand, Message Flow und Trackinginformationen
lesen, aber keine administrativen Operationen ausfuehren. SQL-seitig wird sie
ueber `BTS_READONLY_USERS` vermittelt.
### LocalSystem und lokaler WMI-Zugriff
Der Checkmk Windows Agent und der Agent Controller laufen standardmaessig als `LocalSystem` (`NT AUTHORITY\SYSTEM`). Der Wrapper und die EXE erben diesen Kontext. Das Plugin verbindet sich lokal mit `\\<eigener-server>\root\MicrosoftBizTalkServer`, setzt keine eigenen Anmeldedaten, nutzt kein Remote-WMI und fuehrt keine veraendernden WMI-Methoden aus. Das lokale Windows Application Event Log wird ebenfalls nur gelesen.
Die lokalen Rechte von `LocalSystem` reichen fuer diese Zugriffe normalerweise aus. Im regulaeren lokalen Betrieb werden deshalb keine zusaetzlichen DCOM-, Firewall- oder pauschalen WMI-Namespace-Freigaben benoetigt.
### Netzwerkidentitaet zum SQL Server
BizTalk-WMI-Klassen koennen ihre Daten aus der BizTalk Management- oder MessageBox-Datenbank beziehen. Liegt SQL Server auf einer anderen Maschine, authentifiziert sich `LocalSystem` dort mit dem Active-Directory-Computerkonto des BizTalk-Servers:
Soll:
```text
DOMAIN\BIZTALKSERVER$
DOMAIN\svc_biztalk_cmk$
-> konfigurierte BizTalk Server Read Only Users-Domaingruppe
-> vorhandener Windows-Gruppenlogin am SQL Server
-> BTS_READONLY_USERS in den von BizTalk konfigurierten Datenbanken
```
Dieses Konto besitzt nicht automatisch BizTalk- oder SQL-Berechtigungen. Daraus kann die Situation entstehen, dass die Verbindung zum lokalen WMI-Namespace erfolgreich ist, einzelne SQL-gestuetzte WMI-Klassen aber `Access denied`, `UnauthorizedAccessException` oder `UNKNOWN` liefern.
Die genaue Gruppe ist aus
`MSBTS_GroupSetting.BizTalkReadOnlyUserGroup` beziehungsweise der
BizTalk-Administration zu lesen. Nicht vom Standardnamen ausgehen.
Der ACC-Test vom 29.07.2026 bestaetigt genau diesen Pfad: Auf `AV23AGPWBIO1` ist WMI erreichbar, aber der Provider meldet `COMException 0x80131904` mit `Login failed for user 'BEW\AV23AGPWBIO1$'`. Die `UNKNOWN`-Services fuer Plattform, Host Instances, Runtime Artifacts und Suspensions sowie die fehlende SQL-Zielermittlung sind Folgefehler. DCOM-, Firewall- oder WMI-ACL-Erweiterungen beheben diesen konkreten SQL-Loginfehler nicht. Der Event-Log-Check arbeitet bereits und seine Fehler/Warnungen sind separat zu bewerten.
Die Operator-Gruppe (`BTS_OPERATORS`) wird erst geprueft, wenn eine konkret
benannte erforderliche WMI-Klasse trotz nachgewiesener Read-Only-Konfiguration
und neuem Anmeldetoken abgewiesen wird. Die Erweiterung muss mit Security,
BizTalk- und SQL-Administration begruendet werden.
Die Codekorrektur ersetzt die Berechtigungsfreigabe nicht. Sie klassifiziert den Fehler korrekt, zeigt das abgewiesene Konto und fuehrt die SQL-Folgediagnose als Berechtigungsfehler. Sie veraendert weder AD noch SQL Server. Daher bleibt die neue Version ohne Gruppenfreigabe `UNKNOWN`; umgekehrt kann auch die alte Version nach korrekter Freigabe grundsaetzlich auf die Daten zugreifen.
Unzulaessig:
### Pruefung und Freigabe
- Checkmk-Dienstkonto aendern,
- Maschinenkonto pauschal berechtigen,
- individueller SQL-Login fuer das Provider-Konto,
- direkte ad-hoc DB-Rollen,
- `db_owner` oder `sysadmin`,
- WMI-/DCOM-Vollzugriff als Reaktion auf einen SQL-Loginfehler.
Der direkte Programmstart in einer administrativen Shell laeuft unter dem angemeldeten Benutzer und ist deshalb kein ausreichender Berechtigungstest. Verbindlich ist die Ausfuehrung durch den Checkmk Agent Controller als `LocalSystem`:
### 6.2 Dateisystem-ACL
Der Installer entfernt die Vererbung an den Runtimeverzeichnissen und setzt
explizite Eintraege mit sprachneutralen Well-known-SIDs:
| Ziel | Collector | SYSTEM | lokale Administratoren |
| --- | --- | --- | --- |
| Runtime-Root | RX | RX | F |
| `data` | Modify | RX | F |
| `logs` | Modify | Modify | F |
`LocalSystem` kann deshalb den Snapshot lesen, aber im Datenverzeichnis nicht
schreiben. Schreibrecht im Logverzeichnis wird benoetigt, um abgelehnte
Snapshots aus dem Consumer-Kontext zu protokollieren.
## 7. Scheduled Task
Name:
```text
BizTalk Checkmk Pulse Provider
```
Sollkonfiguration:
| Einstellung | Wert |
| --- | --- |
| Trigger | einmalig, Wiederholung jede Minute ohne Enddatum |
| Programm | `%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe` |
| Argument | `--collect` |
| Arbeitsverzeichnis | `%ProgramFiles%\BizTalkCheckmkPulse` |
| Benutzer | dediziertes Dienstkonto oder gMSA |
| Mehrfachinstanzen | `IgnoreNew` |
| Laufzeitlimit | 5 Minuten |
| StartWhenAvailable | aktiv |
| Restart | zweimal im Minutenabstand |
Der Task wird mit gespeichertem Dienstkontokennwort beziehungsweise gMSA
ausgefuehrt, also unabhaengig von einer interaktiven Anmeldung.
## 8. Installation
### 8.1 Build
```cmd
scripts\test-release.cmd
scripts\package-release.cmd
```
### 8.2 gMSA
Voraussetzungen:
1. gMSA in AD erstellen und Abrufrecht auf den BizTalk-Server begrenzen.
2. Konto lokal installieren und mit `Test-ADServiceAccount` pruefen.
3. gMSA in die exakt konfigurierte BizTalk-Read-Only-Gruppe aufnehmen.
4. AD-Replikation abwarten.
Installation:
```powershell
& "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump |
Select-String -Pattern "BizTalk|Access denied|Unauthorized|UNKNOWN" -Context 0,1
.\Install-BizTalkCheckmkPulse.ps1 `
-CollectorAccount 'BEW\svc_biztalk_cmk$' `
-Gmsa `
-EnvironmentName ACC
```
Bei Zugriffsfehlern gilt folgendes Least-Privilege-Vorgehen:
### 8.3 regulaeres Dienstkonto
1. Die exakt konfigurierte Operator-Gruppe in der BizTalk Administration Console unter `BizTalk Group` > `Properties` > `General` feststellen.
2. Das Computerobjekt des BizTalk-Servers durch einen AD-Administrator in genau diese Gruppe aufnehmen. Fuer ACC ist dies `AV23AGPWBIO1` beziehungsweise `BEW\AV23AGPWBIO1$`.
3. Keine direkten SQL-Logins, BizTalk-Datenbankrollen oder `sysadmin`-Rechte fuer das Maschinenkonto anlegen.
4. AD-Replikation abwarten und den Server im Wartungsfenster neu starten; alternativ Maschinen-Tickets mit `klist purge -li 0x3e7` und den Checkmk-Dienst erneuern.
5. Den Agent-Dump wiederholen und `operator_group`, zwei SQL-Ziele sowie das Verschwinden der Berechtigungs-`UNKNOWN`s kontrollieren.
6. Nur fuer weiterhin abgelehnte, konkret identifizierte WMI-Klassen mit BizTalk- und SQL-Administration pruefen, ob Administratorrechte erforderlich sind.
```powershell
.\Install-BizTalkCheckmkPulse.ps1 `
-CollectorAccount 'BEW\svc_biztalk_cmk' `
-EnvironmentName ACC
```
Die Operator-Rolle ist fuer grundlegendes Monitoring und Zustandsabfragen vorgesehen. Direkte manuelle Aenderungen an den Rollen der BizTalk-SQL-Datenbanken sind zu vermeiden; die durch BizTalk konfigurierte Windows-Gruppe ist die vorgesehene Berechtigungsgrenze.
Der Installer muss als lokaler Administrator laufen. Er vergibt keine
AD-/BizTalk-/SQL-Rechte; diese bleiben getrennte administrative Freigaben.
Im Normalfall ist diese Windows-Gruppe bereits als SQL-Gruppenlogin und als Datenbankbenutzer eingerichtet. Ihre Benutzerzuordnung vermittelt `BTS_OPERATORS` unter anderem in `BizTalkMgmtDb` und `BizTalkMsgBoxDb`. `BEW\AV23AGPWBIO1$` erhaelt den Zugriff durch die AD-Gruppenmitgliedschaft und braucht keinen eigenen SQL-Login.
### 8.4 Checkmk
Bleibt der Fehler trotz bestaetigter Gruppenmitgliedschaft, AD-Replikation und erneuertem Maschinen-Token bestehen, pruefen BizTalk- und SQL-Administration:
Der installierte Wrapper liegt unter:
1. Ist die exakt konfigurierte Domain-Gruppe in `sys.server_principals` als Windows-Gruppe vorhanden?
2. Existiert ihr Datenbankbenutzer in `BizTalkMgmtDb` und `BizTalkMsgBoxDb`?
3. Ist dieser Benutzer in beiden Datenbanken Mitglied von `BTS_OPERATORS`?
4. Entspricht diese Abbildung weiterhin der BizTalk-Konfiguration?
```text
%ProgramData%\checkmk\agent\local\biztalk_checkmk_pulse.cmd
```
Fehlende Zuordnungen werden fuer die konfigurierte Gruppe konsistent repariert. Ein individueller Login, manuelle Sonderrollen oder `sysadmin` fuer das Maschinenkonto waeren keine geeignete Abkuerzung.
Der Agent darf den Consumer synchron ausfuehren. Er liest nur maximal 1 MiB
lokale Daten; ein Checkmk-Async-Cache ist daher nicht notwendig. Falls alte
`check_mk.user.yml`-Regeln fuer den bisherigen 300-Sekunden-Cache existieren,
sollten sie entfernt werden, damit Checkmk den minuetlich aktualisierten
Snapshot nicht zusaetzlich verzoegert.
| Agent-Dump-Ergebnis | Massnahme |
| --- | --- |
| Plausible Werte fuer alle BizTalk-Services | Keine Berechtigungsaenderung. |
| WMI-Namespace nicht erreichbar | BizTalk-WMI-Provider, WMI-Dienst, Namespace und ACL gezielt pruefen. |
| Nur SQL-gestuetzte Klassen scheitern | Computerkonto in die BizTalk-Operator-Gruppe aufnehmen. |
| Nur Event-Log-Service ist `UNKNOWN` | Lokalen Application-Log-Zugriff pruefen. |
| Fehler bleibt mit Operator-Rolle bestehen | Betroffene Klasse und konkrete BizTalk-/SQL-Rollenanforderung untersuchen. |
Nach dem Agent-Dump:
### Automatische Diagnose im Programm
1. Service Discovery fuer den BizTalk-Host ausfuehren.
2. sechs stabile Services aufnehmen.
3. Changes aktivieren.
4. Views/Benachrichtigungen nach Umgebung konfigurieren.
WMI-Verbindungsaufbau und jede erforderliche WMI-Klasse werden separat bewertet. Erwartbare Exceptions werden in folgende Kategorien eingeordnet:
## 9. Logging
| Diagnose | Bedeutung | Ausgegebene Massnahme |
Pfad:
```text
%ProgramData%\BizTalkCheckmkPulse\logs\
biztalk-checkmk-pulse-YYYYMMDD.log
```
Jede Zeile enthaelt UTC-Zeit, Level, Komponente, PID, Windows-Identitaet und
einzeilige Nachricht. Provider-Erfolge werden pro Lauf geloggt; der Consumer
loggt nur abgelehnte Snapshots. Exceptions werden mit Typ, Nachricht,
HRESULT-/Providerdetails und Stacktrace einzeilig gespeichert.
Logging ist best effort: Ein blockiertes Log darf Checkmk-Ausgabe oder
Snapshot-Publikation nicht zerstoeren. Der Provider entfernt beim Start Dateien
aelter als `LogRetentionDays`.
## 10. Diagnose und Runbook
### 10.1 Grundpruefung
```powershell
Get-ScheduledTaskInfo -TaskName 'BizTalk Checkmk Pulse Provider'
Get-Item "$env:ProgramData\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot"
Get-Content "$env:ProgramData\BizTalkCheckmkPulse\logs\*.log" -Tail 100
& "$env:ProgramFiles\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume
& "C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump
```
### 10.2 Kein Snapshot
Pruefen:
1. Task existiert und ist aktiviert.
2. `LastTaskResult` und Provider-Log.
3. Dienstkonto kann sich als Batch anmelden.
4. gMSA ist lokal installiert und abrufbar.
5. Provider besitzt Modify auf `data` und `logs`.
6. EXE/Config sind ausfuehrbar.
### 10.3 Staler Snapshot
Der Consumer nennt Alter und Grenzwert. Ursachen:
- Task deaktiviert oder Konto/Kennwort ungueltig,
- vorheriger Lauf haengt,
- WMI-/SQL-Timeouts,
- Task Scheduler lief waehrend Wartung nicht,
- Snapshot-Publikation wird durch AV/EDR oder ACL blockiert.
Nicht einfach `SnapshotMaxAgeSeconds` stark erhoehen. Zuerst den minuetlichen
Lauf wiederherstellen. Bei geplanten Wartungen darf Checkmk bewusst `UNKNOWN`
anzeigen.
### 10.4 SHA-256-/Formatfehler
Snapshot nicht reparieren oder direkt an Checkmk kopieren. Task neu starten,
Datentraeger und AV/EDR pruefen. Wiederholt sich der Fehler, Temporaerdateien,
NTFS-Ereignisse und Schreibrechte untersuchen.
### 10.5 BizTalk-/SQL-Permission
1. Log zeigt `execution_identity` des Providers.
2. `BizTalkReadOnlyUserGroup` gegen BizTalk-Konfiguration abgleichen.
3. AD-Gruppenmitgliedschaft des Provider-Kontos pruefen.
4. neuen Logontoken durch neuen Tasklauf sicherstellen.
5. SQL-seitig Gruppenlogin und `BTS_READONLY_USERS` read-only pruefen.
6. keine Einzelrechte erteilen.
7. Nur wenn eine spezifische Klasse weiter abgewiesen wird, Read-Only-Umfang
mit Microsoft-Dokumentation und BizTalk-Betrieb abgleichen; Operator-Rolle
ist eine bewusste Eskalation.
### 10.6 WMI-Schema
`InvalidClass` oder `InvalidQuery` wird als `Wmi/Schema` klassifiziert.
Berechtigungserhoehung kann eine nicht vorhandene Klasse nicht erzeugen.
Installierte BizTalk-Version, WQL und Properties pruefen.
## 11. Konfiguration
Alle AppSettings befinden sich in:
```text
%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe.config
```
Runtime:
| Key | Default | Bereich |
| --- | --- | --- |
| `Wmi/Permission` | Namespace, BizTalk-WMI-Klasse oder deren eingebetteter SQL-Zugriff verweigert den Zugriff. | Namespace-ACL nur bei Verbindungsfehlern; bei `Login failed for user` das genannte Maschinenkonto der BizTalk-Operator-Gruppe zuordnen. |
| `Wmi/Connectivity` | WMI-/RPC-Ziel nicht erreichbar. | WMI-Dienst, Provider und bei Remote-WMI zusaetzlich DNS/RPC/Firewall pruefen. |
| `Wmi/Timeout` | WMI-Abfrage ueberschreitet `QueryTimeoutSeconds`. | WMI-, BizTalk- und SQL-Auslastung untersuchen, bevor der Timeout erhoeht wird. |
| `Wmi/Configuration` | BizTalk-WMI-Namespace fehlt oder Plattformdaten sind unvollstaendig. | Provider, Namespace und BizTalk-Konfiguration pruefen. |
| `Wmi/Schema` | `InvalidClass` oder `InvalidQuery`; Klasse beziehungsweise WQL passt nicht zum installierten Provider. | Klasse/Properties gegen das BizTalk-WMI-Schema pruefen; keine Rechteerhoehung vornehmen. |
| `Sql/Permission` | Login oder Datenbankzugriff wird abgelehnt. | Maschinenkonto der BizTalk-Operator-Gruppe zuordnen, Kerberos erneuern, keine direkten DB-Rollen vergeben. |
| `Sql/Connectivity` | SQL-Server oder Instanz nicht erreichbar. | Servername, DNS, SQL-Dienst, TCP-Protokoll, Port und Firewall pruefen. |
| `Sql/Timeout` | SQL-Verbindung oder Testabfrage laeuft in den Timeout. | Netzwerk und SQL-Auslastung pruefen; Timeout nur begruendet anheben. |
| `Sql/Configuration` | WMI-Ziele unvollstaendig oder TLS-, Zertifikats-, SPN-/SSPI-Konfiguration fehlerhaft. | Plattformabfragen beziehungsweise Zertifikatskette, Verschluesselung, SPN und Kerberos gezielt pruefen. |
| `SnapshotPath` | `%ProgramData%\BizTalkCheckmkPulse\data\...` | absolut |
| `SnapshotMaxAgeSeconds` | `180` | 60 bis 86400 |
| `SnapshotMaxBytes` | `1048576` | 4096 bis 16777216 |
| `LogDirectory` | `%ProgramData%\BizTalkCheckmkPulse\logs` | absolut |
| `LogRetentionDays` | `30` | 1 bis 365 |
Jede Diagnose enthaelt Bereich/Kategorie, betroffene Komponente, eine kurze Ursache, `Massnahme:` und `Technik:` mit Exception-Typ, HRESULT oder SQL-Fehlernummer. Bei WMI-Abfragefehlern werden zusaetzlich WQL und Laufzeit bis zum Fehler ausgegeben. Erforderliche Datenquellen besitzen eigene Verfuegbarkeitsflags. Schlaegt beispielsweise `MSBTS_ServiceInstance` fehl, wird `BizTalk Suspended Instances` zwingend `UNKNOWN`; eine leere Ergebnisliste darf nicht als 'keine Suspensions' fehlinterpretiert werden.
BizTalk-Probes:
Die Operator-Mitgliedschaft des Computerkontos steht allen auf diesem Server als `LocalSystem` laufenden Diensten fuer Netzwerkzugriffe zur Verfuegung. Falls diese Sicherheitsauswirkung nicht akzeptabel ist, kann ein separater Collector unter einem dedizierten gMSA- oder Dienstkonto mit Operator-Rechten Checkmk-Spooldaten erzeugen. Diese Variante ist noch nicht Bestandteil der aktuellen Implementierung. Der komplette Checkmk-Agent sollte nicht allein fuer dieses Plugin auf eine andere Identitaet umgestellt werden, weil dies alle Agent-Sektionen und Local Checks betrifft.
| Key | Default |
| --- | --- |
| `Server` | `.` |
| `QueryTimeoutSeconds` | `25` |
| `ProbeSqlConnectivity` | `true` |
| `SqlConnectionTimeoutSeconds` | `5` |
| `ProbeEventLog` | `true` |
| `EventLogLookbackMinutes` | `60` |
Quellen:
Alarmierung:
| Key | Default |
| --- | --- |
| `WarnResumableThreshold` | `1` |
| `CritNonResumableThreshold` | `1` |
| `AlertOnArtifactRuntimeIssues` | `false` |
| `EmitPerApplicationSuspensionServices` | `false` |
| `EventLogWarnThreshold` | `1` |
| `EventLogCritThreshold` | `10` |
## 12. Tests und Abnahmekriterien
Automatisiert:
- Release-Build .NET Framework 4.7.2,
- exakt sechs Self-Test-Services,
- unbekannte Quellen werden `UNKNOWN`,
- dynamische Anwendungsservices nur bei bekannter Anwendung,
- WMI-Queryvertrag nutzt dokumentierte Properties,
- eingebetteter SQL-Loginfehler wird `Permission`,
- abgewiesener Principal wird extrahiert,
- Snapshot-Roundtrip und Ersatz,
- SHA-256-Manipulation wird verworfen,
- Stale-Snapshot wird verworfen,
- Consumer-Fallback enthaelt sechs `UNKNOWN`-Services.
Windows-/ACC-Abnahme:
1. `LastTaskResult=0`.
2. Snapshot wird mindestens dreimal minuetlich aktualisiert.
3. Provider-Log nennt das dedizierte Konto.
4. `BizTalk Platform` zeigt `read_only_group=`.
5. `BizTalk SQL Access`: `targets=2`, `available=2`.
6. keine Permission-`UNKNOWN`s.
7. ACL-Test: `LocalSystem` kann Snapshot lesen, nicht schreiben.
8. Task deaktivieren: nach 180 Sekunden sechs stale-`UNKNOWN`s.
9. Task wieder aktivieren: naechster Snapshot stellt Echtzustand her.
10. Agent-Dump und Checkmk Service Discovery erfolgreich.
Erst nach ACC-Abnahme erfolgt der gestufte Rollout nach DEV/TST/PRD.
## 13. Deinstallation und Rollback
```powershell
.\Uninstall-BizTalkCheckmkPulse.ps1
```
`-KeepRuntimeData` erhaelt Logs und Snapshot. Das Skript entfernt Task,
Wrapper und Programmdateien, aber keine AD-Gruppenmitgliedschaft. Die
Berechtigung wird separat nach Change-Verfahren entzogen.
Rollback auf die alte direkte `LocalSystem`-Architektur ist nicht empfohlen.
Falls kurzfristig notwendig, muss Security die Maschinenkonto-Berechtigung
explizit freigeben; der Checkmk-Agentdienst selbst darf nicht auf das
Collector-Konto umgestellt werden.
## 14. Transport per certutil
Die Source-Uebergabe besteht aus ZIP plus Base64-TXT:
```cmd
certutil -decode <datei>.zip.b64.txt <datei>.zip
certutil -hashfile <datei>.zip SHA256
tar -xf <datei>.zip
```
ZIP und Base64 werden erst nach dem Git-Commit aus genau diesem Commit erzeugt.
## 15. Referenzen
- https://learn.microsoft.com/en-us/biztalk/core/managing-biztalk-server-security
- https://learn.microsoft.com/en-us/biztalk/core/windows-groups-and-user-accounts-in-biztalk-server
- https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-groupsetting-biztalkreadonlyusergroup-property-wmi
- https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-groupsetting-wmi
- https://docs.checkmk.com/latest/en/agent_windows.html
- https://docs.checkmk.com/latest/en/localchecks.html
- https://learn.microsoft.com/en-us/biztalk/core/minimum-security-user-rights
- https://learn.microsoft.com/en-us/biztalk/core/access-control-and-data-security
- https://learn.microsoft.com/en-us/biztalk/core/windows-groups-and-user-accounts-in-biztalk-server
- https://learn.microsoft.com/en-us/biztalk/core/access-control-for-administrative-roles
- https://learn.microsoft.com/en-us/biztalk/core/how-to-modify-group-properties
- https://learn.microsoft.com/en-us/entra/architecture/service-accounts-computer
- https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adgroupmember
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/klist
- https://learn.microsoft.com/en-us/windows/win32/wmisdk/access-to-wmi-namespaces
## Resilienz
Das Plugin ist bewusst defensiv gebaut:
- Der dependency-freie Regressionstest laeuft mit dem gleichen .NET-Framework-/MSBuild-Baseline wie die Anwendung.
- WMI-Queries haben ein konfigurierbares Timeout.
- WMI-Namespace und Pflichtklassen werden getrennt auf Berechtigung, Konfiguration, Erreichbarkeit und Timeout geprueft.
- Management- und Master-MessageBox-Datenbank werden aus einer dokumentierten WMI-Klasse ermittelt und mit der echten Agent-Identitaet getestet.
- `InvalidClass`/`InvalidQuery` werden als Schemafehler statt als Berechtigungsproblem ausgewiesen.
- Host Instances werden ohne namensabhaengigen WQL-Filter clientseitig auf den ueberwachten Server begrenzt.
- Bereits fuer Runtime-Zustaende gelesene Artefakte werden fuer das Best-Effort-Application-Mapping wiederverwendet; doppelte WMI-Abfragen entfallen.
- SQL-Fehlernummern werden in Berechtigung, Erreichbarkeit, Timeout oder Providerfehler klassifiziert.
- Fehlgeschlagene Pflichtabfragen erzeugen `UNKNOWN` statt irrefuehrender Nullwerte.
- Optionale WMI-Klassen erzeugen Diagnosehinweise statt Totalabbruch.
- Fehlende Properties werden als leer/unknown behandelt.
- Local-Check-Ausgaben verwenden gueltige Checkmk-Zeilen mit genau vier Feldern.
- Fatal Errors erzeugen `UNKNOWN` fuer alle stabilen Services.
- Event-Log-Auswertung ist isoliert; ein Fehler dort bricht WMI-Monitoring nicht ab.
- Service-Namen sind stabil, damit Service Discovery nicht bei jedem Lauf neue Services erzeugt.
## Statusmodell
### BizTalk Platform
- `OK`: BizTalk-WMI erreichbar.
- `UNKNOWN`: WMI nicht erreichbar oder kompletter Programmfehler.
Dieser Service ist der Integrationsindikator. Wenn er `UNKNOWN` ist, sind Berechtigungen, BizTalk-Installation oder WMI-Repository zu pruefen.
### BizTalk SQL Access
- `OK`: Datenbankziele vollstaendig ermittelt und integrierte Anmeldung an allen Zielen erfolgreich.
- `UNKNOWN`: Zielermittlung unvollstaendig, Anmeldung verweigert, SQL nicht erreichbar, Timeout oder Providerfehler.
- Bei `ProbeSqlConnectivity=false`: `OK` mit sichtbarem Hinweis, dass die Probe deaktiviert ist.
Metriken: `biztalk_sql_targets_total`, `biztalk_sql_targets_available` und `biztalk_sql_targets_failed`. Die Ausgabe nennt ausserdem `execution_identity`, `network_identity` und den Zustand jedes getesteten Datenbankziels.
### BizTalk Suspended Instances
- `OK`: keine suspendierten Instanzen.
- `WARN`: mindestens `WarnResumableThreshold` resumable suspended instances.
- `CRIT`: mindestens `CritNonResumableThreshold` non-resumable suspended instances.
- `UNKNOWN`: Datenquelle nicht lesbar.
### BizTalk Host Instances
- `OK`: alle Host-Instanzen sind started.
- `WARN`: mindestens eine Host-Instanz ist pending.
- `CRIT`: mindestens eine Host-Instanz ist stopped oder unknown.
- `UNKNOWN`: keine Host-Instanzen gefunden oder Datenquelle nicht lesbar.
### BizTalk Runtime Artifacts
- `OK`: Artefakte lesbar, keine unbekannten Statuswerte.
- `WARN`: nur wenn `AlertOnArtifactRuntimeIssues=true` und deaktivierte/inaktive Artefakte vorhanden sind.
- `CRIT`: unbekannte Send-Port- oder Orchestration-Statuswerte.
- `UNKNOWN`: mindestens eine erforderliche WMI-Artefaktklasse nicht lesbar.
Deaktivierte Receive Locations und gestoppte Ports koennen in BizTalk fachlich korrekt sein. Deshalb ist die Alarmierung hier standardmaessig informativ.
### BizTalk Event Log
- `OK`: keine relevanten Fehler/Warnungen ueber Schwellwert.
- `WARN`: Fehler oder Warnungen ab `EventLogWarnThreshold`.
- `CRIT`: Fehler ab `EventLogCritThreshold`.
- `UNKNOWN`: Event Log nicht lesbar.
## Dashboard-Empfehlung
Pro Umgebung sollte der BizTalk-Host in einem eigenen Host-Ordner oder Host-Tag fuer `ACC`, `DEV`, `TST`, `PRD` liegen. Im Dashboard eignen sich:
- Service State Widgets fuer die sechs stabilen BizTalk-Services
- Graphen fuer `biztalk_sql_targets_failed`, `biztalk_suspended_total`, `biztalk_host_instances_stopped`, `biztalk_eventlog_errors`
- Hostgruppe/Ordner pro Umgebung
- Optional eine View gefiltert auf `Service starts with BizTalk`
Empfohlene Reihenfolge im Dashboard:
1. `BizTalk Platform`
2. `BizTalk SQL Access`
3. `BizTalk Suspended Instances`
4. `BizTalk Host Instances`
5. `BizTalk Event Log`
6. `BizTalk Runtime Artifacts`
7. SQL-Server-Services aus dem Checkmk-MSSQL-Plugin
## Rollout-Vorgehen
1. Build-Paket erzeugen.
2. In `DEV` auf dem BizTalk-Server installieren.
3. `--self-test` und normalen Lauf ausfuehren.
4. Agent-Dump pruefen.
5. Checkmk Discovery durchfuehren.
6. Eine Woche Messwerte und false positives beobachten.
7. Nach `TST` und `ACC` uebernehmen.
8. In `PRD` mit `AlertOnArtifactRuntimeIssues=false` starten.
9. Nach Betriebsfreigabe Schwellwerte feinjustieren.
## Troubleshooting
### Service bleibt UNKNOWN
Pruefen:
```cmd
"%ProgramData%\checkmk\agent\local\biztalk_checkmk_pulse.cmd"
```
Wenn WMI nicht erreichbar ist:
```cmd
wmic /namespace:\\root\MicrosoftBizTalkServer path MSBTS_HostInstance get HostName,RunningServer,ServiceState
```
Der Checkmk Windows Agent laeuft normalerweise als LocalSystem. Daher immer auch den Agent-Dump verwenden:
```cmd
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump
```
Die Diagnose im Service-Text nach `Massnahme:` abarbeiten. Wichtige Kategorien:
- `Wmi/Permission`: lokale Namespace-ACL oder BizTalk-Operator-Zuordnung pruefen.
- `Wmi/Schema`: Klasse/WQL gegen das installierte BizTalk-Schema pruefen; `InvalidClass` ist nicht durch zusaetzliche Rechte loesbar.
- `Sql/Permission`: Maschinenkonto `DOMAIN\BIZTALKSERVER$` und BizTalk-Operator-Gruppe pruefen.
- `Sql/Connectivity`: SQL-Server-/Instanzname, DNS, SQL-Dienst, TCP und Firewall pruefen.
- `Sql/Timeout`: SQL- und Netzwerkauslastung pruefen; Timeout nicht als erste Massnahme erhoehen.
Der direkte Aufruf des Wrappers kann wegen des angemeldeten Administratorkontos ein anderes Ergebnis liefern als der Agent-Dump. Fuer die Freigabe ist immer der Agent-Dump massgeblich.
### Keine Services in Discovery
Pruefen:
- Liegt `biztalk_checkmk_pulse.cmd` direkt unter `%ProgramData%\checkmk\agent\local`?
- Gibt der Wrapper direkt eine Zeile im Format `0 "Service" metric=value Details` aus?
- Wurde der Checkmk-Agent nach Policy-/Bakery-Aenderungen neu ausgerollt?
### Runtime Artifacts zeigt deaktivierte Artefakte
Das ist standardmaessig `OK`, damit gewollt deaktivierte BizTalk-Artefakte nicht alarmieren. Fuer strengere PRD-Standards:
```xml
<add key="AlertOnArtifactRuntimeIssues" value="true" />
```
## Weiterentwicklung
Sinnvolle naechste Ausbaustufen:
- MKP mit Agent-Bakery-Regel fuer zentrale Konfiguration.
- Optionales serverseitiges Check-Plugin nach Checkmk Check API V2.
- Custom Dashboard/View als Checkmk GUI Extension.
- Ergaenzung um MessageBox-Spool/Tracking-Daten, falls operativ benoetigt.
- https://docs.checkmk.com/latest/en/spool_directory.html