# 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: ```bat 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: ```bat 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-.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-.json` geschrieben wurde und keine Initialisierungsfehler enthält. - [ ] Die timestamp-basierte Datei `emergency-source-before-.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-.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-.json` muss nach einem echten Lauf vorhanden sein, sofern der Nachher-Snapshot gelang. - [ ] `emergency-restore-diff-.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.