Partekatu honen bidez:


Administración de runbooks en Azure Automation

Para agregar un runbook a Azure Automation, puede crear uno o importar uno existente desde un archivo o desde la Galería de runbooks. En este artículo se proporciona información para administrar un runbook, así como patrones y procedimientos recomendados con el diseño de runbooks. Puede encontrar todos los detalles sobre el acceso a los módulos y los runbooks de la comunidad en Galerías de runbooks y módulos para Azure Automation.

Crear un runbook

Cree un runbook nuevo en Azure Automation mediante Azure Portal o PowerShell. Una vez creado el runbook, se puede editar siguiendo la información de las secciones siguientes:

Creación de un runbook en Azure Portal

  1. Inicie sesión en Azure Portal.
  2. Busque y seleccione Cuentas de Automation.
  3. En la página Cuentas de Automation, seleccione su cuenta de Automation en la lista.
  4. Desde la cuenta de Automation, seleccione Runbooks en Automatización de procesos para abrir la lista de runbooks.
  5. Haga clic en Crear un runbook.
    1. Asigne un nombre al runbook.
    2. Desde el menú desplegable Tipo de runbook. Seleccione su tipo. El nombre del runbook debe empezar por una letra y puede tener letras, números, guiones bajos y guiones.
    3. Seleccione la versión del entorno de ejecución.
    4. Escriba la descripción correspondiente.
  6. Haga clic en Crear para crear el runbook.

Creación de un runbook con PowerShell

Use el cmdlet New-AzAutomationRunbook para crear un runbook vacío. Use el parámetro Type para especificar uno de los tipos de runbook definidos para New-AzAutomationRunbook.

En el ejemplo siguiente se muestra cómo crear un nuevo runbook vacío.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    Name                  = 'NewRunbook'
    ResourceGroupName     = 'MyResourceGroup'
    Type                  = 'PowerShell'
}
New-AzAutomationRunbook @params

Importación de un runbook

Puede importar un script de PowerShell o de flujo de trabajo de PowerShell (.ps1), un runbook gráfico (.graphrunbook) o un script de Python 2 o Python 3 (.py) para crear su propio runbook. Especifique el tipo de runbook que se creará durante la importación teniendo en cuenta las consideraciones siguientes.

  • Puede importar un archivo .ps1 que no contenga un flujo de trabajo, ya sea en un runbook de PowerShell o en un runbook de flujo de trabajo de PowerShell. Si lo importa en un runbook de flujo de trabajo de PowerShell, se convertirá en un flujo de trabajo. En este caso, se incluyen comentarios en el runbook para describir los cambios realizados.

  • Solo puede importar un archivo .ps1 que contiene un flujo de trabajo de PowerShell en un runbook de flujo de trabajo de PowerShell. Si el archivo contiene varios flujos de trabajo de PowerShell, se produce un error en la importación. Debe guardar cada flujo de trabajo en su propio archivo e importar cada uno por separado.

  • No debe importar un archivo .ps1 que contiene un flujo de trabajo de PowerShell en un runbook de PowerShell, ya que el motor de scripts de PowerShell no lo reconoce.

  • Importe solo un archivo .graphrunbook en un runbook gráfico nuevo.

Importación de un runbook desde Azure Portal

Puede usar el siguiente procedimiento para importar un archivo de script en Azure Automation.

Nota:

Solo puede importar un archivo .ps1 en un runbook de flujo de trabajo de PowerShell mediante el portal.

  1. En Azure Portal, busque y seleccione Cuentas de Automation.
  2. En la página Cuentas de Automation, seleccione su cuenta de Automation en la lista.
  3. Desde la cuenta de Automation, seleccione Runbooks en Automatización de procesos para abrir la lista de runbooks.
  4. Haga clic en Importar un runbook. Puede seleccionar cualquiera de las siguientes opciones:
    1. Buscar un archivo: esta opción selecciona un archivo de la máquina local.
    2. Examinar desde la galería: puede examinar y seleccionar un runbook existente de la galería.
  5. Seleccione el archivo.
  6. Si el campo Nombre está habilitado, tiene la opción de cambiar el nombre del runbook. El nombre debe empezar por una letra y puede tener letras, números, guiones bajos y guiones.
  7. El tipo de runbook se rellenará automáticamente, pero puede cambiarlo después de tomar en cuenta las restricciones aplicables.
  8. La versión del entorno de ejecución se rellena automáticamente o puede elegir la versión de la lista desplegable.
  9. Haga clic en Import. El nuevo runbook aparece en la lista de runbooks de la cuenta de Automation.
  10. Tiene que publicar el runbook antes de poder ejecutarlo.

