Deployment of Winget-AutoUpdate via Intune - all devices have AllSigned as Execution Policy by Intune configuration

[dlundahl91]

Dear Romaitho & team

I am in the situation where we used to sign all scripts downloaded from:
https://github.com/Romanitho/Winget-AutoUpdate/archive/refs/heads/main.zip
and then deploy it using Winget-AutoUpdate-Install.ps1 file.

----EDITED AFTER POSTING!!!!----
The reason we do this is that all of our devices in our tenant have the ExecutionPolicy set to AllSigned as we don't allow PowerShell scripts to run without signature.
----EDITED AFTER POSTING!!!! FINISHED----

Now with the .msi installer, our devices can no longer install WAU as the powershell scripts in the .msi are not signed.

I am making this new discussion to ask you if there is a way we can do this, without using the .msi installer, so that we can sign the scripts?

I was thinking of moving forward with this method:
----PREPARATION----
Download it all here:
https://github.com/Romanitho/Winget-AutoUpdate/archive/refs/heads/main.zip
Sign each and every powershell script in this folder "Winget-AutoUpdate"
Place everything in a .zip folder.

Make an export of:
HKLM\SOFTWARE\Romanitho with the desired settings we have. (we installed it in sandbox first, where the script signatures isn't an issue, so that we can export this file.

Make an export of this scheduled task:
Winget-AutoUpdate-Notify
----PREPARATION FINISHED----

----ACTUAL DEPLOYMENT----
Unzip the .zip folder into /Program Files
Import the Romanitho registry.
Import the Winget-AutoUpdate-Notify scheduled task.
----ACTUAL DEPLOYMENT FINISHED----

After installation we call the winget-upgrade script via Intune remediation daily, to check for updates.

Would this work the same way as if we installed it with the .msi file?

Images for discussion:

[AndrewDemski-ad-gmail-com]

I understand that security matters, but there might be a less ruthless method of securing PoSh scripting.
Lets think about dual approach
A. PowerShell execution policy set to 'RemoteSigned' instead of 'AllSigned'
B. AppLocker/ Application control defining which PoSh scripts can be executed at all.
secondary control mechanism makes decisions based on file hashes, file paths and certificates used for signing those files

That way every script either launched from netshare or downloaded from internet will still require local approval from AppLocer/AppControl solution.
And there you can have whitelisted location in which WAU PS1 files reside, i.e. INSTALLDIR.

That way you will maintain the same level of control (if not better) over scripts as in current setup.
The AllSigned execution policy prompts you before running scripts from publishers that you haven't yet classified as trusted or untrusted, right?
MS LInk

With B control you wont leave that option to users.

BR
AD

[dlundahl91]

Hi AD

Thanks for a fantastic thorough reply! I am writing this from phone, right before bed. 9:17 PM here now.

Our PoSh scripts are limited to only run if they are signed with our own codesigning certificate. So no other PoSh scripts are allowed to run at all.

Can you elaborate on how to allow INSTALLDIR to run scripts? I want to show your suggestion to our IT security team who has these strict policies. We deploy with Intune configuration to only allow signed powershell scripts, and only those signed specifically with our own codesigning certificate.

Thanks so much for all your help!

Can write more tomorrow! Right now my thumbs are tired from phone typing!

-Dan

[dlundahl91]

Windows defender application control we also use- and files deployed by Intune are automatically approved- all other files aren’t.

[AndrewDemski-ad-gmail-com]

Sure, that requires adding a path base rule to AppLocker, if WAU lands in program files, then path of scripts will match that entry and execution will be permitted.
More info here

[dlundahl91]

Hi @AndrewDemski-ad-gmail-com !

When we run the winget-upgrade like this:
conhost.exe --headless powershell.exe -NoProfile -File "C:\Program Files\Winget-AutoUpdate\winget-upgrade.ps1"

As user, from an Intune remediation, it updates the "updates" log file like this:
######################################

28-11-2024 CHECK FOR UPDATE (User context)

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

But then it seems like it stops..

Where as, if I write that command:
conhost.exe --headless powershell.exe -NoProfile -File "C:\Program Files\Winget-AutoUpdate\winget-upgrade.ps1"
Into powershell locally, as the user, it updates everything beautifully and writes it all into the log.

Any idea why our Intune can't initiate it properly as the user?

Thanks so much in advance!

--Dan

[dlundahl91]

It works well if Intune initiates the remediation as user with this command:
powershell.exe -WindowStyle Hidden -File 'C:\Program Files\Winget-AutoUpdate\winget-upgrade.ps1'

[KnifMelti]

conhost.exe --headless

This is just for not showing any windows at all, not even a flashing one

[AndrewDemski-ad-gmail-com]

I am more willing that I am going to admit, but i think that is is a result of several external factors taking part in cumulative configuration of you machine @dlundahl91.
In one hand we have and argument showing that WAU is being initiated and can operate without allocating any console and writes down some dat to log file, but in the other it seems that it stops abruptly.

The next line in the log could look like this:
WAU Policies management Enabled.

You would need to go through Event Log to see what was executed at that time, but before that a thing so-called deep scriptblock logging must be turned on.
While transcriptions can also be explicitly turned on and off using the Start-Transcript and Stop-Transcript cmdlets, you can enable script block logging only by using GPOs or by setting the appropriate registry key directly. Therefore, there is still a need for the older method, such as recording the output in your own scripts.
The relevant GPO setting is called Turn on PowerShell Script Block Logging and can be found under
Policies > Administrative Templates > Windows Components > Windows PowerShell.

Full instruction created by Wolfgang Sommergut can be found at 4sysops