Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have Windows Server 2008 Enterprise. I need to copy files from network folder, I connected as a Z: drive. I need to schedule the copy. In scheduler I run it every 5 minutes.

robocopy.exe Z:\ C:\destination /E

I've tried to put it to .bat file, tried to write in scheduler, it doesn't help. I've set run with highest privilegies...

Task Scheduler successfully completed task "\RoboCopy" , instance "{dd2d2d1c-4ef1-4e30-b226-4a77aa52dab9}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 16.

share|improve this question
    
Does scheduled task run as another account? If it does, the network folder is also mapped as Z drive? And that account has permission to access network folder? –  Tanarri Aug 12 '09 at 19:35
add comment

3 Answers

Is there some reason you are not providing a UNC to robocopy? I find that using a UNC is much more reliable then depending on a mapped drive in a scheduled task.

share|improve this answer
add comment

From technet -

Exit code16

Robocopy did not copy any files.  Check the command line parameters and verify that Robocopy has enough rights to write to the destination folder.

This sounds like it could be a permission issue. Scheduled tasks typically run as a separate user and your z: may not be accessible and mapped by the user used for the task.

I recommend running as a network user that has permission on the remote drive, and instead of using z:, use \\computer_name\share as this should get around the permission problem.

For a list of exit codes, look here - http://blogs.technet.com/deploymentguys/archive/2008/06/16/robocopy-exit-codes.aspx

share|improve this answer
add comment

Are both the source and the destination on the same network? I had this problem in the past where my mapped drive was at a remote location and I had to allow the SMB traffic in both directions and at both sites. Also be sure to look at your OS firewalls.

Another troubleshooting step you can take is add the /LOG:c:\path\to\logfile.txt flag so you can examine the output in the future.

share|improve this answer
add comment

Your Answer

 
discard

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.