Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to schedule a file-sync between two dedicated servers on a LAN. The remote machine is running Windows Server 2003 and the local machine is running Windows Server 2008.

I mounted the remote folder as the J: network drive to overcome any permission issues and when I run the command manually everything works as expected and the folder contents are mirrored:

robocopy J:\\ C:\\Files /MIR > c:\\robocopy.log

But as soon as I put it in a scheduled task, it fails with return code 0x10 (16), which is a serious error. So I assumed a network permissions error and tried scheduling the action between two local folders. The same error occurred and no robocopy.log output file is created. I am running the action as an Administrator.

Why is my scheduled task failing?

Output from schtasks /query /v /fo LIST /s localhost for reference:

HostName:                             localhost
TaskName:                             \Sync Task
Next Run Time:                        11/7/2010 3:00:00 AM
Status:                               Ready
Logon Mode:                           Interactive/Background
Last Run Time:                        11/6/2010 2:49:21 PM
Last Result:                          16
Author:                               HOST\Administrator
Task To Run:                          robocopy.exe "C:\\LocalFolder" "C:\\Destination" /MIR /LOG > c:\\robocopy.log
Start In:                             N/A
Comment:                              N/A
Scheduled Task State:                 Enabled
Idle Time:                            Disabled
Power Management:                     Stop On Battery Mode
Run As User:                          HOST\Administrator
Delete Task If Not Rescheduled:       Enabled
Stop Task If Runs X Hours and X Mins: Disabled
Schedule:                             Scheduling data is not available in this format.
Schedule Type:                        Daily 
Start Time:                           3:00:00 AM
Start Date:                           8/6/2010
End Date:                             N/A
Days:                                 Every 1 day(s)
Months:                               N/A
Repeat: Every:                        Disabled
Repeat: Until: Time:                  Disabled
Repeat: Until: Duration:              Disabled
Repeat: Stop If Still Running:        Disabled
share|improve this question
you can use the /log flag for robocopy to see what is going wrong there. You can also take a look at the scheduled tasks log file. And are you sure the J: drive is available to the scheduled task when it runs? why don't you write a batch file where the j: drive first is mounted and when you know it is, then you can run the robocopy command. – natxo asenjo Nov 6 '10 at 13:15
If you doubt permission issue, the best thing to do is run Process Monitor and fire the command. Check if there is any ACCESS DENIED and hopefully that should give a clue. – Vivek Kumbhar Nov 6 '10 at 13:59

Instead of using a mapped drive letter, use the UNC path of the share (\\servername\sharename\folder). That'll simplify things since your mapped drives are associated with your session, not necessarily the session that the scheduled task runs in.

Next, ensure that the user associated with the scheduled task has access to that share.

That should get you fixed up.

share|improve this answer
IIRC, backing up servers with robocopy was annoying for me until I figured this out as well. Let us know how it goes @FreshCode. – ajstein Nov 6 '10 at 15:43
up vote 0 down vote accepted

Solved by adding the following action before calling the robocopy command:

net use j: \\RemoteHost\Files RemotePassword /user:RemoteUser
share|improve this answer
If one user connects a drive letter to a remote drive, other users (runas etc) dont get to see that drive letter. If you connect J: as user, and effectively runas the task as Administrator, the latter wont see J:. There seem to be exceptions, though. – Posipiet Nov 8 '10 at 7:27
Skip that step and just use UNC paths in your robocopy command (ala my answer). Why over-complicate just to get a drive letter? – Chris_K Nov 10 '10 at 5:30
@Chris_K: How do I specify a username and password if I skip the net use? – pate Nov 12 '10 at 8:46
One option would be to change the scheduled task to run as a user w/ access to the share. Other option would be to modify the share perms to be usable by the user that runs the schedule task (which is set in job props). – Chris_K Nov 12 '10 at 18:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.