Nota:

Después de importar un runbook gráfico, puede convertirlo en otro tipo, pero no puede convertir un runbook gráfico en un runbook de texto.

Importación de un runbook con PowerShell

Use el cmdlet Import-AzAutomationRunbook para importar un archivo de script como un runbook en borrador. Si ya existe el runbook, se producirá un error de importación, a menos que utilice el parámetro Force con el cmdlet.

En los ejemplos siguientes se muestra cómo importar un archivo de script en un runbook.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    Name                  = 'Sample_TestRunbook'
    ResourceGroupName     = 'MyResourceGroup'
    Type                  = 'PowerShell'
    Path                  = 'C:\Runbooks\Sample_TestRunbook.ps1'
}
Import-AzAutomationRunbook @params

Control de recursos

Si el runbook crea un recurso, el script debe comprobar que el recurso ya exista antes de intentar crearlo. Este es un ejemplo básico.

$vmName = 'WindowsVM1'
$rgName = 'MyResourceGroup'
$myCred = Get-AutomationPSCredential 'MyCredential'

$vmExists = Get-AzResource -Name $vmName -ResourceGroupName $rgName
if (-not $vmExists) {
    Write-Output "VM $vmName does not exist, creating"
    New-AzVM -Name $vmName -ResourceGroupName $rgName -Credential $myCred
} else {
    Write-Output "VM $vmName already exists, skipping"
}

Recuperación de detalles del registro de actividad

Puede recuperar detalles del runbook, como la persona o la cuenta que ha iniciado un runbook, del registro de actividad para la cuenta de Automation. En el siguiente ejemplo de PowerShell se proporciona el último usuario que ha ejecutado el runbook especificado.

$rgName = 'MyResourceGroup'
$accountName = 'MyAutomationAccount'
$runbookName = 'MyRunbook'
$startTime = (Get-Date).AddDays(-1)

$params = @{
    ResourceGroupName = $rgName
    StartTime         = $startTime
}
$JobActivityLogs = (Get-AzLog @params).Where( { $_.Authorization.Action -eq 'Microsoft.Automation/automationAccounts/jobs/write' })

$JobInfo = @{}
foreach ($log in $JobActivityLogs) {
    # Get job resource
    $JobResource = Get-AzResource -ResourceId $log.ResourceId

    if ($null -eq $JobInfo[$log.SubmissionTimestamp] -and $JobResource.Properties.Runbook.Name -eq $runbookName) {
        # Get runbook
        $jobParams = @{
            ResourceGroupName     = $rgName
            AutomationAccountName = $accountName
            Id                    = $JobResource.Properties.JobId
        }
        $Runbook = Get-AzAutomationJob @jobParams | Where-Object RunbookName -EQ $runbookName

        # Add job information to hashtable
        $JobInfo.Add($log.SubmissionTimestamp, @($Runbook.RunbookName, $Log.Caller, $JobResource.Properties.jobId))
    }
}
$JobInfo.GetEnumerator() | Sort-Object Key -Descending | Select-Object -First 1

Seguimiento del progreso

Se recomienda crear los runbooks para que tengan una naturaleza modular, con una lógica que se pueda reutilizar y reiniciar fácilmente. El seguimiento del progreso en un runbook garantiza que la lógica de dicho runbook se ejecute correctamente si hay incidencias.

Puede realizar un seguimiento del progreso de un runbook mediante un origen externo, como una cuenta de almacenamiento, una base de datos o archivos compartidos. Cree lógica en el runbook para comprobar primero el estado de la última acción que se ha realizado. Luego, en función de los resultados de la comprobación, la lógica puede omitir o continuar tareas específicas del runbook.

Evitación de trabajos simultáneos

