Microsoft Graph PowerShell v3 Drops Windows PowerShell 5.1 Support in Q4 2026

On September 16, 2026, Microsoft started a 12-month countdown for Windows PowerShell 5.1 support in Microsoft Graph PowerShell — the Microsoft.Graph module family that most Intune and Entra ID automation, from admin workstation one-liners to scheduled tasks and Azure Automation runbooks, is built on. The v2.x modules keep working on Windows PowerShell 5.1 during that window, and they keep receiving security fixes. What stops is everything else: new features, bug fixes, and validation now target PowerShell 7.x only. Then, in Q4 CY2026, Microsoft Graph PowerShell v3 ships — and v3 will not run on Windows PowerShell 5.1 at all.

If you have never separately installed PowerShell 7, the PowerShell you already have is Windows PowerShell 5.1 — the version that ships built into every copy of Windows, launched as powershell.exe. PowerShell 7 (launched as pwsh.exe) is a different product you install on top of it. This post explains exactly what changed, how to tell if you are affected, and how to move your admin workstations, scheduled tasks, Azure Automation runbooks, and Intune-run scripts off Windows PowerShell 5.1 before the clock runs out.

The problem: your Graph scripts still work today — that is exactly what makes this risky

Here is the trap. If you run Connect-MgGraph and any other Microsoft.Graph cmdlet on Windows PowerShell 5.1 right now, nothing breaks. The script runs, authenticates, returns data, exits 0. Nothing on your screen tells you a clock started.

Microsoft's own words, from the devblog announcement, are specific about what is happening underneath that calm surface:

Then comes the part that turns this from "slower support" into "your automation stops working on a fixed date":

This is not a niche corner of Microsoft 365 administration. If you manage Intune-enrolled devices, Entra ID (the identity service formerly called Azure Active Directory) groups, or Conditional Access policies from PowerShell, you almost certainly have at least one script, scheduled task, or Azure Automation runbook that calls Graph PowerShell. The question this post answers is: which PowerShell host is actually running it, right now, on every machine that matters?

Why it happens: two different products, one retiring clock

To understand why this matters operationally, you need to be clear on what Windows PowerShell 5.1 and PowerShell 7 actually are, because a lot of admins have never had to distinguish them before.

Windows PowerShell 5.1 is the PowerShell built into every current copy of Windows. It launches as powershell.exe. It is built on the .NET Framework, and it has not received a new major version since 2017 — it exists for backward compatibility and stability, not active feature development. It is what runs when a helpdesk analyst opens "Windows PowerShell" from the Start menu, and it is what most existing enterprise scripts, scheduled tasks, and Intune scripts were written against by default.

PowerShell 7 (and 7.1 through 7.7 and beyond) is a completely different, actively developed product, built on modern .NET. Microsoft's own PowerShell documentation is explicit that this is a deliberate, permanent split, not a version bump:

In plain terms: powershell.exe and pwsh.exe are two separate executables that install side by side and do not replace each other. Installing PowerShell 7 does not upgrade, remove, or touch Windows PowerShell 5.1 in any way. Both keep running independently on the same machine, forever, unless someone explicitly uninstalls one of them.

That side-by-side design is also why "I already installed Microsoft.Graph" is not a reliable statement on its own. Microsoft's own installation guide for the Graph PowerShell SDK spells this out directly:

Put the two pieces together and the retirement announcement makes complete sense. Microsoft is not degrading a feature inside one product — it is redirecting engineering investment away from an entire, separately-installed legacy host (Windows PowerShell 5.1) toward the actively developed one (PowerShell 7.x), on a published timeline, ending with a major version (v3) that simply does not ship a Windows PowerShell 5.1-compatible build.

Where this hits hardest: automation that runs unattended

A single admin running a Graph PowerShell command interactively will probably notice a failure quickly and adapt. The real exposure is automation nobody is watching: a scheduled task that has run nightly for two years, an Azure Automation runbook that fires on a timer, or an Intune Proactive Remediation that has quietly passed every day since it was deployed. All three commonly default to Windows PowerShell 5.1 unless someone specifically pointed them at pwsh.exe, and all three fail silently from a human perspective — the only signal is a job history nobody checks until something downstream breaks.

How to verify: find every place you are still on Windows PowerShell 5.1

Before fixing anything, find out exactly where you stand. Run these checks on any machine, scheduled task host, or Azure Automation account that touches Graph PowerShell.

Step 1 — Confirm which PowerShell host you are actually in

$PSVersionTable.PSVersion tells you the version of whichever host you typed the command into — it does not tell you anything about the other host. Run it in both, deliberately.

If you only ever see a Major value of 5 on a given machine, PowerShell 7 is not installed there at all yet, regardless of what any script assumes.

Step 2 — Check whether Microsoft.Graph is installed in each host, separately

Run this inside Windows PowerShell 5.1 first, then run the same command inside PowerShell 7. Do not assume one result applies to both, for the reason explained above.

