A few days ago, I tried to use Install-Module on the old Windows 2008R2 system that I use for specific tasks.
install-module adessentials -Scope CurrentUser -Force
Unfortunately, it failed with a weird message saying:
WARNING: Source Location ‘https://www.powershellgallery.com/api/v2/package/PSEventViewer/1.0.13' is not valid.
PackageManagement\Install-Package : Package ‘PSEventViewer' failed to download.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\188.8.131.52\PSModule.psm1:1772 char:21
+ … $null = PackageManagement\Install-Package @PSBoundParameters
+ CategoryInfo : ResourceUnavailable: (C:\Users\adm_jz…entViewer.nupkg:String) [Install-Package], Exception
+ FullyQualifiedErrorId : PackageFailedInstallOrDownload,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
At first, I thought that PowerShellGallery is just blocked or broken, so I gave up retrying. However, today Justin Grote mentioned in a tweet that it's because PowerShellGallery disabled support for TLS 1.0 and is now requiring TLS 1.2. A simple change, but for older systems a breaking change. You can read about this change on the official PowerShell Team blog.
If you check SecurityProtocol that is used by PowerShell, it reports SystemDefault.
But SystemDefault is different on every system. So while my up to date Windows 10 didn't notice any change, my work servers did. The error you saw above comes from TLS 1.2 requirement where servers I use are set to default TLS 1.0. The workaround for this issue is simple
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
But the problem with that approach is that you need to run it every time you open a new PowerShell session and want to use Install-Module, Update-Module, or any other command that interacts with PowerShellGallery. In case you want to fix this permanently you could use registry entries forcing all .NET processes targeting .NET 4.5 to use strong crypto.
Set-ItemProperty ` -Path "HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319" ` -Name "SchUseStrongCrypto" ` -Value "1" ` -Type DWord ` -Force Set-ItemProperty ` -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319" ` -Name "SchUseStrongCrypto" ` -Value "1" ` -Type DWord ` -Force
So if you're using any automated scripts that use Install-Module or Update-Module to configure things, you may want to update registry or add additional code to prevent any issues. For details you can read Transport Layer Security (TLS) best practices with the .NET Framework. Make sure to backup registry before making changes.
PowerShell Team (on 17th of April 2020) has released a new PowerShellGet, which solves the issue with TLS 1.2 requirement.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 install-module powershellget -force -SkipPublisherCheck -Scope CurrentUser -AllowClobber
I've tested this on Windows 2008R2 without administrative rights, and it solves the issue.