Algunos runbooks se comportan de forma extraña si se ejecutan en varios trabajos al mismo tiempo. En este caso, es importante que un runbook implemente la lógica para establecer si ya hay un trabajo en ejecución. Este es un ejemplo básico.

# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process

# Connect to Azure with system-assigned managed identity 
$AzureContext = (Connect-AzAccount -Identity).context

# set and store context 
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext

# Check for already running or new runbooks 
$runbookName = "runbookName" 
$resourceGroupName = "resourceGroupName" 
$automationAccountName = "automationAccountName"

$jobs = Get-AzAutomationJob -ResourceGroupName $resourceGroupName -AutomationAccountName $automationAccountName -RunbookName $runbookName -DefaultProfile $AzureContext

# Ranking all the active jobs
$activeJobs = $jobs | where {$_.status -eq 'Running' -or $_.status -eq 'Queued' -or $_.status -eq 'New' -or $_.status -eq 'Activating' -or $_.status -eq 'Resuming'} | Sort-Object -Property CreationTime 
$jobRanking = @() 
$rank = 0 
ForEach($activeJob in $activeJobs) 
{         
    $rank = $rank + 1 
    $activeJob | Add-Member -MemberType NoteProperty -Name jobRanking -Value $rank -Force 
    $jobRanking += $activeJob 
}
    
$AutomationJobId = $PSPrivateMetadata.JobId.Guid 
$currentJob = $activeJobs | where {$_.JobId -eq $AutomationJobId} 
$currentJobRank = $currentJob.jobRanking 

# Only allow the Job with Rank = 1 to start processing. 
If($currentJobRank -ne "1") 
{ 
    Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check failed as Current Job Ranking is not 1 but $($currentJobRank) therefore exiting..." 
    Exit 
} Else
{
    Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check passed. Start processing.." 
} 

Si desea que el runbook se ejecute con la identidad administrada asignada por el sistema, deje el código tal y como está. Si prefiere usar una identidad administrada asignada por el usuario, haga lo siguiente:

  1. En la línea 5, quite $AzureContext = (Connect-AzAccount -Identity).context.
  2. Reemplace el valor por $AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).context.
  3. Escriba el id. de cliente.

Nota:

En el caso de los trabajos híbridos de PowerShell 7.2, realice cambios en la línea 28. Reemplace $PSPrivateMetadata.JobId.Guid por $env:PSPrivateMetaData.

Control de errores transitorios en un script dependiente del tiempo

Los runbooks deben ser sólidos y capaces de controlar los errores, incluidos los transitorios, que pueden provocar que se reinicien o fallen. Si se produce un error en un runbook, Azure Automation vuelve a intentarlo.

Si el runbook se ejecuta normalmente dentro de una restricción de tiempo, haga que el script implemente la lógica para comprobar el tiempo de ejecución. Esta comprobación garantiza la ejecución de operaciones, como el inicio, el apagado o el escalado horizontal, solo durante horas específicas.

Nota:

La hora local en el proceso de espacio aislado de Azure se establece en UTC. Debe tenerse en cuenta este aspecto en los cálculos de fecha y hora de los runbooks.

Lógica de reintento en el runbook para evitar errores transitorios

Los runbooks suelen realizar llamadas a sistemas remotos, como Azure a través de ARM, Azure Resource Graph, servicios SQL y otros servicios web. Cuando el sistema al que llaman los runbooks está ocupado, la limitación temporal no disponible o la implementación bajo carga, las llamadas son vulnerables a errores en runtime. Para crear resistencia en los runbooks, debe implementar la lógica de reintento al realizar las llamadas para que los runbooks puedan controlar un problema transitorio sin errores.

Para obtener más información, consulte patrón de reintento y REST general y directrices de reintento.

Ejemplo 1: Si el runbook realiza solo una o dos llamadas

$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName  $searchServiceName -ApiVersion 2015-08-19
$searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey

Al llamar a Invoke-AzureRmResourceAction, puede observar errores transitorios. En este escenario, se recomienda implementar el siguiente patrón básico en torno a la llamada al cmdlet.

