Scheduled tasks got re-enabled after update

[andyat]

Looks like scheduled tasks got re-enabled after windows update/reboot. Is that expected?

Does script need to be run periodically to keep them disabled?

[abbodi1406]

It was not changed in my test 19045.6396 > 19045.6456

however, just to be safe, i guess you should run the script after installing any new Cumulative Update

[andyat]

Yes, my update was to 19045.6456. According to the task history, they got re-created during boot. And triggered shortly after on logon. Would be tricky to disable them before logon.

System Boot Time: 15-Oct-2025, 14:51:06
Logged: 15-Oct-2025 14:51:27 User "NT AUTHORITY\System" deleted Task Scheduler task "\Microsoft\Windows\Clip\ClipESUConsumer"
Logged: 15-Oct-2025 14:51:42 User "NT AUTHORITY\System" registered Task Scheduler task "\Microsoft\Windows\Clip\ClipESUConsumer"
Logged: 15-Oct-2025 14:51:42 User "NT AUTHORITY\System" updated Task Scheduler task "\Microsoft\Windows\Clip\ClipESUConsumer"
Logged: 15-Oct-2025 15:02:04 Task Scheduler launched "{xxx-xxx-xxx-xxx-xxx}" instance of task "\Microsoft\Windows\Clip\ClipESUConsumer" due to user "xxxxxx" logon.

[abbodi1406]

They have 15 minutes delay after logon i think, so it can be disabled after logon

[Sworddragon]

Shortly before local accounts didn't work anymore and I saw that this project had a script to disable the Consumer ESU scheduled tasks to e.g. possibly prevent the ESU-license to need to be renewed or such I thought already that this is very risky as in the past years I have seen several reports from other users and even experienced myself as soon as you try to tamper with Windows's system-configuration files (can be system services, scheduled tasks, and even some group policies, etc.) Windows might try at some point to revert your changes if it desires that the user should not tamper with them. And thus I almost expected that the next cumulative update will cause issues here and it might not be even limited to just installing them. So relying on disabling the Consumer ESU scheduled tasks will be always risky.

But at that time I also thought about opening a feature request here but decided later to delay it eventually after the first 60 day check kicks in. The idea was that rather than tampering with the Consumer ESU scheduled tasks the script could provide an option to install (and uninstall respectively) itself as scheduled task (since those are normally safe from Windows trying to tamper with stuff) that would run after the Consumer ESU scheduled tasks and as a safety on every boot and every 24 hours (might require in general a mutex at the start of the script to prevent races for several concurrent system-/user-initiated script calls). It would then check if the ESU-enrollment isn't valid anymore and respectively would gather a new ESU-license with the same options again.

However, the last point is not reliable possible anymore now that local accounts don't work anymore. But there might be a better solution anyways: When installing the script as scheduled task it would create its own license storage e.g. somewhere within %APPDATA% and keep a copy of the ESU-license the system is being enrolled with and once it notices the Consumer ESU scheduled tasks caused issues here it will just reapply this license. But I don't know what the Consumer ESU scheduled tasks are exactly doing, e.g. if they just delete your ESU-license or if they use a more advanced form of invalidation. So I can't tell if this would work but maybe abbodi1406 can evaluate this better.

[abbodi1406]

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ClipESUConsumer.exe" /v Debugger /t REG_SZ /d systray.exe /f
🚶