biztalk-checkmk-pulse/README.md

# BizTalk Checkmk Pulse

`BizTalk Checkmk Pulse` ist ein robuster Checkmk-2.4-Local-Check für Microsoft
BizTalk Server 2020 auf Windows Server 2019. Die Anwendung trennt den
berechtigten BizTalk-Datenzugriff vollständig vom Checkmk-Agenten:

![Architektur von BizTalk Checkmk Pulse mit Provider, Endpoint-Probes, Snapshot und Checkmk-Consumer](docs/architecture.svg)

Damit bekommt `LocalSystem` keine BizTalk- oder SQL-Berechtigung. Nur das
dedizierte Provider-Konto wird in die konfigurierte BizTalk Server Read Only
Users-Gruppe aufgenommen. Der Checkmk-Consumer liest keine BizTalk-Datenbank,
verwendet kein WMI und nimmt keine Identitätswechsel vor.

## Endpoint-Erreichbarkeitsprüfung

Der Provider prüft die netzwerktechnische Erreichbarkeit der externen Ziele
aktiver BizTalk Send Ports und Receive Locations. Die Funktion ist im eigenen
Checkmk-Service `BizTalk Endpoint Reachability` zusammengefasst:

- Berücksichtigt werden nur Send Ports mit `Status=Started` und Receive
  Locations mit `IsDisabled=false`. Dynamische Send Ports werden nicht als
  statisches Ziel interpretiert.
- Fehlt der lokale Endpoint-Katalog, wird er aus den bereits gelesenen
  `MSBTS_SendPort`- und `MSBTS_ReceiveLocation`-Daten aufgebaut. Alle
  168 Stunden erfolgt ein vollständiger Abgleich mit der BizTalk-Umgebung.
- HTTP(S), SFTP, FTP, WCF/`net.tcp` und UNC/SMB werden durch einen reinen
  TCP-Verbindungsaufbau zu Host und Port geprüft. Explizite
  `udp://host:port`-Ziele verwenden ein UDP-Datagramm.
- Scheduling-Komponenten werden vollständig aus der Endpoint-Prüfung
  ausgeschlossen. Oracle-`DATABASE`-Ziele werden aus
  `Database://host[:port]/.../Oracle` auf TCP 1521 beziehungsweise den
  expliziten Port reduziert. WCF-SAP nutzt den ersten SAProuter-Hop oder
  `ListenerGwHost`/`ListenerGwServ`; `sapgwNN` wird als TCP `33NN` aufgelöst.
- Automatisch abgeleitete DATABASE-/WCF-SAP-Probes sind Best-Effort:
  erfolgreiche Tests bleiben messbar, nicht ableitbare oder nicht erreichbare
  Ziele erzeugen jedoch weder `UNKNOWN` noch `WARN`/`CRIT`. Für verbindliche
  Alarmierung kann weiterhin ein manueller Katalogeintrag verwendet werden.
- Es werden weder HTTP-Aufrufe noch Anmeldungen, fachliche Requests oder
  BizTalk-Nachrichten gesendet. Der Check validiert DNS, Netzwerkpfad,
  Firewall und bei TCP einen annehmenden Zielport, nicht die fachliche
  Funktion des entfernten Dienstes.
- Im OK-Fall meldet Checkmk nur, dass alle aktiven Endpunkte erreichbar sind.
  Bei einem Fehler werden ausschließlich die nicht erreichbaren Endpunkte
  ausgegeben; lange Listen sind begrenzt, die Metriken bleiben vollständig.
- Doppelte Protokoll-/Host-/Port-Ziele werden nur einmal verbunden. Mit den Defaults
  benötigen 70 vollständig timeoutende eindeutige Ziele theoretisch etwa
  15 Sekunden; die harte Standardgrenze von 100 Zielen liegt bei etwa
  21 Sekunden.

Der Checkmk-Agent führt diese Netzwerkprobes nicht selbst aus. Er liest als
`LocalSystem` weiterhin ausschließlich den validierten lokalen Snapshot.
Details zum Katalog und zu manuellen Overrides stehen in
[docs/EndpointCatalog.md](docs/EndpointCatalog.md).

## Warum die Architektur geändert wurde

Der ACC-Test vom 29.07.2026 zeigte:

```text
Login failed for user 'BEW\AV23AGPWBIO1$'
```

