Winget Install Issue Via EnterPSSession

XXLMandalorian013 commented 1 year ago

Brief description of your issue

Greeting Winget Team and other Tech folks!

I was exploring Winget and had an issue similar to issue #715 except I was remoting from my PC into a Target PC.

The first remote install and uninstall of Microsoft.Office was fine (see steps below) but trying to reinstall it remotely gave Installer hash does not match; this cannot be overridden when running as admin. I tried it in Terminal and just straight up PS7. Much like [#715] I also tried --Force and it was no better.

I physically logged into the PC I was trying to install Microsoft.Office on again and ran PS7 administratively and was able to install Microsoft.Office again via winget install --id Microsoft.Office --accept-source-agreements --Scope Machine

I was combing over past issue and [#715] and its merge into winget-pkgs pull request #83280.

I don't have much GPO experience but did the --force ever get rolled into the settings .json?

I also seem to remember seeing a settings change via the Winget Settings.json to add or make sure it was running administratively but can't seem to find it. Does anyone have a link to that?

Look forward to hearing from you,

Steps to reproduce

Start PowerShell 7 or Terminal PS7 ran as admin.
Type Enter-PSSession -ComputerName PC-123 -Credential User@doamin.com.
Run winget CMD winget install --id Microsoft.Office --accept-source-agreements --Scope Machine.
Once installed, uninstall with winget uninstall --id Microsoft.Office
Reinstall it again with the same as step 3.

Expected behavior

This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://officecdn.microsoft.com/pr/wsus/setup.exe
  ██████████████████████████████  7.13 MB / 7.13 MB
Successfully verified installer hash
Starting package install...
Successfully installed```

### Actual behavior

  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  1024 KB / 4.87 MB
  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  2.00 MB / 4.87 MB
  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  3.00 MB / 4.87 MB
  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–’â–’â–’â–’â–’â–’  4.00 MB / 4.87 MB
  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆ  4.87 MB / 4.87 MB

  â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  0%
  â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  0%

Found Microsoft 365 Apps for enterprise [Microsoft.Office] Version 16.0.15427.20210
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://officecdn.microsoft.com/pr/wsus/setup.exe

  â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’â–’  0.00 B / 7.13 MB
  â–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆâ–ˆ  7.13 MB / 7.13 MB
Installer hash does not match; this cannot be overridden when running as admin

### Environment

```shell
My Machine:

   OS: Win 10 Pro 64 Bit 21H2 (19044.2130)

   PowerShell: 7.2.7

   MS Terminal: 1.15.2874.0

   Windows Package Manager: v1.3.2691

   User Acct: Domain Profile w/ Admin

   UAC Settings: Default

Target Machine:

   OS: Win 10 Pro 64 Bit 21H2 (19044.2130)

   PowerShell: 7.2.7

   Windows Package Manager: v1.3.2691

   User Acct: Domain Profile w/ Admin

   UAC Settings: Default

XXLMandalorian013 commented 1 year ago

@denelon Not sure what the fix was but installing and uninstalling --ID "Microsoft.Office" works just fine now via Enter-PSSession as of 10-31-22. I looked at the Microsoft.Office pkgs manifest here and it was last updated 12 days ago, and this issue was only 5 days ago.

denelon commented 1 year ago

We had some CDN related issues impacting the cache. You may have been impacted by that issue. It's possible the PR to add the new hash succeeded, but the CDN endpoints didn't get correctly updated with the new manifest containing the hash. We've been manually forcing cache resets while we work on the automated solution.

https://github.com/microsoft/winget-pkgs/issues/86160

XXLMandalorian013 commented 1 year ago

Ah, that could of been it.

The more I test, the more I think this is my issue. If a non admin domain user is logged into PC A, and I remote in via EnterPSSession as a domain Profile with admin rights on PC A and run winget install --id Google.Chrome --accept-source-agreements --Scope Machine I get Installer hash does not match; this cannot be overridden when running as admin.

Is there no work around for installing and uninstalling software?

denelon commented 1 year ago

Not at this point. We're still working through the "remote" interfaces for leveraging WinGet on a remote machine. Generally speaking, one is connecting to the remote machine with a "system" account and may need to have the "user" logged in to affect changes for software installed in the user context on the remote machine.

The other message about the hash which is also work to be done for handling the ability to enable a hash override (requires admin access) and then using an argument to bypass or ignore the hash failure. The current UX is bad as an administrator can't override the hash, it only functions today in the user context (It's an open bug).

XXLMandalorian013 commented 1 year ago

Understood, I look forward to WinGets development and hope it will eventually run an admin profile without needing to be signed in as that admin profile by just requesting creds. I think this pack manager already has some great legs! Thanks @denelon.

microsoft / winget-cli