Installing PowerShell Modules in Current User Scope of System User

Being a system administrator on workstations and a fan of PowerShell, I often try to solve issues with PowerShell when necessary. Recently, we’ve started using Simple NuGet Server for our internal PowerShell repository, and I ran into an issue.

Installing PowerShell modules to the system (default) scope makes sense for modules that will be used by all users of the system. However, I prefer to not clutter the desktop of our users by dropping things in the All Users desktop. Likewise, I didn’t want to clutter the system modules of our users with modules that are really only used for system maintenance and support. Things that, frankly, don’t need to be even seen by the customers/users.

I thought it would be a non-issue. My processes run as the System user ( NT AUTHORITY\System ), and I could just Install-Module -Scope CurrentUser and it would be fine. I was wrong …

Issue

Installing PowerShell modules would quietly, not work. I could run Install-Module -Scope CurrentUser and it would look like everything worked as expected, but I could not use or see the module on the system. I immediately went into troubleshooting mode …

When installing to the current user, the Install-Module command uses the first path in $env:PSModulePath . So I looked at that real fast (\WindowsPowerShell\Modules ) and immediately noticed an issue: \WindowsPowerShell\Modules .

So where did my module get installed? Well, I checked the root of C: since technically, that is a valid relative path and might have put the module here: C:\WindowsPowerShell\Modules . However, that path didn’t get created. After a lot of poking, I believe the module didn’t get installed anywhere, but I’ve yet to just turn on debug and verbose console messages to see if I get any feedback there.

Troubleshooting

If I install a module with verbose messaging, I see that things seem to have installed successfully:

VERBOSE: Module 'QuserObject' was installed successfully to path 'C:\Windows\system32\config\systemprofile\Documents\PowerShell\Modules\QuserObject\0.2.30'.

1	VERBOSE: Module 'QuserObject' was installed successfully to path 'C:\Windows\system32\config\systemprofile\Documents\PowerShell\Modules\QuserObject\0.2.30'.

So, I was left wondering where Windows thought the Documents folder was. So, I asked: [System.Environment]::GetFolderPath('MyDocuments') . That’s odd, Windows gave me an empty string back. So, I wondered what would happen if I made the Documents folder in the System user profile …

The System user profile ( $env:USERPROFILE ) is here: C:\Windows\system32\config\systemprofile . So, I just needed to add the documents folder and hope the rest would sort itself out. I created the following folder ( C:\Windows\system32\config\systemprofile\Documents ), rebooted the computer, and it just worked!

Installing PowerShell Modules

After a reboot of the computer for good measure, I jumped back on the system profile and:

PS C:\> whoami
nt authority\system
PS C:\> $env:PSModulePath.Split(';')[0]
C:\Windows\system32\config\systemprofile\Documents\WindowsPowerShell\Modules
PS C:\> Install-Module QuserObject -Scope CurrentUser -Force
PS C:\> Get-Module QuserObject -ListAvailable

    Directory: C:\Windows\system32\config\systemprofile\Documents\WindowsPowerShell\Modules

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     0.2.30     QuserObject

PS C:\> whoami

nt authority\system

PS C:\> $env:PSModulePath.Split(';')[0]

C:\Windows\system32\config\systemprofile\Documents\WindowsPowerShell\Modules

PS C:\> Install-Module QuserObject -Scope CurrentUser -Force

PS C:\> Get-Module QuserObject -ListAvailable

Directory: C:\Windows\system32\config\systemprofile\Documents\WindowsPowerShell\Modules

ModuleType Version Name ExportedCommands

---------- ------- ---- ----------------

Script 0.2.30 QuserObject

🎉 That’s a lot better!!

Scope

I’ve tested this on both Windows PowerShell (Desktop) and PowerShell (Core). It’s the same issue on both.

Windows PowerShell

Here’s the $PSVersionTable I tested:

Name                           Value
----                           -----
PSVersion                      5.1.19041.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Name Value

---- -----

PSVersion 5.1.19041.1

PSEdition Desktop

PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}

BuildVersion 10.0.19041.1

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

PowerShell

Here’s the $PSVersionTable I tested:

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0.}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name Value

---- -----

PSVersion 7.1.0

PSEdition Core

GitCommitId 7.1.0

OS Microsoft Windows 10.0.19041

Platform Win32NT

PSCompatibleVersions {1.0, 2.0, 3.0, 4.0.}