How to pass parameters containing backslash in Start-AzAutomationRunbook correctly with Hybrid Workers and Powershell 7

Question

How to pass parameters containing backslash in Start-AzAutomationRunbook correctly with Hybrid Workers and Powershell 7

Martin Preishuber 0

Hi,

I'm trying to call one Powershell 7 Azure runbook from another one by using

Start-AzAutomationRunbook

There is one parameter containing backslash characters (basically an UNC path), so it looks like this

$Params  = @{ 
    "param" = "\\myserver\myshare"
}

Start-AzAutomationRunbook -AutomationAccountName "account" -Name 'childrunbook' -ResourceGroupName 'rg' -DefaultProfile $AzureContext -Parameters $Params -Wait

The child runbook has a string param

param
(
    [Parameter(Mandatory = $false)]
    [string]$param
)

When running the child runbook the input parameter is always shown as "\\myserver\myshare", so apparently the backslash gets quoted with another backslash.

The interesting thing is, that the parameter within the child runbook has a different value depending on whether the child runbook is running in Azure or on a Hybrid worker (with '-runon "hybridworkergroup"'):

in Azure: apparently the param value get's properly decoded, the value of $param is "\myserver\myshare"
on a Hybrid Worker: the param stays as it is, so the value of $param is still "\\myserver\myshare"

Is this some kind of expected behaviour or is it a bug?

Thanks & BR,

Martin

Martin Preishuber 0 Reputation points

2026-05-21T06:30:39.86+00:00

The AI based answer sounds nice, but if it is correct then it is still bad design, runbooks should behave identical independently on whether they are run in Azure or on a Hybrid Worker.

Plus I think the suggested fix / workaround is not correct ...
Siva shunmugam Nadessin 10,895 Reputation points Microsoft External Staff Moderator

2026-05-22T01:44:28.7966667+00:00
Hello

Thank you for reaching out to the Microsoft Q&A forum.

When investigated we see that this is happening because of how Start-AzAutomationRunbook serializes your parameters into JSON and how different run environments (Azure sandbox vs. PS7 Hybrid Worker) handle un-escaping that JSON.

Below are the scenarios which is happening

Start-AzAutomationRunbook takes your hashtable (@{ param = "\myserver\myshare" }) and JSON-encodes it.

In JSON, backslashes must be escaped, so your single \ becomes \ in the JSON payload.

The Azure sandbox runbook host automatically un-escapes that JSON string before giving it to your child runbook, so you see \myserver\myshare.

The PS 7 Hybrid Worker currently does not perform that JSON un-escape step, so your child runbook sees the raw escaped form \myserver\myshare.

Is it a bug? Kinda – it’s a known quirk/limitation of PS7 hybrid jobs today (PS 5.1 hybrid and cloud jobs don’t show it). The team has it on their backlog but there’s no ETA yet.

Try follow below Workarounds

Double-escape in the parent:

# This literal has 2 backslashes per slash so JSON encoding yields 4 $Params = @{ "param" = "\\\\myserver\\myshare" } Start-AzAutomationRunbook … -Parameters $Params -RunOn "hybridworkergroup" Use –ParametersJson and supply your own JSON string: $json = '{ "param": "\\\\myserver\\myshare" }' Start-AzAutomationRunbook … -RunOn "hybridworkergroup" -ParametersJson $json Strip the extra escape in the child runbook: param([string]$param) # only unescape if you detect a Hybrid Worker job if ($env:AZUREPS_HOST_ENVIRONMENT -eq 'HybridWorker') { $param = $param -replace '\\\\','\' } Write-Output "Fixed path: $param"

If you don’t strictly need a Hybrid Worker for this particular runbook, running it “in Azure” (i.e. drop the –RunOn) or targeting a PS 5.1 Hybrid Worker will bypass the issue entirely.

Let me know if any further queries - feel free to reach out!

References

• Start a runbook in Azure Automation: https://learn.microsoft.com/azure/automation/start-runbooks

• Hybrid Runbook Worker basics: https://learn.microsoft.com/azure/automation/automation-hrw-run-runbooks

• Child runbooks in Azure Automation: https://learn.microsoft.com/azure/automation/automation-child-runbooks
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-25T18:20:18.24+00:00

Just following up to check if the information shared by Siva was helpful? If it addressed your query, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thank you!
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-26T18:32:44.13+00:00

Martin, Just following up to check if the information shared by Siva was helpful? If it addressed your query, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thank you!

1 answer

Your answer

Martin Preishuber 0 Reputation points

2026-05-21T06:30:39.86+00:00

The AI based answer sounds nice, but if it is correct then it is still bad design, runbooks should behave identical independently on whether they are run in Azure or on a Hybrid Worker.

Plus I think the suggested fix / workaround is not correct ...
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-25T18:20:18.24+00:00

Just following up to check if the information shared by Siva was helpful? If it addressed your query, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thank you!
Bharath Y P 10,180 Reputation points Microsoft External Staff Moderator

2026-05-26T18:32:44.13+00:00

Martin, Just following up to check if the information shared by Siva was helpful? If it addressed your query, please consider accepting the answer and giving it an upvote.

If you have any further questions or need additional clarification, feel free to reach out. Thank you!

Answer 1

This behavior is expected given how parameters are serialized and deserialized when starting runbooks, especially across Hybrid Runbook Workers.

Start-AzAutomationRunbook sends parameter values through the Azure Automation web service. Parameters are serialized (often via JSON or similar mechanisms) and then deserialized on the worker. For string values that contain backslashes (like UNC paths), this serialization layer escapes backslashes as \\ during transport.

In Azure sandboxes, the runtime is correctly unescaping the value so the runbook parameter ends up as \\server\share (PowerShell literal for \\server\share), which is what is expected for a UNC path.

On Hybrid Runbook Workers, the same parameter is not being unescaped in the same way, so the runbook receives the raw escaped representation (\\\\server\\share), which is why the input view shows doubled backslashes. This difference is due to how Hybrid Runbook Workers handle the parameter payload, not to how the parameter is defined in the runbook.

To work around this on Hybrid Runbook Workers, normalize the parameter value at the start of the child runbook, for example by replacing double backslashes with single backslashes:

param(
    [Parameter(Mandatory = $false)]
    [string]$param
)

# Normalize UNC path if it arrived double-escaped
$param = $param -replace '\\\\', '\\'

This keeps the calling pattern with Start-AzAutomationRunbook unchanged and ensures the child runbook always works with a correctly formatted UNC path, regardless of whether it runs in Azure or on a Hybrid Runbook Worker.

References: