Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

BLOG

BLOGGING CONSULTANTS

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

Erweitertes Fehlerhandling in DSM

Wer sich schon einmal aufmerksam durch die DSM Logs gearbeitet hat, wird schon mal auf die Variablen "_LAST_ERROR_TEXT" und "_ERROR_SEVERITY" gestossen sein. Diese Variablen werden ggf. gefüllt, wenn ein interner DSM Befehl nicht funktioniert hat. I.d.R. ist die Auswertung der internen DSM Befehle allerding nicht sonderlich relevant. Simple Befehle wie ein "InstallFileList" erkenne selber, wenn eine interne Funktion (z.B. aufgrund eines Filelocks) eine Fehler erzeugt hat. 

Allerdings gilt dies nicht für alle Befehle oder alle Konstellationen von Befehlen. Kann z.B. ein "LocalGroupAddMember" Befehl den User, der in die Gruppe hinzugefügt werden soll nicht auflösen, wird das eScript trotzdem mit "Erfolg" verlassen. Im Worst case erfährt der Administrator also niemals etwas davon, dass ein Paket fehlgeschlagen ist. Die beiden oben genannten Variablen helfen bei der Fehleranalyse. Im Beispiel des "LocalGroupAddMember" Befehls wird (bei Fehler) die "ERROR_SEVERITY" mit "3" befüllt, der "_LAST_ERROR_TEXT" mit einem Informationstext über die Ursache des Problems. Folgende Randbedingungen sind beim Einsatz dieser Variablen zu beachten: 

 

 

  • Die Auswertung sollte sich auf Befehle konzentrieren, die tendenziell einen Fehler verursachen könnten. Die Überwachung eines Standard InstallFileList Befehls macht keinen Sinn.
  • Der Informative Fehlertext ist nicht für weitere Auswertung geeignet, da die Fehlermeldungen der betroffenen OS Funktion in der eingestellten UI Sprache des Betriebssystems ausgegeben werden. 
  • Die Auswertung der Variablen muss direkt nach einem Befehl erfolgen, der einen tendenziellen Fehler schmeissen könnte. 
  • Einige Befehle erzeugen einen Fehler bei Erfolg. Wird z.B. der Prozess "notepad.exe" mit einem KillProzess Befehl unter Windows 7 beendet, wird die Meldung "Couldn't get privilege SeDebugPrivilege..." ausgegeben, auch wenn dass Beenden des Prozesses erfolgreich war.
  • Die Variablen werden nur im Fehlerfall neu geschrieben. Schmeisst der erste Befehl einen Fehler und wird im Anschluss ein Befehl erfolgreich ausgeführt, sind die Variablen immer noch mit der Severity und dem Fehlertext des ersten Befehls befüllt. 
×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Feststellen des Online Status
Zielgerichteter ClientSync in Multi-BLS Umgebungen

Ähnliche Beiträge

 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Bereits registriert? Hier einloggen
Montag, 07. Oktober 2024

Sicherheitscode (Captcha)