I saw this error multiple times for now, that I cannot download new modules form the NuGet Repository on a freshly installed or running Windows Server 2016. One time it was the MsolService Module, the other times the AzureAD PowerShell module and today the Exchange Online v2 one, and all just gave me the following error message:
Install-Module ExchangeOnlineManagement NuGet provider is required to continue PowerShellGet requires NuGet provider version '2.8.5.201' or newer to interact with NuGet-based repositories. The NuGet provider must be available in 'C:\Program Files\PackageManagement\ProviderAssemblies' or 'C:\Users\admin\AppData\Local\PackageManagement\ProviderAssemblies'. You can also install the NuGet provider by running 'Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force'. Do you want PowerShellGet to install and import the NuGet provider now? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y WARNING: Unable to download from URI 'https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409' to ''. WARNING: Unable to download the list of available providers. Check your internet connection. PackageManagement\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 C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7405 char:21 … $null = PackageManagement\Install-PackageProvider -Name $script:N …~~~~~~~~~~~~~ CategoryInfo : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-Pac kageProvider], Exception FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackagePro vider PackageManagement\Import-PackageProvider : No match was found for the specified search criteria and provider name 'NuGet'. Try 'Get-PackageProvider -ListAvailable' to see if the provider exists on the system. At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:7411 char:21 … $null = PackageManagement\Import-PackageProvider -Name $script:Nu …~~~~~~~~~~~~~ CategoryInfo : InvalidData: (NuGet:String) [Import-PackageProvider], Exception FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProv ider
So, I checked the internet connection for the VM, I checked if DNS resolution is working and if there are any other blockers that keep me from installing modules from NuGet Repo, but nothing…
The workaround…
Then I finally found a working solution for my issue: Running the following command forces PowerShell to use Tls1.2 for connecting to the NuGet Repository, which makes module installation possible again.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Now all works again, but as soon as I close my shell and open another one, the issue is there again… at least I could install my modules in the prior shell and use them now.
The solution?
When we check the used protocol version by our currently open PowerShell, by using the following command, we can see, it is “Ssl3” and “Tls” by default.
[Net.ServicePointManager]::SecurityProtocol Ssl3,Tls
That’s bad, because SSLv3 is vulnerable since Heartbleed and (hopefully) nobody is using it anymore. Tls(1.0) on the other hand is still considered safe (enough), but more and more service providers tend to remove support for protocols below Tls1.2, which is a wise long overdue decision, from my perspective.
So, how do we solve this issue now, without having to manually change the used Tls version to Tls1.2 manually for any new shell? Some blog posts and the answers.microsoft.com board state, the following command changing the registry should work, but my Server 2016 (1607 Build 14393.3866) still wants to use the older protocols for connecting to the Repository…
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Another blogger states, it is much simpler to just issue the workaround command in your profile environment that is executed every time you start a new shell.
I will add the required steps later, to complete this post…