Windows Server 2022 Scheduled Task issue

Copper Contributor

I discovered yesterday that multiple scheduled tasks suddenly stopped working on a 2022 server. The tasks and the paths to the scripts they run have not changed in months. Last confirmed success was Feb 28th. The tasks run as an Active Directory account with permissions to run scripts on a network share, that hasn't changed either.

 

I get the error code FFFD0000 as "Last Run Result" and in the History tab it also gives the exit code 4294770688. By extensive research online these codes mainly point to:

* The script having an incorrect -File path.

* The -File path to the script is relative.

* The -File path does not include double quotes around it.

* Then path to powershell.exe needs to contain the full path, not just the file name.

None of these issues were affecting my tasks.

 

What is weird is that it works if I select "Run only when user is logged in". But not when I select "Run wether user is logged in or not" and enter the password so that it is stored within the task.

I have confirmed this with another high privilege AD account as well, on two separate 2022 servers, and it gives the same FFFD0000 and 4294770688 errors.

Exporting a task to 2016 or 2019 servers, and running them = success

 

Also:

It works if I run a cmd prompt as the user and then run the same command line:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File "\\my.domain\PathToScript.ps1"

It works if I run PowerShell ISE as the user, browse to the scripts and run them.

It also works if I move the script to the server locally, for example "C:\temp\script.ps1"

Tasks running as SYSTEM on the 2022 servers also work.

 

The 2022 servers are all patched with the March cumulative updates.

 

Can anyone else confirm this?

5 Replies

@MikaelZewgren 

We are experiencing some of the same strange behaviours when migrating scheduled tasks from server 2012r2/2016/2019 to server 2022. All patched with july 22 updates.
One Example:

We have a small powershell script connecting to a sql-database and exporting the results from a query to a .csv file. When we run the task on server 2012r2/2016/2019 with a service account in the domain the task is connecting to the db and presenting a .csv-file with the results. (we replicated this on three 2022 servers, none of which worked. and several 2016 and 2012 r2 servers are all working fine)

When we try the task on server 2022 we get this error in our logs:
invoke-sqlcmd : Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
the scheduled task is running as a domain user and we exported/imported the task on all the test-servers. When we login to the server as the domain service account and run the script manually it works on the 2022 servers.

It works if we select "only run when the user is logged on", but as soon as we change to "run whether the user is logged on or not" we get the same error as above.
Current workaround is running the task as "LOCAL SYSTEM" and granting the computer object access to the path where the .csv file is to be produced.

Do you have access to any Windows 10 or Windows 11 device?
If yes, then open start and search for feedback and open the Feedback Hub app and select Windows Server and report this issue and share steps to reproduce the problem, log files or any helpful information.

We are installing a new server 2022 and we can not get the task scheduler to run jobs.

We can not get it to run MSACCESS.EXE. I have tried Dos Batch files. 

Batch files run until they are exectuted via a trigger. Then they stop working again 1@MikaelZewgren 

I suggest file a bug report on this, as I mentioned earlier, you could file bug report for Windows Server using Feedback Hub app in Windows 10 or Windows 11.
Ok I had the same issue with a scheduled task writing to a Network share from a 2022 server. In the end I found if you use ADSIedit on the NAS object in AD and change the setting of msDS-SupportedEncryptionTypes to allow/include AES128/256 (there are 31 options) this link has all the types - https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-... then everything worked like a dream.