Geek School: Apprenez à utiliser les Jobs dans PowerShell

PowerShell propose quatre types de travaux: les travaux d'arrière-plan, les travaux distants, les travaux WMI et les travaux planifiés. Rejoignez-nous pour découvrir ce qu'ils sont et comment nous pouvons les utiliser.

Assurez-vous de lire les articles précédents de la série:

• Apprenez à automatiser Windows avec PowerShell
• Apprendre à utiliser des applets de commande dans PowerShell
• Apprendre à utiliser des objets dans PowerShell
• Apprentissage de formatage, filtrage et comparaison dans PowerShell
• Apprenez à utiliser Remoting dansPowerShell
• Utilisation de PowerShell pour obtenir des informations sur l'ordinateur
• Utilisation des collections dans PowerShell

Et restez à l'écoute pour le reste de la série toute la semaine.

Background Jobs

Jusqu'à présent, tout ce que je vous ai montré dans PowerShell était synchrone, ce qui signifie que nous tapons quelque chose dans le shell et que nous ne pouvons pas vraiment faire grand-chose tant que cette commande n'est pas terminée. C'est là qu'interviennent les travaux en arrière-plan. Pour démarrer un arrière-plan, le travail passe simplement un bloc de script à la cmdlet Start-Job.

Start-Job -Name GetFileList -Scriptblock{ Obtenir-ChildItem C: \ -Recurse}

Maintenant, nous sommes libres de faire ce que nous voulons dans le shell pendant que ce bloc de script s'exécute en arrière-plan.

Lorsque vous démarrez un nouveau travail, PowerShell crée un nouvel objet de travail qui représente ce travail. Vous pouvez obtenir une liste de tous les travaux à tout moment en exécutant la cmdlet Get-Job.

Les objets de travail vous indiquent l'état des travaux. Par exemple, dans la capture d'écran ci-dessus, nous pouvons voir que nous avons un BackgroundJob appelé GetFileList qui est toujours en cours d'exécution, mais a déjà commencé à retourner des données. Si, à un moment donné, vous décidez que le travail est en cours depuis trop longtemps, vous pouvez facilement l'arrêter en le redirigeant vers Stop-Job.

Get-Job -Name GetFileList |Stop-Job

Cependant, une fois que vous avez arrêté un travail, toutes les données qu'il a reçues jusqu'au moment où vous l'avez arrêté sont toujours disponibles. Il y a un gotcha, cependant. Dans PowerShell, une fois que vous recevez les résultats d'un travail, ils sont supprimés. Pour qu'ils restent, vous devez spécifier le paramètre keep switch de Receive-Job.

Get-Job -Name GetFileList |Receive-Job -Keep

Une fois que vous avez terminé avec un travail, il est recommandé de le supprimer. Pour supprimer le travail, dirigez-le simplement vers la cmdlet Remove-Job.

Get-Job -Name GetFileList |Remove-Job

Cela le supprimera de la liste des tâches renvoyées par Get-Job.

Remote Jobs

Il y a quelques leçons, nous avons examiné comment utiliser Remoting pour exécuter des commandes PowerShell sur une machine distante en utilisant Invoke-Command, mais saviez-vous que vous pouvez également utiliser Invoke-Command pour lancer un travail distant en arrière-plan? Pour ce faire, ajoutez simplement le paramètre -AsJob à la fin de votre commande:

Invoke-Command -ComputerName Flash, Viper -Credential administrator -ScriptBlock{ gci} -AsJob

C'était une commande simple et devrait avoir fini d'être exécutée maintenantlaisse jeter un oeil à notre statut d'emplois.

Hmm, on dirait que ça a échoué.Cela m'amène sur mon premier gotcha avec des emplois. Lorsque vous créez un nouveau travail de tout type dans PowerShell, il crée un travail parent en plus d'un travail enfant pour chaque ordinateur sur lequel vous exécutez le travail. Lorsque vous utilisez la cmdlet Get-Job, elle affiche uniquement les travaux parents et la propriété state est le pire des cas, ce qui signifie que même si la commande ne peut s'exécuter que sur un ordinateur sur cent, l'état des travaux parents indiqueéchoué.Pour voir une liste des travaux enfants, vous devez utiliser le paramètre IncludeChildJob.

Si vous regardez de plus près, vous verrez que le travail n'a effectivement échoué que sur un ordinateur, ce qui nous amène au prochain gotcha. Lorsque vous essayez d'obtenir les résultats du travail, si vous spécifiez le nom ou l'ID du travail du parent, PowerShell renvoie les données de tous les travaux enfants. Le problème est que s'il y a eu une erreur dans l'un des travaux enfants, nous allons nous retrouver avec du texte rouge.

Il y a deux façons de contourner cela. Premièrement, si vous connaissez les ordinateurs pour lesquels vous voulez obtenir les résultats, vous pouvez simplement utiliser le paramètre ComputerName de la cmdlet Recieve -Job.

Get-Job -Id 3 |Receive-Job -Keep -ComputerName Viper

Vous pouvez également obtenir les résultats d'un travail enfant spécifique en utilisant son ID de travail.

Get-Job -Id 3 -IncludeChildJob

Get-Job -Id 5 |Recevoir-Job -Keep

Travaux WMI

Les tâches WMI sont sensiblement les mêmes que les tâches distantes, ce qui nécessite l'ajout du seul paramètre -AsJob à la cmdlet Get-WmiObject.

Malheureusement, cela signifie qu'ils sont également soumis aux mêmes pièges que ceux mentionnés dans la section Remote Jobs.

Travaux planifiés

Les trois derniers types de travaux que nous avons examinés n'étaient pas persistants, ce qui signifie qu'ils ne sont disponibles que dans votre session en cours. Fondamentalement, cela signifie que si vous lancez un travail, puis ouvrez une autre console PowerShell et exécutez Get-Job, vous ne verrez aucun travail. Cependant, revenez à la console dont vous avez retiré le travail, vous pourrez voir son statut. Cela est en contraste avec les tâches planifiées dont sont persistantes .Fondamentalement, un travail planifié est un bloc de script qui s'exécute sur une planification. Dans le passé, le même effet aurait pu être obtenu en utilisant le planificateur de tâches de Windows, qui est vraiment ce qui se passe sous le capot. Pour créer un nouveau travail planifié, nous procédons comme suit:

Register-ScheduledJob -Nom GetEventLogs -ScriptBlock{ Get-EventLog -Nom du nom de sécurité -Newest 100} -Trigger( New-JobTrigger -Daily -At 17h) -ScheduledJobOption( New-ScheduledJobOption-RunElevated)

Il y a beaucoup de choses dans cette commande, alors décomposons-la.

• Tout d'abord, nous donnons à notre Job Scheduled un nom de GetEventLogs.
• Nous lui disons alors que lorsqu'il est déclenché, nous voulons qu'il exécute le contenu du bloc de script spécifié, qui reçoit essentiellement les 100 dernières entrées du journal des événements de sécurité.
• Ensuite, nous spécifions un déclencheur. Puisque le paramètre trigger prend un objet trigger en entrée, nous avons utilisé une commande entre parenthèses pour générer un trigger qui se déclenchera tous les jours à 17h.
• Puisque nous traitons le journal des événements, nous devons exécuter en tant qu'administrateur, que nous pouvons spécifier en créant un nouvel objet ScheduledJobOption et en le passant au paramètre ScheduledJobOption.

Comme il s'agit d'un type de travail légèrement différent, vous devrez également utiliser une commande différente pour récupérer une liste de tous les travaux planifiés sur une machine.

Get-ScheduledJob

C'est tout ce qu'il y a à faire.