$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName  $searchServiceName -ApiVersion 2015-08-19

    # Adding in a retry
    $Stoploop = $false
    $Retrycount = 0
 
    do {
        try   {
               $searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey
               write-verbose "Invoke-AzureRmResourceAction on $resource.ResourceId completed"
               $Stoploop = $true
              }
        catch {
               if ($Retrycount -gt 3)
                 {
                  Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId after 3 retrys."
                  $Stoploop = $true
                 }
               else  
                 {
                  Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId retrying in 30 seconds..."
                  Start-Sleep -Seconds 30
                  $Retrycount = $Retrycount + 1
                 }
               }
        }
    While ($Stoploop -eq $false)

Nota:

El reintento de la llamada es de hasta tres veces, suspendiendo durante 30 segundos cada vez.

Ejemplo 2: si el runbook realiza llamadas remotas frecuentes

Si el runbook realiza llamadas remotas frecuentes, podría experimentar problemas transitorios en runtime. Cree una función que implemente la lógica de reintento para cada llamada que se realiza y pase la llamada como un bloque de script que se va a ejecutar.

Function ResilientRemoteCall {

         param(
               $scriptblock
               )
        
         $Stoploop = $false
         $Retrycount = 0
 
         do {
             try   {
                    Invoke-Command -scriptblock $scriptblock 
                    write-verbose "Invoked $scriptblock completed"
                    $Stoploop = $true
                   }
             catch {
                    if ($Retrycount -gt 3)
                      {
                       Write-verbose "Invoked $scriptblock failed 3 times and we will not try again."
                       $Stoploop = $true
                      }
                    else  
                      {
                       Write-verbose "Invoked $scriptblock failed  retrying in 30 seconds..."
                       Start-Sleep -Seconds 30
                       $Retrycount = $Retrycount + 1
                      }
                    }
             }
         While ($Stoploop -eq $false)
}

A continuación, puede pasar cada llamada remota a la función como

ResilientRemoteCall { Get-AzVm } o

ResilientRemoteCall { $searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey}

Trabajo con varias suscripciones

El runbook debe poder trabajar con suscripciones. Por ejemplo, para controlar varias suscripciones, el runbook debe usar el cmdlet Disable-AzContextAutosave. Este cmdlet garantiza que no se recupere el contexto de autenticación desde otro runbook que se ejecute en el mismo espacio aislado.

# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process

# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context

# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription `
    -DefaultProfile $AzureContext

$childRunbookName = 'childRunbookDemo'
$resourceGroupName = "resourceGroupName"
$automationAccountName = "automationAccountName"

$startParams = @{
    ResourceGroupName     = $resourceGroupName
    AutomationAccountName = $automationAccountName
    Name                  = $childRunbookName
    DefaultProfile        = $AzureContext
}
Start-AzAutomationRunbook @startParams

Si desea que el runbook se ejecute con la identidad administrada asignada por el sistema, deje el código tal y como está. Si prefiere usar una identidad administrada asignada por el usuario, haga lo siguiente:

  1. En la línea 5, quite $AzureContext = (Connect-AzAccount -Identity).context.
  2. Reemplace el valor por $AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).context.
  3. Escriba el id. de cliente.

Trabajo con un script personalizado

Nota:

Normalmente no se pueden ejecutar scripts y runbooks personalizados en el host con un agente de Log Analytics instalado.

Para utilizar un script personalizado, haga lo siguiente:

  1. Crear una cuenta de Automation.
  2. Implemente el rol Hybrid Runbook Worker.
  3. Si está en una máquina Linux, necesitará privilegios elevados. Inicie sesión para desactivar las comprobaciones de firmas.

Prueba de un runbook

Cuando se prueba un runbook, se ejecuta la versión de borrador y se completan todas las acciones que realiza. No se crea ningún historial de trabajos, pero los flujos salida y advertencia y error se muestran en el panel de salida de la prueba. Los mensajes del flujo detallado solo se muestran en el panel de salida si la variable VerbosePreference está establecida en Continue.

Aun cuando se ejecuta la versión de borrador, el runbook se ejecuta con normalidad y realiza las acciones correspondientes en los recursos del entorno. Por este motivo, solo debe probar runbooks en recursos no pertenecientes a entornos de producción.

Nota:

