[2026.3.0] Module discovery not working in scripts using alternate credentials
[2026.3.0] Module discovery not working in scripts using alternate credentials
Hi.
I mentioned this in the 2026.3.0 update thread, but I reckon that is the wrong place, so I'll copy the same text over here instead:
After upgrading an existing PowerShell Universal installation from 2026.2.3.0 to 2026.3.0.0, I encountered what appears to be a regression involving module discovery when combining the built-in PowerShell 7 environment with an alternate execution credential.
Configuration
The affected scripts use:
- Environment: PowerShell 7, configured with -Type "PowerShell7"
- Execution → Credential: an AD service account
- Modules installed under the standard machine-wide Windows module directories
The original environment configuration was:
New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7"
Actual behavior
When a script runs in PowerShell 7 using the AD service-account credential, modules installed in the standard module directories cannot be discovered.
For example:
Import-Module TOPdeskPS
fails with:
The specified module 'topdeskps' was not loaded because no valid module file was found in any module directory.
Importing TOPdeskPS by its full path causes its dependency to fail instead:
Import-Module 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1'
Result:
The required module 'PSFramework' is not loaded. Load the module or remove the module from 'RequiredModules' in the file 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1'.
If I import both PSFramework and TOPdeskPS using their complete paths, they load successfully. This confirms that the modules themselves work in this host, but automatic module discovery does not.
The problem only occurs with the combination:
PowerShell 7 + AD service-account execution credential
The same modules load successfully when using Windows PowerShell 5.1 or when running with another execution account.
Workaround
Adding the standard module directories explicitly to the PowerShell 7 environment resolves the issue:
New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7" -PSModulePath @(
'C:\Program Files\PowerShell\Modules'
'C:\Program Files\WindowsPowerShell\Modules'
'C:\Windows\System32\WindowsPowerShell\v1.0\Modules'
)
After applying this configuration, I tested several affected scripts using the AD service account and they all completed successfully without any script-specific workarounds.
Expected behavior
The normal machine-wide PowerShell module directories should remain available when a PowerShell 7 job is started using an alternate execution credential, without requiring them to be added explicitly to every environment.
Could you confirm whether this is a known regression in 2026.3.0.0, possibly related to the changes around PowerShell versions or process hosting?
I can provide sanitized PSModulePath output or relevant logs if needed.
All Comments (4)
@daniel2 Are both PSFramework and TOPdeskPS installed in the WindowsPowerShell modules directory? I ask because we specifically disable Windows PowerShell Compatibility in certain circumstances and this would cause exactly what you are seeing.
about_Windows_PowerShell_Compatibility - PowerShell | Microsoft Learn
We ship a powershell.config.json file that can do this.
about_PowerShell_Config - PowerShell | Microsoft Learn
I'm unaware of any changes in 2026.3.0+ vs 2026.2.5 that changed this behavior but it's worth investigating. Are you primarily seeing this in scripts\jobs?
Adam Driscoll
PowerShell Expert and Software Architect at Devolutions
@daniel2 Are both PSFramework and TOPdeskPS installed in the WindowsPowerShell modules directory? I ask because we specifically disable Windows PowerShell Compatibility in certain circumstances and this would cause exactly what you are seeing.
about_Windows_PowerShell_Compatibility - PowerShell | Microsoft Learn
We ship a powershell.config.json file that can do this.
about_PowerShell_Config - PowerShell | Microsoft Learn
I'm unaware of any changes in 2026.3.0+ vs 2026.2.5 that changed this behavior but it's worth investigating. Are you primarily seeing this in scripts\jobs?
@Adam Driscoll
Yes, both TOPdeskPS and PSFramework are installed under:
C:\Program Files\WindowsPowerShell\Modules
I am seeing this in Automation scripts/jobs. More specifically, it occurs when a job uses the built-in PowerShell 7 environment together with an alternate AD execution credential.
The same script and modules work when using Windows PowerShell 5.1 or when PowerShell 7 is run without that alternate credential.
I understand that disabling implicit Windows PowerShell Compatibility could prevent modules in Windows PowerShell locations from being discovered. However, both modules load and work directly in PowerShell 7 when I import PSFramework and then TOPdeskPS using their full paths. They do not appear to require a WinPSCompatSession in this case.
Adding the following path to the PSU PowerShell 7 environment resolves module discovery for all affected jobs:
C:\Program Files\WindowsPowerShell\Modules
This worked without an explicit PSModulePath before upgrading from 2026.2.3.0 to 2026.3.0.0. I did not install the intermediate 2026.2.4 or 2026.2.5 releases, so I cannot determine exactly where the behavior changed.
Is excluding C:\Program Files\WindowsPowerShell\Modules from PSModulePath an intentional consequence when implicit WinCompat is disabled, even for modules that can load natively in PowerShell 7? Or should native-compatible modules in that directory still be discoverable?
I can also provide PSModulePath and powershell.config.json output from the affected job if useful.
@daniel2 That's a good question about the WinCompat and excluding that module path. I would have to verify that is actually the case. Now that you mention PSModulePath, I wonder if a change there is more likely the root cause. Can you print PSModulePath from a job the runs in the PS 7 environment with and without a credential?
Adam Driscoll
PowerShell Expert and Software Architect at Devolutions
Can you print PSModulePath from a job the runs in the PS 7 environment with and without a credential?
Ok, tried now.
Without credential I get this:
C:\Program Files (x86)\Universal\Modules;C:\Users\svcpsuldaps\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files (x86)\universal\hosts\7.5\Modules;C:\ProgramData\UniversalAutomation\Repository\Modules;C:\ProgramData\UniversalAutomation\Repository\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\WindowsPowerShell\Modules;
With credential I get this:
C:\Users\svcscoadmgt\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files (x86)\universal\hosts\7.5\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files (x86)\Universal\Modules