BizTalkPlatformManagementTool/docs/PROD-Shutdown-Dialog-Sichtbarkeit-2026-08-27.md

PROD-Analyse: Shutdown-Dialog nicht sichtbar

Datum: 27.08.2026

Zielversion: 2.3.4

Befund: Nach der Receive-Location-Phase wurde kein sichtbarer Dialog zur Bestätigung des Leerlaufens wahrgenommen.

Ergebnis der Ursachenanalyse

Der fachliche Checkpoint war in Version 2.3.3 vorhanden: Jeder Shutdown-Plan mit nachgelagerter Arbeit enthält genau eine persistierte OperatorCheckpoint-Zeile vor Orchestrierungen, Send Ports und lokalen Host Instances. Ohne Callback, bei einem Fehler oder bei Nein stoppt der Executor fail-closed; keine geschützte spätere Phase wird ausgeführt.

Die Oberfläche hatte aber zwei voneinander unabhängige Sichtbarkeitsprobleme:

1. Dry run ist standardmäßig aktiv. In diesem Modus wird keine Receive Location deaktiviert. Deshalb wird der echte Entscheidungsdialog absichtlich nicht aufgerufen; nur die Checkpoint-Zeile wird simuliert. Der kleine Haken und der generische Status machten diesen Unterschied während der Ausführung nicht eindeutig.
2. Die Bestätigungen hatten keinen Fenster-Owner. MessageBox.Show(...) wurde aus dem UI-Thread aufgerufen, aber nicht an das Hauptformular gebunden. Unter RDP, nach Monitorwechseln oder bei abweichender Z-Order konnte der modale Dialog hinter dem Hauptfenster beziehungsweise außerhalb des erwarteten Vordergrunds liegen. Der Background-Worker wartete dann korrekt auf Invoke, während das Hauptfenster weiterhin nur Preparing shutdown... zeigte und deaktiviert wirkte.

Der Screenshot allein unterscheidet die beiden Fälle nicht, weil der Einstellungsbereich mit Dry run nicht sichtbar und kein shutdown-result.json beigefügt ist. Der sichtbare Zustand Preparing shutdown... bei bereits dargestelltem Plan ist jedoch mit einem wartenden, owner-losen Plan- oder Drain-Dialog vereinbar. Ein abgeschlossenes DryRun=true mit leerer CheckpointDecision belegt dagegen die beabsichtigte Simulation.

Korrektur in 2.3.4

• Planfreigabe, Drain-Entscheidung und Emergency-Restore-Bestätigung verwenden das Hauptformular explizit als Owner und holen es vor dem Anzeigen nach vorn.
• Unmittelbar vor der echten Drain-Entscheidung meldet die Statuszeile: ACTION REQUIRED: Shutdown paused.
• Der Titel des Checkpoints beginnt mit ACTION REQUIRED; der Text erklärt, dass der Shutdown pausiert ist und Nein oder Schließen sicher stoppt.
• Die erste Freigabe eines echten Shutdowns kündigt den zweiten Dialog nach der Receive-Location-Phase ausdrücklich an.
• Dry-run und Realbetrieb haben gut sichtbare, farblich getrennte Texte. Während einer Operation sind diese Einstellungen gesperrt.
• Ein Shutdown-Dry-run zeigt einen eigenen owner-gebundenen Hinweis: keine Runtime-Änderung, keine deaktivierte Receive Location und daher keine echte Drain-Entscheidung.

Die Sicherheitssemantik bleibt unverändert: Das Tool behauptet keinen automatisch erkannten Leerlauf. Nur der Operator kann nach Prüfung von Group Hub und Enterprise-Monitoring mit Ja fortsetzen.

Diagnose vorhandener 2.3.2/2.3.3-Läufe

shutdown-result.json und shutdown-plan.json sichern und wie folgt bewerten:

Evidenz	Bedeutung
DryRun=true, Checkpoint-Outcome DryRun, keine CheckpointDecision	Erwartete Simulation; es gab keine Runtime-Änderung und bewusst keinen Entscheidungsdialog.
Kein Ergebnisreport, UI bleibt bei Preparing shutdown...	Lauf wartet möglicherweise auf einen verdeckten Plan- oder Drain-Dialog; Taskwechsel/Alt+Tab prüfen. Prozess nicht blind beenden.
DryRun=false, CheckpointDecision=Stop	Operator hat Nein gewählt oder sicher gestoppt; spätere Zeilen müssen NotExecuted sein.
DryRun=false, CheckpointDecision=Error	Dialogmechanismus fehlte/fehlerhaft; fail-closed, spätere Zeilen müssen NotExecuted sein.
DryRun=false, CheckpointDecision=Continue	Eine positive Entscheidung wurde erfasst; spätere Phasen durften laufen.
Plan ohne OperatorCheckpoint	Nur zulässig, wenn keine Orchestrierung, kein Send Port und keine lokale Host Instance nachgelagert herunterzufahren war.

PROD-Abnahme 2.3.4

1. Setup 2.3.4 als Administrator installieren und im Setup-Log setup_version=2.3.4.0 sowie den erfolgreichen Ziel-Self-Test prüfen.
2. Tooldateiversion und Self-Test-Ausgabe 2.3.4-net461 prüfen.
3. Dry run aktiviert lassen, Shutdown wählen und den Hinweis Shutdown Dry Run - No Runtime Changes prüfen. Es darf keine BizTalk-Mutation stattfinden.
4. shutdown-plan.json prüfen: Bei späterer Shutdown-Arbeit steht OperatorCheckpoint vor Orchestrierungen, Send Ports und Host Instances.
5. In einem freigegebenen Wartungsfenster Dry run deaktivieren. Der Modus muss REAL EXECUTION - drain dialog required anzeigen.
6. Den gespeicherten Plan im ersten owner-gebundenen Dialog bestätigen.
7. Nach den Receive Locations muss die Statuszeile ACTION REQUIRED zeigen und der Dialog ACTION REQUIRED - Confirm BizTalk Inbound Drain vor dem Hauptfenster stehen.
8. Zuerst Nein testen. shutdown-result.json muss CheckpointDecision=Stop und für alle späteren Zeilen NotExecuted enthalten.
9. Den kontrollierten Test wiederholen, Group Hub/Monitoring prüfen und erst nach bestätigtem Leerlauf Ja wählen. Danach dürfen Orchestrierungen, Send Ports und Host Instances folgen.
10. RDP minimieren/wiederherstellen und, falls im Betrieb üblich, Monitorwechsel testen. Der owner-gebundene Dialog muss dem Hauptfenster zugeordnet bleiben.

Die portable Verifikation umfasst Release-Build aller vier Projekte, 43 Regressionstests, Runtime-Self-Test und die manifest-/hashgeprüfte Paketierung. Die abschließende Sichtbarkeits- und BizTalk-Abnahme bleibt ein Windows-/PROD-Test.