WMF 5.1 Upgrade - Broken Repositories

Welcome Forums General PowerShell Q&A WMF 5.1 Upgrade - Broken Repositories

This topic contains 7 replies, has 5 voices, and was last updated by

5 months, 1 week ago.

  • Author
  • #73955

    Points: 22
    Rank: Member

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

  • #74065

    Points: 1,785
    Helping HandTeam Member
    Rank: Community Hero

    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.

    • #74698

      Points: 22
      Rank: Member

      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.

  • #74701

    Points: 1,785
    Helping HandTeam Member
    Rank: Community Hero

    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.

    • #74904

      Points: 22
      Rank: Member

      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.

  • #76699

    Points: 1
    Rank: Member

    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.

    • #91984

      Points: 0
      Rank: Member

      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


  • #108019

    Points: 41
    Rank: Member

    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.


The topic ‘WMF 5.1 Upgrade - Broken Repositories’ is closed to new replies.