How are permissions handled?

[Jacinto27]

The problem

The installation instruction isnt very clear (there´s also no wiki) so I am at a loss when installing this app. I´m a standard user on a system with an admin account, how should this app be installed? Should the admin install it? should I install it with an elevated Powershell? Would it run properly? I assume the logical course is for an admin ot install this on this pc and set up the ui shortcuts for me, but idk if it would work as intended, theres also no place in the readme that explains this/makes this explicit.

What version of WAU has the issue?

NA

What version of Windows are you using (ex. Windows 11 22H2)?

Windows 11 23H

What version of winget are you using?

NA

Log information

No response

Additional information

No response

[VerySlapp]

I'm also having problems on clients where the users do not have admin privileges by default.
OS info:

Winget version: v1.8.1791

These are some of the relevant logs:

##################################################

CHECK FOR APP UPDATES - 7/15/2024

##################################################
11:55:51 - Running in System context
11:55:53 - Notification Level: Full. Notification Language: English
11:55:53 - Checking internet connection...
11:55:54 - Connected !
11:56:00 - Winget Version: v1.7.11261
11:56:00 - WAU current version: 1.17.8
11:56:00 - WAU AutoUpdate is Disabled.
11:56:00 - WAU uses External Mods from: C:\ProgramData\Winget-AutoUpdate-Configurator\mods
11:56:01 - Mods are up to date.
11:56:01 - WAU uses Black List config
11:56:03 - Checking application updates on Winget Repository...
...

12:20:01 - ########## WINGET UPGRADE PROCESS STARTS FOR APPLICATION ID 'Microsoft.VCRedist.2015+.x86' ##########

12:20:01 - -> Running: Winget upgrade --id Microsoft.VCRedist.2015+.x86 --accept-package-agreements --accept-source-agreements -h

\

Found Microsoft Visual C++ 2015-2022 Redistributable (x86) [Microsoft.VCRedist.2015+.x86] Version 14.40.33810.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...

\
|
/

Installer failed with exit code: 1260
Installer log is available below