Todas las acciones de ejecución de runbooks se registran en el registro de actividad de la cuenta de Automation con el nombre de la operación Crear un trabajo de Azure Automation. Sin embargo, la ejecución de runbooks en un panel de prueba donde se ejecuta la versión de borrador del runbook se registraría en los registros de actividad con el nombre de la operación Escribir un borrador de runbook de Azure Automation. Seleccione las pestañas Operación y JSON para ver el ámbito que termina en .. /runbooks/(nombre de runbook)/draft/testjob.

El procedimiento para probar cada tipo de runbook es el mismo. No hay diferencias entre realizar las pruebas en el editor de texto o en el editor gráfico de Azure Portal.

  1. Abra la versión de borrador del runbook en el editor de texto o el editor gráfico.
  2. Haga clic en Prueba para abrir la página de prueba.
  3. Si el runbook tiene parámetros, se enumeran en el panel izquierdo, donde puede proporcionar los valores que se usarán para la prueba.
  4. Si quiere ejecutar la prueba en una instancia de Hybrid Runbook Worker, cambie los Parámetros de ejecución a Hybrid Worker y seleccione el nombre del grupo de destino. De lo contrario, mantenga el valor predeterminado Azure para ejecutar la prueba en la nube.
  5. Haga clic en Iniciar para iniciar la prueba.
  6. Puede usar los botones en el panel de salida para detener o suspender un runbook de flujo de trabajo de PowerShell o gráfico mientras se está probando. Cuando se suspende el runbook, este completa la actividad que está realizando en ese momento antes de suspenderse. Una vez suspendido, puede detener o reiniciar el runbook.
  7. Inspeccione la salida del runbook en el panel de salida.

Publicación de un runbook

Cuando cree o importe un runbook nuevo, debe publicarlo para poder ejecutarlo. Cada runbook de Azure Automation tiene una versión de borrador y una versión publicada. Solo es posible ejecutar la versión publicada y solo es posible editar la versión de borrador. Los cambios realizados en la versión de borrador no afectan la versión publicada. Cuando la versión de borrador deba estar lista para su disponibilidad, puede publicarla, lo que sobrescribirá la versión publicada actual con la versión de borrador.

Publicación de un runbook en Azure Portal

  1. En Azure Portal, busque y seleccione Cuentas de Automation.
  2. En la página Cuentas de Automation, seleccione su cuenta de Automation en la lista.
  3. Abra el runbook en la cuenta de Automation.
  4. Haga clic en Editar.
  5. Haga clic en el botón Publicar y, a continuación, seleccione en el mensaje de comprobación.

Publicación de un runbook mediante PowerShell

Utilice el cmdlet Publish-AzAutomationRunbook para publicar el runbook.

$accountName = "MyAutomationAccount"
$runbookName = "Sample_TestRunbook"
$rgName = "MyResourceGroup"

$publishParams = @{
    AutomationAccountName = $accountName
    ResourceGroupName     = $rgName
    Name                  = $runbookName
}
Publish-AzAutomationRunbook @publishParams

Programación de un runbook en Azure Portal

Una vez publicado el runbook, puede programarlo para que funcione:

  1. En Azure Portal, busque y seleccione Cuentas de Automation.
  2. En la página Cuentas de Automation, seleccione su cuenta de Automation en la lista.
  3. Seleccione el runbook de la lista de runbooks.
  4. Seleccione Programas en Recursos.
  5. Seleccione Agregar una programación.
  6. En el panel Programación de un runbook, seleccione Vincular una programación a su runbook.
  7. En el panel Programación, seleccione Crear una nueva programación.
  8. Escriba un nombre, una descripción y otros parámetros en el panel Nueva programación.
  9. Una vez creada la programación, resáltela y haga clic en Aceptar. Ahora debería estar vinculada a su runbook.
  10. Busque un correo electrónico en el buzón que le informa sobre el estado del runbook.

Restauración del runbook eliminado

Puede recuperar un runbook eliminado mediante scripts de PowerShell. Para recuperar un runbook, asegúrese de que se cumplan las condiciones siguientes:

  • Los runbooks que se van a restaurar se eliminaron en los últimos 29 días.
  • La cuenta de Automation para ese runbook existe.
  • El permiso de rol colaborador de Automation se concede a la identidad administrada asignada por el sistema de la cuenta de Automation.

