Windows PowerShell: Gängige Parameter und Laufzeitvariablen

  • Artikel

Jeden Monat in diesem Jahr präsentieren Don Jones eine Ratenzahlung in einem 12-Teil-Tutorial auf Windows PowerShell -Workflow. Wir empfehlen Ihnen, durch die Serie in Ordnung, zu lesen, beginnend mit der Januar 2013 Spalte.

Don Jones

Die nette Dinge über einen Workflow gehört Sie eine Tonne integrierte Funktionalität zu erhalten. Zum Beispiel weiß jeder Workflow, den Sie nativ schreiben wie man mit Remotecomputern über Windows PowerShell -Remoting (Windows Remote Management, WinRM genannt) spricht.

Das heißt, Sie können schreiben, jeder Workflow für den lokalen Computer ausgeführt, und Sie können die Fernbedienung die ganze Sache. Gemeinsamen Workflow-Parameter und Variablen können Sie diese native "Verknüpfung"-Funktionen zugreifen.

Gemeinsamen Workflow-Parameter

Diese sind alle in der About_WorkflowCommonParameters-Hilfedatei dokumentiert, obwohl Sie manuell importieren das PSWorkflow-Modul im Windows PowerShell 3.0 in Reihenfolge für die Hilfedatei sichtbar sein müssen. Hier ist ein Blick auf einige der häufigsten sind:

  • -AsJob zwingt den Workflow als Hintergrundjob ausgeführt. Der Verwandte - JobName-Parameter können Sie den Auftrag einen eigenen Namen zuweisen.
  • -PSAuthentication können Sie einen Authentifizierungsmechanismus wie Kerberos oder Credential Security Support Provider (CredSSP), angeben für Remoteverbindungen. CredSSP ist nützlich, wenn der Workflow muss nicht lokale Ressourcen zugreifen, die erfordern eine zusätzliche Netzwerk "Hop."
  • -PSComputerName können Sie einen oder mehrere Computernamen angeben, auf denen Sie den Workflow ausführen möchten. Z.B. PSComputerName-(Get-ADComputer-Filter * | Wählen Sie - erweitern Sie den Namen) würde den Workflow auf allen Domänencomputern ausführen. Sie sollten vorsichtig mit diesem sein.
  • -PSConnectionRetryCount gibt die Anzahl der Zeiten, die der Workflow versucht jede remote-Computer herstellen, und - PSConnectionRetryIntervalSec ist die Anzahl der Sekunden zwischen den versuchen zu warten.
  • -PSCredential können Sie alternative Anmeldeinformationen für Remoteverbindungen angeben.
  • -PSParameterCollection können Sie eine Hashtable mit gemeinsamen Workflow-Parameter angeben. Dieses ist schwierig. Sie können eine durch Kommas getrennte Liste von Hashtables, mit jeder Hashtable, Herstellen einer Verbindung zu einem oder mehreren Computern angeben. Dies gibt z. B. eine andere Verbindung Wiederholungszähler für Computer eins und zwei: -

PSParameterCollection, @{PSComputerName='ONE';PSConnectionRetryCount=10},@{PSComputerName='TWO';PSConnectionRetryCount=20}

  • PSPort und -PSUseSSL können Sie angeben, Alternative Ports und optional SSL aktivieren (vorausgesetzt, die remote-Rechnern ein gültiges SSL-Zertifikat und WinRM-Listener konfiguriert haben) für die Verbindung.

Denken Sie daran, dass alle Workflows diese Optionen erhalten. Du musst keinen Code arbeiten schreiben. Und es steht Ihnen frei, das ist genial.

Automatische Workflow Variablen

Windows PowerShell -automatische Variablen, z. B. $Args, $Error, $MyInvocation, $PSBoundParameters und $PsCmdlet, stehen innerhalb eines Workflows zur Verfügung. Workflows hinzufügen viel mehr am Anfang was Windows PowerShell bietet:

  • $PSParentActivityID sieht einen eindeutigen Bezeichner für den aktuellen Bereich und alle untergeordneten Bereiche. Auf diese Weise können Sie jede Instanz eines Workflows, z. B. Wenn Sie Daten in einer zentralen Datei protokollieren möchten eindeutig zu identifizieren.
  • $PSWorkflowRoot enthält den Root-Pfad eines Workflows.
  • $WorkflowInstanceID ist der eindeutige Bezeichner für die Workflowinstanz.

