When creating a scheduled task to run on system startup with the Run whether user is logged in or not option, many administrators encounter the frustrating error 2147943711. This error typically appears in Task Scheduler history with messages about failed logon attempts, even when you've specifically selected Do not store password.

# Common error pattern in event logs
Event ID 104: Task Scheduler failed to log on
Failure occurred in "LsaLogonUser"
Error Value: 2147943711

Despite selecting "Do not store password", Windows still attempts to authenticate the task using credentials. This behavior stems from the underlying security architecture where:

• Interactive logons require valid credentials
• Non-interactive tasks still need authentication context
• The "Do not store password" option doesn't mean "no credentials"

Here are three proven approaches to resolve this issue:

1. Using SYSTEM Account

The most reliable method is to configure the task to run as NT AUTHORITY\SYSTEM:

schtasks /create /tn "SystemStartupTask" /tr "powershell.exe -File C:\\scripts\\startup.ps1" 
/sc ONSTART /ru "NT AUTHORITY\\SYSTEM" /rp "" /rl HIGHEST /f

Key points:

• No password required for SYSTEM account
• Has highest privileges by default
• Works even when no user is logged in

2. Service Account with Password

If you must use a specific account:

# Create the task with stored credentials
$password = ConvertTo-SecureString "YourPassword" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential ("DOMAIN\\ServiceAccount", $password)

Register-ScheduledTask -TaskName "ServiceStartupTask" 
-Trigger (New-ScheduledTaskTrigger -AtStartup) 
-Action (New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File C:\\scripts\\service_start.ps1") 
-User $credential.UserName -Password $credential.GetNetworkCredential().Password 
-RunLevel Highest

3. Using Group Policy Preferences

For domain environments, GPP startup scripts avoid these authentication issues:

# Sample GPO configuration (command line equivalent)
gpupdate /force

• Always check Task Scheduler Operational logs in Event Viewer
• Verify account permissions with whoami /priv
• Test with simple commands before complex scripts
• Consider using Windows Services for critical startup processes

For enterprise environments, consider this reusable function:

function Register-StartupTask {
    param(
        [string]$TaskName,
        [string]$ScriptPath,
        [pscredential]$Credential = $null
    )

    $trigger = New-ScheduledTaskTrigger -AtStartup
    $action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File "$ScriptPath""

    if ($Credential) {
        Register-ScheduledTask -TaskName $TaskName -Trigger $trigger -Action $action 
        -User $Credential.UserName -Password $Credential.GetNetworkCredential().Password -RunLevel Highest
    }
    else {
        Register-ScheduledTask -TaskName $TaskName -Trigger $trigger -Action $action 
        -User "NT AUTHORITY\SYSTEM" -RunLevel Highest
    }
}

# Usage examples:
# With credentials
# $cred = Get-Credential
# Register-StartupTask -TaskName "EnterpriseStartup" -ScriptPath "C:\scripts\enterprise_init.ps1" -Credential $cred

# Without credentials (SYSTEM)
# Register-StartupTask -TaskName "SystemStartup" -ScriptPath "C:\scripts\system_init.ps1"

When configuring scheduled tasks to run at system startup without requiring user login, many administrators encounter the frustrating Error 2147943711. This typically manifests when trying to execute PowerShell scripts or other processes during system boot.

The error appears in Task Scheduler history with multiple event IDs (101, 104, 311) pointing to authentication failures. Despite selecting "Run whether user is logged in or not" and "Do not store password", the system still attempts password-based authentication.

// Typical error chain observed:
Event ID 104: LsaLogonUser failure
Event ID 311: LUAIsElevatedToken failure  
Event ID 101: Task startup failure

For successful startup execution without stored credentials, three critical settings must align:

1. "Run whether user is logged in or not" checked
2. "Do not store password" checked (forces non-interactive mode)
3. Principal account must have "Log on as a service" right

The most reliable approach combines proper task configuration with system policy adjustments:

# Create task with correct parameters
schtasks /create /tn "SystemStartupTask" /tr "powershell -ExecutionPolicy Bypass -File C:\\scripts\\startup.ps1" /sc ONSTART /ru "NT AUTHORITY\\SYSTEM" /rp /rl HIGHEST /f

# Alternative using SYSTEM account
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\\scripts\\startup.ps1"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable -DontStopOnIdleEnd -RunOnlyIfNetworkAvailable
Register-ScheduledTask -TaskName "SystemStartupTask" -Action $action -Trigger $trigger -Settings $settings -User "NT AUTHORITY\\SYSTEM" -RunLevel Highest

Grant necessary rights through Local Security Policy (secpol.msc):

# Using PowerShell to grant service logon rights
$tmp = [System.IO.Path]::GetTempFileName()
secedit /export /cfg $tmp
(Get-Content $tmp).Replace("SeServiceLogonRight = ", "SeServiceLogonRight = YourDomain\\ServiceAccount") | Set-Content $tmp
secedit /configure /db secedit.sdb /cfg $tmp
Remove-Item $tmp

• Check Task Scheduler history for post-configuration errors
• Verify script execution through log files or event markers
• Test with system reboots to confirm consistent startup behavior