Azure Automation runbooks

Both breaks come from identity: one missing a role, one from before managed identities existed.

1Break it: the identity with no rights

Open the failed job from step 3 and read its Errors tab, or ask the CLI for the exception:

$job = az automation job list --resource-group rg-saat-core --automation-account-name aa-saat --query "[0].name" -o tsv
az automation job show --resource-group rg-saat-core --automation-account-name aa-saat --name $job --query exception -o tsv

You’ll see something like this:

The client '3f6a...' with object id '3f6a...' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/.../resourceGroups/rg-saat-vms' or the scope is invalid. If access was recently granted, please refresh your credentials.

The sign-in worked; the identity exists. But it has no role on rg-saat-vms, so even listing the VMs is refused (AuthorizationFailed, Lesson 7). Runbooks fail like this every time someone forgets the role assignment, or moves the target resource group.

Fix it: grant the smallest role that does the job, at the resource group, then start the runbook again in the portal:

az role assignment create --assignee-object-id $aaPid --assignee-principal-type ServicePrincipal --role "Virtual Machine Contributor" --scope "/subscriptions/$sub/resourceGroups/rg-saat-vms" -o none
az vm start --resource-group rg-saat-vms --name web01

Start Stop-LabVMs again. The Output tab should show something like this:

Stopping web01
win01 is already VM deallocated

A minute later web01 is deallocated. Role changes can take a few minutes to apply; if it still fails, wait and run it again.

To see exactly what an Azure Automation runbook is allowed to do, list the roles of its identity: az role assignment list --assignee $aaPid --all --query "[].{role:roleDefinitionName, scope:scope}" -o table. You should see one line: Virtual Machine Contributor on rg-saat-vms.

Before you publish changes to a runbook, use the Test pane in the portal editor. It runs the draft version against real resources, so treat it like production, but it lets you see output and errors without replacing the published runbook that the schedule uses. Publish only when the test run is clean.

2Break it: the Run As script from the internet

Create a second runbook, Get-LabVMs-Old (PowerShell, 7.4), with this script copied from an old blog post. Publish and start it.

$conn = Get-AutomationConnection -Name 'AzureRunAsConnection'
Connect-AzAccount -ServicePrincipal -Tenant $conn.TenantId -ApplicationId $conn.ApplicationId -CertificateThumbprint $conn.CertificateThumbprint
Get-AzVM -ResourceGroupName 'rg-saat-vms' -Status | Select-Object Name, PowerState

The job fails with something like this:

Get-AutomationConnection: The connection asset 'AzureRunAsConnection' was not found.
Connect-AzAccount: ... (no valid credentials)

Run As accounts were retired in 2023 and can’t be created any more. Thousands of published scripts still start with these lines, and they fail on every new Automation account.

Fix it: replace the first two lines with the managed identity sign-in, publish, and start again:

Connect-AzAccount -Identity | Out-Null
Get-AzVM -ResourceGroupName 'rg-saat-vms' -Status | Select-Object Name, PowerState

The output should list web01 and win01 with their power state.

Clean up: keep aa-saat and Stop-LabVMs with its schedule (they stop your lab VMs every evening from now on), and delete the old runbook:

az automation runbook delete --resource-group rg-saat-core --automation-account-name aa-saat --name Get-LabVMs-Old --yes

✅ Checkpoint: Your runbook signs in with a managed identity, has the right role, and runs every evening. The legacy Run As script is fixed and deleted.