Windows 11 22H2 upgrade breaks "Run whether user is logged on or not" scheduled tasks

Been there, done that -- no help. Does seem related to Credential Guard (not LSA, since that was already running before 22H2), but it is something deeper than just the user's current key.

I've found workarounds with less impact (to me) than deleting/recreating my profile. But I want it to WORK RIGHT! Be nice if there was some procedure to just fully "reset" whatever part of credential store / credential manager / credential guard is screwed up.

I'm not affected by this issue anymore (I created new accounts to get my task to fire on startup) so I can't verify if this helps, but here are a couple of other things to look into if you upgraded from 21H2 to 22H2 and have an affected account/machine:

Instead of creating a new account, reset the password for the affected user and then see if the Scheduled Task is able to run.

Also have a look at an article that discusses LSA Protection being enabled by default in Windows 11 22H2. It's not directly related to the issue with Scheduled Tasks, but the problem sure looks familiar:

https://kb.vmware.com/s/article/90938?lang=en_US

Starting with Windows 11 22H2 Microsoft changed the default setting for the LSA "RunAasPPL" to enable.

 

This setting will require administrator UAC login for the installation, if the application installation context is "User" and the Admin Privileges selection is "YES".

Additional data as follow-up to previous post....

In the task's history, after the task with stored password fails to launch the following two events are logged in TaskScheduler history:

ID 110, Info, "Task triggered by user"

ID 101, Error, "Launch Failure"

Task Scheduler failed to start <task name> task for user <username>. 

Additional Data:  Error Value:  2147943726

The following article about known issues with Credential Guard is dated 12/15/2022. About 3/4 down the page, the first item under "Previous known issues that have been fixed", a substantially similar issue is presented (task fails to run, same error value as shown above). The article claims that problem was fixed by a Windows 10 Cumulative Update in 2017, so perhaps this is an "old issue" that has returned...

Windows Defender Credential Guard - Known issues | Microsoft Learn

I can confirm the same observations as @DanM... A machine loaded fresh with Win11 22H2 works fine. A machine upgraded from Win11 22H1 to 22H2 FAILS. Strangely, I also found that a machine upgraded from Win 10 to Windows 11 22H2 is also working fine.

I am seeing the problem only with "existing accounts" on a machine upgraded from Win11 21H2 --> 22H2. The tasks don't run when a "stored password" is used, whether via schedule or "on demand". Without the stored password, the task runs but can't access network/server resources.

On a machine exhibiting the issue, I did the following simple test to reproduce the issue:

• Created a "test.bat" file with two lines, "timeout /T5" and "exit 0", located where all users have access.
• Created a scheduled task that runs "cmd.exe /c <path>\test.bat" using my user account (member of administrators).
• In all the following tests, the "Run with highest privileges" makes no difference -- same results with it set or cleared.
• With "Run only when user is logged on" set:
  • Right-click task, "Run": Status changes to "Running", cmd window pops up, waits 5 sec, disappears. Clicking "Refresh" changes Status back to "Ready", and last result shows success (0x0). ALL GOOD.
• With "Run whether user is logged on or not" set, and "Do not store password" set:
  • Right-click task, "Run": Status changes to "Running". (No cmd window appears.) Clicking "Refresh" repeatedly shows "Running" for 5s, then status changes to "Ready" and last result shows success (0x0). ALL GOOD.
• With "Run whether user is logged on or not" set, and "Do not store password" cleared (and password entered when saving task):
  • Right-click task, "Run": NOTHING. Status does not change to "Running". No cmd.exe process runs. The "Run" action is simply ignored! The task will not run using my UserID when "Do not store password" is cleared (i.e., a Stored Password).
• Used mmc "local users and groups" to create a new account named "TestUser" with password and member of Administrators (needed for "logon as batch file" rights). Never logged into this account interactively; just created the account, set a password and group membership.
• Changed the above scheduled task to run using the new "TestUser" account and entered the password for TestUser when saving.
• Task still has "Run whether user is logged on or not" set, and "Do not store password" cleared (i.e., a Stored Password).
  • Right-click task, "Run": Status changes to "Running", then after 5s a Refresh shows "Ready" and last result shows success (0x0). ALL GOOD. The task runs fine with a "stored password" from a NEW user account.

The issue appears to be with "existing accounts" on Win11 machines upgraded from 21H2 to 22H2. New accounts work fine, but old accounts CANNOT RUN A TASK WITH A STORED PASSWORD.

"You do not have Manage Auditing rights" is a different error than "Access Denied" so you might be making progress.

First, If you have UAC Enabled, turn it off fully to see if that's your issue:

reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f

Now, if you're running RoboCopy with /COPYALL, change it to /DATSO to skip audit rights.

-OR-

Add the necessary rights for the user in gpedit.msc:

> Computer > Windows Settings > Security Settings > Local Policies > User rights > Manage auditing and security log