PowerShell propose quatre types de travaux: les travaux en arrière-plan, les travaux à distance, 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:
Et restez à l’écoute pour le reste de la série toute la semaine.
Emplois d’arrière-plan
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 d’arrière-plan. Pour démarrer un arrière-plan, il suffit de transmettre un bloc de script à l’applet de commande Start-Job.
Start-Job –Nom GetFileList –Scriptblock {Get-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 lancez une nouvelle tâche, PowerShell crée un nouvel objet de tâche qui représente cette tâche. Vous pouvez obtenir une liste de toutes les tâches à tout moment en exécutant l’applet de commande Get-Job.
Les objets de tâche vous informent sur l’état des tâches. 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 qui a déjà commencé à renvoyer des données. Si à un moment donné vous décidez que le travail est en cours d’exécution depuis trop longtemps, vous pouvez facilement l’arrêter en le redirigeant vers Stop-Job.
Get-Job –Nom GetFileList | Stop-Job
Cependant, une fois que vous avez arrêté un travail, les données qu’il a reçues jusqu’au moment où vous l’avez arrêté sont toujours disponibles. Il y a un piège, 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 –Nom GetFileList | Receive-Job – Garder
Une fois que vous avez terminé un travail, il est recommandé de le supprimer. Pour supprimer le travail, dirigez-le simplement vers l’applet de commande Remove-Job.
Get-Job –Nom GetFileList | Remove-Job
Cela le supprimera de la liste des travaux renvoyés par Get-Job.
Emplois à distance
Il y a quelques leçons, nous avons examiné comment nous pouvons utiliser la communication à distance pour exécuter des commandes PowerShell sur une machine distante à l’aide d’Invoke-Command, mais saviez-vous que vous pouvez également utiliser Invoke-Command pour lancer une tâche à distance 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 de s’exécuter maintenant, alors jetons un coup d’œil à l’état de nos travaux.
Hmm, on dirait que ça a échoué. Cela m’amène à mon premier piège avec les emplois. Lorsque vous créez un nouveau travail de n’importe quel 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 l’applet de commande Get-Job, elle ne vous montre que les travaux parents et la propriété state est le pire des cas, ce qui signifie que même si la commande n’a échoué que sur un ordinateur sur cent, l’état des travaux parents indiquera échoué. Pour afficher 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 en effet échoué que sur un seul ordinateur, ce qui nous amène au prochain piège. Lorsque vous essayez d’obtenir les résultats du travail, si vous spécifiez le nom ou l’ID du travail du parent, PowerShell renverra les données de tous les travaux enfants. Le problème est que s’il y a eu une erreur dans l’un des emplois enfants, nous allons nous retrouver avec du texte rouge.
Il y a deux façons de contourner ce problème. Premièrement, si vous savez pour quels ordinateurs vous souhaitez obtenir les résultats, vous pouvez simplement utiliser le paramètre ComputerName de l’applet de commande 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 | Receive-Job – Garder
Emplois WMI
Les travaux WMI sont sensiblement les mêmes que les travaux distants, car seuls le paramètre –AsJob doit être ajouté à l’applet de commande Get-WmiObject.
Malheureusement, cela signifie qu’ils sont également soumis aux mêmes pièges que j’ai mentionnés dans la section Travaux à distance.
Travaux planifiés
Les trois derniers types d’emplois que nous avons examinés n’étaient pas persistants, ce qui signifie qu’ils ne sont disponibles que dans votre session actuelle. Fondamentalement, cela signifie que si vous lancez une tâche, puis ouvrez une autre console PowerShell et exécutez Get-Job, vous ne verrez aucune tâche. Cependant, revenez à la console à partir de laquelle vous avez lancé le travail, vous pourrez voir son statut. Cela contraste avec les tâches planifiées qui sont persistants. Fondamentalement, un travail planifié est un bloc de script qui s’exécute selon une planification. Dans le passé, le même effet aurait pu être obtenu en utilisant le planificateur de tâches Windows, ce qui est vraiment ce qui se passe sous le capot. Pour créer un nouveau travail planifié, nous procédons comme suit:
Register-ScheduledJob -Name GetEventLogs -ScriptBlock {Get-EventLog -LogName Security -Newest 100} -Trigger (New-JobTrigger -Daily -At 5pm) -ScheduledJobOption (New-ScheduledJobOption -RunElevated)
Il se passe beaucoup de choses dans cette commande, alors décomposons-le.
- Tout d’abord, nous donnons à notre tâche planifiée un nom de GetEventLogs.
- Nous lui disons ensuite que lorsqu’il est déclenché, nous voulons qu’il exécute le contenu du bloc de script spécifié, qui obtient essentiellement les 100 dernières entrées du journal des événements de sécurité.
- Ensuite, nous spécifions un déclencheur. Étant donné que le paramètre de déclenchement prend un objet de déclenchement en entrée, nous avons utilisé une commande entre parenthèses pour générer un déclencheur qui se déclenchera tous les jours à 17 heures.
- Puisque nous traitons le journal des événements, nous devons exécuter en tant qu’administrateur, ce que nous pouvons spécifier en créant un nouvel objet ScheduledJobOption et en le transmettant au paramètre ScheduledJobOption.
Puisqu’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’on peut en dire.