Der Checkmk-Agent lief korrekt als `NT AUTHORITY\SYSTEM` und erreichte lokales
BizTalk-WMI. Datenbankgestützte WMI-Abfragen wurden jedoch am SQL Server als
Maschinenkonto `BEW\AV23AGPWBIO1$` abgewiesen. Eine Mitgliedschaft des
Computerkontos würde die BizTalk-Netzwerkberechtigung allen als `LocalSystem`
laufenden Diensten des Servers geben.

Die neue Trennung reduziert diesen Berechtigungsumfang. Für BizTalk Server
2020 ist die konfigurierte `BizTalk Server Read Only Users`-Gruppe mit der
SQL-Datenbankrolle `BTS_READONLY_USERS` die bevorzugte Grenze. Die
`BizTalk Server Operators`-Gruppe ist nur ein dokumentierter Fallback, wenn
eine konkret benötigte WMI-Klasse trotz bestätigter Read-Only-Zuordnung
abgewiesen wird. Direkte SQL-Logins, manuelle Datenbankrollen und `sysadmin`
sind keine Lösung.

## Robustheit

Der Datenaustausch ist bewusst defensiv:

- Der Provider schreibt zuerst eine eindeutige Temporärdatei im Zielordner,
  leert Betriebssystempuffer und ersetzt danach den Snapshot atomar.
- Der Snapshot enthält Formatversion, UTC-Zeit, Quellmaschine,
  Provider-Identität, Zeilenanzahl und SHA-256 des Payloads.
- Der Consumer akzeptiert nur denselben Rechner, gültiges UTF-8, intakte
  Checkmk-Zeilen, korrekte SHA-256-Prüfsumme und ein maximales Alter von
  standardmäßig 180 Sekunden.
- Fehlende, veraltete, abgeschnittene, manipulierte oder unlesbare Dateien
  ergeben neun gültige `UNKNOWN`-Services statt einer kaputten Agent-Ausgabe.
- Ein exklusives Lock und die Task-Einstellung `IgnoreNew` verhindern
  überlappende Providerläufe.
- Ein unerwarteter Providerfehler erzeugt nach Möglichkeit einen aktuellen
  `UNKNOWN`-Snapshot und einen ungleich null lautenden Task-Exitcode.
- Provider und Consumer protokollieren in tägliche Dateien; die Aufbewahrung
  ist standardmäßig 30 Tage.
- Jeder Installations-/Updatelauf schreibt zusätzlich ein eigenes
  `setup-*.log` mit Phase, Binary-Version, Self-Test-Ausgabe,
  Task-Scheduler-Status, Exception-Kette und Rollback-Ergebnis. Kennwörter
  werden nicht an das Logging übergeben.
- Snapshotgröße, WMI-/SQL-Timeouts, Log-Retention und Stale-Grenze sind
  begrenzt und konfigurierbar.

## Erzeugte Services

Standardmäßig entstehen:

- `BizTalk Platform`
- `BizTalk SQL Access`
- `BizTalk Suspended Instances`
- `BizTalk Host Instances`
- `BizTalk Receive Locations`
- `BizTalk Send Ports`
- `BizTalk Endpoint Reachability`
- `BizTalk Orchestrations`
- `BizTalk Event Log`

Die drei Artefaktbereiche sind absichtlich getrennte Services. Dadurch sind
Zustand und Graphen direkt erkennbar, ohne eine lange Sammelzeile zu lesen:

- Suspensions: total, resumable, non-resumable und Routing Failure Reports
- Receive Locations: total, enabled, unerwartet/bewusst disabled und unbekannt
- Send Ports: total, started, stopped, bound, unbekannt sowie bewusst inactive
- Endpoint Reachability: nur aktive Send-/Receive-Artefakte; im OK-Fall nur
  eine Gesamtaussage, im Fehlerfall ausschließlich nicht erreichbare oder
  wirklich unaufgelöste Ziele
- Orchestrations: total, started, stopped, bound, unbound und unbekannt