Ein ganzen Satz von Variablen spiegelt den Inhalt der gemeinsamen Workflow-Parameter, wie oben beschrieben. Beispielsweise enthält die $PSComputerName - PSComputerName den Wert des Parameters. Sie können auch $ParentJobName und $JobName verwenden, auf Informationen zuzugreifen. Wenn - PSComputerName mehrere Werte enthält, wird jeder Computer mit den Workflow nur seinen eigenen Namen in $PSComputerName angezeigt. Überprüfen Sie dieses vollständige Liste der Variablen für zusätzliche Referenz.

Variable Regeln

Denken Sie daran, dass Variablen in einem Workflow ein wenig anders funktionieren. Beispielsweise können nicht Sie die Ergebnisse eines Unterausdrucks einer Variablen zuweisen. anstelle dieses Codes verwenden:

$x = $(Get-Service)

Sie würde einfach ausführen:

$x = Get-Service

Darüber hinaus können nicht Sie einen Variablenwert in eine andere Variable in derselben Anweisung zuweisen:

$a = $b = 23

Sie müssten dazu als zwei getrennte Vorgänge. Auch, können nicht Sie ein Objekt in einer Variablen zu setzen und Eigenschaften des Objekts zu ändern:

$obj = New-PSSessionOption $obj.SkipCACheck = $true

Eigene Parameter und Variablen

Ihre Workflows können natürlich ihre eigenen Eingabeparameter in einem Param-Block definieren. Diese sind als Variablen innerhalb des Workflows ausgesetzt. Beispielsweise bietet definieren - MyParam Ihnen eine $MyParam-Variable innerhalb des Workflows. Fügen Sie einfach nicht die allgemeinen Workflow-Parameter. Diejenigen werden magisch von Windows PowerShell hinzugefügt, wenn der Workflow ausgeführt wird.

Gemeinsame Aktivitätsparameter

Hier ist ein bisschen verwirrend — jeden Befehl ausführen in einem Workflow oder jeden Block von Befehlen, die Sie in einem InlineScript {} Block ausführen gilt eine Tätigkeit. Windows PowerShell hinzugefügt gemeinsame Parameter auf diese Tätigkeiten, einschließlich - PSComputerName. Weil diese Aktivitäten wie normale Cmdlets aussehen, kann dies verwirrend sein. Beispiele:

Get-Process –PSComputerName ONE,TWO,THREE

Das normale Cmdlet Get-Process hat ein - ComputerName-Parameter, aber kein - PSComputerName-Parameter. Letzteres gilt nur innerhalb eines Workflows, wo Get-Process ist technisch ein Cmdlet nicht — es ist eine Workflowaktivität. Ein InlineScript {} Block unterstützt diese Parameter:

InlineScript { Get-Process } –PSComputerName ONE,TWO,THREE

Die Befehle innerhalb der InlineScript {} sind nur Cmdlets. Sie bekommen nicht die Aktivität allgemeine Parameter. Schließlich, und das ist einfach um zu machen mehr verwirrend, jeder Befehl, der nicht über einen entsprechenden Workflow Tätigkeit wird implizit in einen InlineScript {} eingebunden werden, sondern die gemeinsame Aktivitätsparameter kann nicht verwendet werden. Beispiele:

Get-WindowsFeature

Das ist ein Befehl, keiner Workflow-Aktivität. Es gibt keine entsprechende Aktivität. Nicht, dass Sie wissen, dass würde denn es keine Möglichkeit gibt zu sagen. Jedoch können nicht Sie - PSComputerName hinzufügen. Dies ist in dem Workflow ärgerlich wird, denn es gibt keine Möglichkeit, einfach zu sagen, was eine Aktivität ist und was nicht. Also wird nicht immer wissen Sie außer zu versuchen es und haben es entweder erfolgreich sein oder fehlschlagen.

Sehen Sie, wie dies schwierig bekommt?

Dies ist, wo Arbeit mit Workflows beginnt schwer sein. Du hast alle diese zusätzlichen Bits geschieht unter der Haube. Während die meisten hilfreich sind, sind sie nicht konsequent umgesetzt. Sie am Ende mit viel Versuch und Irrtum.

Denken Sie daran, dass Workflow ist eine andere Welt. Windows PowerShell liefert nur ein Vortor. Du kannst nicht erwarten vollen Übereinstimmung mit der normalen Windows PowerShell -Umgebung.

Don Jones

Don Jones ist ein Windows PowerShell -MVP-Auszeichnung, Empfänger und als Redakteur beim TechNet Magazine. Er hat vier Bücher über Windows PowerShell Version 3.0, einschließlich freie Plätze auf Windows PowerShell -Remoting und Erstellen von HTML-Berichten in Windows PowerShellzusammen. Finden sie alle zur PowerShellBooks.com, oder Jones -Fragen in der Diskussionsforen auf PowerShell.org.

Verwandte Inhalte