Use Batch Jobs and Scheduled Tasks to Copy Backups

I use a lot of batch jobs to copy backup data between Windows and NAS devices. I run the jobs as scheduled tasks. Getting this working smoothly is always a fairly tedious part of setting up a new computer. Here are some tips on setting up the tasks and credentials.

  1. Execute the scheduled task as a user with the fewest privileges possible, e.g. a non-admin domain\ITService account that has access to the source and target data.
  2. You will need to grant the user Log on as Batch Job rights. For a job running on a non-domain computer, modify Local Security Policy. For a job running as on a domain controller, in Group Policy Management, modify the Default Domain Controllers Policy. For a job running on a domain workstation, in Group Policy Management, modify the Default Domain Policy. The path is Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as batch job.
  3. Since the batch jobs run without user interaction, If you are copying to a NAS, or any non-domain computer, you’ll need to save the required credentials in the Windows credential cache of the user that runs the scheduled task. You can either log in as that user on the machine where the task runs, or you can use Sysinternals PsExec to open a command prompt in the context of that user.  (Before using PsExec, you may have to do the local login one time to set up the local profile folders.) To open an interactive prompt as ITService, type this command and provide a password when prompted:
    psexec -i –u domain\ITService cmd
  4. Once you have a command prompt in the context of the task user, use these commands to save credentials for the NAS, e.g. to the Backups share:
    net use X: \\MYNAS\Backups /SAVECRED
    net use X: /delete

    Note that deleting the drive letter does not delete the credential. To see or delete the credential, use this command (still in the task user’s context):
    rundll32.exe keymgr.dll, KRShowKeyMgr
  5. If you want to use Simon Tatham’s PSCP, part of the PuTTY toolset, to download files from a Linux computer or appliance, you will need to run PSCP interactively one time to store the server’s host key in the local machine’s registry. The keys are stored in the user registry (HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys). The only way I have found to do this is to log on interactively as the task user, open an administrative command prompt, and run a PSCP command to connect to the remote server. (On a domain controller, you may need to first give that user the “Log on locally” privilege in the same Local Policies area described in step 2.) You will be prompted asking if you trust that server. Here’s an example that also includes use of a local key for authentication:
    pscp -pw "nopassword" -p -2 -P 22 -i "mykey.private.ppk" [email protected]:/path/to/source/file "X:\path\to\target\folder"
    Once the key is stored, add the -q -batch parameters to run in the batch file:
    pscp -pw "nopassword" -p -2 -P 22 -i "mykey.private.ppk" -q -batch [email protected]:/path/to/source/file "X:\path\to\target\folder"
    I did discover one trick when migrating batch jobs from one computer to another:  I was able to export the registry key above from the old computer and import it to the new one. This allowed the new computer to trust the same hosts that the old computer trusted.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.