PDMeat   0 pts.  |   Aug 3 2006  9:10AM GMT

The security context is local only (like signing on to the PC as a local user with no domain credentials).

If you did a net use q: domainnameusername and punch in a password, that will work.

I’m not familiar with runrmtcmd but if it has an option to connect with domain security credentials, you need to use that. Most other programs like this work the same way.

You may want to look at rclient/rconsvc from the MS resource kits. That runs as a service on the target host and when you connect to it I beleive it actually uses your connecting domain credentials by default so you wouldn’t have to enter your creds each time.

marcola   0 pts.  |   Aug 3 2006  9:28AM GMT

You may also do the following as long as the user has access rights to the share.

To map the drive do:

net use x: computernamesharename

To map the drive permanently do:

net use x: computernamesharename /persistant

To delete the drive mapping do:

net use x: /delete

Once the drive is mapped you can treat it as any other drive.

TylerDurden   0 pts.  |   Aug 3 2006  2:16PM GMT

Thanks all, especially pcatlin who twigged me to one of the problems. It turns out there are several things going on here. In my “sterile” test environment, using the ip address of the server and the share name instead of the UNC name was what fixed the problem.

At my live site, the exact same solution still gives “System error 1312. A specified logon session does not exist. It may already have been terminated”.

Again, I’m suspecting Windows domain or permission issues and am having a closer look at the rest of the network.

TylerDurden   0 pts.  |   Aug 3 2006  2:16PM GMT

Thanks all, especially pcatlin who twigged me to one of the problems. It turns out there are several things going on here. In my “sterile” test environment, using the ip address of the server and the share name instead of the UNC name was what fixed the problem.

At my live site, the exact same solution still gives “System error 1312. A specified logon session does not exist. It may already have been terminated”.

Again, I’m suspecting Windows domain or permission issues and am having a closer look at the rest of the network.

mortree   0 pts.  |   Aug 4 2006  7:47AM GMT

Using the IP & share name is still a UNC. Providing the IP just shortcuts name resolution.

By any chance did your “Sterile” test environment use the same account name and password on local and remote machines? This is one way to trick security contexts expecially where the two machine are not in the same AD domain or not even in same forest context.

Permanent drive mapping isn’t really going to work since the CMD environment is temporary and is destroyed when it is exited. The mapping of drives as a first step within the batch files is the way to go — if using UNCs is too complex or impractical.

Plus for permissions you need to figure out what local account is executing your CMD environment on the remote machine. This similar to how if a batch file is invoked as a scheduled task from the account running the task scheduler service. Any CMD environment invoked remotely without local logon service will inherit the drive mapping etc from the SYSTEM account (XP might be different than 2000). There are, as mentioned by previous posts, parameters that can pass along a particular security account context.

mortree   0 pts.  |   Aug 4 2006  8:07AM GMT

IF NET USE can’t find the account to access the share you get that 1312 error. Usually NET USE can’t find the account because it can not read your mind about which machine has the account you named.

When using NET USE you need to specify the machine on which the account for accessing the share exists using backslash notation. Assume the remote machine is called RemoteMachine and the account you wish to run CMD batch fiels under on RemoteMachine is called AccountCMD.

(all on one line)

NET USE X: RemoteMachineShare /user:RemoteMachineAccountCMD Password

Again what probably happened in your sterile environment is that both your local and remote machine had accounts with the same name and same password. Thus your NET USE command actually caused initial password checking against the local no the remote account. But this worked out because the token created for accessing the share ends up matching the same account and password on the remote machine.

So your production/real world problems probably come about because your aren’t using matching accounts and passwords on the local machine and remote machines.