I'm scripting the download of the latest Windows PowerShell x64 MSI installer. The file downloads successfully with Invoke-WebRequest, but Windows Installer reports: "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 same MSI downloaded manually from the release page installs normally. I compared the scripted and manually downloaded files byte-for-byte, and their SHA256 hashes also match, so the download itself does not appear corrupted. Unblocking the file, running it elevated, launching it through msiexec, and double-clicking it all produce the same result.
The script retrieves release metadata, selects an asset matching *-win*x64.msi, builds a local path, and saves the asset with Invoke-WebRequest. What else could cause the scripted copy to be rejected by Windows Installer?
4 Answers
Since the files compare identically, this probably is not an Invoke-WebRequest corruption issue. Try launching it explicitly through Windows Installer so the exact path is unambiguous: msiexec.exe /i "$DownloadPath" /L*V "$env:TEMPinstaller.log". The verbose log should show whether Windows Installer is rejecting the package or whether another process is interfering.
If the hash is identical to the manually downloaded installer, test the installation in Windows Sandbox or a clean virtual machine. That helps separate a scripting problem from an operating-system, antivirus, or application-level issue. If it fails only on the original machine, check the Windows Installer event log and the verbose msiexec log rather than focusing on the download.
A download using the shown approach should work. In testing, this pattern successfully downloaded and opened the MSI without needing elevation or unblocking: assign the filename with [IO.Path]::GetFileName($downloadURL), create the destination with Join-Path, then call Invoke-WebRequest -Uri $downloadURL -OutFile $DownloadPath. Compare the resulting hash with the publisher’s checksum and make sure the selected URL points to the intended release.
The sample has a few inconsistencies worth checking first. Make sure the API URL actually ends with /releases/latest, and confirm that the asset query returns exactly one MSI URL rather than several values. Also verify that the variables used in the final download command are the same ones assigned earlier. A quick check is to print the selected URL, output path, file length, and SHA256 hash before launching the installer.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures