Automatic run of Winget-Upgrade.ps1 as remediations in Intune

[dlundahl91]

Hey experts!

Still loving this product, you are absolute superstars in my eyes. Thanks so much!

In our company we run the Winget-Upgrade.ps1 file with an Intune as SYSTEM to update all of our packages. (we only have system packages, and we have been avoiding user packages as much as possible, as we had troubles getting the user packages updated.)

My issue, and reason for creating this discussion, is that we might no longer be able to avoid user packages, as our development team needs a piece of software, which is only available as user.

If we run the Winget-Upgrade.ps1 as the USER, initiated via Intune(or locally on the PC via powershell) it comes with a lot of errors, regarding not having access to the Logs folder.
We can make sure that access is granted via our remediation, so that isn't an issue.

However, when the script is launched as user, it also tries to upgrade all of the system packages, and that causes a lot of UACs for our users, that they cannot log into/approve.

Is there a way to run the Winget-Upgrade.ps1 file as user, and automatically only install user packages - and avoid/skip system packages?

Thanks a lot in advance!!

Br

[AndrewDemski-ad-gmail-com]

Hej @dlundahl91,

I could suspect that we are talking about VScode and similar apps :)

If I understand you right, the problem is caused by lack of diversification* of excluded apps list based on execution context to avoid situation in which any given setup launched on behalf of current user won't trigger UAC prompt?

*diversification

context	description
Machine/system/service account	obvious lack of access to user packages, so only machine context is used
(the rest)	by default user packages narrowed down to current user minus apps from context above

Some setups can work in user and machine contexts, some have a logic which switches the INSTALLDIR from program files to appdata of current user on the flight.

You may need to suppress UAC prompts entirely to trigger such behavior.

These registry settings work in Windows 10+ and land in [HKY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

Further details:
ConsentPromptBehaviorAdmin
EnableLUA
PromptOnSecureDesktop
ConsentPromptBehaviorUser

[dlundahl91]

Hi @AndrewDemski-ad-gmail-com

It seems you understand me correctly! I am not sure however that I understand what you are writing in the end - is this something I can utilize?
In this case it is about ID: postman.postman - it seems there are no --scope machine packages, so we have to go with the user package.
(Unless you subscribe to their Enterprise license, in which you do get an .msi installer, but not the lower subscriptions - and we will go for the basic subscription)

Thanks a lot in advance for all help!
I really appreciate your time.

/D

[AndrewDemski-ad-gmail-com]

I edited my 1st response a moment ago..
You may block setups from attempting to raise own privileges and so on via GPO.

[dlundahl91]

Hi @AndrewDemski-ad-gmail-com

Is this a general windows thing?
I was/am looking for a way only to do this regards winget-upgrade installations. Is this not possible?

/D

[AndrewDemski-ad-gmail-com]

Pretty much yes, it is a windows thingy.

Executable and sometimes MSI can work both in user and machine contexts.
setups must have proper manifests embedded or some popups will be generated.
By design setups often try to reach the highest priv context to install everything to program files, if that fails, they switch to user context and deploy everything into profile.
(with some weird mutations like old MSI with teams which used to unpack itself to PF and later installs into user profile vie autorun in registry).

As common sense dictates, users should not be forced to perform administrative tasks at all.
Preventing UAC prompts for consent at all for them is a wise choice, I've seen it in every company I worked for since 2011.

Screenshot taken from MS page

[AndrewDemski-ad-gmail-com]

As much as I wish for WAU to provide solutions to as many daily problems of IT world, some things - such as compliance/regulations/internal processes and procedures - are out of scope.
Change of any group policy on a workstation is not a trivial thing. It should never be done lightly.

I that is the solution for UAC prompts during WAU upgrade cycle, then WAU does not need to be modified IMHO.