Geek School Aprenda Como Usar Empregos no PowerShell

O PowerShell tem quatro tipos de trabalhos - Trabalhos em segundo plano, Trabalhos remotos, Trabalhos WMI e Trabalhos agendados. Junte-se a nós enquanto descobrimos o que são e como podemos usá-los.

Não deixe de ler os artigos anteriores da série:

Aprenda a automatizar o Windows com o PowerShell
Aprendendo a usar cmdlets no PowerShell
Aprendendo como usar objetos no PowerShell
Aprendendo a formatar, filtrar e comparar no PowerShell
Aprenda a usar o Remoting no PowerShell
Usando o PowerShell para obter informações sobre o computador
Trabalhando com coleções no PowerShell

E fique ligado para o resto da série durante toda a semana.

Trabalhos em segundo plano

Até agora, tudo o que mostrei no PowerShell foi síncrono, o que significa que digitamos algo no shell e não podemos fazer muito até que o comando tenha terminado a execução. É aí que entram os trabalhos em segundo plano. Para iniciar um segundo plano, o trabalho simplesmente passa um bloco de script para o cmdlet Start-Job..

Nome-Start-Job GetFileList -Scriptblock Get-ChildItem C: \ -Recurse

Agora estamos livres para fazer o que quisermos dentro do shell enquanto esse bloco de script é executado em segundo plano.

Quando você inicia um novo trabalho, o PowerShell cria um novo objeto de trabalho que representa esse trabalho. Você pode obter uma lista de todos os trabalhos a qualquer momento executando o cmdlet Get-Job.

Os objetos de trabalho informam sobre o status dos trabalhos. Por exemplo, na captura de tela acima podemos ver que temos um BackgroundJob chamado GetFileList que ainda está em execução, mas que já começou a retornar dados. Se em algum momento você decidir que o trabalho está em execução por muito tempo, você pode facilmente pará-lo, interrompendo-o para Stop-Job..

Get-Job -Name GetFileList | Parar trabalho

No entanto, depois de ter parado um trabalho, os dados recebidos até o ponto em que você parou ainda estarão disponíveis. Há uma pegadinha, no entanto. No PowerShell, depois de receber os resultados de um trabalho, eles são excluídos. Para que eles permaneçam, você deve especificar o parâmetro keep switch de Receive-Job.

Get-Job -Name GetFileList | Receber-trabalho-manter

Quando você terminar um trabalho, é recomendável removê-lo. Para remover o trabalho, simplesmente canalize-o para o cmdlet Remove-Job.

Get-Job -Name GetFileList | Remover trabalho

Isso irá removê-lo da lista de trabalhos retornados por Get-Job.

Trabalhos remotos

Algumas lições atrás, vimos como podemos usar o recurso de comunicação remota para executar comandos do PowerShell em uma máquina remota usando Invoke-Command, mas você sabia que também pode usar o Invoke-Command para iniciar um trabalho remoto em segundo plano? Para fazer isso, simplesmente adicione o parâmetro -AsJob no final do seu comando:

Invoke-Command -ComputerName Flash, Viper - Administrador -redencial -ScriptBlock gci -AsJob

Esse foi um comando simples e deve ter terminado a execução até agora, então vamos dar uma olhada no nosso status de trabalhos.

Hmm, parece que falhou. Isso me leva à minha primeira pegadinha com empregos. Quando você cria um novo trabalho de qualquer tipo no PowerShell, ele cria um trabalho pai além de um trabalho filho para cada computador em que você está executando o trabalho. Quando você usa o cmdlet Get-Job, ele mostra apenas as tarefas pai e a propriedade de estado é o pior cenário, o que significa que, mesmo que o comando não tenha sido executado em uma de cem computadores, o estado dos trabalhos pai dirá falhou. Para ver uma lista de tarefas filho, você precisa usar o parâmetro IncludeChildJob.

Se você olhar mais de perto, verá que o trabalho realmente só falha em um computador, o que nos leva à próxima pegadinha. Quando você tenta obter os resultados do trabalho, se especificar o nome ou o ID do trabalho do pai, o PowerShell retornará os dados de todos os trabalhos filhos. O problema é que, se houver um erro em um dos trabalhos filho, ficaremos com algum texto em vermelho.

Existem duas maneiras de contornar isso. Em primeiro lugar, se você souber para quais computadores deseja os resultados, basta usar o parâmetro ComputerName do cmdlet Recieve -Job.

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

Como alternativa, você pode obter os resultados de um trabalho filho específico usando seu ID de trabalho.

Get-Job -Id 3 -IncludeChildJob

Get-Job -Id 5 | Receber-trabalho-manter

Empregos em WMI

Os trabalhos do WMI são praticamente os mesmos que os trabalhos remotos, exigindo que apenas o parâmetro -AsJob seja adicionado ao cmdlet Get-WmiObject.

Infelizmente, isso significa que eles também estão sujeitos aos mesmos problemas que mencionei na seção de Trabalhos remotos..

Trabalhos agendados

Os últimos três tipos de trabalhos que vimos não eram persistentes, o que significa que eles estão disponíveis apenas na sua sessão atual. Basicamente, isso significa que, se você iniciar um trabalho, abrir outro Console do PowerShell e executar o Get-Job, não verá nenhum trabalho. No entanto, volte para o console do qual você cancelou o trabalho e você poderá ver seu status. Isto está em contraste com os trabalhos agendados que são persistentes. Basicamente, um trabalho agendado é um bloco de script que é executado em um agendamento. No passado, o mesmo efeito poderia ter sido alcançado usando o Agendador de Tarefas do Windows, que é realmente o que está acontecendo sob o capô. Para criar um novo trabalho agendado, fazemos o seguinte:

Register-ScheduledJob -Name GetEventLogs -ScriptBlock Get-EventLog -LogName Segurança -Newest 100 -Trigger (New-JobTrigger -Daily -At 5pm) -ScheduledJobOption (New-ScheduledJobOption -RunElevated)

Há muita coisa acontecendo nesse comando, então vamos dividi-lo.

Primeiro, damos ao nosso trabalho agendado um nome de GetEventLogs.
Em seguida, informamos que, quando acionado, queremos que ele execute o conteúdo do bloco de script especificado, que basicamente obtém as 100 entradas mais recentes do log de eventos de segurança.
Em seguida, especificamos um gatilho. Como o parâmetro do acionador usa um objeto acionador como entrada, usamos um comando entre parênteses para gerar um acionador que será acionado todos os dias às 17h..
Como estamos lidando com o log de eventos, precisamos executar como administrador, o que podemos especificar criando um novo objeto ScheduledJobOption e passando-o ao parâmetro ScheduledJobOption.

Como esse é um tipo de trabalho ligeiramente diferente, você também precisará usar um comando diferente para recuperar uma lista de todos os trabalhos agendados em uma máquina..

Get-ScheduledJob

Isso é tudo que existe para isso.