>>> net use \\xyz\pdq hispassword /user:xyz\hisusername
>> ...that does something?
> 
> Sure. For example,
>   net use \\thatmachine\c$ adminpass /user:thatmachine\administrator
> will log you into the administrative share on "thatmachine".

You mean this allows you to access that folder as the specified user 
using only UNC pathnames? (Not that all programs support these, mind you...)

> Or do it the "right" way, and have the backup run as a domain user with 
> permissions to log in to the appropriate shares. That's what domains are 
> for.

Yeah. As I say, the trouble is I don't want my "delete the temp files" 
job to have full network access, only the backup job.

>>> Tell "at" to run *your* job under a different user ID. Not "at" itself.
>> As far as I know, this is impossible.
> 
> Then have your job switch user IDs after it gets started, if you need to.

As far as I know, this is impossible.

>> And then there are other issues, like file access permissions 
> 
> Put your backup user in the backup operator group. That's what it's for.

Being in the backup users group only gives you permission to use the 
backup API. Standard copy programs don't use this API, they use the 
standard file access API.

>> or files being locked. 
> 
> Make a VSS snapshot. That's what it's for.

You can't do that from a DOS script.

> How do you think "real" backup programs get around it?

By being able to access any Win32 system call they wish?

>> Heh, yeah, I never did get as far as figuring out how to send alerts 
>> when it fails...
> 
> Or log it into a file you check until you figure it out. Easiest would 
> be to generate a Windows event for the event log, then have the event 
> log software notify you.

Well, it logs to a text file. But you have to remember to periodically 
read that and make sure nothing bad happened. As far as I know, logging 
to the event log is impossible.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message