Der Provider nutzt für die Endpoint-Discovery keine neue WMI-Klasse. Er liest
`PTAddress`, `STAddress`, `PTTransportType`, `STTransportType`,
`InboundTransportURL` und `AdapterName` aus den bereits vorhandenen
`MSBTS_SendPort`-/`MSBTS_ReceiveLocation`-Abfragen. Der Check selbst ist ein
reiner Host/Port-Test: HTTP(S), SFTP, FTP, WCF/net.tcp, WCF-SQL/mssql und UNC
werden per TCP geprüft; explizite `udp://`-Ziele per UDP-Datagramm. Es werden
keine HTTP-Requests, Anmeldungen oder fachlichen Nachrichten gesendet.
Auch schemafreie `host:port`-Angaben sowie FTP-/SFTP-Adressen der Form
`[benutzer@]host[:port]/pfad` werden erkannt; Benutzer und Pfad werden dabei
nicht in den Endpoint-Katalog übernommen.

Nicht jede aktive BizTalk-Adresse ist selbst ein Socket-Ziel. Dynamische Send
Ports, lokale Pfade, SMTP-Empfänger, Named Pipes, relative HTTP-/WCF-
Receive-Listener, Scheduling-Komponenten sowie nicht sicher ableitbare
DATABASE-/WCF-SAP-Adressen werden deshalb als erwartbar nicht socket-prüfbar
behandelt und erzeugen kein `UNKNOWN`. Nur eine andere aktive statische
Adresse, die tatsächlich ein Netzwerkziel enthalten müsste und nicht sicher
aufgelöst werden kann, bleibt `UNKNOWN` und wird geheimnisfrei mit Artefakt,
Adapter und Grund genannt.

Der geheimnisfreie Katalog liegt unter
`%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml`. Fehlt er, wird er beim
nächsten erfolgreichen Providerlauf erstellt. Alle 168 Stunden wird er gegen
die Umgebung abgeglichen. Automatisch verwaltete Einträge für inzwischen
inaktive Artefakte verschwinden beim Abgleich; bei jedem Minutenlauf werden
sie zusätzlich gegen den aktuellen Started-/Enabled-Zustand gefiltert.

Pro Service werden standardmäßig maximal fünf betroffene Namen gezeigt.
Weitere Treffer erscheinen nur als `(+n more)`; Details sind zusätzlich auf
1600 Zeichen begrenzt. Metriken bleiben trotzdem vollständig.

`EnvironmentName=ACC`, `DEV`, `TST` oder `PRD` kennzeichnet Snapshot und
Endpoint-Katalog. Die neun Checkmk-Servicenamen bleiben standardmäßig
unverändert. Nur das explizite Opt-in
`IncludeEnvironmentInServiceName=true` ergänzt die Umgebung im Servicenamen
und verlangt anschließend eine Checkmk Service Discovery.

Statuslogik und Metriken: [docs/CheckmkServices.md](docs/CheckmkServices.md)

Beispielausgaben: [docs/ExampleOutput.md](docs/ExampleOutput.md)

Endpoint-Katalog, manuelle Overrides und Protokollgrenzen:
[docs/EndpointCatalog.md](docs/EndpointCatalog.md)

Die RTM-Adapterregeln und ihre Herstellerquellen sind in
[docs/RTM-Endpoint-Adapterregeln-2026-08-11.md](docs/RTM-Endpoint-Adapterregeln-2026-08-11.md)
festgehalten.

## Voraussetzungen

Build-Host:

- Visual Studio 2019/2022 Build Tools oder Visual Studio
- MSBuild im `PATH`
- .NET Framework 4.7.2 Developer Pack

BizTalk-Server:

- Windows Server 2019
- BizTalk Server 2020 und lokaler Namespace
  `root\MicrosoftBizTalkServer`
- .NET Framework 4.7.2
- Checkmk Windows Agent
- administrativer Zugriff für die einmalige Installation
- normales dediziertes AD-Servicekonto für den Provider

Das Provider-Konto benötigt:

- lokales Recht zur Ausführung als Scheduled Task
- lokalen Lese-/Ausführungszugriff auf die installierte EXE
- Schreibzugriff nur auf Snapshot- und Logverzeichnis
- Mitgliedschaft in der exakt konfigurierten BizTalk Server Read Only
  Users-Gruppe

Es soll weder lokaler Administrator noch SQL-`sysadmin` sein. Der Scheduled
Task läuft mit `RunLevel Limited`. Das Servicekonto braucht ein gespeichertes
Task-Kennwort und das Recht `Log on as a batch job`. Ein gMSA bleibt optional,
ist aber für diese Installation nicht vorausgesetzt.

