>>It's worth noting that using NET USE is a quick, power-user way to work around these types of problems. You can add a flag to the end of a NET USE command to make sure it's remembered:
>>

>>NET USE blah blah /persistent:y
>>

>
>Technically spot on as usual -
>
>>You should also be careful to map drives (either in the shell or via NET USE) using the account that will normally be running your app. If instead you use batch commands that are run as Administrator, either interactively or as scheduled jobs those drive mappings may not appear in the "normal" user profile.
>
>but here I'd go a step further: I create batch files in discrete directories to be run via specific credentials, so most of the problems you point at are given no chance ;-)

I do that too but that comes with a choice:

- Let the user manually enter the user name and password (usually to a different host name\account), or

- Include the account/password clauses of NET USE in the batch file, which can be a security vulnerability

It's exactly this sort of management issue that makes using a real server and Windows domain appealing.