Guarantee durable visible runtime logging
This commit is contained in:
@@ -0,0 +1,44 @@
|
||||
# PROD-Runbook: Laufzeitlog-Ablage und Version 2.3.1
|
||||
|
||||
**Stand:** 2026-08-26
|
||||
**Zielversion:** 2.3.1
|
||||
|
||||
## Einordnung des Screenshots
|
||||
|
||||
Der gezeigte Ordner `C:\Program Files\BizTalkPlatformManagementTool` ist der Programmordner. Der primäre Laufzeitlogordner ist dagegen `%ProgramData%\BizTalkPlatformManagementTool\Logs`, üblicherweise `C:\ProgramData\BizTalkPlatformManagementTool\Logs`. `C:\ProgramData` ist im Explorer standardmäßig ausgeblendet. Im Programmordner wird deshalb im Normalfall kein Log erwartet.
|
||||
|
||||
Die frühere Implementierung konnte dennoch einen echten Fehler verdecken: Sie prüfte nur, ob sich der Ordner anlegen ließ, und ignorierte einen Fehler beim nachfolgenden `AppendAllText`. Damit konnte das Grid funktionieren, obwohl kein dauerhaftes Log geschrieben wurde.
|
||||
|
||||
## Fix in 2.3.1
|
||||
|
||||
- Jeder Kandidat muss einen echten Create/Write/Flush/Delete-Test bestehen.
|
||||
- Die Reihenfolge ist ProgramData, LocalAppData, EXE-Unterordner `Logs`, Temp.
|
||||
- Ein späterer Append-Fehler wiederholt denselben Datensatz auf dem nächsten Kandidaten.
|
||||
- Fallback und vollständiger Ausfall erscheinen mit Pfad und Exception im Grid.
|
||||
- Jeder GUI-Start schreibt `Runtime log storage verified by startup append. Active file: ...` in Grid und Tagesdatei.
|
||||
- Der Installer-Self-Test prüft einen vollständigen temporären Write/Read-Roundtrip.
|
||||
- Tagesdateien werden nach Abschluss komprimiert; aktueller Tag plus 29 Vortage bleiben erhalten. Bis zu 10.000 Einträge werden nach Neustart ins Grid geladen.
|
||||
|
||||
## PROD-Abnahme nach Update
|
||||
|
||||
1. Setup 2.3.1 als Administrator ausführen und erfolgreichen Ziel-Self-Test prüfen.
|
||||
2. Tool als Administrator starten, noch keine reale BizTalk-Operation ausführen.
|
||||
3. Im Grid den grünen Startup-Verifikationseintrag prüfen und seinen vollständigen Dateipfad notieren.
|
||||
4. Auf eine gelbe Pfad-Fallbackwarnung oder `RUNTIME FILE LOGGING UNAVAILABLE` achten.
|
||||
5. **Log Folder** öffnen und prüfen, dass exakt die genannte Tagesdatei existiert.
|
||||
6. Datei öffnen und den Startup-Verifikationseintrag dieses Starts prüfen.
|
||||
7. **Diagnose** ausführen, Tool regulär schließen und neu starten.
|
||||
8. Prüfen, dass Diagnoseeinträge wieder im Grid erscheinen und auch in der Tagesdatei stehen.
|
||||
9. Erst danach den ScheduledTask-Test zunächst als Dry-run und nach Planreview real durchführen.
|
||||
|
||||
Bei `RUNTIME FILE LOGGING UNAVAILABLE` keine reale Wartungsoperation beginnen. Screenshot des vollständigen Grid-Eintrags, aktiven Benutzer, freien Speicher, Endpoint-Security-Ereignisse und die ACLs der vier genannten Kandidaten sichern. Keine ACL eigenmächtig aufweiten; die Ursache mit dem Serverbetrieb klären.
|
||||
|
||||
## Supportpaket
|
||||
|
||||
- Aktuelle `.log` und relevante `.log.gz` aus **Log Folder**
|
||||
- Screenshot der Startup-Verifikation beziehungsweise vollständigen Speicherwarnung
|
||||
- `shutdown-plan.json`/`restore-plan.json` und passender `*-result.json`-Report
|
||||
- `before.json`, Nachher-Snapshot und unveränderte EXE-Konfiguration
|
||||
- Setup-Log mit `setup_version=2.3.1.0` und erfolgreichem Ziel-Self-Test
|
||||
|
||||
Die Windows-/BizTalk-/PROD-Prüfung bleibt die endgültige Abnahme; die portable Regressionstoolchain simuliert die drei Speicherfehlerpfade ohne BizTalk.
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**Stand:** 2026-08-26
|
||||
|
||||
**Zielversion:** 2.3.0
|
||||
**Zielversion:** 2.3.1
|
||||
|
||||
**Betroffener Adapter:** BizTalk ScheduledTask Adapter 7.0.2
|
||||
|
||||
@@ -12,14 +12,14 @@
|
||||
|
||||
`MSBTS_ReceiveLocation.Enable` und `.Disable` validieren die Transportdaten einer ScheduledTask-Receive-Location. Der Adapter benötigt dafür `Microsoft.BizTalk.Scheduler.dll`. Diese BizTalk-Assembly liegt im BizTalk-Installationsverzeichnis, ist aber nicht in jeder Umgebung im GAC auflösbar. Der Fehler lautete deshalb sinngemäß `Could not load file or assembly Microsoft.BizTalk.Scheduler, Version=3.13.0.0`.
|
||||
|
||||
Version 2.3.0 erkennt ScheduledTask-Schritte an Adaptername oder `scheduler:`-URI. Unmittelbar vor der WMI-Mutation sucht sie die Assembly in der lokalen BizTalk-/Adapterinstallation, prüft ihre .NET-Assemblyidentität und lädt sie nur für den laufenden Toolprozess. Weitere angeforderte Abhängigkeiten werden nach derselben Identitätsprüfung aufgelöst. Das Tool kopiert keine Fremd-DLL, registriert nichts und verändert den GAC nicht.
|
||||
Version 2.3.1 erkennt ScheduledTask-Schritte an Adaptername oder `scheduler:`-URI. Unmittelbar vor der WMI-Mutation sucht sie die Assembly in der lokalen BizTalk-/Adapterinstallation, prüft ihre .NET-Assemblyidentität und lädt sie nur für den laufenden Toolprozess. Weitere angeforderte Abhängigkeiten werden nach derselben Identitätsprüfung aufgelöst. Das Tool kopiert keine Fremd-DLL, registriert nichts und verändert den GAC nicht.
|
||||
|
||||
## Vorbereitung
|
||||
|
||||
1. Vorhandene `before.json`, Ergebnisdateien und Laufzeitlogs außerhalb des Installationsordners sichern.
|
||||
2. Setup 2.3.0 als Administrator installieren beziehungsweise aktualisieren.
|
||||
3. Im Setup-Log `setup_version=2.3.0.0` und erfolgreichen Ziel-Self-Test prüfen.
|
||||
4. Tool als Administrator starten und mit **Log Folder** `%ProgramData%\BizTalkPlatformManagementTool\Logs` öffnen.
|
||||
2. Setup 2.3.1 als Administrator installieren beziehungsweise aktualisieren.
|
||||
3. Im Setup-Log `setup_version=2.3.1.0` und erfolgreichen Ziel-Self-Test prüfen.
|
||||
4. Tool als Administrator starten, den grünen Eintrag `Runtime log storage verified by startup append` prüfen und mit **Log Folder** den dort genannten aktiven Pfad öffnen. Normalfall ist `%ProgramData%\BizTalkPlatformManagementTool\Logs`.
|
||||
5. Prüfen, dass der lokale BizTalk-Installationsordner `Microsoft.BizTalk.Scheduler.dll` enthält.
|
||||
6. Nur wenn BizTalk oder der Adapter abweichend installiert wurde: `AdapterAssemblySearchPaths` in `BizTalkPlatformManagementTool.exe.config` um den vorhandenen lokalen Ordner ergänzen. Mehrere Pfade werden mit Semikolon getrennt. Keine DLL aus ACC, einer alten BizTalk-Version oder einem Downloadordner kopieren.
|
||||
|
||||
@@ -48,11 +48,13 @@ Version 2.3.0 erkennt ScheduledTask-Schritte an Adaptername oder `scheduler:`-UR
|
||||
3. Das Operation Log muss die Einträge des vorherigen Prozesses mit vollständigem Datum und Uhrzeit wieder anzeigen.
|
||||
4. **Clear** leert nur das Grid. Nach erneutem Programmstart wird die aufbewahrte Historie wieder geladen.
|
||||
5. **Log Folder** muss den lokalen Ordner öffnen.
|
||||
6. Die aktuelle Tagesdatei heißt `BizTalkPlatformManagementTool-yyyy-MM-dd.log`.
|
||||
6. Die aktuelle Tagesdatei heißt `BizTalkPlatformManagementTool-yyyy-MM-dd.log` und enthält den bei diesem Start erzeugten Verifikationseintrag.
|
||||
7. Nach dem ersten Start an einem Folgetag wird der abgeschlossene Vortag zu `.log.gz` komprimiert.
|
||||
8. Aktueller Tag plus 29 Vortage bleiben erhalten. Einträge außerhalb dieses Fensters werden beim Start entfernt.
|
||||
9. Das Grid lädt höchstens die neuesten 10.000 Einträge; die 30-Tage-Dateien bleiben davon unabhängig vollständig erhalten.
|
||||
|
||||
ProgramData ist ein separates, üblicherweise ausgeblendetes Windows-Verzeichnis. Im Installationsordner unter Program Files wird im Normalfall kein Log erwartet. Version 2.3.1 prüft ProgramData durch einen echten Schreibzugriff; danach folgen LocalAppData, ein `Logs`-Unterordner im Installationsverzeichnis und Temp. Jeder Fallback oder vollständige Ausfall muss im Grid mit dem betroffenen Pfad und der Exception sichtbar sein.
|
||||
|
||||
## Fehlerfall und Supportpaket
|
||||
|
||||
Bei einem Fehler keine Assembly austauschen und den GAC nicht spontan verändern. Folgende unveränderte Evidenz sichern:
|
||||
@@ -75,6 +77,6 @@ Der Fehlerdatensatz enthält Exceptiontyp, HRESULT, innere Ausnahmen, vorhandene
|
||||
- Ergebnisreport und Nachher-Snapshot werden auch bei einem Teilfehler soweit möglich geschrieben.
|
||||
- Historisches Log erscheint nach Neustart wieder im Grid.
|
||||
- Vortagslogs werden komprimiert und exakt 30 Kalendertage aufbewahrt.
|
||||
- Setup, Tool und Ergebnisdateien melden Version 2.3.0 beziehungsweise `2.3.0-net461`.
|
||||
- Setup, Tool und Ergebnisdateien melden Version 2.3.1 beziehungsweise `2.3.1-net461`.
|
||||
|
||||
Die lokale Mono-Toolchain prüft Resolverlogik, Identitätsgrenze, Persistenz, Kompression und Aufbewahrung ohne BizTalk. Die endgültige Freigabe erfordert diesen realen Windows-/BizTalk-/PROD-Test.
|
||||
|
||||
Reference in New Issue
Block a user