Skip to content

Receiving random Source Location is not valid while attempting to install-module AZ #357

Open

Description

@rlfink

Prerequisites

  • Write a descriptive title.
  • Make sure you are able to repro it on the latest version
  • Search the existing issues.

Steps to reproduce

I have been attempting to install the Az module for the past 2 days. Every attempt results in a different package erroring. For example,
WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/Az.ResourceGraph/1.3.0' is not valid.
PackageManagement\Install-Package : Package 'Az.ResourceGraph' failed to download.

The source location is valid. I have made sure that I am using TLS 1.2. I have attempted on Powershell 5.1 and 7.6. I have attempted on 2 separate machines located on completely separate networks. Once is Windows Server 2022 and the other is Windows 11. The Windows Server is an Azure VM. Same results but different packages error each time even after successive calls.
Install command is:
Install-Module -Name Az -Repository PSGallery -Force -AllowClobber -Scope CurrentUser

I have also marked the respository trusted.

Expected behavior

I expect the installation to be successful.

Actual behavior

For example:
WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/Az.ResourceGraph/1.3.0' is not valid.
PackageManagement\Install-Package : Package 'Az.ResourceGraph' failed to download.

Error details

WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/Az.ResourceGraph/1.3.0' is not valid.
PackageManagement\Install-Package : Package 'Az.ResourceGraph' failed to download.GET

Environment data

PS C:\Windows\system32> $PSVersionTable

Name                           Value                                                                                        
----                           -----                                                                                        
PSVersion                      5.1.20348.5756                                                                               
PSEdition                      Desktop                                                                                      
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                      
BuildVersion                   10.0.20348.5756                                                                              
CLRVersion                     4.0.30319.42000                                                                              
WSManStackVersion              3.0                                                                                          
PSRemotingProtocolVersion      2.3                                                                                          
SerializationVersion           1.1.0.1

Version

5.1.20348.5756

Visuals

No response