## Build und Tests

```cmd
scripts\build-release.cmd
scripts\test-release.cmd
scripts\package-release.cmd
```

Jeder Release-Build der Solution erzeugt automatisch den fertigen Paketordner
und das transportierbare ZIP:

```text
artifacts\
  BizTalkCheckmkPulse-Setup.zip
  BizTalkCheckmkPulse-Setup\
    Setup.exe
    INSTALLATION.md
    biztalk_checkmk_pulse.cmd
    application\
      BizTalkCheckmkPulse.exe
      BizTalkCheckmkPulse.exe.config
```

Das Packaging-Projekt ist Teil von `BizTalkCheckmkPulse.sln`. Ein normaler
`Release`-Build in Visual Studio 2019 genügt daher; ein separates
PowerShell-/WiX-/MSI-Tooling wird nicht benötigt.

Format-Self-Test ohne WMI, SQL oder Event Log:

```cmd
artifacts\BizTalkCheckmkPulse-Setup\application\BizTalkCheckmkPulse.exe --self-test
```

Erwartet werden exakt neun `OK`-Zeilen. Die Regressionstests prüfen
zusätzlich Snapshot-Roundtrip, atomaren Ersatz, SHA-256-Manipulation,
Stale-Erkennung, stabile Fallbacks, den exakten Servicevertrag, erzwungene
Katalogaktualisierung sowie erfolgreiche und abgewiesene
Post-Install-Runtime-Abnahmen.
Ein Mono-Build ist eine hilfreiche Quellcodeprüfung, ersetzt aber nicht die
Windows-/BizTalk-Laufzeitvalidierung.

## Berechtigung vorbereiten

Die exakte Read-Only-Gruppe wird in der BizTalk Administration Console unter
den Eigenschaften der BizTalk-Gruppe abgelesen.

Ein AD-Administrator nimmt das neue Provider-Konto in
`BizTalkReadOnlyUserGroup` auf. Nach AD-Replikation muss das Servicekonto durch
einen neuen Tasklauf einen neuen Anmeldetoken erhalten.

Die BizTalk-Konfiguration muss die Domain-Gruppe bereits als Windows-Login und
in `BizTalkMgmtDb`, `BizTalkMsgBoxDb`, `BizTalkDTADb`,
`BizTalkRuleEngineDb` sowie gegebenenfalls `BAMPrimaryImport` mit
`BTS_READONLY_USERS` abbilden. Eine fehlende Abbildung wird durch BizTalk- und
SQL-Administration für die Gruppe repariert, nicht als Einzelberechtigung
für das Provider-Konto.

## Installation mit normalem Servicekonto

1. `BizTalkCheckmkPulse-Setup.zip` auf dem Zielserver vollständig entpacken.
2. `Setup.exe` starten und die UAC-Abfrage bestätigen.
3. Collector-Konto, zum Beispiel `BEW\t231bizmon`, Kennwort und Umgebung
   eingeben.
4. **Installieren / aktualisieren** wählen.

Der Installer übergibt das Kennwort direkt über die Windows-Task-Scheduler-
COM-Schnittstelle. Es steht weder in einer Prozesskommandozeile noch in der
Konfigurationsdatei oder in Logs. Der Backslash in `DOMAIN\Benutzer` wird als
normaler Bestandteil des Kontonamens verarbeitet.

Wenn das Kennwort rotiert oder abläuft, muss es im Scheduled Task aktualisiert
werden. Dazu `Setup.exe` mit dem neuen Kennwort erneut ausführen. Bis dahin
wird der Snapshot nach 180 Sekunden stale und Checkmk zeigt alle neun Services
als `UNKNOWN`.

Ein gMSA kann über die Checkbox ohne Kennworteingabe installiert werden; die
produktive Standardbeschreibung geht vom normalen Servicekonto aus.

Der Installer (ab Version 2.2.6):

1. prüft Paket und Staging zwingend auf neun Self-Test-Zeilen, bevor der
   bestehende Task angehalten wird. Der Servicevertrag der installierten
   Legacy-Version darf weniger gültige Zeilen enthalten,
