When configuring a Scheduled Task to execute under the NETWORK SERVICE account, you'll encounter the infamous "Access is denied" error. This occurs because by default, the Task Scheduler UI doesn't provide NETWORK SERVICE as a selectable option, and manual entry results in permission issues.

Many developers need scheduled jobs to access network resources without creating dedicated domain accounts. NETWORK SERVICE (NT AUTHORITY\NETWORK SERVICE) is attractive because:

• It's a built-in account requiring no password management
• It provides network authentication capabilities
• It's more secure than using SYSTEM for network operations

The key is to create the task programmatically using PowerShell with explicit permissions:

# Create task action
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File \\server\share\script.ps1"

# Create task principal
$principal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\NETWORK SERVICE" 
    -LogonType Password 
    -RunLevel Limited

# Register the task
Register-ScheduledTask -TaskName "NetworkServiceTask" 
    -Action $action 
    -Principal $principal

For remote share access, you'll need to configure these additional steps:

1. Grant NETWORK SERVICE read/write permissions on the remote share
2. Add the computer account (COMPUTERNAME$) to the share permissions
3. Configure delegation if accessing resources across servers

For enterprise environments, consider gMSAs instead:

# Example using gMSA
$gMSA = Get-ADServiceAccount -Identity 'svc_gMSA'
$principal = New-ScheduledTaskPrincipal -UserId "$($gMSA.SamAccountName)$" 
    -LogonType Password 
    -RunLevel Highest

If you still encounter problems:

• Verify the task actually runs as NETWORK SERVICE with: whoami /priv in your script
• Check Event Viewer for SCHTASKS errors (Event ID 100-110 range)
• Test with a simple batch file before complex scripts

When configuring Scheduled Tasks in Windows, many administrators encounter the "Access is denied" error when attempting to use the built-in NETWORK SERVICE account. While SYSTEM account tasks work seamlessly, NETWORK SERVICE presents unique authentication challenges that require special configuration.

The core issue stems from how Windows handles authentication for service accounts:

# Typical task creation that fails
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "\\server\share\script.ps1"
$principal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\NETWORK SERVICE" -LogonType ServiceAccount
Register-ScheduledTask -TaskName "NetworkServiceTask" -Action $action -Principal $principal

To properly authenticate with remote resources:

1. Create a dedicated local user account with matching credentials on both systems
2. Configure constrained delegation for the NETWORK SERVICE account
3. Use explicit credential objects in your scripts

For PowerShell tasks that need network access:

$cred = New-Object System.Management.Automation.PSCredential (
    "DOMAIN\serviceaccount",
    (ConvertTo-SecureString "Password123" -AsPlainText -Force)
)

Invoke-Command -ComputerName remote-server -Credential $cred -ScriptBlock {
    # Access network resources here
    Copy-Item -Path "\\remote\share\file.txt" -Destination "C:\temp\"
}

For enterprise environments, gMSAs provide a better solution:

# Create gMSA (requires AD module)
New-ADServiceAccount -Name "SvcTaskAccount" -DNSHostName "svctask.domain.com"

# Install on target server
Install-ADServiceAccount -Identity "SvcTaskAccount"

# Use in scheduled task
$principal = New-ScheduledTaskPrincipal -UserID "DOMAIN\SvcTaskAccount$" -LogonType Password

For legacy systems where modification is permitted:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AuthForwardServerList"=dword:00000001