It is quite simple to set up a task to run as a SYSTEM, but when setting it to NETWORK SERVICE it show "Access is denied" error message.

Is there any way to get this working? (The problem is that I don't want to create a new domain user for that task and I need to access a remote share from this task.)


6 Answers 6


I asked this same question. Fortunately RyanRies was able to provide a correct answer.

In Windows Server 2003 you cannot run a scheduled task as NT AUTHORITY\NetworkService (aka the Network Service account). That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008.

Bonus Chatter

  • LocalService Account is a built-in account with limited privileges on the local computer, and accesses the network as anonymous. You should use this account to run your scheduled tasks
  • NetworkService Account is a built-in account with limited privileges on the local computer, and accesses the network as the machine (e.g. VADER$). You can use this account to run your scheduled tasks if you need authenticated network access
  • LocalSystem Account is a built-in account with extensive privileges on the local computer. You should never use this account to run scheduled tasks

You can't. The functionality was introduced in Task Scheduler 2.0, which means Vista/2008+.

From the documentation for Schtasks.exe:

/RU username

A value that specifies the user context under which the task runs. For the system account, valid values are "", "NT AUTHORITY\SYSTEM", or "SYSTEM". For Task Scheduler 2.0 tasks, "NT AUTHORITY\LOCALSERVICE", and "NT AUTHORITY\NETWORKSERVICE" are also valid values.


  • It's very helpful that the doc's specifically mention Task Scheduler 2.0. It eliminates the guesswork.
    – Ian Boyd
    Commented May 30, 2013 at 20:59

I tried doing this several ways, but now I don't think it's possible. I'd be glad to stand corrected on this, but I tried everything I could think of, including adding NETWORK SERVICE to Administrators, tweaking all sorts of Local Security Policy settings, etc.

When I enable auditing, I get this:

Event Type:     Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:       680
Date:           02/03/2010
Time:           8:49:53 PM
Computer:       RESULTANT
 Logon account:  NETWORK SERVICE
 Source Workstation: RESULTANT
 Error Code: 0xC0000064

Event Type:     Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:       529
Date:           02/03/2010
Time:           8:49:53 PM
Computer:       RESULTANT
Logon Failure:
     Reason:        Unknown user name or bad password
     User Name:     NETWORK SERVICE
     Domain:        NT AUTHORITY
     Logon Type:    4
     Logon Process: Advapi  
     Authentication Package: Negotiate
     Workstation Name:       RESULTANT

0xC0000064 decodes to NO_SUCH_USER. That's a bit silly, considering that I entered only network service – how did it know that the account that failed was in NT AUTHORITY?

When I enter an invalid username, I don't even see the authentication attempt at all. So clearly something agrees that NETWORK SERVICE is an actual account.

If I botch the password for a known username (ie Administrator), I get 0xC000006A (STATUS_WRONG_PASSWORD).

Try adding the Log on as a batch job right to NETWORK SERVICE. I think it's a silly idea; you should just bite the bullet and create a domain account…

  • Sorry I mistyped in my previous comment to Matt, but I tried adding it for "Log on as a batch job" and with no luck.
    – Regent
    Commented Mar 1, 2010 at 10:13

Try adding the "Log on as a service" right to the network service account. Detailed instructions here.

  • Nope. It was already listed in "Log on as a service", and adding to "Log on as a service" didn't helped too.
    – Regent
    Commented Feb 25, 2010 at 9:49

Just want to revive this thread as it IS possible to use NETWORK SERVICE for tasks! At the least on both Server 2016 and 2019!

Just a little oddity after selecting the account the usual way. Under

Run whether user is logged on or not

You confusingly have to select:

Do not store the password. The task will only have access to local computer resources

The second part of that should be taken with a shovel full of salt! As what it means here is that you do not have credentials, but if you run something that do not need the account to have credentials, it DOES have access to the network!

Exporting a job, the principal part looks like this

    <Principal id="Author">

I use it for sending status mails through smtp, and it contact the smtp-server just fine


Network Service is a local (computer) account. It will therefore never have rights on another computer (where the share resides).

If you want access to a networked share you have to use an account that is known in the network, so use a domainaccount. And the service you want to run MUST support UNC addressing. If it needs network drive letter access, you need a user session with mapped drives, other wise this also will fail.

(I suppose you know this already, looking at the date of your post. My answer is just an extra for people who wil find this post with a similar issue)


  • 2
    Each computer joined to the domain have its own account in the Active Directory. And as far as I understand NETWORK SERVICE is a local alias to that account therefore it could potentially have access to some shares.
    – Regent
    Commented Feb 14, 2011 at 12:22
  • 1
    NetworkService will have rights on another computer. From MSDN: " It has minimum privileges on the local computer and acts as the computer on the network."
    – Ian Boyd
    Commented Nov 24, 2012 at 19:18
  • 1
    This answer is incorrect. As @IanBoyd also says, NETWORK SERVICE is specifically intended for accessing items on the network (that's why it has "Network" in the name, by contrast with the LOCAL SERVICE account) which it will access using the computer's domain identity, DOMAIN\COMPUTERNAME$, e.g., MAIN\WEBSRV2$.
    – Nick Jones
    Commented Sep 23, 2013 at 15:48
  • It's also not an account (local or otherwise). It's a well-known security principal. Commented Sep 24, 2013 at 5:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .