Installing PowerShell Modules in the Current User Scope of the 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 …


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.


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

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:

🎉 That’s a lot better!!


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:


Here’s the $PSVersionTable  I tested:

Resolving The Issue

For the time being, I’m using a Configuration Item to create the System user’s Documents folder. However, I really feel like this is a bug and should be resolved, even if resolution just means spitting out an error.

Visitor Count

Leave a Reply

Your email address will not be published. Required fields are marked *