Die Wege, die der Support im Problemfall beschreiten kann, sind entweder eine ausführliche Interaktion mit dem Benutzer, die Analyse von Fehlercodes und Logdateien oder der Abgleich einer definierten funktionierenden Konfiguration mit dem Ist-Zustand des Systems. Die daraus resultierenden Lösungsansätze werden angewendet und das Ergebnis bezüglich des Erfolges getestet.
Automatisierte Lösungen bieten dabei den Vorteil einer geringen Fehleranfälligkeit. Innerhalb eines Windows Trouble-shooting Packs (WTP) arbeiten mehrere PowerShell-Skripte kooperativ an der Überwindung von Konfigurationsproblemen. Jedes Skript erzeugt Rückgabewerte, die wiederum andere Skripte starten und steuern. Sie erhalten so eine geführte Lösung von Systemproblemen, die im besten Fall die optimale Abfolge zu einer Wiederherstellung des gewünschten Zustandes einhält. Initialisieren können diese Troubleshooting-Packs entweder Benutzer, etwa über PowerShell-Cmdlets,oder auch Anwendungen selbst.
Die Umgebung setzt sich zusammen aus den Bestandteilen des Troubleshooting Packs sowie der PowerShell. Die Bühne, auf der beide Komponenten spielen, ist die Troubleshooting-Engine. Sie ist die Ablaufumgebung aller Bestandteile des WTP. Zudem hostet Sie eine eigene PowerShell-Umgebung. Aus Sicherheitsgründen ist diese in einen eigenen Prozessraum ausgelagert. Wäre diese Konstruktion als In-Process-Komponente umgesetzt, könnte jedes fehlerhafte Skript die gesamte Troubleshooting-Runtime mit in den Abgrund ziehen – mit möglichen Nebeneffekten für die betroffenen Systeme.
Schematisch sieht das Zusammenspiel folgendermaßen aus: Die PowerShell-Skripte eines Troubleshooting-Packs sind für den Input zuständig, etwa durch welchen Rückgabewert einer Abfrage das Problem definiert ist. Das Ergebnis dieser Analyse wird von der Troubleshooting-Runtime zu Reports verarbeitet. Die
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.