After extensive testing across Windows Server 2016-2022 and Windows 10/11, I've identified these essential permissions for a non-admin scheduled task account:

1. Log on as a batch job (SeBatchLogonRight)
2. Read/execute permissions to:
   - The target script/executable
   - %SystemRoot%\System32\Tasks (task definition storage)
   - %SystemRoot%\System32\Tasks\YourTaskFolder (if applicable)
3. "Log on as a service" right (SeServiceLogonRight) if running as service

First, set the account permissions using Local Security Policy (secpol.msc):

# PowerShell alternative for SeBatchLogonRight
Import-Module ActiveDirectory
$user = "automatictask"
$computer = $env:COMPUTERNAME
$sid = (Get-ADUser $user).SID
$tmp = [System.IO.Path]::GetTempFileName()
secedit /export /cfg $tmp
(Get-Content $tmp).Replace("SeBatchLogonRight = ", "SeBatchLogonRight = $sid,") | Set-Content $tmp
secedit /configure /db secedit.sdb /cfg $tmp
Remove-Item $tmp

For the batch file and its dependencies:

# Grant read/execute to specific folder
icacls "C:\scripts\automation" /grant "automatictask:(RX)" /t
# For the Task Scheduler store
icacls "%SystemRoot%\System32\Tasks" /grant "automatictask:(R)"
icacls "%SystemRoot%\System32\Tasks\YourTaskName" /grant "automatictask:(R)"

For maximum security while maintaining functionality:

• Create a dedicated OU in AD with restricted GPOs
• Set "Deny logon locally" and "Deny logon through RDP"
• Apply Process-Level ACLs if using sensitive executables

When tasks fail with "unable to start":

# Check effective permissions
accesschk.exe /accepteula -uvqr automatictask
# Audit logon attempts
auditpol /set /subcategory:"Logon" /failure:enable /success:enable
# Then check Event Viewer Security logs for 4625 events

Remember that some legacy applications may require additional permissions due to COM/DCOM requirements or registry access.

When configuring a Windows Scheduled Task to run under a restricted account, you'll often encounter the frustrating "unable to start" error. The root cause typically comes down to missing specific permissions rather than needing full administrator access.

Through testing and Microsoft documentation analysis, these are the minimum required permissions for a user to execute scheduled tasks:

1. Log on as a batch job (SeBatchLogonRight)
2. Read/Execute permissions on:
   - The task's executable/batch file
   - C:\Windows\System32\Tasks (task definition storage)
   - C:\Windows\System32\Tasks\YourTaskFolder (if applicable)
3. Read permissions on:
   - C:\Windows\System32 (for task scheduler components)

Here's how to configure these permissions programmatically using PowerShell:

# Grant batch logon rights
$user = "DOMAIN\automatictask"
$policy = "SeBatchLogonRight"
$tmp = [System.IO.Path]::GetTempFileName()
secedit /export /cfg $tmp
(Get-Content $tmp).replace("SeBatchLogonRight =", "SeBatchLogonRight = $user") | Out-File $tmp
secedit /configure /db secedit.sdb /cfg $tmp
Remove-Item $tmp

# Set file system permissions
$acl = Get-Acl "C:\path\to\your\script.bat"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($user, "ReadAndExecute", "Allow")
$acl.SetAccessRule($rule)
Set-Acl "C:\path\to\your\script.bat" $acl

Error: "The task image is corrupt or has been tampered with"
Fix: This often indicates missing read permissions on the task definition XML file in C:\Windows\System32\Tasks

Error: "The specified account name is not recognized"
Fix: Ensure the account exists and you're using the correct format (DOMAIN\user or .\user for local accounts)

For enterprise environments, consider these additional best practices:

# Create dedicated service account with:
- Password never expires
- User cannot change password
- Account is disabled for interactive login
- Account is member of no groups except possibly "Users"

To confirm your permissions are correctly set:

1. Run whoami /priv in a test script to verify batch logon right
2. Check Security logs (Event ID 4624) for successful logon events
3. Use Process Monitor to identify any permission-related access denials