An Azure service that is used to automate, configure, and install updates across hybrid environments.
I did some more testing, and it appears to have to do with the method I'm using to call the runbook. We have a handful of runbooks that are initiated by a 5.1 wrapper Runnbook because of this bug. Essentially, PS7 can't parse the incoming data and fails during pre-processing before it even has a chance to log anything meaningful to the console. Since PS5 is better at parsing the incoming data, we have a PS5 runbook accept the webhook, parse the data, and pass it into Start-AzAutomationRunbook with the parsed data in the parameter set.
I created a test runbook that just outputs $PSversionTable to the console and initialized it in the default 5.1 runtime. As expected, the output was 5.1 as expected. I changed it to 7.2, and then 7.4, and in both cases, it successfully executed with the 7.X version of PowerShell on my hybrid workers.
This seemed to contradict what I claimed in my original post. To make a more accurate test, I tried initiating the runbook using Start-AzAutomationRunbook in a wrapper script similar to what we're using in production.
This time, it ran as 5.1 despite the runtime environment being set to 7.4.
This only seems to be an issue if the runbook is initiated as PowerShell 5.1. A separate script initiated with the 7.2 runtime and run by the same wrapper script returns the expected 7.x result.
For now, I've just been deleting scripts that were initiated in 5.1 and recreating them in 7.2 to make this work when called by the wrapper.
Separately, I've noticed that if I initiate a runbook in a custom 7.4 or 7.6 environment, runbooks get stuck in the queue and eventually go into a suspended mode. I've ensured that my environment variables are set properly on the hybrid workers. If I intiate them using the defauly 7.2 runtime, they end up running with 7.6 anyway since that's the installed version of pwsh. I can also change the runtime to 7.4 or 7.6 after initializing them in 7.2 without any issues.