Repository navigation
Description
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.GETEnvironment 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.1Version
5.1.20348.5756
Visuals
No response
Activity
hristozkov69 commentedon Oct 27, 2026
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?
ElvenSpellmaker commentedon Oct 27, 2026
+1 for the same issue, any module I try to install is intermittently failing locally and in CI Pipelines.
E.g.:
Errors vary:
Clicking the link usually makes the nupkg download.
gmolnar-at-am commentedon Oct 28, 2026
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
SqlServerPowerShell module: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.
Other times, it fails with "No match was found for the specified search criteria and module name...":
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.
smc83dk commentedon Nov 6, 2026
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):
Root cause appears to be server-side: the v2 OData feed sometimes returns absolute URLs built from an internal
http://…:8080binding instead of the publichttps://host. Every response is a 200 OK. In the bad ones, bothxml:baseand the packagecontent srcpoint 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()):Good response (same query):
Observed rate (2026-11-06, ~11:50–12:10 UTC, no proxy, direct connection, from Europe): 11 of 180 feed responses (~6%) contained
:8080URLs. This happened on the service index/api/v2/, onSearch()and onFindPackagesById(). 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:
Repro (Windows PowerShell 5.1):
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.
Marco-Valle commentedon Nov 6, 2026
Independent reproduction from a different Front Door edge (Milan,
MIL; the refs above areSTO). 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 (srconhttp://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::8080)X-CorrelationId-b63f-84710c7967bbin all 58x-envoy-upstream-service-timeThe 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:
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, runningInstall-Moduleas SYSTEM, and theAzrollup (~80 dependencies) fails most of the time because a single malformed link aborts the whole install.alerickson commentedon Nov 6, 2026
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).