Activity

  1. hristozkov69 commented on Oct 27, 2026

    @hristozkov69

    Have the same behavior both on Azure machines and on my work notebook. It seems to be global issue. MS should do something about it I guess?

  2. ElvenSpellmaker commented on Oct 27, 2026

    @ElvenSpellmaker

    +1 for the same issue, any module I try to install is intermittently failing locally and in CI Pipelines.

    E.g.:

    Install-Module -Name Pester -RequiredVersion 5.9.0 -Force -ErrorAction Stop
    Install-Module -Name AWS.Tools.Installer -RequiredVersion 2.0.6 -Force -ErrorAction Stop
    Install-AWSToolsModule -Name AWS.Tools.SecurityToken -Version "${env:AWS_TOOLS_VERSION}" -Force -ErrorAction Stop

    Errors vary:

    run:infra:test:network->run:infra:test->test:smoke:pester: WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/AWS.Tools.Installer/2.0.6' is not valid.
    run:infra:test:network->run:infra:test->test:smoke:pester: Install-Package: Package 'AWS.Tools.Installer' failed to download.
    
    run:infra:test:network->run:infra:test->test:smoke:pester: WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/PackageManagement/1.4.8.1' is not valid.
    run:infra:test:network->run:infra:test->test:smoke:pester: Install-Package: Package 'PackageManagement' failed to download.
    
    run:infra:test:network->run:infra:test->test:smoke:pester: Install-Package: No match was found for the specified search criteria and module name 'Pester'.
    run:infra:test:network->run:infra:test->test:smoke:pester: Try Get-PSRepository to see all available registered module repositories.
    

    Clicking the link usually makes the nupkg download.

  3. gmolnar-at-am commented on Oct 28, 2026

    @gmolnar-at-am

    We're experiencing very similar issues.

    As part of our CI/CD deployment pipeline in Azure DevOps, we try to install a specific version of the SqlServer PowerShell module:

    Install-Module -Name SqlServer -RequiredVersion 22.3.0 -Force

    Our pipeline agents are hosted in Azure West Europe.

    This has been failing sporadically over the last 24 hours. Sometimes we get the same "Source Location ... is not valid" error as the original poster. However, if I open the package URL in a browser, it usually downloads just fine.

    2026-10-27T06:07:26.0540184Z WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/SqlServer/22.3.0' is not valid.
    2026-10-27T06:07:26.2110669Z PackageManagement\Install-Package : Package 'SqlServer' failed to download.
    2026-10-27T06:07:26.2111387Z At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21
    2026-10-27T06:07:26.2115844Z     + CategoryInfo          : ResourceUnavailable
    2026-10-27T06:07:26.2122229Z     + FullyQualifiedErrorId : PackageFailedInstallOrDownload
    2026-10-27T06:07:26.2913561Z ##[error]PowerShell exited with code '1'.
    

    Other times, it fails with "No match was found for the specified search criteria and module name...":

    2026-10-27T16:06:55.6269528Z WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
    2026-10-27T16:06:55.8049133Z PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'SqlServer'.
    2026-10-27T16:06:55.8049721Z Try Get-PSRepository to see all available registered module repositories.
    2026-10-27T16:06:55.8051688Z     + CategoryInfo          : ObjectNotFound
    2026-10-27T16:06:55.8052495Z     + FullyQualifiedErrorId : NoMatchFoundForCriteria
    2026-10-27T16:06:55.8749854Z ##[error]PowerShell exited with code '1'.
    

    And sometimes it works without any issues at all. It's hard to identify a pattern or determine why it fails.

    In my experience, rerunning the pipeline usually resolves the issue, if not on the first attempt, then on the second or third. So we're not completely blocked, but having to rerun a production deployment three times is obviously far from ideal.

  4. smc83dk commented on Nov 6, 2026

    @smc83dk

    We hit this on an Azure DevOps pipeline (Dynamics 365 F&O "LCS Asset Upload" task v2.1.2339750, Windows PowerShell 5.1, PowerShellGet 1.0.0.1, PackageManagement 1.4.7):

    WARNING: Source Location 'http://www.powershellgallery.com:8080/api/v2/package/AzureRM.profile/5.8.4' is not valid.
    ERROR: Package 'AzureRM.profile' failed to download.
    

    Root cause appears to be server-side: the v2 OData feed sometimes returns absolute URLs built from an internal http://…:8080 binding instead of the public https:// host. Every response is a 200 OK. In the bad ones, both xml:base and the package content src point at port 8080, which isn't reachable from outside (connections time out). PowerShellGet then rejects the download URL with the error above.

    Bad response (from Search()):

    xml:base="http://www.powershellgallery.com:8080/api/v2"
    <content type="application/zip" src="http://www.powershellgallery.com:8080/api/v2/package/AzureRM.profile/5.8.4"/>

    Good response (same query):

    xml:base="https://www.powershellgallery.com/api/v2"
    <content type="application/zip" src="https://www.powershellgallery.com/api/v2/package/AzureRM.profile/5.8.4"/>

    Observed rate (2026-11-06, ~11:50–12:10 UTC, no proxy, direct connection, from Europe): 11 of 180 feed responses (~6%) contained :8080 URLs. This happened on the service index /api/v2/, on Search() and on FindPackagesById(). The package download endpoint and the CDN worked every time when called with the correct https URL.

    This may help narrow it down: all bad responses had a random-GUID X-CorrelationId. All 74 good responses in the same sample had IDs with a shared suffix, e.g. 400092c4-1801-0d00-b63f-84710c7967bb. That looks like one backend pool behind Front Door that is configured differently from the rest (wrong scheme or port in its public base URL).

    x-azure-ref / X-CorrelationId of bad responses:

    20261106T115832Z-1646d6f4d7bpp6mxhC1STO726400000001v00000000017sf   d1bc009c-4615-46f2-89fe-470f83e74f12
    20261106T115835Z-1646d6f4d7brhv8thC1STOrfc80000000r80000000002vw7   d3dccaf1-4251-4591-be2d-f899e0b528b1
    20261106T115836Z-1646d6f4d7bqxqpdhC1STOwmfs0000000kqg00000000gw94   c98cdaa0-a322-4e01-83b7-4985938c351f
    20261106T115837Z-1646d6f4d7bqgjpfhC1STOezdn0000000c600000000060db   b4b90d0c-b4e1-4737-a2b4-43c563bc77c7
    20261106T115851Z-1658d5bd699459rjhC1STO91300000000rh000000000ubqe   623fb4c4-d743-478d-9f00-aacdcda3519a
    20261106T115857Z-1658d5bd699m4hw8hC1STOzyyw0000000n4000000000nt98   d1c0f164-7036-42f7-bbc4-9277d665cdbb
    20261106T121025Z-1646d6f4d7bqgc5shC1STO279s0000000rtg000000008fk7   b54efdfd-1721-44c9-86b3-ae468073fb4a
    20261106T121030Z-1646d6f4d7bqgc5shC1STO279s0000000rtg000000008g0v   41cab726-b819-4c24-b52d-36a55e77a652
    

    Repro (Windows PowerShell 5.1):

    $ProgressPreference = 'SilentlyContinue'
    $u = 'https://www.powershellgallery.com/api/v2/FindPackagesById()?id=''AzureRM.profile''&$filter=Version%20eq%20''5.8.4'''
    1..40 | ForEach-Object {
      $r = Invoke-WebRequest $u -UseBasicParsing
      if ($r.Content -match ':8080') { "#$_ BAD  x-azure-ref=$($r.Headers['x-azure-ref'])  x-correlationid=$($r.Headers['X-CorrelationId'])" }
    }

    Client-side configuration was ruled out: PSGallery is registered with the default https SourceLocation, and no proxy is configured (env vars, WinHTTP, WinINET). Re-registering the repository won't help, because the bad URL comes from the feed response. Our workaround for now is to retry the pipeline task.

  5. Marco-Valle commented on Nov 6, 2026

    @Marco-Valle

    Independent reproduction from a different Front Door edge (Milan, MIL; the refs above are STO). Windows PowerShell 5.1, direct connection from Italy, 2026-11-06, starting around 12:50 UTC.

    Request: GET /api/v2/Packages(Id='Az.App',Version='2.0.1'). Across three runs, 5 of 120 responses were malformed (src on http://www.powershellgallery.com:8080, ~4%). The last run logged every response, not only the bad ones (60 requests, 2 malformed), and the two populations separate cleanly:

    malformed (:8080) correct
    responses in the last run 2 58
    X-CorrelationId random v4 GUID ends in -b63f-84710c7967bb in all 58
    x-envoy-upstream-service-time present absent

    The correct-response suffix is identical to the one in smc83dk's example (400092c4-1801-0d00-b63f-84710c7967bb), observed from a different network and edge. All four malformed responses for which I recorded headers carry the Envoy header and a random v4 correlation ID.

    This is consistent with the backend-pool hypothesis above, and suggests the bad responses come from a distinct serving path (the one behind Envoy) rather than from random corruption of an otherwise identical response.

    Malformed responses:

    x-azure-ref: 20261106T125355Z-17d9794bb67sk96hhC1MIL8ffw00000012x0000000004q7n  x-correlationid: 01ed02a5-0ef4-4e7c-9d9c-b41af92fcffa
    x-azure-ref: 20261106T125501Z-17d9794bb67sk96hhC1MIL8ffw00000012x0000000004srz  x-correlationid: e84b1161-1aa9-442e-9987-64ce7a525c45
    x-correlationid: 192c405a-3e9b-4fbf-a0c3-7f3d74a84d37
    x-correlationid: ce144175-8388-40ce-8d75-830f4e0768eb
    

    It also reproduces on Packages(Id=...,Version=...) entity requests, in addition to the endpoints listed above. Impact on our side goes beyond CI: we deploy PowerShell modules to managed endpoints through Intune, running Install-Module as SYSTEM, and the Az rollup (~80 dependencies) fails most of the time because a single malformed link aborts the whole install.

  6. alerickson commented on Nov 6, 2026

    @alerickson
    Member

    Hi all thank you for reporting! This issue should be mitigated now (it may take up to an hour for changes to finish propagating through).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions