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

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:

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.