psexec with XCOPY = Parse Error Code 4

[Tim H.]

From within an AutoIt Script, I'm trying to use psexec with system authority to copy files from one place on a remote machine to another. When I issue the necessary command outside of the script (at a command prompt), the command executes properly. Here's the exact one-line command:

psexec \\vmhartlti01 -s XCOPY "C:\temp\hs\Hyperspace POC.lnk" "C:\Documents and Settings\All Users\Application Data\Landesk\ManagementSuite\Launchpad\Dept Apps\" /Y

When I try to run the exact same command from within an AutoIt Script, an XCOPY parse error 4 flashes up for a millisecond in the console and the command fails. The command appears to be formed properly in the message box popup.

$cmd = 'psexec \\vmhartlti01 -s XCOPY "C:\temp\hs\Hyperspace POC.lnk" "C:\Documents and Settings\All Users\Application Data\Landesk\ManagementSuite\Launchpad\Dept Apps\" /Y'
MsgBox(4096, "test", $cmd)
$XCopyStatus = Run($cmd, "c:\temp")

The Run command returns the XCOPY PID rather than zero, further obfuscating the problem. I've been working on this for a while now and I think I must be missing something. Does anyone see the problem?

Thanks for your help.

[Jos]

You probably need to use Shellexec() or add "@comspec /c " in front of your command.

[Tripredacus]

Also, if it were me I would reformat your string as such:

$cmd = "psexec \\vmhartlti01 -s XCOPY " & Chr(34) & "C:\temp\hs\Hyperspace POC.lnk" & Chr(34) & " " & Chr(34) & "C:\Documents and Settings\All Users\Application Data\Landesk\ManagementSuite\Launchpad\Dept Apps\"  & Chr(34) &  "/Y"

(I hope I did that right)

[Tim H.]

Jos: I tried both Shellexec() and "@comspec /c " Shellexec tells me there's no file type associatied in the registry (there isn't for psexec) and adding "@comspec /c " in front results in the same: Parsing error code 4

Tripredacus: I'm not sure what adding the extra quotes (Chr(34)) is meant to do, but I tried it anyway with the same result. I expected to see the extra quotes in the message box, but didn't.

Any other thoughts?

[Jos]

Is PSEXEC located in c:Temp?

In other words: When you run the command from the CMD prompt, what is the active directory?

... and what is the script directory?

Edited March 8, 2013 by Jos

[Tim H.]

Jos: I was running the script by double-clicking it on my desktop. While I was playing, I got the command to work by using a target path that contained no spaces and, consequently, fewer quotes. That had me scratching my head since the syntax with the longer target path looked right. Then I saw your reply.

Given your question, I put the script and a copy of psexec.exe in c:temp, opened a command session there, typed in the script's name, hit enter and "presto chango" it worked!

Next, I figured either psexec had to be in the same directory as the script or running the script from a path with spaces in it was causing the problem. So, I deleted the psexec executable from the c:temp directory and tried it again thinking the long target path with spaces might be the problem. But no, It failed again. Lastly I changed the non-test command string in my script to include the full path to the psexec executable like this:

$cmd = 'C:SysinternalsPsExec ' & $ComputerName & ' -s XCOPY ' & '"' & $LocalSource & $aFile[$n] & '" "' & $LocalPath & '" /Y' (hard to read with the mixed quotes and apostrophes)

and double-clicked it on my desktop. That worked too. So, something about relying on psexec being in my path environment was causing the problem. I went and looked at my path environment to find that psexec's directory was not in the path. So, I double-checked to see if there was a copy in either C:Windows or C:WindowsSystem32. There wasn’t. Installing PSTools must put an entry into the Windows registry so the executables are available from anywhere. Apparently though, that's not good enough. Any idea why that would be?

Anyway, problem solved for now. I appreciate your help!

Edited March 8, 2013 by Tim H.

[Jos]

That was indeed what I was going to get at ones you define the directories used.

We often see the mix-up with WorkingDir and "the path to get to the program".

The command looks now indeed logical to me.

Enjoy,

Jos