EDIT: The Task Scheduler in OS versions past Windows 2016 does not explicitly state that the account it will use is a domain account. The domain will not be listed, but it will still be treated as a domain account. Strange design choice.
EDIT: What seemed to be a permissions problem (file cannot be found, cannot save a file) was actually a problem with a system folder not existing. Office automation requires a folder named Desktop to be created in system folders to perform background functions. The solution can be found here: https://stackoverflow.com/a/29939823/3516585
I'm upgrading an old server (Windows Server 2012 R2) to a new virtual server (Windows Server 2022), and I'm having trouble creating scheduled tasks.
On the old server, we have 3 scheduled tasks that use a domain service account to run 3 programs at different intervals throughout the day. However, when I try to set the "run as" account to "domain\svcaccountname", it changes to "svcaccountname" like it's trying to use a local account with that name.
I've checked the local as well as DC group policy (both old and new server are in the same groups, so same group policy):
- "Deny log on as batch job" is not denying any account.
- "Log on as a batch job" is allowed for "domain\Domain Admin Group", which the service account is a member of.
- "Obtain an impersonation token for another user in the same session" is allowed for "domain\Domain Admin Group", which the service account is a member of.
This may not be relevant, but two of the tasks are .NET applications, which function perfectly when ran directly from the studio code on the server, or from the .EXE on the server. They do not function when running from scheduled task, and the error I get is a permission error due to the account not actually existing.