BizTalkPlatformManagementTool/docs/PROD-Shutdown-Drain-Checkpoint-2026-08-26.md

PROD-Runbook: Shutdown-Drain-Checkpoint und Application-Status

Stand: 2026-08-26

Zielversion: 2.3.2

Ziel

Nach dem Abschalten aller zuvor aktivierten Receive Locations muss BizTalk Zeit erhalten, bereits angenommene Nachrichten und laufende Service Instances kontrolliert zu verarbeiten. Version 2.3.2 hält deshalb vor Orchestrierungen, Send Ports und Host Instances an und verlangt eine explizite Operatorentscheidung.

Der Checkpoint ist als OperatorCheckpoint in shutdown-plan.json gespeichert. Er ist kein automatischer Nachweis, dass die Umgebung leer ist. Die Entscheidung stützt sich auf BizTalk Group Hub und die in der Enterprise-Umgebung vorhandenen Queue-, MessageBox-, Prozess- und Schnittstellenmetriken.

Warum Partially Started erwartbar ist

Microsoft beschreibt Partial Stop - Allow running instances to continue als Deaktivieren der Receive Locations bei unverändert laufenden übrigen Artefakten. Genau dieser Zwischenzustand ermöglicht das Leerfahren und wird in der Administration Console erwartbar als teilweise gestartet sichtbar.

Ein pauschaler Application-Stop wird nicht ergänzt. Je nach ausgewähltem BizTalk-Modus würde er zusätzlich Orchestrierungen und Send Ports stoppen, Subscriptions entfernen, Artefakte unenlisten, Policies undeployen oder laufende Instanzen terminieren. Das wäre keine kosmetische Statuskorrektur und könnte die gerade gewünschte Drain-Phase abbrechen. Microsoft empfiehlt einen Full Stop nur zum Entfernen oder erneuten Bereitstellen einer Anwendung.

Quellen:

• How to Start and Stop a BizTalk Application
• Stop Application Dialog Box
• Restart services or shut down BizTalk Server

Dry-run und Planreview

1. Version 2.3.2 installieren und setup_version=2.3.2.0 sowie erfolgreichen Ziel-Self-Test prüfen.
2. Diagnose und Snapshot Before ausführen.
3. Dry run aktiviert lassen und Shutdown wählen.
4. In shutdown-plan.json die globale Reihenfolge prüfen:
   • alle ReceiveLocation-Zeilen,
   • genau ein OperatorCheckpoint, sofern spätere Shutdownarbeit existiert,
   • Orchestrierungen,
   • Send Ports,
   • Host Instances.
5. Dry-run darf keinen Entscheidungsdialog öffnen; der Checkpoint erscheint als DryRun.

Echter Shutdown

1. Dry-run deaktivieren, den gespeicherten Gesamtplan bestätigen und Shutdown starten.
2. Die Receive-Location-Ergebnisse im Operation Log beobachten. Ein Scheduler-Fehler bleibt rot und wird im Checkpoint gezählt.
3. Beim Dialog Confirm BizTalk Inbound Drain zunächst nichts wählen. Der Dialog darf während der gesamten Leerfahrzeit geöffnet bleiben.
4. Mindestens prüfen:
   • keine neuen eingehenden Nachrichten an den abgeschalteten Schnittstellen,
   • Group Hub: laufende Service Instances entwickeln sich kontrolliert gegen null,
   • keine unerwarteten suspended/resumable Instances,
   • relevante MessageBox-/Queue-/Adapter- und Fremdsystemmetriken sind leer beziehungsweise stabil,
   • fachlich mehrteilige Prozesse haben alle benötigten Eingaben erhalten.
5. Bei leer gelaufener und fehlerfreier Umgebung Yes wählen. Erst dann folgen Orchestrierungen, Send Ports und Host Instances.
6. Bei Unsicherheit, Receive-Location-Fehlern oder weiter laufender Last No wählen. Das Tool verändert danach keine spätere Kategorie.

Nachweis im Ergebnisreport

Bei Yes:

• Checkpointzeile: Outcome=Confirmed
• CheckpointDecision=Continue
• OperatorStopped=false

Bei No:

• Checkpointzeile: Outcome=Declined
• CheckpointDecision=Stop
• OperatorStopped=true
• jede spätere Zeile: Outcome=NotExecuted
• NotExecutedCount entspricht den geschützten Restzeilen

Bei fehlendem oder fehlerhaftem Bestätigungsmechanismus lautet die Entscheidung Error; der Checkpoint ist Failed und alle späteren Zeilen bleiben ebenfalls NotExecuted. In allen Fällen versucht das Tool anschließend shutdown-after.json und speichert shutdown-result.json.

Abnahmekriterien

• Checkpoint steht im gespeicherten Plan exakt zwischen Receive Locations und Orchestrierungen.
• Dry-run öffnet keinen echten Entscheidungsdialog.
• Dialog verwendet No als sichere Standardauswahl.
• Yes setzt ausschließlich die bereits gespeicherten späteren Schritte fort.
• No und Dialogfehler führen zu keiner späteren WMI-Mutation.
• Entscheidung, Zeitpunkt, Teilzustand und alle nicht ausgeführten Schritte sind in Grid, Log und Report nachvollziehbar.
• Es wird kein zusätzlicher Application-Stop und insbesondere kein Full Stop ausgeführt.
• Setup, Tool und neue Reports melden 2.3.2 beziehungsweise 2.3.2-net461.

Die portable Toolchain prüft die Ablaufgrenzen ohne BizTalk. Die endgültige Freigabe benötigt einen Windows-/BizTalk-/PROD-Test mit den realen Enterprise-Monitoringquellen.