My situation is like this, I have 7.4.20 installed on my hybrid workers. The runbooks are sync'd via source control. Source control creates a new runbook as 5.1 but I upgrade it in the Azure portal to 7.2. Source control does not change the runtime version after you change in the web portal but it still sync's the code changes.

All my runbooks are set to the 7.2 "System Generated" runtime environment. Even though this is 7.2 runtime environment, the runbook runs using PowerShell 7 version that's installed which is 7.4.20. This only happened with hybrid workers, Azure ones did not show this behavior. If I create a custom runtime environment with 7.4, the source-control-created runbook runs using PowerShell 5.1 like OP. With the non-source-control-created runbook, it stays stuck at "Queued" until it goes to "Suspended".

I set the "powershell_7_4_path" system environment variable to "C:\Program Files\PowerShell\7" and rebooted. This did not resolve the issue.

Here's how I resolved the issue:

Uninstalling the hybrid worker extension, disconnected the server from Azure Arc and deleted the resource, then uninstalled the Azure Connected Machine Agent then rebooted.

Then after reboot, I onboarded back into Azure Arc, added the hybrid worker extension, then added to the hybrid worker group. After these steps, the 7.4 runtime runbooks failed instantly. They would not run as 5.1 or get stuck at "Queued". Then I updated the "powershell_7_4_path" to "C:\Program Files\PowerShell\7\pwsh.exe" then rebooted. Now all 7.4 runbooks (created via source control and manually) run fine.

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.

Hello @RB

Thank you for reaching out to Microsoft Q&A.

When you change an existing PowerShell 5.1 runbook over to a PowerShell 7.4 Runtime Environment on extension-based Hybrid Workers.

The portal correctly shows the runbook linked to your Powershell-74 environment (and the job also reports that environment), but the process that actually starts on the Hybrid Worker is still Windows PowerShell 5.1. Runbooks that were originally created under 5.1 can keep residual behavior even after the Runtime Environment is updated. Newly created 7.x runbooks work because they are created with the correct metadata from the start.

1. Verify the environment variable on every Hybrid Worker The variable name must be exactly: text

      powershell_7_4_path
   

   and the value must point to the folder that contains pwsh.exe (normally C:\Program Files\PowerShell\7). After setting or correcting it, restart the Hybrid Worker service or reboot the machine. Official requirement: Run Azure Automation Runbooks on a Hybrid Runbook Worker
2. Force a clean re-publish
   • Open the runbook → Edit in portal
     • Make a trivial change (add a blank line)
       • Re-select your Powershell-74 Runtime Environment from the drop-down
         • Save → test in the Test pane (check $PSVersionTable) → Publish Steps are here: Update PowerShell Runbook in Azure Runtime Environment
         1. If it still runs as 5.1 – recreate the runbook under the 7.4 environment Export the content, create a brand-new runbook while already selecting the PowerShell 7.4 Runtime Environment, paste the code, publish, and re-attach any schedules. This is the most reliable fix for runbooks that started life as 5.1. Overview: Runtime Environment in Azure Automation

Also confirm the Hybrid Worker extension is version 1.3.63 or higher (required for PowerShell 7.4 support).

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Because other 7.4 runbooks execute correctly on the same Hybrid Worker, the worker installation and powershell_7_4_path configuration are probably not the cause. Microsoft’s documented upgrade flow is to select the 7.4 Runtime environment in Edit mode, test the runbook, and then publish it. A scheduled, webhook, or production job uses the published runbook, so confirm the 7.4 environment is selected, click Publish, start a fresh job, and check $PSVersionTable.

Also check whether source control is synchronizing the runbook. Azure Automation documentation states that source-control integration does not support PowerShell 7.4; synchronized runbooks are created as 5.1.

Deleting the runbook or recreating schedules should not be necessary. If the published runbook shows 7.4, source control is not involved, and a new Hybrid Worker job still launches 5.1, open an Azure Automation support request with the job ID, runbook name, worker extension version, and runtime-environment metadata. That behavior would require service-side investigation.