Use a Custom Runtime Environment for PowerShell V7.4 with the Microsoft Graph PowerShell SDK

The recent introduction of custom runtime environments for Azure Automation is an important step toward creating a better operational platform. The idea is simple. Microsoft defines a set of system-generated runtime environments and tenants can create their own runtime environments to match their needs.

Until now, Azure Automation has essentially offered just the system-generated runtime environments to cover languages like PowerShell and Python, and tenants have had to deal with whatever limitations existed in those environments. For example, the current version of PowerShell Core is V7.5.2, but Azure Automation only supports V5.1, V7.1, and V7.2. When the Microsoft Graph PowerShell SDK developers decided to remove support for .NET6 in their V2.26.1 release, any runbooks configured to use PowerShell V7.1 or V7.2 promptly broke because of their dependency on .NET6.

At the time, Microsoft’s solution was to advise customers to use PowerShell V5.1 with current versions of the Microsoft Graph PowerShell SDK or to stay with V2.25 of the SDK until Azure Automation delivered support for PowerShell V7.4, which is built on .NET8 and is the long-term support (LTS) version of PowerShell (an important aspect for many customers).

Component of Custom Runtime Environments

Support for PowerShell V7.4 has been available since late June 2025 in the form of a custom runtime environment. I don’t know why PowerShell V7.4 is not in the set of system-generated runtime environments. In any case, it is easy to create a custom runtime environment and execute runbooks created using the latest versions of the Microsoft Graph PowerShell SDK.

Before you can use custom runtime environments, you must select the Try runtime environment “experience” toggle for an automation account (Figure 1). Selecting the toggle exposes the option to access runtime environments under Runbooks in the Process Automation menu section.

A runtime environment is composed of:

• A language (PowerShell in this case, but also Python).
• A runtime version (V7.4).
• Packages (DLLs, Assemblies, and PowerShell modules) required to execute runbooks.

I created a custom runbook environment called PSR74. Figure 2 shows the environment settings and that I have looked four Microsoft Graph PowerShell SDK modules into the environment. In the past, you loaded modules as resources for an automation account. Now, the modules are resources for a specific runtime environment.

You can have as many custom runtime environments (within reason) as you like. It’s conceivable, but not practical, that each runbook would have its own runtime environment. More likely, you’ll end up creating a set of runtime environments to match the kind of work done by runbooks. For instance, I have a runtime environment for Microsoft Graph PowerShell SDK runbooks and another for Exchange Online runbooks.

Moving Runbooks to a Custom Runtime Environment

Existing runbooks are tied to a system-generated runtime environment. For instancem the CheckUtilityAccountSignIns runbook shown in Figure 3 is currently tied to the PowerShell V5.1 environment. To move the runbook, select it from the list and us the Update Runtime Environment option to choose a target runtime environment. You can then opt for any system-generated or custom runtime environment defined for the automation account.

When you move a runbook, remember to check the set of modules loaded into the target environment to ensure that all the components needed by the runbook are present. In this example, because the runbook processes Entra ID sign-in audit records, I had to load the Microsoft.Graph.Identity.SignIns and Microsoft.Graph.Reports modules into the target environment before the runbook executed successfully.

Some limitations exist and you should read the documentation before commiting to the new runtime environment. One noteable problem is that some commonly used modules for Microsoft 365 automation, like the Exchange Online management module, aren’t available for PowerShell V7.4 yet. You can attempt to load these modules into a V7.4 runtime environment, but nothing happens. It might take some time before all your favorite (and required) modules support PowerShell V7.4, so you might have to remain with V5.1 for a while yet. In the meantime, it’s easy to switch between the old and new runtime experience, and to switch runbooks between environments.

Nice Change to Deliver Flexibility

Being able to configure a runtime environment precisely the way that you want is an attractive feature. Some extra overhead is incurred to make sure that all the required modules are present, but that’s a small price to pay for the flexibility delivered by runtime environments.

Need some assistance to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.