psexec - remote share problem

We use this approach for a large batch run we do.  The batch programme copies 1 GB of files to a temporary folder on our DL785 grunt box, then uses PSEXEC to kick of a programme that runs there to process these files into a series of result files, and then returns.  The batch programme on the initiating computer then copies the result files back.

2) Use scheduled tasks.  If your security permits, set up a scheduled task on the remote computer configured to run with the username and password set inside it.  Then just use schtasks /run to run it from the initiating computer.  Keep in mind that the call to start the scheduled task returns immediately, even though the scheduled task may take hours to complete.  One idea is to have a batch programme on the initiating computer delete a flag file, and then kick off the scheduled task, and then wait for the flag file to be created.  The scheduled task does its thing and when completed, creates the flag file, which is detected by the batch on the initiating PC.

3) Remember, the rules around network only apply to things that are controlled by Windows security.  FTP and SQL and other network crossing programmes run fine.  You do have access to the "network", you just cannot rely on your credentials nor rely on Windows letting you do windows type things.

4) If you want to create network shares remotely, look at RMTSHARE.exe.  I used to use PSEXEC.exe to do network share creation remotely, but this required -U and -P which got banned, and so I found this nifty little tool (that does network share permissions easily as well.  Sweeet!)

I solved my problem by configuring the command I need to run in Windows Task Scheduler and using Schtasks to kick it off.

Hello,

can some one offer a workaround to this?

I must use impersonation and I must have network access. I'm sure, that technically this is possible, and I do understand that psexec doesn't support this. Are there any other tools that I can use, maybe in combination with psexec that would allow me to run a process remotely under current credentials and have network access.

I'd like to explain, why I can't specify user name and password pair. I need to run a remote process from a cmd script unattended. Company policy specifically prohibits putting plain text password in scripts. This is why this is an issue. If there were a way to provide this password to psexec in a manner that doesn't require a plain text password stored in a file, this would work for me too.

Thank you in advance, for any insight offered.

Andrew.

hi, bobsmith.

Some of the fourms talk about it but there is nothing that says "Without the -U -P PSEXEC runs as local system".

No, it does not. (This would be a pretty dangerous privilege elevation, would it not!)

I am sure it has been mentioned in previous threads, but I am too lazy at this moment to look them up (meaning I will do so later).

There is an important difference between using implicit versus explicit logon:

• psexec \\target some_command uses implicit logon to \\target.
  I.e. the user logged in locally will be used to logon to \\target. But logging in implicitly he will loose the network resources on \\target that he would have if he had logged on explicitly.
  As -e was not specified his environment will be that of the ".default" user on \\target. Check e.g. the variable %userprofile%.


• psexec \\target -u user - p passw some_command uses explicit logon to \\target.
  psexec is told to explicitly identify as user "user" on \\target (even if he is the same user "user" logged in locally). So network resources assigned to user "user" on \\target may be available.
  As -e was not specified his environment will be that of the ".default" user on \\target. Check e.g. the variable %userprofile%.


• psexec \\target -u user -p passw -e some_command uses explicit logon to \\target and loads the environment of user "user".
  Same as above plus:
  As -e was specified the environment on \\target will be that of user "user", not the one of user ".default".
  
  NOTE:
  Starting with psexec v1.80 the default behaviour changed! The default now is to load the correct user environment. Specifying -e will keep psexec from loading the user's environment and use the .default environment instead.

Having explained the difference between implicit and explicit authentication used by psexec, the answer to your main issue

What I am trying to achieve here is this. Run a remote command that queries a network path without requiring the -U or -P option.

may well be:
You cannot have both!
Either use implicit logon and loose any network resources on \\target.
Or use explicit logon.

Kind regards,
Karl
--
P.S. (06-Mar-2007):
Added note about the reverted meaning of the option -e in psexec v1.80 and above.



Edited by Karlchen - 06 March 2007 at 4:51pm