Harden installer activation against ACC file locks

docs/ACC-Installer-Aktivierungsfehler-2026-08-11.md

@@ -0,0 +1,36 @@
+# ACC-Installer-Aktivierungsfehler vom 11.08.2026
+
+## Befund
+
+Die Installation von Version 2.1.2 auf `AV23AGPWBI01` scheiterte in Phase 3 mit `SETUP-ACTIVATION`, `System.IO.IOException` und HRESULT `0x80070005`. Betroffen war die Verschiebung
+
+`C:\Program Files\BizTalkPlatformManagementTool.staging.<guid>` → `C:\Program Files\BizTalkPlatformManagementTool`.
+
+Das Log belegt gleichzeitig:
+
+- Setup lief 64-Bit und erhöht (`elevated=true`).
+- Das Ziel war eine Neuinstallation (`existing_installation=False`).
+- Paketmanifest, Dateilängen und SHA-256 waren korrekt.
+- Das Staging-Verzeichnis konnte unter `Program Files` angelegt und vollständig beschrieben werden.
+- Die Staging-EXE startete und beendete ihren Self-Test erfolgreich.
+- Zwischen dem protokollierten Self-Test-Ende und dem ersten `Directory.Move` lagen nur rund 15 ms.
+
+Damit sind ein beschädigtes Paket, fehlender Speicherplatz, eine laufende Altversion und ein generelles Fehlen von Schreibrechten als unmittelbare Ursache nicht plausibel. `0x80070005` beweist jedoch nicht, welcher Prozess oder welche Policy die Verschiebung blockierte. Der wahrscheinlichste Befund ist ein noch kurz gehaltenes Delete-/Rename-Handle des Windows Loaders, Virenscanners oder ACC-Endpoint-Schutzes unmittelbar nach Ausführung der neuen EXE. Eine dauerhaft auf Rename beschränkte Endpoint-Policy bleibt als zweite Möglichkeit bestehen.
+
+## Fix in Version 2.1.3
+
+Alle transaktionalen Verzeichnisverschiebungen verwenden jetzt höchstens acht Versuche. Nach einem `IOException` oder `UnauthorizedAccessException` wartet das Setup 250, 500, 1.000, 2.000, 3.000, 5.000 und 8.000 ms. Die gesamte zusätzliche Wartezeit ist damit auf 19,75 Sekunden begrenzt. Jeder Fehlversuch und eine spätere Erholung werden mit Exceptiontyp, HRESULT, Rolle, Versuch und Wartezeit protokolliert.
+
+Bleibt bei einer reinen Neuinstallation die Staging-Umbenennung dauerhaft gesperrt, kopiert das Setup die bereits validierte Payload in das noch nicht vorhandene Installationsziel. Jede Zieldatei wird dabei erneut gegen den Manifest-SHA-256 geprüft. Danach läuft der zweite Self-Test unverändert aus dem endgültigen Ziel. Ein Teilfehler gilt als begonnene Mutation und entfernt das unvollständige Ziel per Rollback.
+
+Für Updates existiert dieser Kopierfallback absichtlich nicht. Lässt sich die aktive Version nicht atomar ins Backup verschieben, bleibt sie unangetastet und das Setup bricht nach den begrenzten Versuchen mit `SETUP-ACTIVATION` ab.
+
+## Erwartete ACC-Abnahme
+
+1. `BizTalkPlatformManagementTool-Setup.zip.b64.txt` dekodieren und den SHA-256 des ZIP prüfen.
+2. In einen neuen Ordner entpacken und `Setup.exe` starten.
+3. Im Erfolgslog `setup_version=2.1.3.0` und `activation_method=atomic_move` oder `activation_method=verified_copy_fallback` prüfen.
+4. Anwendung starten, **Diagnose** ausführen und danach einen Dry-run erstellen.
+5. Bei erneutem Fehler das vollständige neue `setup-*.log` sichern. Die `directory_move_retry`-Ereignisse zeigen dann, ob und wie lange ACC die Operation blockiert hat.
+
+Die lokale Mono-Prüfung deckt Build, 17 Regressionstests, Anwendungsselftest, Paketmanifest und Transportartefakte ab. UAC, Endpoint-Schutz, Windows-Registry, Verknüpfungen und BizTalk-WMI müssen weiterhin auf ACC geprüft werden.

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

@@ -11,6 +11,8 @@ Vor Version 2.1.0 enthielt das Repository keinen Installer für die C#-Anwendung
 - Keine Mutation vor vollständig bestandenem Manifest- und Staging-Self-Test.
 - 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.
 - Zweiter Self-Test nach Aktivierung und vor Windows-Registrierung.
 - Automatisches Datei- und Registrierungsrollback bei Fehlern.
 - Dauerhaftes phasenbezogenes Installerlog unter ProgramData.
@@ -24,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.
-- Vierzehn Regressionstests einschließlich manipulierter/zusätzlicher/ausbrechender Payload-Pfade, Staging-Abbruch ohne Mutation, erzwungenem Fehler des zweiten Self-Tests mit Wiederherstellung der Vorversion, Deinstallation über ein Quarantäneverzeichnis, Diagnosekontext, Log-Fallback und Fehlerisolierung der UI-Ausgabe.
+- 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.
 - 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.
@@ -47,7 +49,7 @@ Die lokale Linux-/Mono-Verifikation kann folgende Windows-spezifische Punkte nic
 2. Startmenü- und optionale Desktop-Verknüpfung über Windows Script Host.
 3. 64-Bit-Uninstall-Eintrag und Aufruf über Apps & Features.
 4. Updateblockade bei laufender installierter GUI.
-5. Reales Rollback bei Dateisperren, Virenscannerzugriff oder Registryfehlern.
+5. Reales Rollback bei nicht durch den neuen Retry/Fallback aufgelösten Dateisperren oder Registryfehlern.
 6. ProgramData-Fehler und Temp-Log-Fallback unter realen Windows-ACLs.
 7. Diagnose und Laufzeitoperationen gegen `root\MicrosoftBizTalkServer` auf BizTalk Server 2020.