PowerShell 7.4 and 7.5 stop receiving fixes on November 10, 2026. Upgrade PowerShell 7.4 to the 7.6 LTS with winget or MSI, then test your scripts.
If you run scripts on PowerShell 7.4, you need to upgrade PowerShell 7.4 within the month. Microsoft’s support lifecycle page lists November 10, 2026 as the end-of-support date for both 7.4 (the previous LTS release) and 7.5. Version 7.6, released March 18, 2026, is the current LTS and is supported until November 14, 2028.
The deadline is easy to miss because PowerShell rarely announces itself. It sits inside scheduled tasks, build agents, maintenance scripts and the muscle memory of whoever set up the backups two years ago. Nothing breaks on the 10th. What changes is that Microsoft stops shipping security fixes for the old line, and the page is explicit that only the latest update of each release is supported anyway.
The upgrade itself takes a few minutes per machine. The real work is finding where PowerShell lives and checking a short list of behavior changes. Below is a five-step path for Windows, with notes on where Microsoft’s documentation stops and you have to test for yourself.
What You Need
You need administrator rights on the machines you are upgrading, a list of those machines, and a way to run your scripts against test data. A second system or a virtual machine is useful for the dry run.
Know the lifecycle facts, because they decide what you aim for. Per Microsoft’s table, PowerShell 7.6 is an LTS release built on .NET 10 with support through 14-Nov-2028. PowerShell 7.5 is a stable, non-LTS release on .NET 9, and 7.4 is the LTS on .NET 8. Both older lines end 10-Nov-2026. After end of life, Microsoft says, no further updates, including security updates, are provided.
One scope note. PowerShell 7 does not replace Windows PowerShell 5.1. Microsoft’s install page says it installs to a separate directory and runs side by side. Scripts running under powershell.exe are not covered by this deadline, and I did not look into the 5.1 lifecycle here.
Step 1: Find Out What You Are Actually Running
Open a PowerShell 7 session and run $PSVersionTable.PSVersion, or run pwsh -v from any shell. Microsoft’s installation page does not document either command, so treat them as the usual convention rather than quoted documentation. The result should read 7.4.x or 7.5.x for machines in scope.
To see where the running copy lives, check $PSHOME. The install page lists typical values: $Env:ProgramFiles\PowerShell\7 for MSI installs, a path under $Env:ProgramFiles\WindowsApps for MSIX, $HOME\.dotnet\tools for the .NET global tool, and anything else for ZIP installs. This matters because the upgrade should use the same method as the original install. A mismatch is the most common reason an upgrade appears to succeed and changes nothing.
Also ask winget what it thinks. Microsoft documents winget list --id Microsoft.PowerShell --upgrade-available for exactly this. If it reports nothing, either you are already current or the copy was not installed through winget.
Step 2: Inventory Every Place PowerShell 7 Runs
The laptop you are typing on is the easy one. The harder ones are scheduled tasks that call pwsh.exe, CI runners with PowerShell baked into the image, Docker images, jump hosts and servers that someone configured once and left. Walk through each category and write down the host, the version and the install method.
Containers deserve a specific warning. Microsoft’s lifecycle page says its Docker images may not have the latest security updates and are provided for testing purposes, and it recommends updating OS packages. If production jobs pull a PowerShell 7.4 image tag, that is an inventory item, not a footnote.
On Linux, the install page lists Ubuntu 26.04, 24.04 and 22.04, and Debian 13 and 12, as currently supported distributions, but it does not give a version matrix confirming 7.6 on each one, and it does not include package commands. Follow Microsoft’s per-distribution install articles for those hosts.
While you inventory, search your script repositories for the one name that has changed: the module-qualified form ThreadJob\Start-ThreadJob. You will see why in Step 4.
Step 3: Install PowerShell 7.6 on Windows
Microsoft recommends WinGet for Windows clients. The documented upgrade command is winget upgrade --id Microsoft.PowerShell, and a fresh install uses winget install --id Microsoft.PowerShell --source winget. Newer 7.x versions replace earlier 7.x versions, so there is no need to uninstall 7.4 first.
There is a wrinkle that affects servers. Starting with 7.6.0, WinGet installs the MSIX package by default. If you want the MSI, add --installer-type wix to the install command. Microsoft says the upgrade command keeps the package format of the current install, if that format is available in the new version. The page also says that from 7.7.0 onward there is no MSI, so the MSI route has a limited future. MSIX is described as suited to casual single-user setups, while the MSI is the one Microsoft pairs with Windows Servers and enterprise deployment.
For managed rollouts, download the MSI from GitHub (the page names 7.6.6 as the latest stable at the time I read it) and install silently with msiexec. The documented property list includes ADD_PATH=1, ENABLE_PSREMOTING=1, REGISTER_MANIFEST=1, and two Microsoft Update opt-ins, USE_MU and ENABLE_MU, both defaulting to 1. Group Policy set by your administrator can override the update setting, and setting ENABLE_MU=0 does not remove an existing setting from a previous installation.
If you want to test 7.6 without touching a production install, use the ZIP method. Microsoft describes it as the route for side-loading and running multiple versions. You must add any Start Menu shortcut and PATH entry yourself.
Step 4: Test Your Scripts Against the Known Changes
Microsoft’s page on upgrading from 7.4 to 7.6 opens with a caution: it documents 7.6.6 and does not compare directly against 7.4, so some items may have arrived in 7.5. Read the list with that in mind. The items most likely to bite a script are these.
The ThreadJob module was renamed. The module is now Microsoft.PowerShell.ThreadJob, so a call written as ThreadJob\Start-ThreadJob must become Microsoft.PowerShell.ThreadJob\Start-ThreadJob. An unqualified Start-ThreadJob is unchanged. Next, WildcardPattern.Escape now escapes lone backticks correctly, which can change paths that contain them. Third, the -ChildPath parameter of Join-Path is now a string array. And event source names no longer have a trailing space, which matters if a log parser matches on the old name.
Other documented changes are subtler. Write-Host now respects OutputRendering set to PlainText. The -Debug switch no longer triggers the ShouldProcess prompt, which could alter a script that relied on confirming under debug. ConvertFrom-Json ignores comments inside array literals. NO_COLOR is respected for console stderr output.
If you use PowerShell remoting, read this one twice: the page says PSRP session key exchange is deprecated between newer clients and servers, and tells you to review remoting setups before upgrading. It does not say what to change. Test a remote session between your actual client and server versions before you roll anything out. The same page lists updated bundled modules, PSResourceGet 1.2.0 and PSReadLine 2.4.5, for which it provides only version numbers, so check their release notes if you script against them.
Step 5: Roll Out, Verify and Record the Result
Upgrade in rings. Start with your own machine, then one low-stakes server, then the rest. After each batch, run the version check from Step 1 and confirm that pwsh resolves to the new install. Microsoft notes the install location is added to PATH, so a stale copy earlier in PATH is a possible culprit when the old version still answers.
Run your scheduled jobs once by hand under the new version before the first unattended run, and read the output rather than the exit code. Silent behavior differences, such as output rendering, do not set error codes.
Then update the places that pin a version. Pipeline definitions, image tags, setup scripts and documentation all tend to say 7.4 somewhere. Replace them with 7.6, or better, with whatever mechanism you use to track the current LTS, so the next deadline is a routine bump. The next one is not far off in the lifecycle sense: the table puts 7.6 at the same support horizon as .NET 10, November 2028.
Keep a record of what you changed and when. Auditors and your future self will both ask.
Troubleshooting: When the Upgrade Does Not Take
winget reports no upgrade, but you are still on 7.4. The copy may have come from a different install method. Match the method: MSI to MSI, MSIX to MSIX, ZIP to a fresh ZIP extraction. Microsoft says to use the same install method you used originally.
The old version still starts. Check PATH ordering and run $PSHOME inside the session that answered. Two installs can coexist if one was a ZIP extraction.
A script fails on a module call. Look for the ThreadJob qualified name first, then for Join-Path calls that pass unusual values for ChildPath.
Remoting to a server fails. Microsoft deprecated PSRP session key exchange between newer clients and servers and offers no workaround in the page I read. Test client and server version pairs, and upgrade both ends where you can.
Automatic updates did not arrive. The MSI’s update opt-ins can be overridden by Group Policy. Check what your administrator set before assuming a fault. The release notes also say update notifications are delayed one week after release.
Telemetry questions. Microsoft says the Windows build respects the diagnostics and feedback setting, and that the named-pipe listener can be disabled with the POWERSHELL_DIAGNOSTICS_OPTOUT variable. Review this if your environment has data-handling rules.
Frequently asked questions
When does PowerShell 7.4 reach end of support?
10-Nov-2026, according to Microsoft’s PowerShell support lifecycle page. PowerShell 7.5 ends the same day. PowerShell 7.6, the current LTS, is supported until 14-Nov-2028.
Do I need to uninstall 7.4 before installing 7.6?
No. Microsoft’s install page says newer PowerShell 7 versions replace earlier ones. Use the same install method as the original install.
Will this affect Windows PowerShell 5.1?
PowerShell 7 installs side by side with Windows PowerShell 5.1 and does not replace it. This deadline concerns the 7.x line; I did not research the 5.1 lifecycle.
What is the most likely script breakage in 7.6?
Calls that use the module-qualified ThreadJob\Start-ThreadJob name, since the module is now Microsoft.PowerShell.ThreadJob. Remoting setups also deserve a test because of the PSRP key exchange deprecation.
Version deadlines for tooling like this are a good test of an operations team’s honesty. The tooling that fails first is usually the tooling nobody lists, a ten-line script on a forgotten server that has worked since 2023. Doing the inventory in Step 2 is more valuable than the upgrade itself, because the list will outlive this particular cutoff. Make the upgrade, keep the list, and set a reminder for next autumn, when the question of what comes after 7.6 starts to matter.
Sources
