When dealing with Windows scheduled tasks, permission issues often arise from subtle configuration changes or credential updates. In your case, three accounts are involved:

Author: A
Run As: B
Current User: C

Despite all being administrators, Windows Server 2008 implements strict security policies for task scheduler that go beyond simple group membership checks.

First, verify the actual permissions with PowerShell:

$task = Get-ScheduledTask -TaskName "YourTaskName"
$task.Principal

This will show the exact security context the task expects. Common red flags include:

• Explicit "Run whether user is logged on or not" setting
• Changed password for account B
• Outdated security tokens

Try resetting the Run As credentials entirely:

# Using schtasks.exe (works on Server 2008)
schtasks /change /tn "YourTaskName" /ru "DOMAIN\B" /rp "newPassword"

If you don't know the password, you'll need to:

1. Open Task Scheduler as Administrator
2. Right-click the task → Properties
3. Switch to the General tab
4. Click "Change User or Group" and re-enter B's credentials

For deeper investigation, check the actual security descriptor:

# Requires admin rights
$task = Get-ScheduledTask -TaskName "YourTaskName"
$sd = $task.GetSecurityDescriptorSddlForm()
$sd

Look for these critical ACEs (Access Control Entries) in the output:

• "NT AUTHORITY\SYSTEM" - Full Control
• "BUILTIN\Administrators" - Full Control
• Your specific user account - Read/Execute

From my experience with Server 2008, these solutions work 90% of the time:

# Solution 1: Re-register the task completely
Unregister-ScheduledTask -TaskName "YourTaskName" -Confirm:$false
Register-ScheduledTask -Xml (Get-Content "C:\path\to\task.xml" | Out-String) -TaskName "YourTaskName"

# Solution 2: Temporary workaround - run as SYSTEM
$task = Get-ScheduledTask -TaskName "YourTaskName"
$task.Principal.UserId = "NT AUTHORITY\SYSTEM"
$task | Set-ScheduledTask

To avoid future issues:

• Use managed service accounts where possible
• Document all task credentials in a secure vault
• Implement regular permission audits with this script:

Get-ScheduledTask | ForEach-Object {
    [PSCustomObject]@{
        TaskName = $_.TaskName
        Author = $_.Author
        UserId = $_.Principal.UserId
        LogonType = $_.Principal.LogonType
    }
} | Export-Csv -Path "C:\audit\scheduled_tasks.csv"

---

This error typically occurs when there's a mismatch between the scheduled task configuration and the actual permissions assigned to the user accounts involved. Even when all accounts are in the Administrators group, Windows Scheduled Tasks have specific security requirements that might cause this behavior.

For a scheduled task to run properly, these elements must align:

• Task creator permissions (Account A)
• Run-as account permissions (Account B)
• Current user permissions (Account C)
• Task Scheduler service configuration

1. Verify Task Security Options

Check the task's security options by running this PowerShell command:

Get-ScheduledTask -TaskName "YourTaskName" | Select-Object *

Pay special attention to the Principal property, which contains the security context.

2. Reset the RunAs Account

Sometimes simply re-entering the password can resolve the issue. Use this PowerShell snippet:

$task = Get-ScheduledTask -TaskName "YourTaskName"
$task | Set-ScheduledTask -User "Domain\B" -Password "yourpassword"

3. Check Local Security Policy

Run secpol.msc and navigate to:

Local Policies > User Rights Assignment > Log on as a batch job

Ensure all relevant accounts (A, B, and C) are listed.

4. Task Scheduler Service Account

The Task Scheduler service itself needs proper permissions. Check its configuration:

sc qc Schedule

It should typically run as LocalSystem.

5. Advanced Permission Check with PowerShell

This script verifies all security aspects of a task:

$taskName = "YourTaskName"
$task = Get-ScheduledTask -TaskName $taskName
$principal = $task.Principal

Write-Host "Task Security Report for: $taskName"
Write-Host "RunAs User: $($principal.UserId)"
Write-Host "Logon Type: $($principal.LogonType)"
Write-Host "Run Level: $($principal.RunLevel)"

# Check if current user has permissions
$currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
if ($principal.UserId -ne $currentUser) {
    Write-Warning "Current user ($currentUser) doesn't match RunAs user ($($principal.UserId))"
}

Password Changes

If Account B's password changed since task creation, the stored credential becomes invalid. Update it via:

schtasks /change /tn "YourTaskName" /ru "Domain\B" /rp "newpassword"

UAC Considerations

Even administrators might face restrictions due to User Account Control. Try:

$task.Principal.RunLevel = "Highest"
$task | Set-ScheduledTask

When all else fails, recreate the task with this PowerShell template:

$action = New-ScheduledTaskAction -Execute "program.exe" -Argument "params"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
$principal = New-ScheduledTaskPrincipal -UserId "DOMAIN\B" -LogonType ServiceAccount -RunLevel Highest

Register-ScheduledTask -TaskName "NewTask" -Action $action -Trigger $trigger -Settings $settings -Principal $principal

Check the Task Scheduler operational log in Event Viewer for detailed errors:

Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" | Where-Object {$_.Id -eq 101} | Format-List