2. baut die neue Version in einem Staging-Verzeichnis auf und übernimmt
   vorhandene AppSettings; neue Keys erhalten ihre neuen Defaults. Die alten
   unveränderten Endpoint-Defaults `12`/`500` werden auf `16`/`100` migriert,
3. vergleicht installierten und neuen Checkmk-Servicevertrag. Rein additive
   Services werden zugelassen und als Discovery-Hinweis gemeldet; entfernte
   oder umbenannte Services stoppen ohne ausdrückliche Bestätigung vor jeder
   Umschaltung,
4. schaltet die Programmdateien per Verzeichniswechsel um,
5. startet einen triggerlosen Provider-Abnahmelauf unter dem echten
   Collector-Konto und erzwingt einen vollständigen Endpoint-Katalogabgleich,
6. wartet höchstens vier Minuten auf `LastTaskResult=0`, bricht bei einem
   bereits abgeschlossenen Fehlerlauf sofort mit Dezimal-/Hexcode ab und validiert danach
   mit der Produkt-EXE einen erst nach Installationsbeginn erzeugten Snapshot,
   die Collector-Identität, alle neun eindeutigen Services sowie den frischen,
   maschinen- und umgebungsgebundenen Endpoint-Katalog. `UNKNOWN` in einem
   Kernservice bleibt ein Abnahmefehler. Ein ausschließlich bei
   `BizTalk Endpoint Reachability` auftretendes `UNKNOWN` wird als sichtbare
   Betriebswarnung übernommen, weil es eine unvollständige Prüfabdeckung und
   keinen defekten Installationslauf beschreibt,
7. registriert erst nach dieser Abnahme den normalen Minutentask; andernfalls
   werden vorherige Version, Wrapper und Task samt frischem Altsnapshot
   wiederhergestellt,
8. behält `%ProgramData%\BizTalkCheckmkPulse` mit Endpoint-Katalog, Snapshot
   und Logs bei. Das laufbezogene Setup-Log enthält auch die vollständige
   Self-Test-Ausgabe sowie bei Abnahmefehlern die letzten Provider-Logzeilen,
9. installiert EXE und Config nach `%ProgramFiles%\BizTalkCheckmkPulse`, setzt
   explizite ACLs für Administratoren, Provider und `LocalSystem` und
   installiert nur den kleinen `.cmd`-Consumer unter
   `%ProgramData%\checkmk\agent\local`,
10. registriert `BizTalk Checkmk Pulse Provider` minütlich mit `IgnoreNew`,
    fünf Minuten Laufzeitlimit und zwei Wiederholungen.

Installation, Update, Deinstallation und Laufzeit verwenden keine PowerShell.

## Verifikation auf dem Server

Task und letzter Lauf:

```cmd
schtasks.exe /query /tn "BizTalk Checkmk Pulse Provider" /v /fo list
```

Provider-Log:

```cmd
dir /o-d "%ProgramData%\BizTalkCheckmkPulse\logs"
type "%ProgramData%\BizTalkCheckmkPulse\logs\biztalk-checkmk-pulse-*.log"
type "%ProgramData%\BizTalkCheckmkPulse\logs\setup-*.log"
```

Die Analyse des in Version 2.2.4 beobachteten Abbruchs mit
`Exitcode=0, Zeilen=8` ist in
[docs/Installer-Self-Test-Analyse-2026-08-11.md](docs/Installer-Self-Test-Analyse-2026-08-11.md)
dokumentiert.

Der nachfolgende ACC-Abbruch mit einem technisch validen Snapshot und
`UNKNOWN=[BizTalk Endpoint Reachability]` ist in
[docs/Installer-Runtime-Unknown-Analyse-2026-08-11.md](docs/Installer-Runtime-Unknown-Analyse-2026-08-11.md)
analysiert. Der Zustand wird nicht grüngefärbt: Setup 2.2.6 schließt ab und
gibt die vollständige UNKNOWN-Zeile als Warnung aus; Checkmk behält Status 3.

Snapshot und Consumer:

```cmd
dir "%ProgramData%\BizTalkCheckmkPulse\data\biztalk-checkmk-pulse.snapshot"
"%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe" --consume
```

Verbindlicher Test im echten `LocalSystem`-Kontext:

```cmd
"C:\Program Files (x86)\checkmk\service\cmk-agent-ctl.exe" dump
```

