Harden installer update activation fallback

docs/Installer-Stabilitaetsanalyse-2026-08-11.md

@@ -12,7 +12,7 @@ Vor Version 2.1.0 enthielt das Repository keinen Installer für die C#-Anwendung
 - Update nur bei geschlossener produktiver Toolinstanz.
 - Staging und Backup als eindeutige Geschwister des Installationsverzeichnisses auf demselben Volume.
 - Acht begrenzte Move-Versuche mit 250, 500, 1.000, 2.000, 3.000, 5.000 und 8.000 ms Backoff zwischen den Versuchen.
-- SHA-256-verifizierter Kopierfallback ausschließlich für eine Neuinstallation ohne aktive Vorversion; Updates bleiben strikt atomar.
+- SHA-256-verifizierter Kopierfallback für eine Neuinstallation ohne Ziel oder für eine Update-Aktivierung nach vollständig atomar gesicherter Vorversion; niemals als In-place-Update.
 - Zweiter Self-Test nach Aktivierung und vor Windows-Registrierung.
 - Automatisches Datei- und Registrierungsrollback bei Fehlern.
 - Dauerhaftes phasenbezogenes Installerlog unter ProgramData.
@@ -26,7 +26,7 @@ Vor Version 2.1.0 enthielt das Repository keinen Installer für die C#-Anwendung
 ## Lokal verifiziert
 
 - Release-Build aller Projekte mit Mono MSBuild.
-- Siebzehn Regressionstests einschließlich manipulierter/zusätzlicher/ausbrechender Payload-Pfade, Staging-Abbruch ohne Mutation, transienter Move-Erholung, verifiziertem Neuinstallationsfallback, begrenztem Updateabbruch, erzwungenem Fehler des zweiten Self-Tests mit Wiederherstellung der Vorversion, Deinstallation über ein Quarantäneverzeichnis, Diagnosekontext, Log-Fallback und Fehlerisolierung der UI-Ausgabe.
+- Neunundzwanzig Regressionstests einschließlich manipulierter/zusätzlicher/ausbrechender Payload-Pfade, Staging-Abbruch ohne Mutation, transienter Move-Erholung, verifiziertem Neuinstallations- und Updatefallback, begrenztem Updateabbruch, erzwungenem Fehler des zweiten Self-Tests mit Wiederherstellung der Vorversion, Deinstallation über ein Quarantäneverzeichnis, Diagnosekontext, Log-Fallback und Fehlerisolierung der UI-Ausgabe.
 - WMI-freier Self-Test der produktiven EXE.
 - Erstellung des Installationsordners, ZIPs, Base64-TXTs und der SHA-256-Datei.
 - Rückdekodierung der Base64-TXT und Bytevergleich mit dem ZIP.

docs/PROD-Installer-Aktivierungsfehler-2026-08-24.md

