Fix legacy installer updates and diagnostics

docs/ACC-Endpoint-Reachability-Analyse-2026-08-10.md

@@ -139,7 +139,7 @@ Endpoint-/Namensfix bewusst nicht grüngefärbt.
 
 ## ACC-Abnahme nach Installation
 
-1. Setup 2.2.4 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
+1. Setup 2.2.5 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
    Beim Wechsel von der fehlerhaften 2.2.1-Ausgabe `BizTalk ACC ...` auf die
    stabilen Namen die Rename-/Discovery-Checkbox bewusst aktivieren.
 2. In der installierten Config bestätigen:

docs/Installer-Self-Test-Analyse-2026-08-11.md

@@ -0,0 +1,68 @@
+# Analyse: Update-Abbruch mit `Exitcode=0, Zeilen=8`
+
+## Beobachtung
+
+Der Installer meldete nach erfolgreicher Paketprüfung, Anmeldung und
+Staging-Validierung:
+
+```text
+Installation/Update fehlgeschlagen. Rollback erfolgreich.
+Ursache: Self-Test fehlgeschlagen. Exitcode=0, Zeilen=8.
+```
+
+Die Reihenfolge im Statusfenster zeigt, dass das neue Paket und das Staging
+bereits erfolgreich neun Services geliefert hatten. Der danach ausgeführte
+Self-Test gehörte zur noch installierten Ausgangsversion.
+
+## Ursache
+
+Version 2.2.4 verwendete dieselbe starre Erwartung von exakt neun Zeilen für
+beide Seiten des Updatevergleichs. Eine ältere, intakte Installation vor
+Einführung von `BizTalk Endpoint Reachability` liefert jedoch acht gültige
+Checkmk-Zeilen und Exitcode 0. Der Updater deutete diese erwartete
+Versionsdifferenz fälschlich als defekten Self-Test. Der Abbruch erfolgte vor
+dem Stoppen des Tasks und vor dem Austausch von Dateien. Die Meldung
+`Rollback erfolgreich` war deshalb technisch irreführend; es war keine
+Systemänderung zurückzusetzen.
+
+## Korrektur in Version 2.2.5
+
+- Paket, Staging und aktivierte Zielversion müssen weiterhin exakt neun
+  eindeutige `OK`-Zeilen liefern.
+- Die installierte Ausgangsversion darf eine andere positive Anzahl
+  eindeutiger `OK`-Zeilen liefern. Damit wird ihr tatsächlicher
+  versionsspezifischer Servicevertrag gelesen.
+- Rein neu hinzukommende Services sind updatekompatibel. Sie werden als
+  Discovery-Hinweis gemeldet, blockieren aber die Umschaltung nicht.
+- Entfernte Namen – und damit auch Renames – bleiben ohne aktivierte
+  Discovery-Bestätigung ein Sicherheitsstopp.
+- Tritt ein Fehler vor der ersten Systemänderung auf, lautet der Status jetzt
+  `kein Rollback erforderlich`.
+
+## Erweiterte Diagnose
+
+Jeder Lauf erzeugt
+`%ProgramData%\BizTalkCheckmkPulse\logs\setup-<UTC>-<PID>.log`. Das Log enthält:
+
+- aktuelle Installationsphase und Setup-Version,
+- Pfad, Dateiversion und Größe jeder geprüften EXE,
+- erwartete und tatsächliche Zeilenzahl, Exitcode sowie vollständiges stdout
+  und stderr jedes Self-Tests,
+- Task-Scheduler-State und `LastTaskResult` dezimal und hexadezimal,
+- vollständige Exception-Kette mit HRESULT und Stacktrace,
+- bei Runtime-Abnahmefehlern bis zu 40 letzte Provider-Logzeilen,
+- Ergebnis jedes Rollback-Schritts.
+
+Das Kennwort wird ausschließlich an `LogonUser` und die
+Task-Scheduler-COM-Schnittstelle übergeben. Die Logging-Komponente erhält es
+nicht.
+
+## Regressionstests
+
+Automatisiert geprüft werden insbesondere:
+
+- acht gültige Zeilen einer Legacy-Ausgangsversion werden akzeptiert,
+- acht Zeilen eines neuen Stagings werden weiterhin abgewiesen,
+- eine reine Service-Erweiterung wird ohne Rename-Bestätigung akzeptiert,
+- ein frisch beendeter Task mit Fehlercode wird sofort erkannt und der Code
+  enthält zusätzlich die hexadezimale Darstellung.

docs/Integration.md

@@ -53,7 +53,7 @@ Verbindlicher Agent-Dump:
 
 ## Service Discovery
 
-Das Setup 2.2.4 schließt erst erfolgreich ab, nachdem der erste Providerlauf
+Das Setup ab 2.2.4 schließt erst erfolgreich ab, nachdem der erste Providerlauf
 unter dem echten Collector-Konto einen frischen Snapshot und – bei aktivierter
 Endpoint-Prüfung – einen frisch synchronisierten Katalog erzeugt hat. Die neun
 stabilen Services müssen vollständig und ohne `UNKNOWN` vorliegen. Diese lokale
@@ -64,6 +64,14 @@ Servicenamen aber standardmäßig nicht. Nur das bewusste Opt-in
 `IncludeEnvironmentInServiceName=true` erzeugt umgebungsabhängige Namen und
 verlangt den anschließenden Discovery-Abgleich.
 
+Ab Setup 2.2.5 darf der gültige Servicevertrag der installierten
+Ausgangsversion weniger als neun Services enthalten. So ist das Update einer
+Legacy-Version mit acht Services möglich; nur Paket, Staging und Zielversion
+müssen exakt neun Services liefern. Additive Services werden gemeldet, aber
+nicht blockiert. Entfernte oder umbenannte Services erfordern weiterhin die
+bewusste Bestätigung im Setup. Laufbezogene Details stehen in
+`%ProgramData%\BizTalkCheckmkPulse\logs\setup-*.log`.
+
 1. Provider dreimal erfolgreich laufen lassen.
 2. `LastTaskResult=0`, frischen Snapshot und Log prüfen.
 3. Agent-Dump im `LocalSystem`-Kontext prüfen.