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:
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:
1 2 3 4 5 6 7 8 9 10 11 12 |
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:
1 2 3 4 5 6 7 8 9 10 |
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:
1 2 3 4 5 6 7 8 9 10 11 |
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 |
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.