Azure Automation catches up with the latest PowerShell
Azure Automation now supports PowerShell 7.6 runbooks in general availability, alongside a new Runtime environment feature that simplifies how execution environments are configured and managed. The update brings Azure Automation in line with the current PowerShell release cycle, which Microsoft has been steadily accelerating.
PowerShell 7.6 ships with performance improvements over the 7.4 branch, better handling of large data sets through improved streaming, and module compatibility updates that matter for anyone running automation scripts against Microsoft 365, Azure, or third-party APIs. If your Azure Automation runbooks are still on PowerShell 5.1, which has been the default for years, the gap in available features and module support is significant.
What the Runtime environment feature actually changes
The Runtime environment feature is the more interesting half of this announcement. Previously, configuring an Azure Automation runbook’s execution environment meant managing modules, versions, and dependencies manually across multiple automation accounts. If you had ten automation accounts for different environments or regions, you either replicated the module setup in each one or accepted drift. The Runtime environment removes that sprawl.
Think of it as a Dockerfile for runbook execution. The runtime definition declares which PowerShell version to use, which modules to load, and which module versions are acceptable. When a runbook executes, Azure Automation provisions an environment that matches the definition exactly. No drift between accounts, and no surprise from an updated module that changes behavior between runs.
The module version pinning is the specific feature that will save most teams the most headaches. Being able to pin a runbook to a specific module version rather than “latest” means you can test against a known set of dependencies and be confident the runbook will produce the same result in production. This alone addresses one of the most common root causes of runbook failures that only surface after a module update.
The feature also supports custom modules. If your runbooks depend on internal PowerShell modules that are not published to the PowerShell Gallery, you can include them in the runtime definition. This removes the workaround of manually uploading modules to each automation account and keeping them in sync across regions.
Why this matters for automation engineers
Azure Automation runbooks handle a lot of critical infrastructure work: scheduled VM start/stop, patching orchestration, incident response workflows, and compliance checks. These runbooks need to be reliable, and module drift is one of the most common causes of silent failures. The Runtime environment directly addresses that by making execution environments reproducible.
The PowerShell 7.6 upgrade matters separately. PowerShell 7.x introduced native binary module support, better error handling, and the ForEach-Object -Parallel construct that makes concurrent operations practical in script. Teams that have been avoiding the migration because it required reconfiguring the automation environment now have a clean path: define a Runtime environment for 7.6, migrate runbooks incrementally, and validate against the pinned module set before switching production traffic.
One practical example: a common automation pattern involves iterating over hundreds of VMs, checking their status, and performing an action. In PowerShell 5.1 this is sequential by default unless you hand-roll parallel logic. PowerShell 7.6’s ForEach-Object -Parallel handles this natively, cutting execution time from minutes to seconds for large fleets. For a patching automation running weekly across 500 VMs, that difference is significant.
Comparing with the old approach
Before the Runtime environment, managing module versions across multiple automation accounts meant using Azure DevOps pipelines to push modules to each account, or manually uploading through the portal. Neither approach scaled. A common workaround was to keep all runbooks in a single automation account and use tags or naming conventions to separate environments, which introduced its own risks.
The Runtime environment also changes how you handle runbook testing. Previously, validating that a runbook worked with a specific module set meant manually checking the module versions in the test account and the production account. Now the runtime definition IS the contract. If it passes in test, it will run against the same dependencies in production. This is a quality-of-life improvement for teams with formal change management processes, because the runtime definition can be version-controlled alongside the runbook scripts.
Migration approach
Microsoft recommends a phased migration. Start by creating a Runtime environment targeting PowerShell 7.6 in a test automation account. Migrate non-critical runbooks first and validate that all cmdlets and modules resolve correctly. The main breaking changes between 5.1 and 7.x involve string encoding defaults, module auto-loading behavior, and some cmdlet parameter changes. Microsoft publishes a migration guide that covers the common issues.
The Runtime environment supports side-by-side runbook execution. PowerShell 5.1 runbooks and 7.6 runbooks can coexist in the same automation account, each pinned to their respective runtime configuration. This avoids the big-bang migration approach that tends to cause issues. You can move runbooks one at a time and roll back individual runbooks if something breaks.
For teams that use Azure Automation extensively, the Runtime environment also simplifies disaster recovery. Instead of reproducing module configurations in a secondary region, you export the runtime definition and apply it to the recovery automation account. The pinned module versions travel with the configuration, so the recovery runbooks behave identically to the primary region.
Availability
PowerShell 7.6 runbooks and the Runtime environment are available in all Azure public regions except Brazil Southeast and Azure Government clouds. No additional cost beyond standard Azure Automation execution pricing. Existing runbooks continue to work on their current runtime without changes, but Microsoft recommends migrating active runbooks to the new Runtime environment model for consistency.