[Bug]: WAUv2 installer not creating scheduled tasks if installed under SYSTEM user

[newmrac]

The problem

Hi. To mass deploy WAU on user's computer I use a remote management tool that executes cmd commands under NT Authority\SYSTEM account on remote computers (ESET Agent cmd command). No issues with deploying WAUv1. After changing the installer to MSI-based, I found an issue: the installer doesn't create Scheduled tasks (and without them, WAU don't start even with a manual start). My simple script to install (and uninstall v1):

powershell.exe -noprofile -executionpolicy bypass -file "C:\ProgramData\Winget-AutoUpdate\WAU-Uninstall.ps1"
cd c:\windows\temp
del WAU.msi /F
c:\windows\system32\taskkill.exe /im curl* /f
C:\windows\System32\curl.exe https://github.com/Romanitho/Winget-AutoUpdate/releases/download/v2.0.0/WAU.msi -o WAU.msi -H "Connection: close" -L 
if not exist WAU.msi goto End
msiexec /i WAU.msi /qn LISTPATH=GPO USERCONTEXT=1 DESKTOPSHORTCUT=0 STARTMENUSHORTCUT=1 UPDATESINTERVAL=Weekly UPDATESATTIME='06:00:00'
:End
del c:\windows\temp\WAU.msi /F

If command msiexec /i WAU.msi /qn started under regular users, scheduled tasks are created normally. If started under SYSTEM account, installation finishing without creating of scheduled tasks.

What version of WAU has the issue?

WAU 2.0.0

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

Windows 11 24H2

What version of winget are you using?

1.8.1911

Log information

No response

Additional information

How to reproduce easily:

1. Download Sysinternals Pstools, unpack.
2. run psexec to switch to SYSTEM user: in terminal use: .\PsExec64.exe /s /i cmd
3. In the new terminal window check current user by command: whoami. It should be nt authority\system
4. From this terminal start silent installation of WAUv2: msiexec /i WAU.msi /qn
5. As a result: WAUv2 was installed, scheduled tasks are absent, WAUv2 is completely broken.

[Romanitho]

Strange. WAU self-update updates WAU under the system context. No issues so far. I also use SCCM and Intune to push the MSI version with system context. No issues either.

[KnifMelti]

The culprit here is UPDATESATTIME='06:00:00' Either without single qoutes or with double qoutes will make it work as intended.

Tested as SYSTEM, no problem here.

EDIT: When testing your original single qoutes string as SYSTEM the tasks failed in creation it's a CMD thing

[newmrac]

Yes, you are right. Double quotes/removing parameters fixes installation. I tested without any parameters and with them, but it didn't work. And now it is working. It's really strange. Thank you for fast help!

[Romanitho]

You can even remove it since "6am" is the default value. Thanks, @KnifMelti, for spotting that.

[newmrac]

You can even remove it since "6am" is the default value. Thanks, @KnifMelti, for spotting that.

I used exactly setting of 06:00:00 instead of 6am, because of the bug with time format in version 1. It was ignored: https://github.com/Romanitho/Winget-AutoUpdate/issues/583

[Romanitho]

Oh I see. Still not fixed? I'll have to check that.

[ITistheworst]

Seem to be getting the same issue here, deployed via intune from a win32app with the following install command

msiexec /i "WAU.msi" /qn RUN_WAU=NO DISABLEWAUAUTOUPDATE=0 USEWHITELIST=1 USERCONTEXT=1 BYPASSLISTFORUSERS=0 DESKTOPSHORTCUT=0 STARTMENUSHORTCUT=0 NOTIFICATIONLEVEL=Full UPDATESATLOGON=1 UPDATESINTERVAL=Never DONOTRUNONMETERED=0

No scheduled tasks seem to get configured on the deployed machines.

[AndrewDemski-ad-gmail-com]

Hi, I managed to recreate the problem if WAU_UpdatesAtTime value in HKEY_LOCAL_MACHINE\SOFTWARE\Romanitho\Winget-AutoUpdate was left from previous attempt to install from WAU.msi with UPDATESATTIME='06:00:00' commandline argument.

In such condition, playing rounds with commandline (changing to double quotes etc) did not help at all. Shouldn't wrapper/MSI be dropping the reg key in HKLM during installation? Just to be sure that we start from clean slate?

[Romanitho]

We wanted to migrate the settings how much as possible.

Should be ok for next releases: #740

[github-actions[bot]]

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

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.