Get-Module -ListAvailable is the more reliable of the two here — it lists every version physically present on disk for that host, including versions installed by a different tool than Install-Module. ModuleBase in the output shows you exactly which folder it came from, which is the fastest way to confirm you are looking at a Windows PowerShell 5.1 install versus a PowerShell 7 install.

Step 3 — Audit what actually calls Graph PowerShell unattended

The interactive checks above only tell you about the machine you are sitting at. The real risk is in automation you are not watching. Build a list covering:

• Admin workstations — any laptop or jump box where someone runs Graph PowerShell scripts by hand or via a saved .ps1 shortcut.
• Windows Task Scheduler jobs — check every task's Actions tab for a powershell.exe or pwsh.exe program path, on every server and workstation that runs scheduled Graph scripts.
• Azure Automation runbooks — every PowerShell runbook has a Runtime Version setting; it can be 5.1, 7.4, or 7.6 depending on what was picked when the runbook was created.
• Intune Proactive Remediations and Win32 app scripts — these currently always execute through powershell.exe (Windows PowerShell 5.1), with no built-in setting to switch the host — covered in detail in the fix below.

The companion script for this post automates the first two checks (host versions and module install locations) on a single machine in one pass. Run it on your admin workstations and any server that hosts Task Scheduler jobs calling Graph PowerShell, before you start migrating anything.

The fix: moving admin workstations, scheduled tasks, Azure Automation, and Intune scripts to PowerShell 7

The fix is the same underlying action everywhere — make sure PowerShell 7 is installed, make sure Microsoft.Graph is installed inside PowerShell 7 specifically, and make sure whatever calls your script invokes pwsh.exe instead of powershell.exe. The mechanics differ by channel, so each one gets its own walkthrough below.

Admin workstations: install PowerShell 7 and install Microsoft.Graph inside it

1. Install PowerShell 7 using winget, which pulls the current release from the Microsoft-owned winget source:
   PowerShell (Administrator)

   winget install --id Microsoft.PowerShell --source winget
2. For a silent, scripted install (an Intune Win32 app, an image build step, or a fleet push), add the unattended flags:
   Silent install — Intune Win32 app / build script

   winget install --id Microsoft.PowerShell --exact --silent --accept-package-agreements --accept-source-agreements
3. Alternatively, use the MSI directly (useful when winget is not available, such as on a locked-down server build), then confirm the install path:
   Command Prompt (Administrator)

   msiexec.exe /i PowerShell-7.6.5-win-x64.msi /quiet /norestart # After install, pwsh.exe lives at: C:\Program Files\PowerShell\7\pwsh.exe
4. Open PowerShell 7 specifically — not Windows PowerShell — from the Start menu, and install the Graph SDK there, using Microsoft's documented command:
   PowerShell 7 (Administrator)

   Install-Module Microsoft.Graph -Scope AllUsers -Repository PSGallery -Force
5. Confirm the install landed where you expect, from inside PowerShell 7:
   PowerShell 7

   Get-InstalledModule Microsoft.Graph | Select-Object Name, Version

Scheduled tasks: repoint the Action to pwsh.exe

A Windows Scheduled Task's Action does not care which PowerShell it is calling — it just runs whatever program path you give it, with whatever arguments you give it. That means repointing a task is a matter of changing the Action, not the script itself.

1. Open Task Scheduler (taskschd.msc), locate the task, and open its Properties.
2. Go to the Actions tab, select the existing action, and select Edit.
3. Change Program/script from powershell.exe to the full path of pwsh.exe:
   C:\Program Files\PowerShell\7\pwsh.exe
4. Update Add arguments to the same flags you used before, unchanged — pwsh.exe accepts the same -File, -NoProfile, and -ExecutionPolicy switches as powershell.exe:
   -NoProfile -ExecutionPolicy Bypass -File "C:\Scripts\GraphAudit.ps1"
5. Select OK, save the task, and trigger it once manually (Run from the task list) to confirm it completes with the expected result before relying on the schedule.

Azure Automation runbooks: change the Runtime Version, not just the code

Azure Automation runs each PowerShell runbook against a specific Runtime Version you select when the runbook is created or edited — it is a setting, not something the runbook's own code controls. Microsoft's own documentation confirms the currently supported values and is explicit that PowerShell 7.1 and 7.2 are no longer supported by the parent PowerShell product, so 7.4 or 7.6 are the only current PowerShell 7 choices — and per the callout above, 7.6 is the one with real runway past November 2026.

