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

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.