As highlighted by this page: Here it seems that errors from Child Runbooks in Azure is not really displayed correctly.
In my case above is the error message I was getting. The problem in the end was that my script was referencing a registry key that pointed to HKCU which I assume doesn’t exist at the time.
The workaround is to add the child runbook in small sections to troubleshoot the error message.
This is just a short post explaining how I understand the differences between running a runbook against an Azure VM and using the Runbook worker agent:
When I run a Powershell runbook for example the Powershell session is executed in an”Azure Powershell instance” This means that if I want to target one of my Azure VMs I need to either use the Azure Custom script extension to inject a script to run locally on the VM or use one of the remote PS tools to remotely connect to the VM and execute.
With the Runbook worker you install the Microsoft Management Agent on the VM itself and then register the Agent with your automation account. Once that is done you can directly target the runbook worker VM. This means that any Runbook that I run will run directly on this on premise machine, same as if running an actual powershell script while logged in.
To me this makes it a lot easier to run configurations as I don’t need to run the commands remotely for installing software etc.
Now according to Microsoft’s design as I understood it, you only install for example 1 runbook worker in your on premise environment and then target your other machines using this server. Like this picture below:
Azure on premise automation design
As you can see there is only one runbook worker that does all the work. My question is why not just install the runbook worker on all my machines and then I can target machines directly instead of going through the whole remoting scenario?
Then why not just install the Agent on my Azure machines so I can execute runbooks directly on them as well?