1. Sign in to the Azure portal and open your Automation Account.
2. Go to Process Automation > Runbooks and open the runbook that calls Graph PowerShell.
3. If the runbook does not already use the runtime environment experience, create or select a Runtime environment and set its Runtime Version to 7.6.
4. Under that runtime environment's Modules, import Microsoft.Graph.Authentication (and any other Graph submodules the runbook needs) specifically for that 7.6 runtime environment — a module imported against the 5.1 runtime is not automatically available to a 7.6 runbook, the same separate-module-path principle as on a workstation, just expressed through the portal instead of a file path.
5. Assign the runbook to that runtime environment, save, and run a manual test execution before trusting the schedule.

Intune-run scripts: work around the fixed powershell.exe host

This is the one channel where you cannot simply point at pwsh.exe in a setting, because Intune does not currently expose one. Win32 app detection/install/uninstall scripts and Proactive Remediation detection/remediation scripts are all executed by the Intune Management Extension through powershell.exe — Windows PowerShell 5.1 — with no portal toggle to change that host.

1. Sign in to the Intune admin center.
2. Go to Devices > Scripts and remediations > Proactive remediations (or Apps > Windows > Win32 apps for an app's detection/install scripts).
3. Open the script that currently imports Microsoft.Graph, and decide which of the two workarounds above fits: re-launch under pwsh.exe only if you have already confirmed (via the audit script in this post) that PowerShell 7 is deployed fleet-wide, otherwise convert the Graph calls to direct Invoke-RestMethod calls against https://graph.microsoft.com.
4. Test the updated script against a small pilot group before reassigning it to the full device group.

The companion script: auditing PowerShell hosts and Graph module locations

The script for this post, Get-GraphPowerShellVersionAuditReport.ps1, runs the Step 1 and Step 2 checks from the "How to verify" section above in one pass on a single machine: it detects whether powershell.exe and pwsh.exe are present and their versions, reads the Microsoft.Graph.Authentication module folders directly from disk under both hosts' module paths, and reports a plain risk flag — AT RISK if Graph is installed under Windows PowerShell 5.1 only, TRANSITIONAL if it is installed under both, HEALTHY if it is installed under PowerShell 7, or NOT INSTALLED if neither has it. It is entirely read-only: it never calls Install-Module, Update-Module, Uninstall-Module, or any other state-changing cmdlet, and it never calls Connect-MgGraph or any Graph API — it only inspects local PowerShell host and module inventory.

Run it locally first and confirm the output matches what you already found in Step 1 and Step 2, before rolling it out to other machines.

Run with -CsvPath to log one row per machine, so you can build a simple fleet-wide list of which devices still show AT RISK before the v3 cutover.

Proof it worked: what a clean migration looks like

"Proof it worked" here means proof each channel is actually invoking PowerShell 7 with Graph PowerShell installed there — not just that PowerShell 7 exists somewhere on the machine. Check each of these before considering a channel migrated:

• Admin workstation. Opening PowerShell 7 (not Windows PowerShell) from the Start menu and running Get-InstalledModule Microsoft.Graph returns a version, and $PSVersionTable.PSVersion.Major reads 7.
• Scheduled task. The task's Last Run Result shows 0x0 (success) after the Action was repointed, and the task's history (right-click the task > Enable All Tasks History if not already on, under Task Scheduler's View menu) shows an actual launch of pwsh.exe, not powershell.exe.
• Azure Automation runbook. The runbook's Runtime Version reads 7.6 in the portal, its most recent job completed with status Completed, and the job's output stream does not contain a module-not-found error for any Graph submodule.
• Intune-run script. The remediation or detection script's device-level output in the Intune admin center shows the expected result (compliant/non-compliant, or your custom output), whether you chose the pwsh.exe relaunch approach or the direct Invoke-RestMethod approach.
• Fleet-wide. Running the companion script's -CsvPath option across your admin workstations and script-hosting servers produces a CSV with no remaining AT RISK rows for machines that genuinely still call Graph PowerShell.

If any of those checks come back differently — PowerShell 7 shows a version but Graph PowerShell is missing from it, or a scheduled task's history still shows powershell.exe despite editing the Action — stop and re-check that specific step before assuming the migration is complete. A half-migrated channel (PowerShell 7 installed, but the actual caller still invoking Windows PowerShell 5.1, or vice versa for the module) is easy to create by accident and looks identical to a full migration until the day v3 ships and it stops working.

References

• Microsoft 365 Developer Blog — Investing in a more reliable Microsoft Graph PowerShell experience (the original announcement, September 16, 2026)
• Microsoft Learn — Install the Microsoft Graph PowerShell SDK (per-host installation, Install-Module / Update-Module reference)
• Microsoft Learn — Differences between Windows PowerShell 5.1 and PowerShell 7.x (the pwsh.exe rename and side-by-side design)
• Microsoft Learn — Install PowerShell 7 on Windows (winget, MSI, and Microsoft Store install methods)
• Microsoft Learn — Azure Automation runbook types (Runtime Version support for PowerShell 5.1, 7.4, and 7.6)
• Microsoft Learn — PowerShell support lifecycle (end-of-support dates by version)

Microsoft MVP community deep-dives