Latest MSI exits without installing, no error messages

[Farmbuyer]

Steps to reproduce

Following the instructions at https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH-Using-MSI to do a test installation on a VM before trying it on a larger scale:

1. Using PowerShell in Administrator mode, on Windows 10 Enterprise Edition 20H2 build 19042.1706. (The production systems are running build 1766, this test VM just happens to be a bit older.)
2. msiexec /i OpenSSH-Win64-v8.9.1.0.msi ADDLOCAL=Client

Expected behavior

I expected either a text-based or GUI popup installer, to install only the client feature.

Actual behavior

A small installer dialog appears, gets as far as "Configuring " (it's visible for only a second), then... that's it. The installer exits, nothing is installed, and no error messages are displayed either in the PowerShell window or in GUI format.

After reading issue #1936, I tried running the installer again without the ADDLOCAL, figuring if it put both client and server in place, I could always try rerunning with REMOVE=Server to take sshd back out. Got the same early-exit, no-op, no diagnostics behavior.

Then I wondered whether it might be detecting the original outdated OpenSSH feature that I'm trying to replace, and bailing out because it's present. So I ran Remove-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 which as expected removed C:\Windows\System32\OpenSSH altogether. However, running the MSI after that still did nothing, with no errors.

As a workaround, I gave up on the MSI and downloaded the OpenSSH-Win64.zip instead. This works in that I can move it in place and then tweak security permissions as documented in the first four steps on https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH, but manually extracting a zip file and shuffling around permissions isn't going to fly with the larger IT organization here, even if it's scripted. They'll accept a signed MSI from Microsoft, but they're scared of anything that looks "unpolished".

Error details

No errors are mentioned.

Environment data

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

Version

OpenSSH-Win64-v8.9.1.0

[jborean93]

Have you run msiexec with logging enabled to try and find out why it is bailing out?

msiexec /i OpenSSH-Win64-v8.9.1.0.msi /L*V C:\path\to\install.log ADDLOCAL=Client

When it fails you can scan through that log to try and figure out if it has any errors or other useful information that could indicate the problem.

[Farmbuyer]

Gave that a try just now, thanks for the /L tip. There's a very brief flicker of a popup dialog, even quicker than before. The logfile gets created and is zero length.

Whatever's going awry has been overtaken by events here; it turns out that we need some of the changes in the 9.0 release of OpenSSH, so even getting the MSI working wouldn't help us. Can probably just close this issue, I'm assuming?

[jannikac]

Ran into this issue as well. The solution was to use an absolute path for msiexec.exe.

So instead of msiexec /i OpenSSH-Win64-v8.9.1.0.msi ADDLOCAL=Client

use something like msiexec /i C:\Users\...\OpenSSH-Win64-v8.9.1.0.msi ADDLOCAL=Client

[weavage]

I found that running it in powershell without the msiexec seems to work too. No clue why.
Something like this:
.\OpenSSH-Win64-v8.9.1.0.msi ADDLOCAL=Client

[tgauth]

@Farmbuyer - sounds like you no longer need a fix immediately, but if you have a chance, could you try out the above suggestions from @jannikac and @weavage & see if either works for you?

If neither of those work, I'm curious as to whether the issue with msiexec is isolated to OpenSSH - are you able to install other programs on the VM via msiexec?

manually extracting a zip file and shuffling around permissions isn't going to fly with the larger IT organization here, even if it's scripted. They'll accept a signed MSI from Microsoft, but they're scared of anything that looks "unpolished".

As far as install workarounds, WinGet is also an option for installing the OpenSSH Beta Releases that are available on GitHub.