BizTalkPlatformManagementTool/docs/ACC-Emergency-Restore-before-json-Runbook.md

ACC Emergency Restore aus before.json

Stand: 19.08.2026
Ausführung: Donnerstag, 20.08.2026, oder Montag, 24.08.2026
Zielserver: AV23AGPWBI01
Benötigte Toolversion: 2.2.2

Kurzantwort

Ja. Die vorhandene, mit Version 2.1.3 erzeugte before.json kann von Version 2.2.2 direkt als Recovery-Quelle verwendet werden. Zusätzliche Dateien des abgebrochenen Shutdowns sind nicht erforderlich. Die Kompatibilität wird durch einen Regressionstest abgedeckt; die echte BizTalk-/ACC-Ausführung muss noch vor Ort bestätigt werden.

Für diesen Teilzustand ausschließlich Emergency Restore verwenden. Dieser Modus startet zuerst ENTSSO, arbeitet danach den gespeicherten Sollzustand idempotent ab, setzt nach Einzelfehlern fort und überschreibt die Quell-before.json nicht.

1. Dateien vorbereiten

• Originale before.json an einem zweiten Ort unverändert sichern.
• Optional den Hash der Originaldatei protokollieren:

certutil -hashfile before.json SHA256

• Die Release-Datei BizTalkPlatformManagementTool-Setup.zip.b64.txt und die zugehörige SHA-256-Datei auf ACC übertragen.
• Die TXT-Datei rekonstruieren und das ZIP prüfen:

certutil -decode BizTalkPlatformManagementTool-Setup.zip.b64.txt BizTalkPlatformManagementTool-Setup.zip
certutil -hashfile BizTalkPlatformManagementTool-Setup.zip SHA256
type BizTalkPlatformManagementTool-Setup.zip.sha256.txt

• Nur fortfahren, wenn beide ZIP-Hashes exakt gleich sind.
• ZIP in einen neuen Ordner entpacken, die laufende Toolinstanz schließen und Setup.exe als Administrator starten.
• Installation/Update auf Version 2.2.2 vollständig abschließen.
• Ein neues, leeres Ausgabeverzeichnis anlegen, zum Beispiel C:\BizTalk-Recovery\2026-08-20 oder C:\BizTalk-Recovery\2026-08-24.

Wichtig: Die Recovery-Quelle außerhalb dieses Ausgabeverzeichnisses lassen. Während der Recovery nicht Snapshot Before anklicken, damit kein neuer Teilzustand als vermeintlicher Sollzustand gespeichert wird.

2. before.json ohne WMI prüfen

• Anwendung als Administrator starten.
• Im Feld Server AV23AGPWBI01 eintragen. Kurzname und FQDN desselben Hosts werden akzeptiert.
• Unter Output das neue Recovery-Ausgabeverzeichnis auswählen.
• Über State... die gesicherte before.json auswählen.
• Dry run aktiviert lassen.
• Validate State anklicken.
• Im Erfolgsdialog prüfen:
  • Snapshotversion ist erwartungsgemäß 2.1.3-net461 oder 2.1.3.
  • Snapshotserver ist AV23AGPWBI01 beziehungsweise dessen FQDN.
  • Erstellzeit und Anzahl von Applications, Host Instances, Receive Locations, Send Ports und Orchestrations wirken plausibel.

Validate State öffnet keine WMI-Verbindung und verändert weder BizTalk noch Windows-Dienste. Bei einer roten Fehlermeldung nicht real ausführen, sondern zuerst Pfad, JSON-Datei und Serverauswahl korrigieren.

3. Emergency-Dry-run prüfen

• Dry run bleibt aktiviert.
• Emergency Restore anklicken.
• Den erzeugten emergency-restore-plan-<Zeitstempel>.json öffnen.
• Prüfen, dass der Plan zu AV23AGPWBI01 gehört.
• Reihenfolge prüfen:
  1. Windows-Dienst ENTSSO,
  2. alle Host Instances,
  3. alle Send Ports,
  4. alle Orchestrations,
  5. alle Receive Locations.
• Prüfen, dass der Dry-run-Report emergency-restore-result-<Zeitstempel>.json geschrieben wurde und keine Initialisierungsfehler enthält.
• Die timestamp-basierte Datei emergency-source-before-<Zeitstempel>.json als zusätzliche Recovery-Evidenz sichern.

Der Dry-run führt keine Zustandsänderung aus. Er bestätigt aber, dass genau die erhaltene Datei gelesen, validiert und in einen ausführbaren Emergency-Plan übersetzt werden kann.

4. Echten Wiederanlauf ausführen

• Sicherstellen, dass SQL Server, Netzwerk und die übrigen BizTalk-Abhängigkeiten erreichbar sind.
• Noch einmal kontrollieren: Server, Output-Pfad und State-Datei sind korrekt.
• Dry run deaktivieren.
• Emergency Restore anklicken.
• Im Bestätigungsdialog Quellpfad, Zielserver, Plandatei und Schrittzahl lesen.
• Erst danach mit Yes bestätigen.
• Anwendung bis zum Abschluss geöffnet lassen.

Die reale Reihenfolge ist:

1. ENTSSO auf Running bringen.
2. Host Instances gemäß before.json abgleichen.
3. Send Ports abgleichen.
4. Orchestrations abgleichen; im Snapshot nur Bound gebliebene Orchestrations werden bewusst zur manuellen Kontrolle markiert.
5. Receive Locations zuletzt abgleichen.

Vor jeder Mutation liest Version 2.2.2 den Istzustand. Ein bereits korrekter Zustand wird als AlreadySatisfied protokolliert und nicht erneut per WMI geändert. Ein einzelner Fehler wird als Failed gespeichert; alle späteren unabhängigen Schritte werden trotzdem versucht. Auch ein Fehler der optionalen GUI-Loganzeige kann die fachliche Ausführung nicht unterbrechen.

5. Ergebnis abnehmen

• emergency-restore-result-<Zeitstempel>.json prüfen.
• Idealfall: FailedCount ist 0, InitializationError und PostSnapshotError sind leer.
• AlreadySatisfied ist normal und bedeutet, dass keine unnötige Mutation ausgeführt wurde.
• emergency-restore-after-<Zeitstempel>.json muss nach einem echten Lauf vorhanden sein, sofern der Nachher-Snapshot gelang.
• emergency-restore-diff-<Zeitstempel>.json, .csv und .html prüfen. Im vollständigen Sollzustand sind keine fachlichen Unterschiede enthalten.
• Danach Diagnose ausführen und den BizTalk-Zustand zusätzlich in der BizTalk Administration Console kontrollieren.
• Empfang, Verarbeitung und Versand mit dem für ACC vorgesehenen fachlichen Smoke-Test prüfen; Suspended Instances kontrollieren.
• Recovery-Quelle, Plan, Ergebnis, Nachher-Snapshot, Diff und Laufzeitlog gemeinsam sichern.

Sonderfall RV_PMP_Trigger_Schedule

Wenn die Receive Location noch aktiviert ist und before.json ebenfalls Enabled=true vorgibt, wird sie als AlreadySatisfied übersprungen. Damit wird der fehlerhafte Scheduler-WMI-Aufruf nicht erneut ausgelöst.

Wenn sie deaktiviert ist, obwohl before.json sie aktiviert erwartet, versucht das Tool die Aktivierung. Tritt der bekannte Fehler zu Microsoft.BizTalk.Scheduler, Version=3.13.0.0 erneut auf, wird genau dieser Schritt als Failed protokolliert; die übrigen Receive Locations werden weiterbearbeitet. Dann:

• Ergebnisreport und vollständige Exception sichern.
• Aktuellen Zustand der Receive Location in der BizTalk Administration Console prüfen.
• Scheduler-Assembly/Abhängigkeiten auf dem Administrations-/BizTalk-Host reparieren oder den Schritt nach fachlicher Freigabe manuell ausführen.
• PROD erst freigeben, wenn der verbleibende Einzelfehler behoben oder ausdrücklich akzeptiert und getestet ist.

Wenn der Lauf erneut unterbrochen wird

Die ursprüngliche before.json bleibt unverändert. Version 2.2.2 kann mit derselben Recovery-Quelle erneut gestartet werden, weil bereits erreichte Zustände als AlreadySatisfied übersprungen werden. Vor dem Wiederholen immer den jüngsten Ergebnisreport sichern und prüfen, welcher Schritt tatsächlich fehlgeschlagen ist.

Go/No-Go für PROD

ACC ist erst ein belastbarer PROD-Nachweis, wenn der echte Emergency Restore abgeschlossen wurde, der Ergebnisreport vollständig ist, der automatische Diff geprüft wurde und jeder verbliebene Failed-Schritt fachlich behandelt wurde. Die lokalen 27 Regressionstests und der Self-Test ersetzen diesen realen BizTalk-/Windows-Nachweis nicht.