Scheduled Robocopy task fails with 0x10 error

Question

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

Solution 1

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

net use j: \\RemoteHost\Files RemotePassword /user:RemoteUser

Solution 2

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.

Comments

[natxo asenjo]

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.

[MikeT]

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.

[songei2f]

IIRC, backing up servers with robocopy was annoying for me until I figured this out as well. Let us know how it goes @FreshCode.

[Posipiet]

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.

[Chris_K]

Skip that step and just use UNC paths in your robocopy command (ala my answer). Why over-complicate just to get a drive letter?

[Petrus Theron]

@Chris_K: How do I specify a username and password if I skip the net use?

[Chris_K]

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).