Windows PowerShell : Variables d'exécution et paramètres courants
Chaque mois de cette année, Don Jones présentera une tranche dans un tutoriel de 12 parties le Workflow Windows PowerShell . Nous vous encourageons à lire la série dans l'ordre, commençant par la janvier 2013 colonne.
Don Jones
Un des propos d'un flux de travail est de vous obtenir une tonne de fonctionnalités intégrées. Par exemple, chaque flux de travail que vous écrivez en mode natif sait comment parler aux ordinateurs distants via Windows PowerShell distante (Windows Remote Management, dite de WinRM).
Cela signifie que vous pouvez écrire à chaque flux de travail à exécuter sur l'ordinateur local, et vous pouvez à distance l'ensemble de la chose. Commune de variables et de paramètres de flux de travail vous permettent d'accéder à ces fonctionnalités natives « raccourci ».
Paramètres de flux de travail communs
Elles sont toutes documentées dans le fichier d'aide about_WorkflowCommonParameters, même si vous devez importer manuellement le module PSWorkflow dans Windows PowerShell 3.0 dans l'ordre pour ce fichier d'aide pour être visible. Voici un regard sur les plus plus fréquentes :
- -AsJob force le flux de travail à exécuter en tant qu'une tâche en arrière-plan. Le paramètre JobName - connexes vous permet d'appliquer un nom personnalisé à l'emploi.
- PSAuthentication - vous permet de spécifier le mécanisme d'authentification, tel que Kerberos ou d'informations d'identification Security Support Provider (CredSSP), pour les connexions distantes. CredSSP est utile lorsque le flux de travail a besoin d'accéder aux ressources non locaux qui exigent un réseau supplémentaire « hop ».
- PSComputerName - vous permet de spécifier un ou plusieurs noms d'ordinateurs sur lesquels vous envisagez d'exécuter le flux de travail. Par exemple, - PSComputerName (Get-ADComputer-filtre * | Sélectionnez - développez nom) courraient le flux de travail sur tous les ordinateurs du domaine. Soyez prudent avec celui-ci.
- -PSConnectionRetryCount spécifie le nombre de fois que le flux essaiera de se connecter à chaque ordinateur distant, et - PSConnectionRetryIntervalSec est le nombre de secondes d'attente entre les tentatives.
- -PSCredential vous permet de spécifier les informations d'identification de rechange pour les connexions distantes.
- PSParameterCollection - vous permet de spécifier une table de hachage des paramètres courants de flux de travail. Celui-ci est délicate. Vous pouvez spécifier une liste séparée par des virgules des tables de hachage, avec chaque connexion à un ou plusieurs ordinateurs de table de hachage. Par exemple, cela spécifie un nombre de tentatives de connexion différente pour les ordinateurs un et deux : -
PSParameterCollection, @{PSComputerName='ONE';PSConnectionRetryCount=10},@{PSComputerName='TWO';PSConnectionRetryCount=20}
- PSPort et PSUseSSL - laissez-vous spécifier d'autres ports et éventuellement activer SSL (en supposant que les ordinateurs distants ont un certificat SSL valide et un écouteur WinRM configuré) pour la connexion.
N'oubliez pas, tous les workflows obtenir ces options. Il ne faut pas écrire de code pour les faire fructifier. Et ils sont gratuits, ce qui est génial.
Variables de workflow automatique
Toutes les normales Windows PowerShell variables automatiques, tels que $Args, $Error, $MyInvocation, $PSBoundParameters et $PsCmdlet, sont disponibles au sein d'un workflow. Flux de travail ajoute beaucoup plus sur le dessus de ce que Windows PowerShell fournit :
- $PSParentActivityID fournit un identificateur unique pour la portée actuelle et pour toutes les étendues de l'enfant. Cela vous permet d'identifier de façon unique chaque instance d'un workflow, par exemple lorsque vous souhaitez enregistrer les informations dans un fichier central.
- $PSWorkflowRoot contient le chemin d'accès racine d'un flux de travail.
- $WorkflowInstanceID est l'identificateur unique pour l'instance de workflow.
Toute une série de variables reflète le contenu des paramètres communs workflow décrits précédemment. Par exemple, $PSComputerName contient la PSComputerName - valeur du paramètre. Vous pouvez également utiliser $ParentJobName et $JobName pour accéder aux renseignements sur les emplois. Si - PSComputerName contient plusieurs valeurs, chaque ordinateur qui exécute le flux de travail verrez que son propre nom en $PSComputerName. Cochez cette case liste complète des variables pour référence supplémentaire.
Règles de variables
N'oubliez pas que les variables dans un flux de travail fonctionnent un peu différemment. Par exemple, vous ne pouvez pas affecter les résultats d'une sous-expression à une variable. à la place de :
$x = $(Get-Service)
Il aurait suffit de lancer :
$x = Get-Service
Aussi, vous ne pouvez pas affecter une valeur de la variable à une autre variable dans la même instruction :
$a = $b = 23
Vous devrez faire cela comme deux opérations distinctes. En outre, vous ne peut pas mettre un objet dans une variable et modifier les propriétés de cet objet :
$obj = New-PSSessionOption $obj.SkipCACheck = $true
Vos propres paramètres et variables
Votre flux de travail peut bien sûr définir leurs propres paramètres d'entrée dans un bloc de Param. Elles sont exposées dans le workflow en tant que variables. Par exemple, définir - MyParam vous donne une variable $MyParam dans le workflow. Juste ne pas y ajouter les paramètres de flux de travail commun. Comme par magie, ils sont ajoutés par Windows PowerShell lorsque le workflow s'exécute.
Paramètres communs d'activité
Voici un peu de confusion — chaque commande que vous exécutez dans un flux de travail, ou chaque bloc de commandes que vous exécutez dans un bloc de {} InlineScript, est considérée comme une activité. Windows PowerShell ajoute des paramètres communs à ces activités, y compris - PSComputerName. Parce que ces activités ressemblent à des applets de commande normale, cela peut être source de confusion. Par exemple :
Get-Process –PSComputerName ONE,TWO,THREE
La cmdlet Get-Process normale a un paramètre ComputerName, mais pas un paramètre - PSComputerName. Ce dernier est valide uniquement dans un flux de travail, où Get-Process pas techniquement une applet de commande — c'est une activité de flux de travail. Un bloc de {} InlineScript prend en charge ces paramètres :
InlineScript { Get-Process } –PSComputerName ONE,TWO,THREE
Les commandes à l'intérieur de la InlineScript () sont des applets de commande juste. Ils n'obtiennent pas l'activité des paramètres communs. Enfin et seulement pour rendre les choses plus confuses, toute commande qui n'est pas un flux de travail équivalent activité seront implicitement encapsulée dans un {} les InlineScript, mais ne pouvez pas utiliser les paramètres de l'activité commune. Par exemple :
Get-WindowsFeature
C'est une commande, pas une activité de workflow. Il n'y a aucune activité équivalente disponible. Non pas que vous savez qui, parce qu'il n'y a aucun moyen de savoir. Mais vous ne pouvez pas ajouter - PSComputerName à elle. C'est là le flux de travail devient ennuyeux, parce qu'il n'existe aucun moyen facile de dire ce qui est une activité ou non. Si vous ne sera pas toujours savoir, sauf pour l'essayer et l'ai réussite ou l'échec.
Voir comment cela devient compliqué ?
C'est où le travail avec les workflows commence à devenir difficile. Vous avez tous ces bits supplémentaires qui passe sous le capot. Bien que la plupart est utile, elles ne sont pas systématiquement implémentées. Vous vous retrouvez avec beaucoup de tâtonnements.
N'oubliez pas, flux de travail est un monde différent. Windows PowerShell fournit simplement une passerelle vers elle. Vous ne pouvez pas attendre une cohérence totale avec l'environnement Windows PowerShell normal.
.jpg)
Don Jones est une récompense de MVP Windows PowerShell destinataire et un rédacteur de contribution à TechNet Magazine. Il a co-écrit quatre livres sur Windows PowerShell version 3.0, y compris celles qui sont libres sur Windows PowerShell remoting et de création de rapports HTML dans Windows PowerShell. Trouvez-les tous à PowerShellBooks.com, ou poser des questions de Jones dans les forums de discussion à PowerShell.org.