Danach in Checkmk eine Service Discovery ausführen, die neun Services
aufnehmen und Changes aktivieren. Ein zusätzlicher Checkmk-Async-Cache ist
nicht erforderlich: Der Consumer liest nur eine kleine lokale Datei und der
Provider besitzt bereits seinen eigenen Minutentakt.

## Dateisystem und Sicherheitsgrenzen

```text
%ProgramFiles%\BizTalkCheckmkPulse\
  BizTalkCheckmkPulse.exe
  BizTalkCheckmkPulse.exe.config

%ProgramData%\BizTalkCheckmkPulse\
  data\
    biztalk-checkmk-pulse.snapshot
    biztalk-checkmk-pulse.snapshot.provider.lock
    endpoints.xml
  logs\
    biztalk-checkmk-pulse-YYYYMMDD.log

%ProgramData%\checkmk\agent\local\
  biztalk_checkmk_pulse.cmd
```

ACL-Soll:

| Pfad | Provider | LocalSystem | Administratoren |
| --- | --- | --- | --- |
| Programm | Lesen/Ausführen | Lesen/Ausführen | Vollzugriff |
| `data` | Ändern | Lesen/Ausführen | Vollzugriff |
| `logs` | Ändern | Ändern | Vollzugriff |

Der Snapshot enthält Monitoringzustand und kompakte Fehlerdetails, aber keine
Passwörter oder Nachrichteninhalte. Der Consumer validiert die Datei trotzdem
vollständig, bevor er sie an Checkmk weitergibt.

## Konfiguration

Datei:

```text
%ProgramFiles%\BizTalkCheckmkPulse\BizTalkCheckmkPulse.exe.config
```

Wichtige Werte:

| Key | Default | Bedeutung |
| --- | --- | --- |
| `EnvironmentName` | leer | Optional `ACC`, `DEV`, `TST`, `PRD`. |
| `IncludeEnvironmentInServiceName` | `false` | Nur mit geplanter Service Discovery aktivieren. |
| `SnapshotPath` | `%ProgramData%\BizTalkCheckmkPulse\data\...` | Gemeinsame Provider-/Consumer-Datei. |
| `SnapshotMaxAgeSeconds` | `180` | Ab diesem Alter liefert der Consumer `UNKNOWN`. |
| `SnapshotMaxBytes` | `1048576` | Harte Eingabegröße für den Consumer. |
| `LogDirectory` | `%ProgramData%\BizTalkCheckmkPulse\logs` | Tageslogs. |
| `LogRetentionDays` | `30` | Provider bereinigt ältere Logs. |
| `ProbeEndpointConnectivity` | `true` | Aktiviert den aggregierten TCP-/UDP-Netzwerkcheck. |
| `EndpointCatalogPath` | `%ProgramData%\BizTalkCheckmkPulse\data\endpoints.xml` | Lokal gepflegte Endpoint-Konfiguration ohne vollständige URIs/Secrets. |
| `EndpointCatalogMaxEntries` | `1000` | Harte Größenbegrenzung für Artefakte im Katalog. |
| `EndpointDiscoveryIntervalHours` | `168` | Intervall für den vollständigen Umgebungsabgleich. |
| `EndpointProbeTimeoutMilliseconds` | `3000` | Timeout je dedupliziertem Host/Port-Ziel. |
| `EndpointProbeMaxConcurrency` | `16` | Begrenzte parallele Socket-Probes. |
| `EndpointMaxCount` | `100` | Obergrenze eindeutiger Host/Port/Protokoll-Ziele und damit Laufzeitbudget; bei 3 s Timeout theoretisch maximal etwa 21 s. |
| `QueryTimeoutSeconds` | `25` | WMI-Timeout je Query. |
| `SqlConnectionTimeoutSeconds` | `5` | SQL-Timeout je Ziel. |
| `WarnResumableThreshold` | `1` | WARN ab n resumable Suspensions. |
| `CritNonResumableThreshold` | `1` | CRIT ab n non-resumable Suspensions. |
| `CritRoutingFailureThreshold` | `1` | CRIT ab n Routing Failure Reports. |
| `AlertOnArtifactRuntimeIssues` | `true` | Unerwartet deaktivierte Receive Locations bzw. inaktive Send Ports werden CRIT. |
| `ExpectedDisabledReceiveLocations` | leer | Pipe-getrennte exakte Allowlist: `Name` oder `Anwendung\Name`. |
| `ExpectedInactiveSendPorts` | leer | Pipe-getrennte exakte Allowlist: `Name` oder `Anwendung\Name`. |
| `AlertOnInactiveOrchestrations` | `false` | Optional WARN für stopped/bound/unbound Orchestrations. |
| `MaxSummaryItems` | `5` | Maximal angezeigte betroffene Artefakte je Service. |
| `MaxDetailCharacters` | `1600` | Harte Obergrenze für Checkmk-Summary. |
| `EmitPerApplicationSuspensionServices` | `false` | Zusätzliche Anwendungsservices. |
| `EventLogLookbackMinutes` | `60` | Event-Log-Zeitfenster des Providers. |

