Rorax Posted November 22, 2006 Share Posted November 22, 2006 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 Link to comment Share on other sites More sharing options...
GaryFrost Posted November 22, 2006 Share Posted November 22, 2006 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. Link to comment Share on other sites More sharing options...
Rorax Posted November 22, 2006 Author Share Posted November 22, 2006 (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 November 22, 2006 by Rorax Link to comment Share on other sites More sharing options...
Aeroceram Posted January 19, 2007 Share Posted January 19, 2007 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 ? Link to comment Share on other sites More sharing options...
sandyd Posted January 19, 2007 Share Posted January 19, 2007 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 ]--- Link to comment Share on other sites More sharing options...
Aeroceram Posted January 22, 2007 Share Posted January 22, 2007 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! Link to comment Share on other sites More sharing options...
Selmak Posted January 23, 2007 Share Posted January 23, 2007 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now