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, see attached image.

The fix was to add a Documents folder in the System Profile. I've detailed this more on my blog:
https://blog.vertigion.com/2020/11/12/installing-powershell-modules-in-the-current-user-scope-of-the-system-user/

the "set-PSrepository" cmdlet of the "powershellget" module does not respect the verbose parameter. OS is windows 10.1809.

steps to reproduce:
PS C:\Users\Administrator> $PSversiontable

Name Value

PSVersion 5.1.17763.1007
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17763.1007
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PS C:\Users\Administrator> get-command -name 'set-PSrepository'

CommandType Name Version Source

Function Set-PSRepository 2.2.2 powershellget

PS C:\Users\Administrator> powershellget\set-PSrepository -name 'PSgallery' -installationpolicy 'untrusted' -verbose:$false
VERBOSE: Repository details, Name = 'PSGallery', Location = 'https://www.powershellgallery.com/api/v2'; IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PSGallery', Location = 'https://www.powershellgallery.com/api/v2'; IsTrusted = 'True'; IsRegistered = 'True'.
PS C:\Users\Administrator>

packages.json in NPM (NodeJS in general) supports prefixes in the version string to specify a minimum required with minor and minor/patch versions being a variable. For example,

The tilde matches the most recent minor version (the middle number). ~1.2.3 will match all 1.2.x versions but won't match 1.3.0.

The caret provides better flexibility. It will refer to the most recent major version (the first number). ^1.2.3 will match any 1.x.x release including 1.3.0, but will hold off on 2.0.0.

Also, an asterisk (*) indicates that the latest version of the module is needed.

Implementing this type of version specification in PowerShell module manifest will help enable flexibility with regards to downloading required modules.

I am trying to update Pester on Windows 2016 to 4.x because the preshipped Pester 3.4.0 emits a note about the depreciation of the -quiet switch when I use the quiet switch. This get's scooped into stdout when executing via AWS SSM remote commands. Version 3.x complains it does not understand "-Show None".

I want to update to 4.x - in which I ran into all the problems documented here: https://github.com/OneGet/oneget/issues/215

But ended up with "Install-module pester -force -SkipPublisherCheck.

So far so bad, but when I go to remove the 3.4.0 version (with admin rights) from: 'c:\program files\windowspowershell\modules\pester\3.4.0' I get errors because only TrustedInstaller has permissions.

If this scenario wasn't horrible enough, putting preinstalled modules under Windows Resource Protection really throws it over the top.

Could someone please make sure that preinstalled modules can be replaced cleanly? Or don't preinstall them?

Install-PackageProvider cannot retrieve the list of available providers if the machine doesn't have direct access to the internet.

PS C:\Windows\system32> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package
provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : InvalidArgument: (Microsoft.Power...PackageProvider:InstallPackageProvider) [Install-Pac

kageProvider], Exception

+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro

vider

How to reproduce:
1. Setup a network completely separate from the internet.
2. Setup an HTTP-proxy in that network as following:
2.1. The machine with HTTP-proxy has 2 network interfaces: 1 connected to a LAN and another one - to the internet.
2.2. Configure the proxy in a way to require authentication, not allowing anonymous connections. Configure Kerberos authentication.
2.3. Allow access to the internet via the proxy for AD user accounts only, not for the computer ones.
3. Publish the proxy with WPAD.
4. Use Group Policy to configure Internet Explorer throughout the network to use WPAD as a source of proxy settings.
5. Try access the internet (http://example.com) via Internet Explorer - everything works fine.
6. Launch PowerShell console as an administrator, using AD account allowed to access internet via the proxy.
7. Try to download NuGet provider using Install-PackageProvider cmdlet - you receive an error shown above.

Steps to reproduce:

1. Install WMF5 RTM on a fresh Windows 2012 R2 system


2. Open an Administrator PS prompt and run "Install-Module Pester -Force"

Expected result: The -Force parameter causes the NuGet client to be installed without user intervention.

Actual result: The following message is displayed:

NuGet-anycpu.exe is required to continue.
PowerShellGet requires NuGet-anycpu.exe to interact with NuGet based galleries. NuGet-anycpu.exe must be available in
'C:\Program Files\PackageManagement\ProviderAssemblies' or
'C:\Users\Administrator\AppData\Local\PackageManagement\ProviderAssemblies'. For more information about NuGet provider,
see http://OneGet.org/NuGet.html. Do you want PowerShellGet to download NuGet-anycpu.exe now?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

The MSDN documentation for $PSCmdlet.ShouldContinue (https://msdn.microsoft.com/en-us/library/ms568259%28v=vs.85%29.aspx) states "Cmdlets calling ShouldContinue should also implement a Force parameter that allows the cmdlet to bypass these calls. If this is not done, it will be difficult to use the cmdlet from scripts and noninteractive hosts." I'm trying to use Install-Module from an automated setup script on a fresh machine, and this prompt causes the script to hang.

Workaround: Before using Install-Module for the first time, run the following command to fetch NuGet-anycpu.exe (this is what Install-Module is doing internally):

PackageManagement\Get-PackageProvider -Name NuGet -Force

In order to register external module dependencies (dependencies living in another repository), the name has to be registered in a string array property within the PSData Hashtable property in the PrivateData section in the psd1 manifest like so for registering module 'psFtp':

PrivateData = @{
PSData = @{

ExternalModuleDependencies

ExternalModuleDependencies = @('psFtp')
}
} # End of PrivateData hashtable

However, the new-modulemanifest doesn't have an -ExternalModuleDepencies parameter, nor is it possible to register externalmoduledependencies like so:

-PrivateData @{ PSData = @{ ExternalModuleDependencies = @('psFtp') } }

Which from a client perspective of the the existing new-modulemanifest api, would be an intuitive way of setting ExternalModuleDependencies.

Suggestion is:
Either make -ExternalModuleDependencies available as parameter or let the processing of the -PrivateData arguments handle nested hashtables (such as PSData in this case).

Repro setup

The following path exists:
~\Documents\WindowsPowerShell

Windows 10 Enterprise with the following PSVersionTable:
PS C:> $PSVersionTable

Name Value

PSVersion 5.0.10586.122

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

BuildVersion 10.0.10586.122

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

PS C:> [Environment]::GetFolderPath("MyDocuments")
C:\Users\JanEgil\Documents

PS C:> $env:USERPROFILE
C:\Users\JanEgil

Repro steps

Run Install-Script -Name Test-RPC -Scope CurrentUser
~\Documents\WindowsPowerShell\Scripts\Test-RPC.ps1 is created, but the following error occurs:
PS C:> Install-Script -Name Test-RPC -Scope CurrentUser
PackageManagement\Install-Package : Could not find a part of the path ~\Documents\WindowsPow
erShell\Scripts\InstalledScriptInfos\Test-RPC_InstalledScriptInfo.xml'.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:2693 char:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : OpenError: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Packag 

e], Exception

+ FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.OutFileCommand,Microsoft.PowerS 

****.PackageManagement.Cmdlets.InstallPackage

If I delete the downloaded ps1-file and create ~\Documents\WindowsPowerShell\Scripts\InstalledScriptInfos before running Install-Script -Name Test-RPC -Scope CurrentUser it runs without issues.