Windows PowerShell: Die Windows PowerShell-Workflow-Umgebung
Don Jones wird dieses Jahr im Rahmen eines zwölfteiligen Lernprogramms jeden Monat einen Beitrag zum Thema Windows PowerShell-Workflow veröffentlichen. Wir empfehlen Ihnen, durch die Serie in Ordnung, zu lesen, beginnend mit der Januar 2013 Spalte.
Don Jones
Wie ich letzten Monat erklärt, ist Windows PowerShell -Workflow ein neues Feature in Windows Management Framework-Version 3. Es ist unter Windows Server 2012 und Windows 8 vorinstalliert. Es ist auch für Windows Server 2008 R2, Windows 7 und Windows Server 2008 verfügbar. Benötigen Sie eines dieser Betriebssysteme, einen Workflow auszuführen. Sie können auch ein Workflow-Ziel, — d. h. Aufgaben gegen — jeder Version von Windows, abhängig von der Aufgabe, die Sie versuchen zu erreichen.
Es gibt zwei wesentliche Voraussetzungen für die Verwendung Windows PowerShell -Workflow, abgesehen von den standard-System-Anforderungen für Windows PowerShell Version 3. Zuerst musst du das gebündelte PSWorkflow-Modul verwenden, um Workflow-Funktionen innerhalb der Shell aktivieren. Zweitens musst du haben Windows PowerShell -Remoting aktiviert auf den Maschinen mit Windows PowerShell -Workflow ansprechen möchten.
Remoting muss nicht unbedingt auf dem Computer ausgeführt werden, wo Sie Workflows ausgeführt, aber unabhängig davon, welche Maschinen Sie inventarisieren, konfigurieren oder anderweitig zu verwalten möchten Remoting aktiviert haben müssen. Windows PowerShell Workflow verwendet Remoting als seine primäre Kommunikationsprotokoll. Es gibt wahrscheinlich einige Workflows, den, die Sie schreiben könnte, die Remoting nicht brauchen, aber die sind dünn gesät.
Remoting ist eine enorm missverstandenen Komponente von Windows PowerShell. Mehr als ein paar Organisationen IT Sicherheit Leute Vorgehen tun-nicht-bereitstellen. Das ist falsch und unglücklich. Die gleichen sicherheitsbewusste Leute haben kein Problem, so dass eine große Anzahl von sonstigen Kommunikationsprotokolle wie Remote Desktop Protocol (RDP), Remoteprozeduraufrufe (RPCs) und HTTP.
Remoting ist der Weg nach vorne für Management-Kommunikation innerhalb einer Windows-Umgebung. Microsoft wird bald beginnen diese ältere Protokolle in Remoting zu konsolidieren. Remoting verwendet HTTP und HTTPS, ist hochgradig konfigurierbar und überschaubar, und Sie können zentral sperren es mit einem Gruppenrichtlinienobjekt (GPO). Es ist auch im Allgemeinen sicherer, mehr prüfbare und mehr steuerbar als die ältere Protokolle. Für eine ausführlichere Diskussion über die Sicherheitsauswirkungen Remoting und seiner Architektur, betrachten herunterladen das gratis e-Book, "Geheimnisse der PowerShell-Remoting."
Innerhalb eines Workflows
Die größte Herausforderung, die Sie, wenn Sie Windows PowerShell -Workflow zu nähern müssen ist zu bedenken, dass es wie ein Windows PowerShell -Skript (insbesondere eine Funktion aussieht), aber es nicht. DieWindows PowerShell -Sprache" schreiben Sie in eine externe Sprache (XAML) übersetzt wird. Wird es durch nicht ausgeführt-Windows PowerShell -Technologie.
Infolgedessen gibt es ein paar unterschiedliche Regeln. Einige von denen sind rein syntaktischen. Im Allgemeinen müssen Sie vollständigen Cmdlet-Namen für Cmdlets verwenden, die Sie ausführen. Außerdem sind nicht Positionsparameter und abgeschnittene Parameternamen zulässig. Sie müssen voll-Parameter-Namen verwenden.
Was eher verwirrend sein kann, ist die gesamte Umgebung innerhalb eines Workflows. Der springende Punkt eines Workflows ist unterbrechen und fortsetzen den Workflow absichtlich oder in Reaktion auf etwas schief in Ihrer Umgebung (z. B. einen Spannungsverlust) tun können.
Das bedeutet, dass jeder Befehl in einem Workflow im wesentlichen alleine stehen muss. Es muss kein Bewusstsein was andere Befehle getan haben und keine native Möglichkeit beibehalten von Daten zwischen Befehlen. Es bedeutet auch, dass Sie eine Variable für die Ausgabe eines Befehls zu halten und übergeben Sie dann diese Variable als Eingabe für einen anderen Befehl nicht festlegen können. Es funktioniert einfach nicht. Auch nicht mit zusätzliche Befehlen Module geladen werden. Es gibt keine beständige Umfeld, um das Modul zu laden.
Der spezielle InlineScript {} Block, die in einem Workflow jetzt kann wird dein bester Freund. Jede InlineScript wird grundsätzlich als Einheit ausgeführt. Windows Workflow Foundation (WWF) dreht sich ein Exemplar von Windows PowerShell, Marmeladen in der gesamten InlineScript, und es läuft. Der Inhalt einer InlineScript Verhalten sich wie ein traditionelles Windows PowerShell -Skript.
Es gibt auch eine implizite InlineScript. WWF kann nicht wirklich Windows PowerShell -Befehle außerhalb einer InlineScript ausgeführt. Wenn Sie in Ihren Workflow ein Windows PowerShell -Cmdlet verwenden, überprüft Windows PowerShell wenn eine native WWF Äquivalent zur Verfügung, und sagt WWF stattdessen ausführen.
Das Windows PowerShell -Team hat WWF-Entsprechungen für viele native Windows PowerShell -Befehle geschrieben, aber wenn Sie versuchen, ein Cmdlet verwenden, die nicht über eine native Version von WWF, Windows PowerShell umschließt implizit Ihren Befehl in einem Block InlineScript. Dadurch wird die WWF Windows PowerShellzu starten, führen Sie den Befehl und dann schließen Sie die Instanz von Windows PowerShell.
Diese mangelnde Dauerhaftigkeit zwischen Befehlen ist, was hilft Windows PowerShell -Workflow, die Ihre Skripts fortsetzbare machen. Deshalb ein großer Teil des Windows PowerShell -Workflow kann Befehle in einem Skript zu parallelisieren. Es verwandelt sie in Multithread-Automatisierung-Maschinen. Jedoch die mangelnde Dauerhaftigkeit ist eine wesentliche Abweichung von wie normal Windows PowerShell -Skripts und Funktionen arbeiten. Es braucht viel zusätzliche Planung, ein Skript ordnungsgemäß funktioniert.
Es wird nicht sein ungewöhnliches Arbeitsabläufe zu sehen, die von ein paar InlineScript Blöcke bestehen. Noch sind es ungewöhnliche Arbeitsabläufe zu sehen, die nichts mehr als einen einzigen, langen InlineScript-Block.
Solche Workflows müssen begrenzt (oder nicht vorhandenen) Parallelisierung oder Resume-Funktionen. Ein InlineScript ist eine einzelne Arbeitseinheit. Sie können einfach solche Skripte als normalen Funktionen ausführen mit Remoting statt Arbeitsabläufe. Sie wäre sehr wenige tatsächliche Vorteile Windows PowerShell -Workflow sowieso immer.
Halten Sie diese griffbereit
Eine Sache, die Windows PowerShell -Workflow deutlich fehlt ist ein Mittel beim Beibehalten einer Workflow-Datenübertragung zwischen Befehlen. Es nützlich, ein breiteres Spektrum an Umstände machen würde. Wenn ein Workflow unterbrochen und fortgesetzt wurden, konnte Befehle leicht neu Statusinformationen wie IP-Adressen, Computernamen, Benutzernamen oder was auch immer und weiter ausgeführt.
Angesichts dieses native Manko ist es etwas, das Sie wahrscheinlich selbst erstellen wollen. Richten Sie SQL Server und Erstellen von Datenbanktabellen, in denen Ihre Workflows Daten gespeichert werden können. Ein Workflow benötigen einige Mittel selbst, wie den Workflownamen und den Namen des Computers, die, den jede Workflowinstanz Zielen ist, eindeutig zu identifizieren.
Ihren Workflow kann dann einer Reihe von getrennten InlineScript Blöcken bestehen. Jeder wird den aktuellen Zustand aus der Datenbank gelesen, führen eine Aufgabe und, falls erforderlich, die Datenbank mit neuen Informationen aktualisieren. Es ist eine Schande, dass Windows PowerShell Workflowfeatures nicht helfen können dies zu automatisieren. Vielleicht ein "$ Workflow: Variable" Architektur verwendet, die XML-Dateien oder SQL Server unter der Motorhaube könnte helfen, aber das ist etwas für eine zukünftige Version.
Die gute Nachricht ist, dass es ziemlich einfach, "roll Ihre eigenen" Persistenz mit SQL Server. SQL Server ist vorzuziehen, XML-Dateien, weil es skalierbarer ist, Sie es leichter von mehreren Netzwerk-Standorten zugreifen können und es besseren gleichzeitigen Zugriff von mehreren Instanzen auf einmal unterstützt.
Die Microsoft .NET Framework System.Data.Sql.SqlClient-Klasse ist einfach zu bedienen. Gibt es Beispiele in meinem "Lernen PowerShell-Werkzeugbau in einem Monat Mittagessen" e-Buch. In der Tat, mein Mitautor und ich erstellt eine gesamte Modul können Sie wiederverwenden und zum kostenlosen download als Teil des Buches Beispielskripts.
Mit diesen Vorbereitungen aus dem Weg können wir beginnen, untersuchen, wie ein grundlegender Workflow aussieht. Das ist das Thema des nächsten Monats.
.jpg)
Don Jones ist ein Windows PowerShell MVP Award Gewinner und Redakteur beim TechNet Magazine. Er hat vier Bücher über Windows PowerShell Version 3, darunter mehrere kostenlose Titel zum Erstellen von HTML-Berichten in Windows PowerShell und Windows PowerShell -Remoting zusammen. Sie finden alles auf PowerShellBooks.com, oder Jones Ihre Frage in der Diskussionsforen auf PowerShell.org.