PowerShell 7.7 Is Out: What Health Care IT Needs to Test Before Upgrading

Microsoft released PowerShell 7.7 to general availability on November 10, 2026. On paper it is a routine Standard Term Support (STS) release built on .NET 11. In practice it changes more than most point releases. According to the PowerShell team's announcement, it brings security hardening in the engine, remoting, and shell, several behavior changes that can break existing scripts, removal of the built-in update notification, and the end of the MSI installer on Windows.

The support lifecycle matters too. PowerShell 7.4 LTS and PowerShell 7.5 both reached end of support on the same day, according to Microsoft's PowerShell support lifecycle page. If your scheduled tasks, deployment scripts, or interface automation run on either version, they are now running on unsupported software, whether or not you plan to touch 7.7.

At a Glance

Affected: Any Windows server or endpoint running PowerShell 7.4, 7.5, or automation you plan to move to 7.7.

Find every system still running PowerShell 7.4 or 7.5. Both are now out of support.
For production automation that needs a per-machine install, SYSTEM execution, scheduled tasks, or inbound remoting, standardize on PowerShell 7.6 LTS, which is supported until November 14, 2028 and still ships as an MSI.
Test scripts against 7.7 in a lab before adopting it, focusing on New-Guid, Test-Json, Export-Csv, formatting cmdlets, and Constrained Language Mode.
Update Intune and Configuration Manager packages, Group Policy, and startup scripts that reference PowerShell installers or paths.

What Is New in 7.7

The headline of the release is security hardening. The announcement lists tighter restrictions in Constrained Language Mode, including limits on property assignment, additional validation in remoting, and hardening of how updatable help content is extracted. These are the kinds of changes that close gaps attackers use, which is good news for organizations that lock down PowerShell on clinical workstations and shared servers. It also means any script that has quietly depended on looser behavior under Constrained Language Mode may stop working.

The release also adds new cmdlets and parameters and updates bundled modules, including PSResourceGet and Archive. If your automation installs modules from a repository or zips log files and exports for transfer to a vendor, those module updates belong on your test list.

One smaller change deserves attention from teams without formal patch tracking for PowerShell: the built-in update notification has been removed. PowerShell 7.7 will no longer tell you a newer version exists when you open a session. If that banner was how you learned about new releases, you need another method, such as your software inventory tool or a recurring check of the lifecycle page.

Behavior Changes That Can Break Scripts

Microsoft called out several changes that alter how existing commands behave. Each one is worth a specific test.

New-Guid now defaults to version 7 UUIDs. Version 7 UUIDs are time-sortable, meaning values generated later sort after values generated earlier. For most uses, such as unique file names, correlation IDs, or temporary identifiers, this is harmless and often helpful. If any of your automation treats a GUID as an unguessable token rather than simply a unique ID, review that code, because a time-sortable value is more predictable by design.

Test-Json requires -FetchExternalReference for external schemas. If a script validates JSON against a schema that references other schema files, it will no longer retrieve those external references unless you add the parameter. Teams that validate JSON payloads from interface engines, FHIR endpoints, or vendor APIs should check whether their schemas use external references.

Export-Csv deprecates certain parameter combinations. The announcement flags this change, but the specific combinations should be checked against the v7.7.0 release notes before you test. CSV exports are everywhere in health care IT: user lists for access reviews, device inventories, extracts sent to billing or EHR vendors. A failing export in a nightly job can go unnoticed until someone downstream asks why a file is missing.

Formatting cmdlets also belong on your test list. Review the full breaking changes list before you sign off on any upgrade.

The Big One: MSIX Replaces MSI on Windows

Starting with 7.7, Microsoft no longer provides an MSI installer for Windows. The team explained the change in a post on MSI deprecation, and the v7.7.0 GitHub release reflects it: 7.7 and future releases ship as MSIX. The MSI remains available for 7.6 LTS.

For a single admin workstation, this may not matter. For servers and managed fleets, it matters a lot. Based on Microsoft's deprecation post and a third-party installation guide, the MSIX package restricts several scenarios health care IT teams depend on:

Per-machine (all users) installation
Inbound WinRM remoting into the PowerShell 7 installation
Running under the SYSTEM account or from scheduled tasks
Some enterprise deployment workflows built around MSI packages in Configuration Manager (formerly SCCM) and Intune

That list covers a large share of how PowerShell actually runs in a hospital. Scripts deployed through Configuration Manager and Intune often run as SYSTEM. Nightly jobs on utility servers run as scheduled tasks. Remote administration of servers depends on remoting.

Informal community feedback has centered on the same deployment friction, with administrators expecting some organizations to stay on 7.6 LTS longer where remoting or SYSTEM execution is required. Treat those reactions as anecdotal rather than as Microsoft guidance, and confirm behavior in your own environment.

The practical consequence is that many organizations will run two PowerShell 7 versions for a while: 7.6 LTS on servers and anywhere automation runs unattended, and possibly 7.7 on admin workstations where per-user MSIX installs work fine. That is more version management, not less, so decide deliberately where each version belongs.

What This Looks Like in a Small Hospital

Consider a 25-bed Critical Access Hospital with one IT person, a handful of servers, and around 40 workstations. That administrator has a scheduled task on a utility server that runs nightly under SYSTEM, exports disabled Active Directory accounts to CSV, and drops the file on a share for the compliance officer. PowerShell 7.4 was installed by MSI two years ago and never revisited.

That server is now on an unsupported version. The obvious fix, installing the newest release, does not work cleanly here, because the 7.7 MSIX package reportedly does not support SYSTEM execution or scheduled tasks. The right move for this server is the 7.6 LTS MSI, followed by a test run of the export job to confirm the CSV still lands where it should. If the administrator wants 7.7 on their own workstation for interactive work, that can happen separately.

The Compliance Angle

No HIPAA provision governs which PowerShell version you run or how it is packaged. But PowerShell scripts routinely touch systems that hold electronic protected health information (ePHI), and those systems fall under the Security Rule's technical safeguards. The access control standard at 45 CFR 164.312(a)(1) requires technical policies and procedures that allow access to ePHI only to persons or software programs that have been granted access rights. The audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use ePHI.

When a script's execution context changes, for example moving from a SYSTEM scheduled task to a service account, or from one PowerShell version to another, the access rights and logging behind that script can change too. Treat a PowerShell upgrade on systems that touch ePHI as a change that warrants confirming your access and audit controls still work as documented.

What to Do Now

Review the 7.7 announcement and the v7.7.0 release notes, including the full breaking changes list.
Inventory PowerShell 7 installations and identify anything on 7.4 or 7.5. Prioritize servers running unattended automation.
Move unattended, remoted, or SYSTEM-context workloads to 7.6 LTS using the MSI.
Test existing scripts and modules against 7.7 in a lab, focusing on New-Guid, Test-Json, Export-Csv, formatting cmdlets, and Constrained Language Mode.
Choose a deployment method for 7.7 where it fits: winget, the Microsoft Store, or manual MSIX installation.
Update Intune and Configuration Manager packages, Group Policy, and startup scripts that reference PowerShell installers or paths.
Roll out in phases and keep a path back to 7.6 if something breaks.
Watch for Microsoft guidance or community workarounds on MSIX support for remoting, SYSTEM execution, and all-users installs, particularly on Windows Server.

None of this is an emergency, but the 7.4 end of support is real and already in effect. Start with the inventory, settle your servers on 7.6 LTS, and treat 7.7 as something to adopt where it fits rather than everywhere at once.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.