I'm having some trouble with a scheduled task that runs a PowerShell script under the system user context. The script needs to read two files located on a file share via a UNC path. I've tried setting permissions on both a standard Windows share and on a Synology NAS but haven't had any luck. I expected that granting permissions to DOMAINDomain Computers and/or Authenticated Users would suffice, but it hasn't worked out. Has anyone else encountered this issue with Windows 11 recently?
5 Answers
Have you tried running the script manually outside of the scheduled task? I often encounter issues like this, and adding logging at various points in the script can help identify where it fails. It might clarify whether it's a permissions issue.
It might help to explicitly add the computer's account (like computername$) to the NTFS and share permissions. If that solves your issue, consider creating a group to automatically include new computer accounts. Alternatively, setting up a GMSA account is ideal for this situation, though it might require command line configuration since you can't save passwords in scheduled tasks anymore. Also, have you considered using a logon script instead? It might accomplish what you need.
The SYSTEM user can't authenticate against the share directly. A better solution might be to create a new account in Active Directory specifically for this task and set the password to never expire. You can then link the scheduled task to run under this new account and give it the necessary NTFS permissions for the share.
If someone is starting from scratch with service accounts, GMSA would be a good consideration. It's frustrating how some organizations overlook them, but it's worth passing along the information.
You might want to add the actual computer account that's running the script to the share permissions. Since the SYSTEM account is local, it can't authenticate against shares on other machines.
But they mentioned adding domain computers. It seems like the problem stems from using the SYSTEM account instead of NetworkService.
If you want to use machine credentials for network access, set the task to run as NT AUTHORITYNetworkService. SYSTEM and LocalService accounts use anonymous authentication for network resources, which could be part of the issue.
It runs fine manually, but fails under the system context in the task scheduler. It's definitely a permissions issue on the share that I can’t pinpoint.