Script de PowerShell

  • Ejecute el script de PowerShell como un trabajo en la cuenta de Automation para restaurar los runbooks eliminados.
  • Descargue el script de PowerShell desde GitHub. Como alternativa, puede importar el script de PowerShell denominado Restaurar runbook de Automation desde la Galería de runbook. Proporcione el nombre del runbook que se va a restaurar y ejecútelo como un trabajo en Azure Automation para restaurar los runbooks eliminados.
  • Descargue el script desde GitHub o importe el script de PowerShell denominado Lista de runbooks eliminados de Automation de la Galería de runbooks para identificar los nombres de los runbooks que se eliminaron en los últimos 29 días.

Obtención de estados del trabajo

Visualización de los estados en Azure Portal

En Azure Automation, los detalles del control de trabajos se proporcionan en Trabajos. Cuando esté listo para ver los trabajos de runbook, use Azure Portal y acceda a su cuenta de Automation. A la derecha, se puede ver un resumen de todos los trabajos de runbook en Estadísticas de trabajo.

Icono Estadísticas de trabajo

Este resumen muestra un contador y una representación gráfica del estado de trabajo de cada trabajo ejecutado.

Al hacer clic en el icono aparece la página Trabajos, que incluye una lista resumida de todos los trabajos ejecutados. En esta página se muestra el estado, el nombre del runbook, la hora de inicio y la hora de finalización de cada trabajo.

Captura de pantalla de la página Trabajos.

Para filtrar la lista de trabajos, puede seleccionar Filtrar trabajos. Filtre por un runbook específico, estado de trabajo o una opción de la lista desplegable y proporcione el intervalo de tiempo para la búsqueda.

Filtrado por estado del trabajo

Como alternativa, puede ver los detalles resumidos de los trabajos de un runbook concreto; para ello, selecciónelo en la página Runbooks de la cuenta de Automation y, después, seleccione Trabajos. Esta acción presenta la página Trabajos. Desde aquí, puede hacer clic en un registro del trabajo para ver sus detalles y resultados.

Captura de pantalla de la página Trabajos con el botón Errores resaltado.

Recuperación de los estados del trabajo con PowerShell

Puede utilizar el cmdlet Get-AzAutomationJob para recuperar los trabajos creados para un runbook y los detalles de un trabajo determinado. Si inicia un runbook mediante Start-AzAutomationRunbook, se devuelve el trabajo resultante. Utilice Get-AzAutomationJobOutput para recuperar la salida del trabajo.

En el ejemplo siguiente se recupera el último trabajo para un runbook de ejemplo y se muestra su estado, los valores proporcionados para los parámetros del runbook y la salida del trabajo.

$getJobParams = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Runbookname           = 'Test-Runbook'
}
$job = (Get-AzAutomationJob @getJobParams | Sort-Object LastModifiedDate -Desc)[0]
$job | Select-Object JobId, Status, JobParameters

$getOutputParams = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Id                    = $job.JobId
    Stream                = 'Output'
}
Get-AzAutomationJobOutput @getOutputParams

En el ejemplo siguiente se recupera la salida de un trabajo específico y se devuelve cada registro. Si hay una excepción para uno de los registros, el script escribe la excepción en lugar del valor. Este comportamiento resulta útil, ya que las excepciones pueden proporcionar información adicional que podría no registrarse normalmente durante la salida.

$params = @{
    AutomationAccountName = 'MyAutomationAccount'
    ResourceGroupName     = 'MyResourceGroup'
    Stream                = 'Any'
}
$output = Get-AzAutomationJobOutput @params

foreach ($item in $output) {
    $jobOutParams = @{
        AutomationAccountName = 'MyAutomationAccount'
        ResourceGroupName     = 'MyResourceGroup'
        Id                    = $item.StreamRecordId
    }
    $fullRecord = Get-AzAutomationJobOutputRecord @jobOutParams

    if ($fullRecord.Type -eq 'Error') {
        $fullRecord.Value.Exception
    } else {
        $fullRecord.Value
    }
}

Pasos siguientes