PSEXEC and VBS?

[StumpedTechy]

I guess I am still a little green with this tool.

Here is the code I am trying to use -

1)Set WshShell = WScript.CreateObject ("WScript.Shell")
WshShell.Run "C:\psexec.exe \\" & strDeviceName & " cmd /c ""\\server\share\long directory name\WindowsXP-KB928388-x86-ENU.exe"" /q""",1 , True

2)WshShell.Run "C:\psexec.exe \\" & strDeviceName & " cmd /c ""\\server\share\long directory name\WindowsXP-KB928388-x86-ENU.exe"" /q""",1 , True

I also get a similar error when I do -

3)WshShell.Run "C:\psexec.exe \\" & strDeviceName & " ""\\server\share\long directory name\WindowsXP-KB928388-x86-ENU.exe"" /q""",1 , True

The errors range from -
1)Access is denied. cmd Exited on PC with error code 1

I have full admin rights on the remote machine and access to the share I am trying to pull the information from.

2)Could not start \\server\share\long directory name\WindowsXP-KB928388-x86-ENU.exe on PC: The system cannot find the file specified.

This I know isn't true because the file is right there on the network share. I am logged in as me on both machines so its not a permissions issue.

3) PsExec could not start \\server\share\long directory name\WindowsXP-KB928388-x86-ENU.exe on PC: Access is denied.

Just an FYI I tried this on about 3 other computer and checked to make sure this PC was pingable and firewall disabled as well.

The part that is bugging me so immensly is if I do a copy of the file from the share to local and then run the file local it works fine.

E.G.
Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.CopyFile "\\Server\share\long directory name\Window~1.exe" , "\\" & strDeviceName & "\C$\"
Set WshShell = WScript.CreateObject ("WScript.Shell")
WshShell.Run "C:\psexec.exe \\" & strDeviceName & " cmd /c ""C:\WindowsXP-KB928388-x86-ENU.exe"" /q""",1 , True

What I have a problem with is why I have to copy this file locally to the PC and cannot seem to access it on the network directly using the UNC path?

Anyone care to help me with this tool and making it so I don't have to copy the files locally to run them.

 

[mrmovie]

rrr, you might find that this exe need to be extracted first before you can run it otherwise it pops up a messagebox about trusting the source, there is a work around to this by writing a 'funny' environment variable or you can extract the 'real' hotfix/setup.exe/msp etc...but then the update you are talking about might not fall into this catagory but it is worth checking out.

some updates dont like to be run unless they are copied locally first (well some msi/msps i have found)

 

[mrmovie]

actually that bit about copying stuff locally might have been misleading, i hate running stuff whcih self extracts from different vendors directly from a software pool, leads you to perhaps wonder if the extraction will occur locally or on your software pool which worries me as you will have lots of people installing at once and extracting to the same place,,,perhaps i worry too much

 

[mrmovie]

SEE_MASK_NOZONECHECKS is the environment variable.

also be careful with IEZONE settings as those throw up warnings like 'are you sure you want to run this it could be a virus'...hence copying it locally gets round those issues (but generally we update IEZONE to include our softwarepool/s)

 

[StumpedTechy]

you might find that this exe need to be extracted first before you can run it otherwise it pops up a messagebox about trusting the source

Well the funny thing is if I run it via command line from anycomputer I get no trust issues, no virus prompts, no warnings of any kind it just installs.

Doubleclicking on the gui I do get the trust prompt tho.

i hate running stuff whcih self extracts from different vendors directly from a software pool, leads you to perhaps wonder if the extraction will occur locally or on your software pool

I would too in most instances but I know with KB patches they usually install just fine from a network source.

Thanks fo the overall information and the Zone stuff I'll look into that as it may be useful when troubleshooting other things but I don't think that is whats blocking this.

E.G. Install ran from network path locally via command line no problems. Install ran remotely from command line using wshShell.Run and psexec fails.

Makes me think it has to be some limitation on the psexec side possibly?

 

[dm4ever]

How big is the patch? You can have psexec copy it over to the remote machine and execute which normally works fine.

--------------------------------------------------------------------------------
dm4ever
My philosophy: K.I.S.S - Keep It Simple Stupid

 

[mrmovie]

never used pseexec, always been lucky enough to have an installation service on all clients, WMI can start remote threads

 

[dm4ever]

If you look at the usage for PSExec you'll find this towards the end

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.

Alternately, like I said you can have PSExec copy the file over and execute by using the -c or -v switches.

--------------------------------------------------------------------------------
dm4ever
My philosophy: K.I.S.S - Keep It Simple Stupid

 

[StumpedTechy]

dm4ever, Thanks I think that's whats blocking it the patch is dinky its only like a few hundred k.

How do you setup the exe to copy the file it needs? I am still learning the utility.

I wish we had some kind of installer service. Right now they have decomissioned SUS and all is supposed to patch through LanDesk which seems to only work about 50% of the time here. :/

 

[dm4ever]

To copy the file over you would do something like this:

psexec.exe \\strComputer -c -v "\\server\share\WindowsXP-KB928388-x86-ENU.exe"

The path \\server\share\WindowsXP-KB928388-x86-ENU.exe is relative to the machine running psexec since the -c -v switches will copy it over to the target machine

I saw in the examples you posted above that you use a /q switch for the exe. I think you can pass it like this (don't remember for sure):

psexec.exe \\strComputer -c -v "\\server\share\WindowsXP-KB928388-x86-ENU.exe" WindowsXP-KB928388-x86-ENU.exe /q

--------------------------------------------------------------------------------
dm4ever
My philosophy: K.I.S.S - Keep It Simple Stupid

 

[StumpedTechy]

Yeah it has to be quiet thats the most important part as it will be done during production. I'll look into this I think the -c -v will be very benificial and is exactly what I am looking for.