What Else Happened in PowerShell This Spring
Robert Prüst
PowerShell 7.6 GA in March was the headline of the spring, and the new DSC v3.2 release (covered separately, with a DSC v3 primer alongside it) is the most substantial follow-up since. A few other things shipped in PowerShell-land in between that are worth a quick sweep — a candid release postmortem, the first 7.7 preview, an MSI deprecation announcement, the LTS patch wave, and a couple of community notes.
The 7.6 release postmortem
The PowerShell team published a postmortem at the start of April explaining why 7.6 slipped — and they were candid about it. Worth reading regardless of whether the slip itself bothered you; it’s a rare look at how an open-source release actually breaks down.
The short version of the timeline they walk through:
- Oct 2025 — a build change in 7.6-preview.5 broke the Alpine package (the new build system wasn’t compatible with how
Microsoft.PowerShell.Nativebuilds on Alpine) - Nov 2025 — new compliance requirements forced rebuilding the non-Windows packaging tooling (FPM out)
- Dec 2025 — preview 6 was blocked by the manual NuGet publishing process and the holiday freeze
- Jan 2026 — RHEL 8 (Red Hat Enterprise Linux 8) compatibility issues surfaced
- Feb–Mar 2026 — fixes and backporting until the release was published
The root causes named: “late-cycle packaging system changes”, “tight coupling to packaging dependencies”, “reduced validation signal from previews”, and “release ownership and coordination gaps” during maintainer handoffs.
What they’re committing to: explicit per-release ownership, better internal tracking visibility, a tighter preview cadence, simpler packaging systems, and clearer signals for community updates via GitHub Discussions.
Pair this with my 7.6 GA writeup from March and you’ve got the whole story.
First look at 7.7-preview.1
The 7.7.0-preview.1 release was published in late April. Three additions stood out for me as genuinely useful in day-to-day scripting.
-ExcludeProperty on Format-* cmdlets
Finally. The number of times you’ve piped to Select-Object * -ExcludeProperty SomeNoise | Format-Table only to find the formatter doesn’t honour the selection cleanly? Format-Table, Format-List, and Format-Custom all now take -ExcludeProperty directly.
-Extension on Join-Path
A small thing that you’ll use more than you’d expect:
Join-Path -Path 'C:\logs' -ChildPath 'app' -Extension 'log'
# C:\logs\app.logNo more "$path.log" string-concatenation gymnastics.
ToRegex() on WildcardPattern
If you’ve ever needed to convert a wildcard pattern (*.ps1, Get-*) to a regular expression for a tool that takes regex, that used to mean writing your own converter. Now it’s a method call.
Plenty of smaller wins in the release notes — verbose output on Get-Service, better tab completion for $PSBoundParameters.Keys, fixes to Test-Json with oneOf/anyOf schemas. Worth a scroll. Also note the breaking changes: Format-* now validates -Property as not-null-or-empty, and Where-Object finally treats -[Operator]:$false consistently.
MSI is going away from 7.7 onwards
The MSI deprecation announcement was published in April, and it’s worth reading in full because it does explain the why. From 7.7-preview.1 onwards, PowerShell drops MSI in favour of MSIX. 7.6 LTS keeps MSI for its support lifecycle, so nothing is removed from under existing deployments.
The drivers Microsoft calls out:
- Accessibility — the post is unusually direct here: “MSI doesn’t meet modern accessibility requirements, particularly for screen reader scenarios.” MSIX brings the predictable tab stops and accurate screen-reader announcements that MSI’s installer UI can’t guarantee
- Servicing model — MSIX supports built-in updates with differential delivery; MSI servicing typically needs external tools or a full reinstall
- Modern architecture — declarative installation, versus MSI’s custom-actions-and-scripts approach
The honest caveat in the same post: “MSIX doesn’t support all use case scenarios that MSI enabled, such as remoting and execution by system-level services (like Task Scheduler).”
That’s the gap. If you deploy PowerShell at scale and rely on Task Scheduler, scheduled remoting, or any system-level service context to run scripts, you don’t yet have a fully MSIX-shaped story. The team commits to closing this, but for now it’s something to be aware of when planning the move.
My own view differs a bit here: coming from a packaging and Intune background, I’m more in the MSI camp. Part of that is simply familiarity with MSI and the tooling around it, but it’s also flexibility. The PowerShell MSI lets you configure the install right on the msiexec command line, with properties like ADD_PATH, ENABLE_PSREMOTING and REGISTER_MANIFEST (full list in the install docs). The MSIX package has no equivalent, and the same docs list its limitations: Store installs are per-user with no option to install for all users, and the app runs sandboxed, with virtualized access to parts of the file system and registry.
To be fair, MSIX still works with Intune and Configuration Manager, so it’s not that your deployment tooling can’t handle it. What you lose is the install-time configuration. It’s telling that those same docs still call MSI the “best choice for Windows Servers and enterprise deployment scenarios”.
The April patch wave
The LTS branches got a coordinated refresh on April 21. Three patches in one day:
Routine .NET SDK bumps for each, plus an SSH pipe-handle fix that’s worth picking up if you’re remoting over SSH from any of those branches. Not exciting, but the kind of patch you want applied before something breaks at 2am.
PowerShell + DevOps Global Summit 2026
The PowerShell + DevOps Global Summit 2026 was in Bellevue in mid-April (April 13–16, at the Meydenbauer Center). Next to PSConfEU, it’s the biggest PowerShell oriented conference. It’s one I really want to attend, but so far the timing and money haven’t lined up — and the session videos aren’t online yet, so this is genuinely secondhand — Gilbert Sanchez wrote up a nice recap that’s worth reading if you missed the event entirely.
Two items from his writeup with independent primary sources worth a look:
- psake v5.0 was released during the Summit. The notes lean into reducing token usage and surfacing clearer error messages, explicitly designed for both humans and AI assistants — a small acknowledgement of how the audience for build-script errors has shifted
- PSDepend revival — PowerShell.org formally kicked off an effort to resuscitate dormant community modules, with PSDepend chosen as the first target and Warren Frame back providing support. If you’ve been holding on to forks of abandoned modules, that’s the initiative to watch
For the rest — keynote framing, hallway-track themes, the specific session content — go read Gilbert’s writeup!
A note on tooling
vscode-powershell 2026.1.0-preview was published in early April. Mostly housekeeping: settings reorganisation for VS Code 1.101+, enum-member alignment options, parser fixes. Useful if you’re on the preview channel; nothing groundbreaking.
Wrap
That’s the spring in PowerShell-land. The platform is moving — sometimes in ways the team is willing to be honest about (the postmortem), sometimes in ways that’ll require planning (MSI → MSIX), but moving. And if you’ve been wondering whether now is a good time to invest in DSC v3, April’s release is worth a proper look — rough edges included, as the standalone post on that one shows.
Happy scripting 😊