ShellExecute inconsistency

[aleph01]

Greetings:

I’m having a curious issue with ShellExecute.  Actually the following script works exactly as I intend it on my Windows7, 64-bit system.  However I gave the script to my supervisor running an identical system, and instead of opening a command prompt in privileged mode, it opens in normal mode and the Send command is never sent, as WinWait awaits an admin command prompt.  Even if I change this to not require an admin command prompt, it fails.  He gets a “psexec is not  recognized as an internal or external command” message after the Send command executes.  If he opens a command prompt by right-clicking and “Run as Administrator, and types in the same command: psexec computername cmd and enters, it works fine.

The script is designed to open a remote command prompt, allowing the tech to get IP or MAC addys, run code, or do anything one could do through the command prompt if sitting at the remote console.

Any ideas as to why the code works fine on my machine but not my netadmin’s would be appreciated.  Again, the problem is that the script doesn’t open an administrator command prompt on his system.

Even though we're both network admins, I am also a local admin on my system.  I had him add himself as a local admin, but still no success.  I haven't tried logging  in to his system to see if it works under my profile yet, and that's something I'll try on Thursday.  I'm grasping at straws.  Again any input would be appreciated.

Thanks,

_aleph_

 

 

 

$remoteName = InputBox ("Computer Name", "Enter the remote computer name to manipulate through a command prompt window on your desktop.")
If $remoteName = "" Then Exit
ShellExecute ("C:\Windows\System32\cmd.exe", "/admin", "", "open")
WinWait ("Administrator:")
Send ("psexec \\" & $remoteName & " cmd{ENTER}")



 

[Jos]

Why are you not using #requireadmin and why use send at all in stead of running psexec directly?

Jos

[aleph01]

Jos,

#requireadmin is a good idea, and I will incorporate.  Trying to run psexec directly is also a good idea, and I like to be given pointers to make my code more elegant.  However I tried modifying to

ShellExecute ("C:\Windows\system32\PsExec.exe", $remoteName & " cmd{ENTER}")

I'm getting a "PsExec.exe file not found," although the file in fact is there.  I don't know why that is, but does the argument in the new ShellExecute line look right?

However, as helpful as these pointers may be toward making me a better coder (and I appreciate that), they don't help me figure out why my script works fine on my system, but not on my netadmin's.  btw, the script also works fine on another desktop tech's system, same Dell model as mine - thinking about it, the netadmin may have a different model of Dell laptop, but I dnot see how that would matter.

Thanks, for the consideration.

_aleph_

[Jos]

You are probably running it with the x86 version of AutoIt3.

Either run with the autoit3_x64.exe or copy psexec in the "C:WindowsSysWOW64" directory.

Also removed the {enter} in your commandline as you are not type the command but running it.

Jos

Edited September 7, 2014 by Jos

[aleph01]

Jos,

Putting the PsExec.exe in the SysWOW64 directory allowed the command prompt to appear, but only for  a few tenths of a second before it closed.  Obviously, I need it to be persistently open if I am to use it.  I'm wondering if creating a shortcut to C:\Windows\System32\cmd.exe /admin, and using that shortcut to open a command prompt might just do the trick, inelegant though it may be.

_aleph_

[Jos]

If you want the cmd prompt to stay open you could do this as well:

Run(@ComSpec & " /k C:\Windows\system32\PsExec.exe " & $remoteName & " cmd")

Jos

[aleph01]

Jos,

That kept the command prompt open, and seems to have done the trick.  The test will be when I can try it on my netadmin's system.

Many thanks for the bountiful gifts you have bestowed upon me today.

I'll finalize this post with my final code after the test, which may be as late as Thursday.

Of the 0s and 1s of the binary world, I rate you a 1.  I believe you to be Homo sapiens digitalis (1₂), as opposed to Homo sapiens analogiens (0₂.)  Yeah, that's a zero, not an oxygen molecule..

_aleph_