Nach einer Config-Änderung den Scheduled Task manuell starten. Der Consumer
liest den nächsten atomar publizierten Snapshot.

## Fehlerbilder

| Beobachtung | Ursache / Maßnahme |
| --- | --- |
| Alle neun Services melden fehlenden Snapshot | Task, Provider-Log, Task-Konto/Kennwort und ACL prüfen. |
| Snapshot ist `stale` | `LastTaskResult`, Laufzeit, WMI-/SQL-Timeout und Log prüfen. |
| SHA-256 oder Format ungültig | Datei nicht manuell bearbeiten; Datenträger/AV und Schreibpfad prüfen, Task neu starten. |
| Provider meldet `Login failed` | Provider-Konto und exakt konfigurierte Read-Only-Gruppe sowie `BTS_READONLY_USERS` prüfen. |
| Receive Locations / Send Ports sind CRIT | `affected=` prüfen; nur fachlich bewusst inaktive Namen exakt in die jeweilige Allowlist aufnehmen. |
| Endpoint Reachability ist CRIT | Nur `unavailable=` prüfen; DNS, Zielport, Firewall und externen Dienst kontrollieren. |
| Endpoint Reachability ist UNKNOWN | `unresolved_endpoints=`, WMI-Vollständigkeit, `endpoints.xml` und wöchentlichen Refresh prüfen. Schedule sowie nicht ableitbare DATABASE-/WCF-SAP-Ziele sind ab 2.2.7 bereits ausgenommen; andere indirekte Ziele bei Bedarf geheimnisfrei manuell überschreiben. |
| `Wmi/Schema` | Klasse/Properties gegen BizTalk-2020-Schema prüfen; keine Rechte ausweiten. |
| Nur Event Log `UNKNOWN` | lokalen Application-Log-Zugriff des Provider-Kontos prüfen. |
| Task-Result `2` | Parallelstart oder Snapshot-I/O; Log und Lock/ACL prüfen. |

Ausführliche Betriebs- und Architekturdetails stehen in
[Dokumentation.md](Dokumentation.md).

## Deinstallation

`Setup.exe` erneut starten und **Deinstallieren** wählen. Snapshot und Logs
bleiben dabei unter `%ProgramData%\BizTalkCheckmkPulse` erhalten.

Die AD-Gruppenmitgliedschaft des Provider-Kontos wird bewusst nicht automatisch
geändert und muss separat durch AD-/BizTalk-Administration entfernt werden.

## Quellen

- Microsoft: BizTalk `MSBTS_GroupSetting.BizTalkReadOnlyUserGroup`
- Microsoft: Windows Groups and User Accounts in BizTalk Server
- Microsoft: Managing BizTalk Server Security
- Microsoft: [`MSBTS_SendPort` (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-sendport-wmi)
- Microsoft: [`MSBTS_ReceiveLocation` (WMI)](https://learn.microsoft.com/en-us/biztalk/core/technical-reference/msbts-receivelocation-wmi)
- Microsoft: [SQL-Adapter-Verbindungs-URI](https://learn.microsoft.com/en-us/biztalk/adapters-and-accelerators/adapter-sql/create-the-sql-server-connection-uri)
- Microsoft: [Oracle-Database-Adapter-Verbindungs-URI](https://learn.microsoft.com/en-us/biztalk/adapters-and-accelerators/adapter-oracle-database/create-the-oracle-database-connection-uri)
- Checkmk: Windows Agent und Local Checks

Die genauen Links stehen in [Dokumentation.md](Dokumentation.md).