120 lines
7.5 KiB
Markdown
120 lines
7.5 KiB
Markdown
# 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-<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.
|