Latest metadata.json update introduced asset that does not exists/cannot be downloaded

Matthew John Cheetham (@mjcheetham)

          @jshigetomi, since the PR was merged the "https://aka.ms/install-powershell.ps1" script fails when run on a Windows ARM64 machine with the following arguments:

$installScript = "$env:TEMP\install-powershell.ps1"
Invoke-WebRequest -Uri "https://aka.ms/install-powershell.ps1" -OutFile $installScript
& $installScript -AddToPath

An exception is thrown saying the following URL is 404-ing:

https://powershellinfraartifacts-gkhedzdeaghdezhr.z01.azurefd.net/install/v7.6.0-preview2/PowerShell-7.6.0-preview.2-win-arm64.zip

Comes from line 374 in the script:

        $metadata = Invoke-RestMethod https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/metadata.json
        if ($Preview) {
            $release = $metadata.PreviewReleaseTag -replace '^v'
        } else {
            $release = $metadata.ReleaseTag -replace '^v'
        }

        if ($IsWinEnv) {
            if ($UseMSI) {
                $packageName = "PowerShell-${release}-win-${architecture}.msi"
            } else {
                $packageName = "PowerShell-${release}-win-${architecture}.zip"
            }
        } elseif ($IsLinuxEnv) {
            $packageName = "powershell-${release}-linux-${architecture}.tar.gz"
        } elseif ($IsMacOSEnv) {
            $packageName = "powershell-${release}-osx-${architecture}.tar.gz"
        }

        $downloadURL = "https://github.com/PowerShell/PowerShell/releases/download/v${release}/${packageName}"
        Write-Verbose "About to download package from '$downloadURL'" -Verbose

        $packagePath = Join-Path -Path $tempDir -ChildPath $packageName
        if (!$PSVersionTable.ContainsKey('PSEdition') -or $PSVersionTable.PSEdition -eq "Desktop") {
            # On Windows PowerShell, progress can make the download significantly slower
            $oldProgressPreference = $ProgressPreference
            $ProgressPreference = "SilentlyContinue"
        }

        try {
****        Invoke-WebRequest -Uri $downloadURL -OutFile $packagePath ****
        } finally {
            if (!$PSVersionTable.ContainsKey('PSEdition') -or $PSVersionTable.PSEdition -eq "Desktop") {
                $ProgressPreference = $oldProgressPreference
            }
        }

Originally posted by Matthew John Cheetham (@mjcheetham) in #24764 (comment)

It seems a major part of the issue is also that ReleaseTag was updated to point to the preview release, where install-powershell.ps1 expects it to point to the current stable release, so it's currently failing for everyone, not just preview users.

$metadata = Invoke-RestMethod https://raw.githubusercontent.com/PowerShell/PowerShell/master/tools/metadata.json
if ($Preview) {
    $release = $metadata.PreviewReleaseTag -replace '^v'
} else {
    $release = $metadata.ReleaseTag -replace '^v'
}

The really frustrating and sad thing is that there is no mention of this issue and it's been happening for at least half a day at this point. I've been trying to figure out why I'm seeing a failure message for:
Invoke-WebRequest : The request was aborted: The connection was closed unexpectedly.

I've created a pull request to revert ReleaseTag back to v7.4.6 as I believe it was unintentionally changed to a preview release.

#24787

fangfei (@fangfei)

fangfei (@fangfei) Thanks for bringing this to my attention. We did run into some release delays with new security protocols implemented without our knowledge. The preview is released everywhere now except PMC.

I was not aware there were dependencies on the ReleaseTag parameter to be the latest stable release. Thanks for pinpointing that Sebastian Johansson (@ChlorideCull).

I'm tracking the PR from KyZy7 and brought it to the maintainers' attention. Fix should be out soon, thank you for the PR.

The issue should be fixed now

fangfei (@fangfei)

📣 Hey fangfei (@fangfei), how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

This issue doesn't appear fully fixed. Now, it will download the MSI file but then opens the installer seemingly without passing any parameters to the installer so it runs in full gui mode without silent installation. Can we get a check on this and have some testing done?

bassmanadam

bassmanadam The following worked for me to get silent installation without GUI on an elevated pwsh instance.

Invoke-Expression "& { $(Invoke-RestMethod 'https://aka.ms/install-powershell.ps1') } -UseMSI -Quiet"

Ok, guess I'll have to implement that, it wasn't necessary prior to this issue getting introduced.

I think this will become an issue for others though as I'm using the PS7Bootstrap.ps1 method with intune to ensure that powershell7 is installed and then it uses PS7Bootstrap.ps1 script from PSGallery to then restart the script as PS7 due to PnP modules no longer being supported in PS 5.0. The great and powerful Michael Niehaus documented this use case in June of 2024. His script has the line written exactly as I have it and it has worked until this change broke that. I am capable of editing around it with that work around, but anyone else relying on the same method will have this issue. I would not call this closed when this issue will require lots of people to perform a workaround to something that was broken instead of fixing the underlying issue that caused it.

