I will do some research on this and thank you. How ever Microsoft as a company should take care of this.
Windows 11 22H2 upgrade breaks "Run whether user is logged on or not" scheduled tasks
I have a number of scheduled tasks with the "Run whether user is logged on or not" option set, with the default setting of storing the password for the account.
Everything was running fine, until the 22H2 update.
Now such tasks won't start, yielding
"Task Scheduler failed to start "xxx" task for user "yyy". Additional Data: Error Value: 2147943726.
Re-entering the password for the (local) user account does not help.
If I check the "Do not store password" option the task can start, but this prevents the task from accessing network resources.
Repro'ed on two machines, so doesn't feel like a configuration issue.
Any clue?
Windows for home | Windows 11 | Accounts, profiles, and login
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
63 answers
Sort by: Oldest
-
Anonymous
2023-02-08T22:12:24+00:00 -
Anonymous
2023-02-19T18:58:49+00:00 I found the same issue for Windows 2019 after update of December22 patch, which troubles all applications jobs running with domain accounts are not working..any fix or solutions..???
I could see it's reported on NOV22 @Microsoft- any final solutions to fix other than we still checking
-
Anonymous
2023-02-19T22:34:48+00:00 I am glad so many are reporting this issue. Microsoft seems to need a big push to respond. Still need a fix for that latest feature update 22H2. .
-
Anonymous
2023-02-23T11:13:55+00:00 Still broken. Any update on this? Any1 care to either confirm or deny the issue? Learn to communicate MSFT!
-
Anonymous
2023-02-28T23:40:29+00:00 Just updated to 22H2 and now have BROKEN scheduled tasks. I need tasks to run "whether user is logged on or not", AND I need those tasks to have access to network resources (so the "Do not store password" option, while it allows the task to run, does not support the task's requirements).
I suspect this may be related to either LSA Protection or CredentialGuard, which (for most machines) was auto-enabled with 22H2 update. Before I dig into that, has anyone else already tried disabling LSA Protection and/or Credential Guard to see if that solves the issue?
My current workaround: I added explicit "net use \server\share PASSWORD" into the batch files to connect network resources. The scripts then work with the "Run whether user is logged on or not" and "Do not store password" combination. Obviously, hard-coding passwords for network shares in a script is not a good idea. Microsoft has shot us in the foot here -- their attempt at increasing security on 22H2 is forcing me into less security (plain text passwords in batch files) on 22H2!