@@ -0,0 +1,52 @@
+# PROD-Installer-Aktivierungsfehler vom 24.08.2026
+
+## Kurzbefund
+
+Der Screenshot zeigt nicht den aktuellen Repository-Stand, sondern `BizTalk Platform Management Tool 2.1.2`. Der Lauf bestand um 12:40:59 die Staging-Prüfung und scheiterte unmittelbar danach in Phase 3 mit:
+
+```text
+SETUP-ACTIVATION
+System.InvalidOperationException: Installation/Update fehlgeschlagen
+System.IO.IOException: Access to the path
+'C:\Program Files\BizTalkPlatformManagementTool.staging.<guid>' is denied.
+at System.IO.Directory.InternalMove(...)
+```
+
+Die Abschlussmeldung enthält `Kein Rollback erforderlich`. Im 2.1.2-Code bedeutet das, dass weder ein vorhandenes Installationsverzeichnis ins Backup verschoben noch ein neues Ziel aktiviert wurde. Der Fehler trat somit an der ersten Systemmutation auf; Paketkopie und Staging-Self-Test waren bereits erfolgreich.
+
+## Ursachenbewertung
+
+Version 2.1.2 führte für die Aktivierung genau einen `Directory.Move` aus. `Access denied` beim Umbenennen des vollständig erstellten und bereits ausführbaren Staging-Verzeichnisses ist mit einer kurzzeitigen Loader-/Virenscanner-/EDR-Sperre oder einer auf Rename/Delete beschränkten Richtlinie vereinbar. Der Screenshot allein identifiziert den blockierenden Prozess nicht. Er belegt aber:
+
+- kein Manifest- oder SHA-256-Fehler,
+- keinen Fehler des WMI-freien Staging-Self-Tests,
+- keinen BizTalk-Laufzeitfehler,
+- keinen erforderlichen Rollback einer aktiven Version,
+- einen Fehler beim Verzeichnis-Rename unter `C:\Program Files`.
+
+Der gleiche 2.1.2-Codepfad war bereits am 11.08.2026 in ACC aufgefallen. Der damals ab 2.1.3 ergänzte Retry- und Neuinstallationsfallback war in der auf dem Screenshot ausgeführten Datei noch nicht enthalten.
+
+## Fix in Version 2.2.3
+
+Version 2.2.3 enthält die bereits vorhandenen acht begrenzten Move-Versuche mit 250, 500, 1.000, 2.000, 3.000, 5.000 und 8.000 ms Backoff. Bleibt ausschließlich der Staging-Rename gesperrt, wird die validierte Payload in das fehlende Ziel kopiert und jede Zieldatei erneut gegen das Manifest geprüft.
+
+Der Fix deckt jetzt beide sicheren Situationen ab:
+
+1. Neuinstallation: Es existiert kein Installationsziel.
+2. Update: Die vollständige Vorversion wurde zuvor atomar ins Backup verschoben und das Installationsziel existiert nicht mehr.
+
+Der Fallback überschreibt niemals eine aktive Installation. Bei einem Update bleibt das Backup während Kopie, Hashprüfung und zweitem Self-Test erhalten. Scheitert einer dieser Schritte, entfernt der Installer die teilweise neue Version und stellt das Backup wieder her. Kann schon das Backup nicht atomar erzeugt werden, bleibt die Vorversion unverändert aktiv und es gibt keinen Kopierfallback.
+
+Zwei neue Failure-Injection-Regressionstests belegen den erfolgreichen Updatefallback und die vollständige Wiederherstellung der Vorversion nach einem erzwungen fehlgeschlagenen Ziel-Self-Test.
+
+## Vorgehen in PROD
+
+1. Die 2.1.2-Datei nicht erneut starten.
+2. Screenshot und vollständiges `setup-*.log` aus `%ProgramData%\BizTalkPlatformManagementTool\InstallerLogs` als Vorfallevidenz sichern.
+3. `artifacts\BizTalkPlatformManagementTool-Setup.zip.b64.txt` aus Version 2.2.3 mit `certutil -decode` rekonstruieren.
+4. Den SHA-256 des ZIPs mit `BizTalkPlatformManagementTool-Setup.zip.sha256.txt` vergleichen.
+5. Das ZIP in einen neuen Ordner entpacken und die dortige `Setup.exe` starten. Der Fenstertitel muss `2.2.3` zeigen.
+6. Im Erfolgslog `setup_version=2.2.3.0` und `activation_method=atomic_move` oder `activation_method=verified_copy_fallback` prüfen. Beim Fallback muss zusätzlich `scope=new_install` oder `scope=update_after_backup` protokolliert sein.
+7. Danach in der Anwendung zuerst **Diagnose** und anschließend mit aktiviertem **Dry run** den vorgesehenen Betriebsablauf prüfen.
+
+Eine Windows-/BizTalk-/EDR-Abnahme in PROD bleibt erforderlich; die lokale Mono-Suite kann reale ACLs, Endpoint-Schutz, Registry und Verknüpfungen nicht simulieren.