0

I am new to SysInternals tools, and I have a question whether there exists a workaround.

I need to launch an executable that is a command-line console to some network functions in target-LAN environment. It works fine until I issue the "online" command at that tool which basically connects it to a server.

From the remote administrative host, I use the PsExec to call that network tool locally. It gives me the initial output just fine. However, when I issue the "online" command, the PsExec console stops providing me any output, but I can clearly see the process is still running.

I assume that PsExec hooks up to a process and redirects output to the actual user. However if the target executable needs to interact with network on it's own, PsExec cannot handle such "nested" connection.

Am I correct about this assumption? Is PsExec working fine for you if you invoke a network-interactive tool?

Since the target software is proprietary, I am unable to share it with you. I hope you would be able to advise on that topic despite of this.

If not, let this thread die silently :-)

Best regards, Alex

AlexPawlak
  • 779
  • 1
  • 10
  • 22
  • can you share your psexec command line ? – Loïc MICHEL Jan 10 '14 at 10:40
  • PsExec.exe \\Computer -> this launches fine, gives a fair message on startup, looks like working. Normal step (if the exec is launched locally) would be to send "online" command which connects to local server and enables further commands. However, once the online command is executed, the command prompt is "stuck" on the next line and looks like "loading". This is the moment where the exec connects to host. It looks that when it connects, PsExec cannot gather the data from the output to send to me. – AlexPawlak Jan 10 '14 at 11:40
  • please try to specify the user and password to be used by the exe. Quote from help : If you omit a user name the process will run in the context of your account on the remote system, but will not have access to network resources (because it is impersonating). Specify a valid user name in the Domain\User syntax if the remote process requires access to network resources or to run in a different account. Note that the password is transmitted in clear text to the remote system. – Loïc MICHEL Jan 10 '14 at 12:27
  • That is definitely not an issue. We are using the AD environemnt, with admin rights granted. The target executable does not require any kind of authentication - the server is open to connections. Anyone with network access can connect to the server. The workaround would be to copy the executable and associated required files (incl. registry) but this isn't doable due to security policies. – AlexPawlak Jan 10 '14 at 15:40
  • Im sorry but i dont really understand what do you mean. I did try and above is the result of my attempts. I understand this question may be hard to answer w/o knowing the exact behaviour of the target exec but i still gave it a try – AlexPawlak Jan 10 '14 at 22:54
  • try with this cmdline : `psexec -u domain\user -p password yourexe.exe` – Loïc MICHEL Jan 12 '14 at 08:57

0 Answers0