1

My aim: To simply mirror a database backup directory onto another server

Approach: Use Robocopy statement contained in a scheduled task

robocopy "C:\MylocalDirBackup" "\\MY.IP\DatabaseBackupsShare"  /mir /z /log:"C:\MyLocalDIR\RobocopyTestLog.txt"

Environment:

  • Windows Server 2008R2
  • Scheduled task user "MylocalUser": Local adminon local machine
  • Network config: Both servers on workgroup

Tests:

  • navigate to share \MY.IP\DatabaseBackupsShare as "MylocalUser" - success, no prompt for credentials
  • Run robocopy command from command line when logged on as "MyLocalUser" - success

The Problem!: When running Robocopy command from a scheduled task the following error is raised:

2013/10/22 20:04:57 ERROR 1326 (0x0000052E) Accessing Destination Directory \\MY.IP\DatabaseBackupsShare\ Logon failure: unknown user name or bad password.

I found several other people who are having similar problems, and followed suggestions here: http://social.technet.microsoft.com/Forums/scriptcenter/en-US/b591346e-3ed0-4ed1-9453-24851ebe1bb1/scheduling-robocopy-to-run-at-system-startup?forum=ITCG

Any help gratefully received. I thought this was going to be a quick task...

4 Answers 4

2

When I was doing something similar, I was unable to get it to work without first mapping the drive.

Action 1 in Task Scheduler:

net use z: \\MY.IP\DatabaseBackupsShare mypass /user:myuser

Action 2 in Task Scheduler:

robocopy "C:\MylocalDirBackup" z:  /mir /z /log:"C:\MyLocalDIR\RobocopyTestLog.txt"

Because you're storing the password--ew--use an unprivileged account rather than an admin and give that account a strong password, the least possible privileges for the task, etc.

3
  • 1
    Agreed. You don't need a privelaged account if all you're doing is copying from point A to point B. Just make sure that the account can write to point B. This is just a copy job not a program that interacts with the operating system.
    – Techie Joe
    Oct 23, 2013 at 0:34
  • I've seen other people make this suggestion, so I tried explicilty mapping a drive specifying credentials. I come across another problem: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again. This despite no other connections (tried net use * /del) Oct 23, 2013 at 8:17
  • Navigating to \\MY.IP\DatabaseBackupsShare in Windows Explorer counts as a connection to the server, alas. That's probably what you have. Oct 23, 2013 at 17:45
0

I would post this as a comment/reply but I don't have enough rep to do that.

How exactly are you launching the scheduled task?

When I've done scheduled tasks with robocopy, I put the entire robocopy command in a .bat file, and then use that for the scheduled task. In other words, I'm NOT scheduling robocopy.exe and specifying runtime parameters - I'm just scheduling the .bat file. You can avoid a lot of syntax issues that way.

1
  • Thanks for your input. In my first attempt I used the scheduled task to execute a Powershell script, which I'd imagine to behave similarly to the batch file approach Oct 22, 2013 at 21:33
0

are you specifying the account used in the scheduled task? Or are you using the local user? I am with @Katherine about not storing the credentials in the script. If you specify them in the task, you can tell it to use a privileged account. That way you aren't storing it in an easily access space and you can run with a different account for the script on login...

4
  • It's still viewable by anyone who can access Task Scheduler. Oct 23, 2013 at 1:29
  • The GUI doesn't expose the password and without said credentials will not let you modify the task setup. Though a simple workaround is to modify the action file it is pointing to. Also, the password is stored in the registry as a hash, not as a password. Or maybe there is another way to expose the password that I am not aware?
    – MikeAWood
    Oct 23, 2013 at 1:56
  • @KatherineVillyard is correct (well, sorta). The credentials can be forcibly decrypted, but it requires more than a working knowledge of Credentials Manager, the locally logged in user used to create the task's key and the necessary processes to decrypt it. ie... not easily stolen, but still a possibility, but certainly better than plaintext in the script.. This was an actual question on SF already serverfault.com/questions/342084/…
    – MikeAWood
    Oct 23, 2013 at 2:06
  • The account specified in the scheduled task is the same one I've been testing with at the command line - "MylocalUser", hence the suprise at a permissions issue. Oct 23, 2013 at 8:15
0

After confirming that task scheduler was indeed using the account expected but still failing I have arrived at a solution using a pass through authentication approach.

  • I created a new local user account at the destination server - MyNewLocalUser
  • I created a new local user account at the host server MyNewLocalUser
  • Both have the same username and password
  • Changed the scheduled task to run under MyNewLocalUser

Robocopy runs successfully when the task is run under this new user.

You must log in to answer this question.

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