Orchid XP v8 wrote:
>>> The backup scan ran as an AT job.
>>
>> I'm assuming you mean it ran at the server to pull files, rather than 
>> at the client to push files. Might be better to switch that around.
> 
> Yeah, that would mean that all the directory scanning would be local 
> rather than remote. Probably a lot faster that way.

You'd still have to compare against the server, so that part is likely the 
same either way. Unless you're going to trust the last time it ran.

> Because that's the only way to specify the logon credentials for the 
> remote system.

net use \\xyz\pdq hispassword /user:xyz\hisusername

>>> mapped under the system account which runs AT jobs, 
>>
>> Why? Tell AT to run it as a different user.
> 
> There are other AT jobs running, of course...

Tell "at" to run *your* job under a different user ID. Not "at" itself.
Hmmm, if that doesn't work, use Task Manager, where that *is* an option.
And if you don't have that, then launch yourself and have yourself change privs.

Or use the domain administrator, which should have access to everything, 
right? Or give backup privs to the account running at jobs on the server?

>>> And don't even get me started on how absurdly difficult it is to 
>>> write DOS scripts that handle failure properly...
>>
>> That's what robocopy is for.
> 
> Not sure how you figure that out, but hey.

Google.

> Robocopy can't copy a file, it says "I can't copy this file" and exits. 

Uh, no. Do a "robocopy /?" and look at the retry options section. What would 
you have it do if the files it's backing up are on a PC that someone turns off?

> Now the script has to do something about this.

There isn't a lot it can do except look at the exit status of robocopy and 
send you a message if it failed.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message