From Michael Niehaus's script:

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
$Script = ""
$MinimumVersion = "7.4.3"
# Check the current installed PowerShell version
if (Test-Path "HKLM:\Software\Microsoft\PowerShellCore\InstalledVersions") {
    $version = Get-ChildItem "HKLM:\Software\Microsoft\PowerShellCore\InstalledVersions" | Get-ItemPropertyValue -Name SemanticVersion | Measure-Object -Maximum
    $currentVersion = $version.Maximum
    Write-Host "Current PowerShell version = $currentVersion"
} else {
    Write-Host "No PowerShell LTS version found."
    $currentVersion = "0.0.0"
}
Write-Host "Minimum PowerShell version = $MinimumVersion"

# Install or upgrade as needed
if ($currentVersion -lt $MinimumVersion) {
    Write-Host "Installing PowerShell LTS"
    Invoke-Expression "& { $(Invoke-RestMethod https://aka.ms/install-powershell.ps1) } -UseMSI"

    # Make sure we have the current path (including pwsh.exe).  Note that this will drop any user path entries.
    $newPath = (Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Session Manager\Environment" -Name PATH).Path
    $env:Path = $newPath
}

bassmanadam

bassmanadam You bring up a good point, if it worked differently before then I will work to restoring that functionality. I'm sorry for the inconvenience caused you. I reopened the issue. I will look into this further and get back to you.

No worries, I am resetting a machine now to make sure that it isn't doing it only when it is already installed as the machine I was testing on to figure out why it wasn't working before had it on there because I got winget working to install it. I will report back if it works fine on the fresh system which is almost ready.

It is doing it on a fresh system as well.

Steve Lee (@SteveL-MSFT)

There are times when you want slient installs (hence the -Quiet switch & was added years ago by Steve Lee (@SteveL-MSFT)) and others when you want to run through the installer manually.

As such it is correct to have this be how this script is called to accomodate for both those usecases & defaulting to showing the installer unless you provide the -Quiet switch.

bassmanadam - With only 7k downloads of the PS7Bootstrap.ps1 script from PSGallery I'd have to disagree with this being all that widely used tbh, we don't however have the numbers on direct use of the install-powershell.ps1 (or it's sister script install-powershell.sh) to compare with. I also cannot see how that script would have ever tried to silently install PowerShell from what has been published & is from my POV working as it has been intended. Nor would it actually keep to installing a LTS release, which was why I added -LTS as an option in the install-powershell.ps1 script, which is yet to be made available for use with this script.

I'm also one of the last to have made modifications to this script and have an ongoing PR that has been sat on/off since I started in in July 2023, though it has been picked back up by Travis Plunk (@TravisEz13) this week & look at getting the needed addtional fixes added before it can be merged & even then, there are additional items on this script that many would like to see added for new functionality that has since been added to the MSI installer since my last amendments. Work on this halted, due to there not seemingly being enough desire to have this maintained and supported.

Note - According to the documentation, this script, is not actually a recommended way to install powershell & therefore not really supported either, and falls into the grey area of your milage may vary.

I've used it for a long time & been asking for it to be documented as a supported way to install. I also wrote this post on Installing PowerShell Versions side by Side for testing purposes making use of this script as I needed a repeatable way to do so to aid me with testing things as part of my time as part of the working groups I am a part of, which you can read more in that post.

Also I think the original issue raised here was with a release branch being made with no release actually being published, which is expected as that file/s from that release doesn't exist to be downloaded. We shouldn't really need to code around that in the install-powershel script, as we shouldn't really ever have a release branch that doesn't have a release from it. This is all due to process and is fundamentally a timing issue, and one that, I we already had solved prior to this recent set of attempted releases.

I do realise that the release process isn't exactly straight forward, with additonal complexities when we are like we are now in the process of moving between having LTS & preview to having LTS & stable & preview like we have now with 7.4.x is LTS, 7.5.x is stable & 7.6.x is preview, and this especially if there are new team members/maintainers that are learning all the moving parts needed to invoke the release. Which will bring up issues like this. I hope we won't have similar issues in future releases but that's just one of the joys of the software development process that we have to be mindful about & hope that we don't come across in the future.

This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.

Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.

Navigation Menu

Repository navigation

Latest metadata.json update introduced asset that does not exists/cannot be downloaded #24780

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Latest metadata.json update introduced asset that does not exists/cannot be downloaded #24780

Description

Activity

ChlorideCull commented on Jan 15, 2025

bassmanadam commented on Jan 15, 2025

KyZy7 commented on Jan 15, 2025

jshigetomi commented on Jan 16, 2025

jshigetomi commented on Jan 16, 2025

microsoft-github-policy-service commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

jshigetomi commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

jshigetomi commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

bassmanadam commented on Jan 16, 2025

kilasuit commented on Jan 18, 2025

microsoft-github-policy-service commented on Jul 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions