0

I have a brand new windows 2008 server (64 bit), and the remote deployment scripts using nant and psExec are not behaving like they do on the old servers.

This works: psExec \\newserver.myco.com cmd
This successfully runs Nant: psexec \\newserver.myco.com "C:\Program Files (x86)\Nant\Nant.exe"
Ok, it doesn't do anything meaningful with nant, but it shows that nant.exe does in fact run.
But this does not run:
psexec \\newserver.myco.com Nant or
psexec \\newserver.myco.com Nant.exe or
psexec \\newserver.myco.com "Nant.exe"

I get: 

PsExec could not start Nant.exe on newserver.myco.com :  
The system cannot find the file specified.

this works fine on the other servers, which run Server 2003, also 64 bit.

I can verify that Nant is on the path on newServer:

C:\>path  
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;"C:\Program Files (x86)\nant"

And if I type "nant" in a command window on that machine, I get nant's output. The path and nant is present and correct even if I get in via psexec cmd.

What's up with the path over psexec on 2008?

Anthony
  • 113
  • 1
  • 6
  • What does procmon on the server show when you try to fire off the command? – Shial Dec 10 '09 at 15:15
  • If psexec \\newserver.myco.com "C:\Program Files (x86)\Nant\Nant.exe" works, why not use this? Is it because this script is run against a bunch of servers and you don't necessarily know the OS on the server? – shufler Dec 10 '09 at 16:34
  • shufler; yes, the script is run against a number of servers. – Anthony Dec 10 '09 at 18:09
  • shial: Process Monitor shows literally hundreds of thousands of events. The ones that I think may be relevant involve Process Name: PSEXECSVC.EXE doing things like FASTIO_NETWORK_QUERY_OPEN on "C:\Windows\Nant.exe" and other similar paths. Looking for the exe? It also tries "C:\Windows\SysWOW64\"C:\Program Files (x64)\nant"'\nant.exe" - with result "NAME INVALID" is this a mangled path or something else special? – Anthony Dec 10 '09 at 18:27

3 Answers3

2

Looking at the Process Monitor results its a mangled filepath so the path variable is messed up. Remove the double quotes from "C:\Program Files(x86)\nant", if you look at the one result it shows the quotes are getting embedded directly into the filepath.

You don't need double quotes in a PATH variable, its the semi-colons that mark where things are rather than spaces.

I do not know if you have to add a trailing backslash (C:\Program Files(x86)\nant\ ) or not, try it both ways.

I so love sysinternals

Shial
  • 1,017
  • 1
  • 9
  • 14
  • this is a correct answer, fixing the path to your spec allows psExec to work. However, in what way is the path "messed up"? - other tools such as cmd worked fine with it as it was. – Anthony Dec 11 '09 at 09:32
  • When you type in the command windows tries to look at each entry in the filepath for the executable. CMD works because the very first item in the path variable is C:\windows\system32 so it tries c:\windows\system32\cmd.exe which works so it never tries the other ones. Thats why you saw in procmon it tried to do c:\windows\nant.exe, it was testing the filepaths listed. I'm guessing it saw the " and began appending that to filepaths plus your executable – Shial Dec 11 '09 at 13:33
  • As an FYI in procmon you can rightclick on processes listed and select exclude and it will filter that out of the results. I normally exclude out most background processes and whatever else isn't needed to narrow it down faster. – Shial Dec 11 '09 at 13:38
  • Shial, when I say "cmd worked fine" I mean that cmd can find nant on the path. psExec cannot, so either cmd is doing something extra with the path, or psExec is not doing enough. My guess is the latter. – Anthony Dec 14 '09 at 09:42
0

Thanks Matthew.

Neither the -i worked, nor did specifying a working directory. Remember, the executable IS getting to the remote machine, and it IS installing the service! It just cannot find the path.

But as I am thinking about this, psexec used to push to the system32 path, and then they changed it to push to the windows path. Hmmm... maybe it's looking for itself in the wrong place?

Bob

  • I copied the executable to the windows/system32 path and it still did not work. Also, I searched the registry for psexesvc and found a bunch of entries, but oddly, even though I can see it in the service manager, it is not listed in the registry as a service. Perhaps it is the installation of psexesvc as a service that is failing? –  Jan 19 '11 at 18:33
0

Might try:

-i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session.

-w Set the working directory of the process (relative to the remote computer).

Let me know, -Mathew

MathewC
  • 6,877
  • 9
  • 38
  • 53