2.8 KiB
Analyse: Update-Abbruch mit Exitcode=0, Zeilen=8
Beobachtung
Der Installer meldete nach erfolgreicher Paketprüfung, Anmeldung und Staging-Validierung:
Installation/Update fehlgeschlagen. Rollback erfolgreich.
Ursache: Self-Test fehlgeschlagen. Exitcode=0, Zeilen=8.
Die Reihenfolge im Statusfenster zeigt, dass das neue Paket und das Staging bereits erfolgreich neun Services geliefert hatten. Der danach ausgeführte Self-Test gehörte zur noch installierten Ausgangsversion.
Ursache
Version 2.2.4 verwendete dieselbe starre Erwartung von exakt neun Zeilen für
beide Seiten des Updatevergleichs. Eine ältere, intakte Installation vor
Einführung von BizTalk Endpoint Reachability liefert jedoch acht gültige
Checkmk-Zeilen und Exitcode 0. Der Updater deutete diese erwartete
Versionsdifferenz fälschlich als defekten Self-Test. Der Abbruch erfolgte vor
dem Stoppen des Tasks und vor dem Austausch von Dateien. Die Meldung
Rollback erfolgreich war deshalb technisch irreführend; es war keine
Systemänderung zurückzusetzen.
Korrektur in Version 2.2.5
- Paket, Staging und aktivierte Zielversion müssen weiterhin exakt neun
eindeutige
OK-Zeilen liefern. - Die installierte Ausgangsversion darf eine andere positive Anzahl
eindeutiger
OK-Zeilen liefern. Damit wird ihr tatsächlicher versionsspezifischer Servicevertrag gelesen. - Rein neu hinzukommende Services sind updatekompatibel. Sie werden als Discovery-Hinweis gemeldet, blockieren aber die Umschaltung nicht.
- Entfernte Namen – und damit auch Renames – bleiben ohne aktivierte Discovery-Bestätigung ein Sicherheitsstopp.
- Tritt ein Fehler vor der ersten Systemänderung auf, lautet der Status jetzt
kein Rollback erforderlich.
Erweiterte Diagnose
Jeder Lauf erzeugt
%ProgramData%\BizTalkCheckmkPulse\logs\setup-<UTC>-<PID>.log. Das Log enthält:
- aktuelle Installationsphase und Setup-Version,
- Pfad, Dateiversion und Größe jeder geprüften EXE,
- erwartete und tatsächliche Zeilenzahl, Exitcode sowie vollständiges stdout und stderr jedes Self-Tests,
- Task-Scheduler-State und
LastTaskResultdezimal und hexadezimal, - vollständige Exception-Kette mit HRESULT und Stacktrace,
- bei Runtime-Abnahmefehlern bis zu 40 letzte Provider-Logzeilen,
- Ergebnis jedes Rollback-Schritts.
Das Kennwort wird ausschließlich an LogonUser und die
Task-Scheduler-COM-Schnittstelle übergeben. Die Logging-Komponente erhält es
nicht.
Regressionstests
Automatisiert geprüft werden insbesondere:
- acht gültige Zeilen einer Legacy-Ausgangsversion werden akzeptiert,
- acht Zeilen eines neuen Stagings werden weiterhin abgewiesen,
- eine reine Service-Erweiterung wird ohne Rename-Bestätigung akzeptiert,
- ein frisch beendeter Task mit Fehlercode wird sofort erkannt und der Code enthält zusätzlich die hexadezimale Darstellung.