# 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.