Open SteveL-MSFT opened 8 years ago
And APPX/WSA for Win10/2016 to remove them properly from the system, right?
I was going to say it should be an MSU - but those don't play nice over remoting. In otherwords, don't play nice over Chef, Puppet, Packer, etc, etc.
I've been doing MSI since it was released - I'm not sure it's the right answer - but that would be a long conversation for a github thread ;)
I regularly install packages supplied as MSUs remotely over WinRM. The trick is to extract the CAB from the MSU and use DISM.
Not the most recent example - this is for WMF 3.0: c:\windows\system32\dism.exe /online /add-package /PackagePath:C:\Windows6.1-KB2506143-x64.cab /NoRestart
So would DISM be a viable option?
@Fitzroy87 - Thanks, I am actually aware of the work arounds. I designed one script function to recognize that it was being asked to do MSU over remoting and it would automatically do the extraction (using expand.exe) and installation (using dism) on the far side without directly running the MSU. (for any arbitrary MSU it was handed)
However, each practitioner has several days of forehead bludgeoning on a brick wall to both discover and then remedy this. So when going into a new project, I usually try to avoid putting my fellow techs through that.
In this regard, I would consider SSH a special case - it exists to enable remote access - so it would be sadly ironic if it is a labyrinth to install remotely. It would be like installers for automation tools that can't be easily automated (nah, that never happens ;) )
MSU's (Microsoft Update) are only used for updates to existing components that already ship with Windows. WSA will probably be needed for Nano. MSI is needed for downlevel.
@SteveL-MSFT - do you know if all these packaging types are buildable in the CI solutions you are considering?
AFAIK, MSU's are the only packages we couldn't build with a public CI system.
I have a strong preference for the deployment options to include WSA/AppX/chocolatey packages. I suppose the chocolatey package could be built on the MSI?
Providing an MSI installer, similar to the latest PowerShell releases, would be great for deploying it en masse via tools like ConfigMgr.
Providing an MSI installer, similar to the latest PowerShell releases, would be great for deploying it en masse via tools like ConfigMgr.
Agreed. Please provide an MSI installer 😊
hi, where can I find opensshserver.cab?
@he852100 - You don't need cab files. When you install the openssh through optional features it will use the cab files. The cab files are not publicly available.
For downlevel windows OS, please use the github releases (zipped payload). For Azure VMs with downlevel OS (win10 below / 2019 server below), we do have OpenSSH as an VM extension. In AZ Cli, you can use the below commands C:> az vm extension set --publisher "Microsoft.Azure.OpenSSH" -n WindowsOpenSSH --resource-group myrg --vm-name myvm
C:> az vm open-port --resource-group myrg --name myvm --port 22
We don't have any plans to provide the MSI installer for downlevel.
We need to make it easier to deploy ssh on Windows