WMF 5.1 Upgrade - Broken Repositories

When upgrading our 2008 R2 servers to WMF 5.1 just about all of them have an issue registering the repository for the PSGallery. If I run Get-PSRepository after upgrading, I get the following:

PS C:> Get-PSRepository
WARNING: MSG:UnableToDownload «https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409» «»
WARNING: Unable to find module repositories.

I can browse to https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409 on the server with IE just fine though.

There is also no way for me to register any new repositories. If I try it tells me I need a Nuget provider. When I try to install that, it fails as well. I get the following when I try to register a new repository:

PS C:> Register-PSRepository -Name ‘Dev’ -SourceLocation $psRepositoryPath -InstallationPolicy Trusted

NuGet provider is required to continue
PowerShellGet requires NuGet provider version ‘’ or newer to interact with NuGet-based repositories. The NuGet
provider must be available in ‘C:\Program Files\PackageManagement\ProviderAssemblies’ or
‘C:\Users\mcelreathma\AppData\Local\PackageManagement\ProviderAssemblies’. You can also install the NuGet provider by
running ‘Install-PackageProvider -Name NuGet -MinimumVersion -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\\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

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\\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

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\Get-PackageProvider : Unable to find package provider ‘NuGet’. It may not be imported yet. Try
‘Get-PackageProvider -ListAvailable’.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\\PSModule.psm1:7415 char:30

  • … tProvider = PackageManagement\Get-PackageProvider -Name $script:NuGet …
  •             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : ObjectNotFound: (Microsoft.Power…PackageProvider:GetPackageProvider) [Get-PackageProvi
      der], Exception
    • FullyQualifiedErrorId : UnknownProviderFromActivatedList,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPacka

Register-PSRepository : NuGet provider is required to interact with NuGet-based repositories. Please ensure that
‘’ or newer version of NuGet provider is installed.
At line:1 char:1

  • Register-PSRepository -Name ‘Dev’ -SourceLocation $psRepositoryPath - …
  •   + CategoryInfo          : InvalidOperation: (:) [Register-PSRepository], InvalidOperationException
      + FullyQualifiedErrorId : CouldNotInstallNuGetProvider,Register-PSRepository

Most of the time I can manually uninstall WMF 5.1, reboot, then reinstall and everything works. There have been a handful of cases where re-installing does not fix the issue at all so we have some servers that cannot use a PSRepository.

Has anyone seen this before? Or would anyone be able to point me in the right direction to start?

It’s depressing that servers still have I.E. on them at all.

I’ve not run into that. It’s would honestly take a good amount of locally based packet sniffing and troubleshooting to figure it out. Have you tried manually downloading and installing NuGet, since you’re able to access the URL normally? Also, have you checked to see if any firewalls are limiting access by certain processes? E.g., it’s entirely possible to let Internet Explorer (may it Rest In Peace someday) have outbound traffic, but not other processes.

Firewall is not enabled on this machine at all. Running an Invoke-WebRequest to the URL, https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409 does fail through PowerShell. When I uninstall WMF 5.1 though, Invoke-WebRequest works on my test server. Is there a file or setting somewhere in PowerShell that is used to configure PowerShell to use a Proxy? We have had some proxy changes that I have suspected might be behind this but haven’t found any definitive proof.

PowerShell just asks .NET, which just asks the OS, to complete the HTTP(S) request, so whatever system-level proxy is configured, should be used. The fact that your Invoke-WebRequest fails and then succeeds does suggest it’s something system-level - like perhaps the proxy (or whatever) is sensitive to a process signature or something.

I ended up finding a workaround. The Package Providers are stored under C:\Program Files\PackageManagement\ProviderAssemblies. I was able to copy the NuGet provider from a working server and am now able to at least register our internal repository. I’ll just do this for the servers that a re-install doesn’t fix the issue. Still can’t register the default repo for the PowerShell Gallery but I don’t anticipate we will be needing to install modules directly from the gallery on servers anyway. Plus our 2008 server retirement project is kicking off soon anyway.

Matt, I found that an Schannel client error was occurring every time I tried to invoke `Install-Module`. This was visible in the System log in Event Viewer, Event ID 36871. This happened to be a result of SSL/TLS hardening I’d preformed on the server. I was seeing the same error that you recorded, "WARNING: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to “.” I reverted our changes to Schannel/Crypto (using the IISCrypto tool), rebooted, and was able to install the NuGet provider and subsequent modules from www dot powershellgallery dot com.

I came across this post, having the same issue. I, too, had hardened by Server 2016 build with IISCrypto to disable insecure protocols and ciphers. Also, when I explicitly ran Invoke-WebRequest against the URL ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’, I received a vague “connection was reset” error or something like that.

I got around that by turning back on TLS 1.0 support, only for Client, in the registry, and left all other settings based on the PCI 3.1 template that is built into IISCrypto. After turning on TLS 1.0 Client, I was able to register the repository.

So apparently, the server(s) to which the above URL redirects do not support TLS 1.1 or higher.

Here are the settings that I had to change to re-enable TLS 1.0 client support (the “Enabled” value corresponds to a DWORD value of ffffffff):

PS C:\Windows\system32> get-item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client'

Hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0

Name Property

Client Enabled : 4294967295
DisabledByDefault : 0

The previous values were:

Name Property

Client Enabled : 0
DisabledByDefault : 1


I also just hit this issue on a group of servers with hardened crypto settings (i.e. SCHANNEL). Not only did I need to re-enable TLS 1.0 Client but I also had to re-enable the SHA hash. Note, my issue was not specific to a 5.1 upgrade, my issue was on 5.0.