Why does an MSI downloaded with Invoke-WebRequest fail to install even though it matches the manual download?

0
0
Asked By MellowPine42 On

I'm trying to automate downloading the latest PowerShell Windows x64 MSI installer with PowerShell. Invoke-WebRequest completes successfully, but launching the downloaded file produces: "This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package."

The strange part is that the downloaded file appears identical to the one obtained manually from the release page. Comparing the files byte-for-byte shows no differences, and their SHA-256 hashes match as well.

The script currently obtains release metadata, selects an asset matching `*-win*x64.msi`, extracts the filename, and saves the asset with Invoke-WebRequest:

`$repository = 'PowerShell/PowerShell'`
`$fileNamePattern = '*-win*x64.msi'`
`$downloadPath = 'C:Temp'`
`$releasesUri = "https://api.github.com/repos/$repository/releases/latest"`
`$downloadUrl = ((Invoke-RestMethod -Method Get -Uri $releasesUri).assets | Where-Object Name -Like $fileNamePattern).browser_download_url`
`$fileName = [System.IO.Path]::GetFileName($downloadUrl)`
`$destination = Join-Path $downloadPath $fileName`
`Invoke-WebRequest -Uri $downloadUrl -OutFile $destination`

Unblocking the file, running it elevated, double-clicking it, and invoking `msiexec /i` all produce the same result. What else could cause Windows Installer to reject this file when the downloaded and manually downloaded files have matching contents?

1 Answer

Answered By NorthWagon5 On

The download itself should work with a straightforward scalar path, such as `$destination = Join-Path $env:TEMP $fileName; Invoke-WebRequest -Uri $downloadUrl -OutFile $destination`. The MSI does not normally need to be run as administrator, and `Unblock-File` only removes the downloaded-file security zone marker; it cannot repair an invalid package. Since the hashes match and the manual copy behaves differently only if launched on another system, investigate the local OS, antivirus, filesystem permissions, and Windows Installer logs.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.