Sign in to follow this  
Followers 0
Rorax

Cant execute part of scripts from networkshare

7 posts in this topic

Good day,

Basically I have this installation script that installs a program from a self installing exe file using local admin rights. But if I use:

RunAsSet("Admin", @ComputerName, "Password")
RunWait("G:\Lexe106.exe)
RunAsSet()

I get a error: "Cannot execute the external program", If I remove the RunAsSet part it works perfectly. Tried to get away from that by using a FileInstall into a the local users temp folder, but thought it would be better to use C:\Temp so every user could access the same Lexe106.exe instead of copying it from the networkshare everytime. So tried:

RunAsSet("Admin", @ComputerName, "Password")
RunWait(@comspec & " /c cacls " & "c:\Temp" &  " /E /P Alla:C", "", @SW_HIDE)
RunWait(@comspec & " /c attrib c:\temp +h", "",  @SW_HIDE)
RunAsSet()

And that also gives me the "Cannot execute external program" if its run from G:\ which is a network share. But it works flawless if I dont use RunAsSet.

The drive G:\ is mapped up from a Novell login script. Anyone have any ideas why it doesnt work?

Regards,

Rorax

Share this post


Link to post
Share on other sites



Use the UNC Path

or use DriveMapAdd for that Admin account

The mapped drive dosen't exist for the admin account.


SciTE for AutoItDirections for Submitting Standard UDFs

 

Don't argue with an idiot; people watching may not be able to tell the difference.

 

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

Tried to use the UNC path to the install file but still the same error ;)

Or did I misunderstand how you mean that I should use the UNC path?

RunAsSet("Admin", @ComputerName, "Password")
RunWait("\\IPnumber\Path\Lex106.exe")
RunAsSet()

Edit: Ah you meant that I execute the script from a UNC path since that seem to work, might have been a one time deal if it wasnt meant to work like that, going to try it on a few other computers. Thanks for your help!

Edited by Rorax

Share this post


Link to post
Share on other sites

I'm having the same issue! I have a Mapped Common Drive on every user's PC, when I do RunAsSet with a Domain Admin the UNC Path Fails. The account's Password is correct and is not locked. If I copy the script to the location of the UNC Paths it works. Any Suggestions ?

Share this post


Link to post
Share on other sites

I have had a problem with scripts running off network drives.

If you create as shortcut to the script executable and set the working directory to be local (c:\) then I find that they work

Try that


----[ SandyD ]---

Share this post


Link to post
Share on other sites

Also Tried that.. Here is the issue in detail

I have 1500+ Users, who all have a Common Drive mapped for them, This is the I Drive. I have a Service Desk Folder with all my quick fixes made in Autoit :)

the I drive is mapped as \\fpserver\

Code in the Application:

RunAsSet(Domain Admin, Password)

Run("\\fpserver\servicedesk\autoitscript.exe")

If I goto the user's PC and explore I:\servicedesk\autoitscript.exer and run the script it error's out saying it can't find the application to run

however if I browse to the script on the user's PC as \\fpserver\servicedesk\autoitscript.exe it works no problem.

Also I have some applications on \\sqlserver\CDES\ however the installation script is on \\fpserver\servicedesk\autoitscript2.exe

when I do the runas domain admin it also can't find the application to run. However if I copy the autoitscript2.exe to the folder on the actual server path \\sqlserver\cdes\ it works fine!

This is not making it easy for me to setup a toolbox for my service desk folks to just goto one folder for automated installs for our users.

Any help would be much app. Thanks!

Share this post


Link to post
Share on other sites

This is documented as standard behaviour of Microsoft's RunAs tool, so I imagine same would apply here.

When a process is run as a different user, access to network resources is lost. This seems to be true regardless of whether or not the other account's profile is loaded.

I was thinking about this issue a few days ago, and wondered if it might be possible to script the elevation of the the standard user's priveleges on a temporary basis, perhaps until next log-off. - If it could be done (not sure) that would solve a lot of software-installation headaches.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0