[1310:0560][2024-07-15T12:20:03]i010: Launching elevated engine process.
[1310:0560][2024-07-15T12:20:03]e000: Error 0x800704ec: Failed to launch elevated child process: C:\Users%user%\AppData\Local\Temp{7929A40F-####-####-####-ECF5B9CF####}.be\VC_redist.x86.exe
[1310:0560][2024-07-15T12:20:03]e000: Error 0x800704ec: Failed to elevate.
[1310:0560][2024-07-15T12:20:03]e000: Error 0x800704ec: Failed to actually elevate.
[1310:0560][2024-07-15T12:20:03]e000: Error 0x800704ec: Failed to elevate.
[1310:0560][2024-07-15T12:20:03]i399: Apply complete, result: 0x800704ec, restart: None, ba requested restart: No
[1310:0560][2024-07-15T12:20:03]i500: Shutting down, exit code: 0x4ec****

[KnifMelti]

You can install in different ways (as Administrator or System):
Administrator - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#intallation
Administrator/System - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#advanced-installation
System - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#intunesccm-use

The path C:\ProgramData\Winget-AutoUpdate-Configurator\mods isn't a part of WAU, could it be you're running the fork (with a very old WAU 1.17.8): https://github.com/Weatherlights/Winget-AutoUpdate-Intune

In your log there is a gap of 24 min:
11:56:03 - Checking application updates on Winget Repository...
12:20:01 - ########## WINGET UPGRADE PROCESS STARTS FOR APPLICATION ID 'Microsoft.VCRedist.2015+.x86' ##########

Is it running the 12:20:01 entry for current user (C:\Users%user%\AppData\Local\Temp{7929A40F-####-####-####-ECF5B9CF####}.be\VC_redist.x86.exe)?

Regarding VCRedist - best is to blacklist them, heres my Blacklist:
Brave.Brave
Dropbox.Dropbox
ElectronicArts.EADesktop
EpicGames.EpicGamesLauncher
Facebook.Messenger
Google.Chrome
Google.GoogleDrive
IDMComputerSolutions,Inc.UltraEdit
IG.IGClient
Microsoft.DeploymentToolkit
Microsoft.DevHome
Microsoft.DotNet*
Microsoft.Edge*
Microsoft.Office
Microsoft.OneDrive
Microsoft.Teams*
Microsoft.UI.Xaml.*
Microsoft.VCRedist*
Microsoft.VC++*
Microsoft.WindowsADK
Microsoft.WindowsAppRuntime.*
Microsoft.WindowsSDK
Mozilla.Firefox*
Nvidia.GeForceNow
SomePythonThings.WingetUIStore
TeamViewer.TeamViewer*
Ubisoft.Connect
VideoLAN.VLC.Nightly

[VerySlapp]

Thank you for replying so quickly, @KnifMelti!

You can install in different ways (as Administrator or System): Administrator - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#intallation Administrator/System - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#advanced-installation System - https://github.com/Romanitho/Winget-AutoUpdate?tab=readme-ov-file#intunesccm-use

The path C:\ProgramData\Winget-AutoUpdate-Configurator\mods isn't a part of WAU, could it be you're running the fork (with a very old WAU 1.17.8): https://github.com/Weatherlights/Winget-AutoUpdate-Intune

I had indeed gotten my tabs mixed around, and I've been following Weatherlights fork (https://github.com/Weatherlights/Winget-AutoUpdate-Intune/wiki/Installation-guide#deploy-using-the-microsoft-store-recommended), so it very much looks like I posted this in the wrong place.

As to the version of WAU that I'm using; I've published the app to my clients via the Microsoft Store, and it does look like it is quite a bit behind on the WAU version. The upside to doing it this way, is that I don't have to update the app myself (or so I thought)

In your log there is a gap of 24 min: 11:56:03 - Checking application updates on Winget Repository... 12:20:01 - ########## WINGET UPGRADE PROCESS STARTS FOR APPLICATION ID 'Microsoft.VCRedist.2015+.x86' ##########

I excluded the parts of the log that referred to other apps and that caused the time gap

Is it running the 12:20:01 entry for current user (C:\Users%user%\AppData\Local\Temp{7929A40F-####-####-####-ECF5B9CF####}.be\VC_redist.x86.exe)?

It should be, as it is configured to do so, but I can't find anything in the logs that explicitly say the app is being updaten in user context. However, I see now that the WAU app is installed in system context (by pushing the app from MS Store via Intune). Could that cause any trouble, or does it work just as well with apps installed in users context?

Regarding VCRedist - best is to blacklist them, heres my Blacklist: Brave.Brave Dropbox.Dropbox ElectronicArts.EADesktop EpicGames.EpicGamesLauncher Facebook.Messenger Google.Chrome Google.GoogleDrive IDMComputerSolutions,Inc.UltraEdit IG.IGClient Microsoft.DeploymentToolkit Microsoft.DevHome Microsoft.DotNet* Microsoft.Edge* Microsoft.Office Microsoft.OneDrive Microsoft.Teams* Microsoft.UI.Xaml.* Microsoft.VCRedist* Microsoft.VC++* Microsoft.WindowsADK Microsoft.WindowsAppRuntime.* Microsoft.WindowsSDK Mozilla.Firefox* Nvidia.GeForceNow SomePythonThings.WingetUIStore TeamViewer.TeamViewer* Ubisoft.Connect VideoLAN.VLC.Nightly

I am very curious why all of these apps should be blacklisted. I get the ones from MS (they'll get updated via MS Update), but I'm hoping WAU could be a way to increase security by avoiding scenarios where users keep outdated versions of any app (that often has a know exploit) for longer than it takes the winget repo to be updated.
Don't get me wrong, I'm all for blacklisting apps if there is a better alternative, but I want to fully understand why before I do.

[KnifMelti]

The author of the fork is aware of the old version issue and is now working on it:
Weatherlights#35

If the user task is installed it first runs in System context and then in User context, upgrading everything it finds installed needing an upgrade.
In the log you should see (for 1.7.8) when it's running in User context:
User logged on, get a list of installed Winget apps in System context...
Starting WAU in User context

Brave, Dropbox, Messenger, Google things, Firefox, etc, upgrades on its own.
Microsoft.WindowsADK/SDK I don't want to upgrade, too much dependencies for me.

The rest is applications that I've had problems with when using WinGet/WAU.
VCRedist has a habit of not erasing the uninstall sections (detection method of WinGet - used by proxy in WAU) when they get updated, resulting in update attempts ever after even if the latest version is installed and it can also mix x86/x64 versions of them resulting in error.
DevHome want to install something demanding administrating rights.
Etc, etc.. ...WinGet/WAU is what it is - not perfect (it takes a lot of tweaking depending on how the applications manifests are written).

[VerySlapp]

The author of the fork is aware of the old version issue and is now working on it: Weatherlights#35

Amazing!

If the user task is installed it first runs in System context and then in User context, upgrading everything it finds installed needing an upgrade. In the log you should see (for 1.7.8) when it's running in User context: User logged on, get a list of installed Winget apps in System context... Starting WAU in User context

It does indeed. Found the part you were referring to in the logs.

Brave, Dropbox, Messenger, Google things, Firefox, etc, upgrades on its own. Microsoft.WindowsADK/SDK I don't want to upgrade, too much dependencies for me.

That makes sense.

The rest is applications that I've had problems with when using WinGet/WAU. VCRedist has a habit of not erasing the uninstall sections (detection method of WinGet - used by proxy in WAU) when they get updated, resulting in update attempts ever after even if the latest version is installed and it can also mix x86/x64 versions of them resulting in error. DevHome want to install something demanding administrating rights. Etc, etc.. ...WinGet/WAU is what it is - not perfect (it takes a lot of tweaking depending on how the applications manifests are written).

Gotcha. Thank you for the list, and for saving me a lot of trial and error.

Two final questions, if you don't mind:

1. How do I add/edit the black list when deploying via the MS Store?

2. How do I get around the problem with needing elevated privileges when updating some apps for the users without admin privileges? Right now it is Microsoft.DevHome who's causing the problem, and by blacklisting it the problem will go away, but I imagine there will be more of them further down the line.
   These are the logs from the most resent attempt:
   

Also, thank you for all your answers and help.

[KnifMelti]

NB: my list contains wildcards * not useable in your WAU version.

1. In the ADMX backed profile you can edit the List:
   https://github.com/Weatherlights/Winget-AutoUpdate-Intune?tab=readme-ov-file#intune-integration-using-admx-backed-profiles
2. Make sure dependencies are installed in System context beforehand

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[soredake]

Not stale.

[Romanitho]

should be closed

[Jacinto27]

As what ? Unplanned ?

[Romanitho]

not sure to understand the point. @KnifMelti's reply is pretty clear I guess.

[VerySlapp]

NB: my list contains wildcards * not useable in your WAU version.

1. In the **ADMX** backed profile you can edit the **List**:
   https://github.com/Weatherlights/Winget-AutoUpdate-Intune?tab=readme-ov-file#intune-integration-using-admx-backed-profiles

Thank you for letting me know. So just remove the wildcards and it should be good?

2. Make sure **dependencies** are installed in **System** context beforehand

When you say "dependencies", are you referring to the Winget-AutoUpdate-aaS-app published from the Microsoft Store (New) or something in the policy settings pictured in the link you posted above?

[KnifMelti]

@Jacinto27:
The original question in this issue concerned the intended installation method for WAU. I believe it has been addressed: WAU should be installed as an elevated admin or system (here).

The installation sets up multiple tasks, with the primary one executing as SYSTEM whenever WAU is activated, either by a shortcut or a scheduled time/event.

@VerySlapp:
Regarding the wildcards; yes remove * and make sure a line contains the full winget application name.
Regarding dependencies; I'm referring to winget applications that have other dependencies.
Winget-AutoUpdate-aaS I don't know any more of.

I've implemented this solution for my company that serves over 5000 clients, and it's performing excellently. My approach includes avoiding the use of -InstallUserContext (Run WAU in user context too).
This is due to the fact that applications installed in the user context, such as Zoom and Visual Studio Code, are updated automatically upon use.
The result is less trouble with strange requirements.

[Jacinto27]

@KnifMelti I think the issue is addressed insofar as there being a guide on how to install as a system admin. But seeing how disperse the documentation is as well as how many questions people have about it, the issue of lack of clear documentation still remains IMO.