I have a simple task, which for the purposes of testing, consists of a batch file with two lines:

whoami >result1.txt
copy \\server\share\test1.txt C:\Users\xxx\Documents > output.txt 2> error.txt

When I run this from an interactive login, it works fine, because I have domain credentials which give me access to the share.

When I run it from Task Scheduler, it fails. The first command succeeds (and incidentally demonstrates that the scheduled task is running with my identity) but the second command fails, presumably because it isn't using the right credentials to connect.

After the task is run, error.txt is empty and output.txt contains "Access is denied." There is no useful information in the task history - just Action Completed and a Last Run Result of (0x1) because the copy failed.

The General Options on the Scheduled Task properties are to run with my domain user account and to "Run whether user is logged on or not". I have tried both with and without "Run with highest privileges" set - doesn't seem to change anything. I also tried changing the "Configure for" option - again with no effect. "Do not store password" is not checked - but I tried checking it just for completeness and it doesn't change the behaviour.

On the server side I have checked the Security Event log. When the command fails I can see an Audit Success Anonymous Logon logon event, an Audit Failure entry which looks like the Anonymous Logon is trying to use SeBackupPrivilege:

A privileged service was called.

  Security ID:      ANONYMOUS LOGON
  Account Name:     ANONYMOUS LOGON
  Account Domain:       NT AUTHORITY
  Logon ID:     0x180e12c36

  Server:   Security
  Service Name: -

  Process ID:   0x4
  Process Name: 

Service Request Information:
  Privileges:       SeBackupPrivilege

and then an Audit Success Anonymous Logon session destroyed.

The client is Windows 10, and the server is Windows 2008 R2. The credentials are a Domain user account in Active Directory.

If I use a different server, a Windows Server 2016 box running IIS and WebDAV, then the task runs fine via the Task Scheduler. So, going via WebDAV, my credentials are being used, whereas going via CIFS they are not.

Can anyone elucidate why the copy is failing and if there is any workaround? Any next steps for testing? I have got it to work by hard-coding credentials in the batch file but obviously that's not really acceptable.

It was suggested that this policy might be relevant but it's disabled so I don't think it is:

Network access: Do not allow storage of passwords and credentials for network authentication


Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
  • 1
    It would help if the details of the task were provided. In particular, the Security Options of the General tab.
    – Greg Askew
    Apr 14, 2020 at 16:08
  • @GregAskew I have edited those in (thanks).
    – strubbly
    Apr 14, 2020 at 16:18
  • What about the option below "Run whether user is logged on or not"?
    – Greg Askew
    Apr 14, 2020 at 17:40
  • That's unchecked ("Do not store password"). Presumably checking that would make it worse?
    – strubbly
    Apr 14, 2020 at 19:53
  • 1
    But the command works fine when run from an interactive logon. And the server is reporting not that I don['t have permission but that an Anonymous Logon doesn't have permission. Also I do have full control. I created the folder and the file.
    – strubbly
    Apr 21, 2020 at 15:39

2 Answers 2


I've seen more anecdotal evidence of permissions behaving differently interactively compared to from a Scheduled Task. And the event log message seems to point towards the fact that it needs the seBackupPrivilige ( which probably really means it wants to change the objects Owner).

Putting the user you run the task under in a built-in local group like Backup Operators on the target server might do the trick ( don't have a test bed to test this, but if unsure start with local admin on both servers and then use elimination).

In theory you could also use the domain GPO to set similar permissions for the specific user or even better their group.

EDITED: Have you tried to omit or change the error output? The security event could be a red-herring ( NTLM auth will always have a failed anonymous entry for instance).

If I run your script it errors out in a scheduled task because there is no path in front of > output.txt and 2> error.txt - but this works:

copy \\two.moh.local\test\test1.txt C:\temp\ > c:\temp\output.txt 2> c:\temp\error.txt

Your script will work if you run it from a command prompt or by double clicking because it will use the parent directory, that works differently when not running interactively (I'm assuming it tried to write somewhere where domain admin does have permissions while your user does not).

  • 1
    On the server, the domain account has full control. The problem seems to be that the user accessing the file on the server is Anonymous Logon, not the domain account that the Scheduled Task is running under.
    – strubbly
    Apr 23, 2020 at 13:56
  • To clafify a little - NTFS full control or as in the user is Local Admin/Power User/Backup Operator? There is a difference between a NTFS ACL ( who can access the data) and a Security Privilege ( who may do what within the Windows OS). Others have explained it way better than I can - for instance: medium.com/@grzegorztworek/ive-got-the-power-4f44b1998c88 Why exactly this behaviour is different when doing this interactively I don't know - but I have seen it before ( also in other question on ServerFault).
    – discondor
    Apr 23, 2020 at 14:05
  • I would still suggest making the user member of a local group - which will grant them the seBackupPrivilege inside Windows on that machine - and seeing if it makes a difference.
    – discondor
    Apr 23, 2020 at 14:05
  • OK - I added the user to the Local Backup Operators group and it didn't fix the problem. And the event in the Security Event Log is unchanged.
    – strubbly
    Apr 23, 2020 at 14:11

First of all "Task Scheduler Error 0x1" his hard to debug and need to try a couple of solutions in order to find the reason on your environment.

After i read the question and the asnwers i will sugest to:

  1. Try to explicitly state all paths used in the scripts or batches files. Don’t use short path. Edit the destination path C:\Users\xxx\Documents to something like D:\test.
  2. Try to include full path on error and output files.

Also i will sugest to check the options at "action tab". Try to use quotes on paths with spaces.

You can also find valuable informacion about return error 0x1 on this source

You must log in to answer this question.

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