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 a 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 do 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 job simplesmente passa um bloco de script para o cmdlet Start-Job.
Start-Job –Name GetFileList –Scriptblock {Get-ChildItem C: –Recurse}
Get-Job –Name GetFileList | Stop-Job
Get-Job –Name GetFileList | Receive-Job –Keep
Get-Job –Name GetFileList | Remove-Job
Isso irá removê-lo da lista de trabalhos retornados pelo Get-Job.
Trabalhos remotos
Algumas lições atrás, vimos como podemos usar o comando remoto para executar comandos do PowerShell em uma máquina remota usando o 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 -Credential administrator -ScriptBlock {gci} –AsJob
Existem duas maneiras de contornar isso. Em primeiro lugar, se você souber quais computadores deseja obter os resultados, simplesmente use o parâmetro ComputerName do cmdlet Recieve –Job.
Get-Job –Id 3 | Receive-Job –Keep –ComputerName Viper
Get-Job -Id 3 –IncludeChildJob
Get-Job -Id 5 | Receive-Job –Keep
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.
Trabalhos agendados
Os últimos três tipos de trabalhos que examinamos não foram 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 Security -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.
Get-ScheduledJob
