Unable to load PS modules after upgrade beyond 2026.1.2

[DanielMalmgren]

Description of Issue

On one of my PSU systems, when I upgrade to versions after 2026.1.2 (have tried .3, .4 and .5 now) I can't load any Powershell modules, whenever I try I get the following:

The term 'Import-PowerShellDataFile' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

This is on a Windows Server 2025 Datacenter 24H2, install is made using msi. I have got another almost identical system and on that machine everything works fine. Both are running Powershell 7.5.2. One difference is that the one that works is using MSSQL, but the one with the problem uses SQLite, don't know if that's relevant.

Version

2026.1.5

Severity

Medium

Hosting Method

MSI (Windows Service)

Operating System

Windows

Database

SQLite

Licensed

Yes

Features

No response

Additional Environment data

No response

Screenshots/Animations

No response

[adamdriscoll]

We are looking into some issues with PSModulePath. They are typically happening with Windows PowerShell so I'm a bit surprised you are seeing them in PS7.

• Are you see this in jobs, apps, endpoints?
• Are you running those in external environments like PowerShell 7 and Windows PowerShell 5.1?
• Have you setup any custom PSModulePath values for these environments?
• Can you navigate to Help \ Support Tools \ Environment variables and provide what is listed for PSModulePath?

Just a little bit more information about why this is happening and seems to sneak back in.

PowerShell's PSModulePath environment variable can be set at the user, machine and process level. Windows PowerShell and PowerShell 7 treat the path a bit differently and actually adjust the process-scoped variable when they are initialized. This is also the same for the PS SDK, which is part of PSU. Installers, users and other processes can modify the user and machine variables pretty easily.

PSU also attempts to manage the path internally for both the server process and any child processes. Those child processes can inherit the environment from the server and run two different flavors of PS which each manage the path differently.

We have code in place to setup the PSModulePath correctly right before execution but have been fighting with unexpected changes or even internal changes, that cause modules to not load from the correct location. We're introducing a new PSUModulePath variable to help work around some of these issues but it's fundamentally a problem with how the PS SDK discovers modules. It makes it really hard to enforce a particular path without inadvertently inheriting the path from somewhere else.

We are looking at ways to combat this with tools like multi-pwsh. We havent integrated it into PSU yet but are considering taking advantage of it to ensure a deterministic module discovery order.

[DanielMalmgren]

Oh, crap. Yep, you are right. The scripts I used for testing this are all set to use Windows PowerShell 5.1, so this is not a problem in PowerShell 7. Still prohibits me from upgrading (and I still don't understand why it only happens on one of my two servers), but I guess this issue can be merged with some other describing the same problem (can't seem to find one right now though).

[adamdriscoll]

Thanks for the feedback! That's what I wanted to know. We have a fix for this coming in 2026.1.6.