Document Details
Automation Runbook Types
❌
This page contains Windows bias
About This Page
This page is part of the Azure documentation. It contains code examples and configuration instructions for working with Azure services.
Bias Analysis
Bias Types:
⚠️
windows_first
⚠️
powershell_heavy
⚠️
windows_tools
⚠️
missing_linux_example
Summary:
The documentation demonstrates a Windows bias by prioritizing PowerShell (a Windows-centric technology) in both order and depth of coverage, providing only PowerShell code examples (with Windows file paths), and referencing Windows-specific tools and environment variables. Linux support is mentioned but not illustrated with examples, and Linux-specific considerations are minimal or absent.
Recommendations:
- Provide Linux-specific examples for PowerShell runbooks, including file paths and environment variables relevant to Linux (e.g., /home/user/modules instead of C:\modules).
- Include explicit guidance and troubleshooting steps for running PowerShell and Python runbooks on Linux Hybrid Runbook Workers, not just Windows.
- Balance the order of presentation so that Python and Linux scenarios are not always after PowerShell/Windows; consider parallel sections or tables.
- Where Windows-specific tools or patterns are discussed (e.g., environment variables, file paths), provide Linux equivalents or note differences.
- Add sample Python runbooks that demonstrate both Windows and Linux compatibility, and clarify any OS-specific limitations.
- Highlight any differences in module/package management between Windows and Linux Hybrid Runbook Workers.
- Explicitly state when a feature or limitation applies only to Windows, Linux, or both, to avoid ambiguity.
Create pull request
Scan History
| Date | Scan ID | Status | Bias Status |
|---|---|---|---|
| 2025-09-12 00:00 | #109 | completed | ✅ Clean |
| 2025-08-12 00:00 | #78 | in_progress | ❌ Biased |
| 2025-08-11 00:00 | #77 | completed | ❌ Biased |
| 2025-08-10 00:00 | #76 | completed | ❌ Biased |
| 2025-08-09 00:00 | #75 | completed | ❌ Biased |
| 2025-08-08 00:00 | #74 | completed | ❌ Biased |
| 2025-08-07 00:00 | #73 | completed | ❌ Biased |
| 2025-08-06 00:00 | #72 | completed | ❌ Biased |
| 2025-08-05 00:00 | #71 | completed | ❌ Biased |
| 2025-08-04 00:00 | #70 | in_progress | ❌ Biased |
| 2025-08-03 00:00 | #69 | completed | ❌ Biased |
| 2025-08-02 00:00 | #68 | in_progress | ✅ Clean |
| 2025-08-01 00:00 | #67 | completed | ❌ Biased |
| 2025-07-31 00:00 | #66 | completed | ✅ Clean |
| 2025-07-30 00:00 | #65 | completed | ✅ Clean |
| 2025-07-29 00:01 | #64 | completed | ✅ Clean |
| 2025-07-28 00:00 | #63 | completed | ✅ Clean |
| 2025-07-27 00:00 | #62 | completed | ✅ Clean |
| 2025-07-26 00:01 | #61 | completed | ✅ Clean |
| 2025-07-25 00:00 | #60 | completed | ✅ Clean |
| 2025-07-24 00:00 | #59 | completed | ✅ Clean |
| 2025-07-23 00:00 | #58 | completed | ✅ Clean |
| 2025-07-22 00:01 | #57 | completed | ✅ Clean |
| 2025-07-21 00:00 | #56 | completed | ✅ Clean |
| 2025-07-19 13:51 | #54 | completed | ✅ Clean |
| 2025-07-17 00:00 | #53 | completed | ❌ Biased |
| 2025-07-16 00:00 | #52 | completed | ❌ Biased |
| 2025-07-13 21:37 | #48 | completed | ❌ Biased |
| 2025-07-09 13:09 | #3 | cancelled | ✅ Clean |
| 2025-07-08 04:23 | #2 | cancelled | ❌ Biased |
Flagged Code Snippets
* `Get-AzStorageAccount` cmdlet might fail with an error: *The `Get-AzStorageAccount` command was found in the module `Az.Storage`, but the module could not be loaded*.
* PowerShell runbooks can't retrieve an unencrypted [variable asset](./shared-resources/variables.md) with a null value.
* PowerShell runbooks can't retrieve a variable asset with `*~*` in the name.
* A [Get-Process](/powershell/module/microsoft.powershell.management/get-process) operation in a loop in a PowerShell runbook can crash after about 80 iterations.
* A PowerShell runbook can fail if it tries to write a large amount of data to the output stream at once. You can typically work around this issue by having the runbook output just the information needed to work with large objects. For example, instead of using `Get-Process` with no limitations, you can have the cmdlet output just the required parameters as in `Get-Process | Select ProcessName, CPU`.
* When you use [ExchangeOnlineManagement](/powershell/exchange/exchange-online-powershell?view=exchange-ps&preserve-view=true) module version: 3.0.0 or higher, you may experience errors. To resolve the issue, ensure that you explicitly upload [PowerShellGet](/powershell/module/powershellget/) and [PackageManagement](/powershell/module/packagemanagement/) modules as well.
* If you import module Az.Accounts with version 2.12.3 or newer, ensure that you import the **Newtonsoft.Json** v10 module explicitly if PowerShell 5.1 runbooks have a dependency on this version of the module. The workaround for this issue is to use PowerShell 7.2 runbooks.
* When you utilize the `New-AzAutomationVariable` cmdlet within Az.Automation Module to upload a variable of type **object**, the operation doesn't function as expected.
**Workaround**: Convert the object to a JSON string using the ConvertTo-Json cmdlet and then upload the variable with the JSON string as its value. This workaround ensures proper handling of the variable within the Azure Automation environment as a JSON string.
**Example** - Create a PowerShell object that has stored information around Azure VMs
# [PowerShell 7.1](#tab/lps71)
**Limitations**
- [PowerShell 7.1](/powershell/scripting/install/powershell-support-lifecycle?view=powershell-7.3&preserve-view=true#powershell-end-of-support-dates) is no longer supported by parent product PowerShell. We recommend that you create new runbooks in PowerShell 7.4 for a long term support and update the outdated runbooks.
- The Azure Automation internal PowerShell cmdlets aren't supported on a Linux Hybrid Runbook Worker. You must import the `automationassets` module at the beginning of your PowerShell runbook to access the Automation account shared resources (assets) functions.
- For the PowerShell 7 runtime version, the module activities aren't extracted for the imported modules.
- *PSCredential* runbook parameter type isn't supported in PowerShell 7 runtime version.
- PowerShell 7.x doesn't support workflows. For more information, see [PowerShell Workflow](/powershell/scripting/whats-new/differences-from-windows-powershell#powershell-workflow) for more details.
- PowerShell 7.x currently doesn't support signed runbooks.
- Source control integration doesn't support PowerShell 7.1 (preview) Also, PowerShell 7.1 (preview) runbooks in source control gets created in Automation account as Runtime 5.1.
- PowerShell 7.1 module management isn't supported through `Get-AzAutomationModule` cmdlets.
- Runbook fails with no log trace if the input value contains the character '.
- Azure runbook doesn't support `Start-Job` with `-credential`.
- Azure doesn't support all PowerShell input parameters. [Learn more](runbook-input-parameters.md).
**Known issues**
- Runbooks taking dependency on internal file paths such as `C:\modules` might fail due to changes in service backend infrastructure. Change runbook code to ensure there are no dependencies on internal file paths and use [Get-ChildItem](/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.3&preserve-view=true) to get the required module information.
**Sample script**
azurepowershell
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
azurepowershell
# Retrieve Azure virtual machines with status information for the 'northeurope' region
$AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"}
$VMstopatch = @($AzVM).Id
# Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch
# Convert the object to a JSON string
$jsonString = $VMstopatch | ConvertTo-Json
# Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook)
New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString
- `Get-AzStorageAccount` cmdlet might fail with an error: *The `Get-AzStorageAccount` command was found in the module `Az.Storage`, but the module could not be loaded*.
- Executing child scripts using `.\child-runbook.ps1` isn't supported in this preview.
**Workaround**: Use `Start-AutomationRunbook` (internal cmdlet) or `Start-AzAutomationRunbook` (from `Az.Automation` module) to start another runbook from parent runbook.
- Runbook properties defining logging preference isn't supported in PowerShell 7 runtime.
**Workaround**: Explicitly set the preference at the start of the runbook as following:
- Avoid importing `Az.Accounts` module to version 2.4.0 for PowerShell 7 runtime as there can be an unexpected behavior using this version in Azure Automation.
- You might encounter formatting problems with error output streams for the job running in PowerShell 7 runtime.
- When you import a PowerShell 7.1 module that's dependent on other modules, you may find that the import button is gray even when PowerShell 7.1 version of the dependent module is installed. For example, Az PowerShell module.Compute version 4.20.0, has a dependency on Az.Accounts being >= 2.6.0. This issue occurs when an equivalent dependent module in PowerShell 5.1 doesn't meet the version requirements. For example, 5.1 version of Az.Accounts were < 2.6.0.
- When you start PowerShell 7 runbook using the webhook, it auto-converts the webhook input parameter to an invalid JSON.
- We recommend that you use [ExchangeOnlineManagement](/powershell/exchange/exchange-online-powershell?view=exchange-ps&preserve-view=true) module version: 3.0.0 or lower because version: 3.0.0 or higher may lead to job failures.
- If you import module Az.Accounts with version 2.12.3 or newer, ensure that you import the **Newtonsoft.Json** v10 module explicitly if PowerShell 7.1 runbooks have a dependency on this version of the module. The workaround for this issue is to use PowerShell 7.2 runbooks.
- When you utilize the `New-AzAutomationVariable` cmdlet within Az.Automation Module to upload a variable of type **object**, the operation doesn't function as expected.
**Workaround**: Convert the object to a JSON string using the ConvertTo-Json cmdlet and then upload the variable with the JSON string as its value. This workaround ensures proper handling of the variable within the Azure Automation environment as a JSON string.
**Example** - Create a PowerShell object that has stored information around Azure VMs