Escuela de friki Aprende a usar trabajos en PowerShell

PowerShell tiene cuatro tipos de trabajos: trabajos en segundo plano, trabajos remotos, trabajos WMI y trabajos programados. Únase a nosotros para descubrir qué son y cómo podemos usarlos..

Asegúrese de leer los artículos anteriores de la serie:

• Aprenda cómo automatizar Windows con PowerShell
• Aprendiendo a usar cmdlets en PowerShell
• Aprender a usar objetos en PowerShell
• Aprendizaje de formato, filtrado y comparación en PowerShell
• Aprende a usar el control remoto en PowerShell
• Uso de PowerShell para obtener información de la computadora
• Trabajando con Colecciones en PowerShell

Y estad atentos para el resto de la serie toda la semana..

Trabajos de fondo

Hasta ahora, todo lo que le he mostrado en PowerShell ha sido sincrónico, lo que significa que escribimos algo en el shell y realmente no podemos hacer mucho hasta que el comando haya terminado de ejecutarse. Aquí es donde entran los trabajos en segundo plano. Para iniciar un fondo, un trabajo simplemente pasa un bloque de secuencia de comandos al cmdlet Start-Job.

Inicio-Trabajo -Nombre GetFileList -Scriptblock Get-ChildItem C: \ -Recurse

Ahora somos libres de hacer lo que queramos dentro del shell mientras el bloque de script se ejecuta en segundo plano.

Cuando inicia un nuevo trabajo, PowerShell crea un nuevo objeto de trabajo que representa ese trabajo. Puede obtener una lista de todos los trabajos en cualquier momento ejecutando el cmdlet Get-Job.

Los objetos de trabajo le informan sobre el estado de los trabajos. Por ejemplo, en la captura de pantalla anterior podemos ver que tenemos un BackgroundJob llamado GetFileList que aún se está ejecutando, pero que ya ha comenzado a devolver datos. Si en algún momento decide que el trabajo se ha estado ejecutando durante demasiado tiempo, puede detenerlo fácilmente enviándolo a Stop-Job.

Get-Job -Nombre GetFileList | Stop Job

Sin embargo, una vez que haya detenido un trabajo, los datos que recibió hasta el momento en que lo detuvo todavía están disponibles. Aunque hay un gotcha. En PowerShell, una vez que recibe los resultados de un trabajo, se eliminan. Para que permanezcan, debe especificar el parámetro del interruptor de mantenimiento de Receive-Job.

Get-Job -Nombre GetFileList | Recibir-Trabajo-Mantener

Una vez que haya terminado con un trabajo, es una buena práctica eliminarlo. Para eliminar el trabajo, simplemente canalícelo al cmdlet Remove-Job.

Get-Job -Nombre GetFileList | Quitar trabajo

Esto lo eliminará de la lista de trabajos devueltos por Get-Job.

Trabajos remotos

Hace algunas lecciones, vimos cómo podemos usar el control remoto para ejecutar comandos de PowerShell en una máquina remota usando Invoke-Command, pero ¿sabía que también puede usar Invoke-Command para iniciar un trabajo remoto en segundo plano? Para hacerlo, simplemente agregue el parámetro -AsJob al final de su comando:

Invoke-Command -ComputerName Flash, Viper -Credential administrador -ScriptBlock gci -AsJob

Ese era un comando simple y debería haber terminado de ejecutarse ahora, así que echemos un vistazo al estado de nuestros trabajos.

Hmm, parece que ha fallado. Esto me lleva a mi primer gotcha con trabajos. Cuando crea un nuevo trabajo de cualquier tipo en PowerShell, crea un trabajo principal además de un trabajo secundario para cada equipo contra el que está ejecutando el trabajo. Cuando usa el cmdlet Get-Job, solo muestra los trabajos principales y la propiedad del estado es el peor escenario, lo que significa que incluso si el comando no se ejecutó en una de cada cien computadoras, el estado de los trabajos principales dirá ha fallado. Para ver una lista de trabajos secundarios, debe usar el parámetro IncludeChildJob.

Si te fijas más, verás que, de hecho, el trabajo solo falló en una computadora, lo que nos lleva a la siguiente cuenta. Cuando intenta obtener los resultados del trabajo, si especifica el nombre o la ID del trabajo principal, PowerShell devolverá los datos de todos los trabajos secundarios. El problema es que si hubo un error en uno de los trabajos secundarios, nos quedará un texto en rojo..

Hay dos maneras de solucionar esto. En primer lugar, si sabe para qué equipos desea obtener los resultados, simplemente puede usar el parámetro ComputerName del cmdlet Recieve -Job.

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

Alternativamente, puede obtener los resultados de un trabajo secundario específico utilizando su ID de trabajo.

Get-Job -Id 3 -IncludeChildJob

Get-Job -Id 5 | Recibir-Trabajo-Mantener

WMI Jobs

Los trabajos de WMI son muy parecidos a los trabajos remotos, que requieren que solo se agregue el parámetro -AsJob al cmdlet Get-WmiObject.

Desafortunadamente, esto significa que también están sujetos a los mismos errores que mencioné en la sección Trabajos remotos.

Trabajos programados

Los últimos tres tipos de trabajos que examinamos no fueron persistentes, lo que significa que solo están disponibles en su sesión actual. Básicamente, eso significa que si inicia un trabajo y luego abre otra Consola PowerShell y ejecuta Get-Job, no verá ningún trabajo. Sin embargo, si regresa a la consola desde la que inició el trabajo, podrá ver su estado. Esto está en contraste con los trabajos programados que son persistentes. Básicamente, un trabajo programado es un bloque de secuencia de comandos que se ejecuta en una programación. En el pasado, el mismo efecto podría haberse logrado utilizando el Programador de tareas de Windows, que es realmente lo que está sucediendo debajo del capó. Para crear un nuevo trabajo programado, hacemos lo siguiente:

Registrar-Programar Job-Nombre GetEventLogs -ScriptBlock Get-EventLog -LogName Seguridad -Newest 100 -Trigger (New-JobTrigger -Daily -At 5pm) -ProgramadoJobOption (New-ScheduledJobOption -RunElevated)

Hay mucho que hacer en ese comando, así que vamos a desglosarlo.

• Primero, le damos a nuestro trabajo programado un nombre de GetEventLogs.
• Luego le decimos que cuando se activa, queremos que ejecute el contenido del bloque de script especificado, que básicamente obtiene las 100 entradas más recientes del registro de eventos de seguridad..
• A continuación, especificamos un disparador. Dado que el parámetro de activación toma un objeto de activación como entrada, usamos un comando entre paréntesis para generar una activación que se activará todos los días a las 5 p.m..
• Dado que estamos tratando con el registro de eventos, debemos ejecutar como un administrador, que podemos especificar creando un nuevo objeto ScheduledJobOption y pasándolo al parámetro ScheduledJobOption.

Dado que este es un tipo de trabajo ligeramente diferente, también necesitará usar un comando diferente para recuperar una lista de todos los trabajos programados en una máquina.

Get-ScheduledJob

Eso es todo al respecto.