new to autoit.. need some help

[fr0stbit3]

well first off guys, im just self studying on this tool which i really find handy with the kind of job i have now.

what i need is a script that simply copies a "installer.exe" file from a computer on the network and stores it to the local pc directory like C:\temp.

once it finishes copying the file, it would then install the "installer.exe" but as different user that has elevated rights.

i'll be using this to simplify the task of updating the computers which are intended for use by encoders. their user profiles is set to limited only that is why i am making this scripting so they could use it rather than calling me every minute to get something updated on the computer. there's about 100 computers so i seriously need to make this work.

here's the code i managed to make just by reading through the help file and some sources over the internet.

;username and password with elevated rights

Local $sUserName = "username"

Local $sPassword = "password"

;Copy installer for Adobe Reader

Local $pid = FileCopy ("network source path for the installer.exe", "destination directory to store the installer.exe", 9)

If $pid = 1 Then

;Install update with admin rights

RunAs ($sUsername, @ComputerName, $sPassword, 2, "directory where the installer.exe was stored")

Endif

ProcessWaitClose("AdbeRdr1013_en_US.exe")

FileDelete ("C:\temp\AdbeRdr1013_en_US.exe")

i didn't get any errors upon compile. i set 2 there as red because if set it to 0,1, or 4 it doesnt run the installer.exe file.

what confuses me further is that, on my computer which i have elevated rights... the script works but only if i set it to 2. but if run this on the client computers... it doesn't run the installer.exe file. however it was able to copy the "installer.exe" from the network source folder...

what am i missing on my codes? thanks much in advance..

this is my 2nd day of using the tool so pardon me if the structure of the code isn't that presentable or clear.

[BrewManNH]

The user name and password you're using to install this, are they a local administrator account, or are they domain credentials?

[fr0stbit3]

good question.. and it's what im trying to analyze now that it might have something to do with the username and password i used.

it's a Domain.. should i use local admin password?

and also since i'm using the Domain credentials.. i assume that the @Computername should be replaced with the Domain name instead?

Edited May 25, 2012 by fr0stbit3

[qvex21]

it's a Domain.. should i use local admin password?

Could be worth a try. Or may be you could add the domain user to the group of local administrators.

[fr0stbit3]

if this user and pass is used to login on any computer, the profile basically has the admin rights so i believe it belongs to the group of local admin.

this was the credentials my boss provided me when i initiated this plan of making this script.

[BrewManNH]

You're using Domain credentials, yet using the computername as the domain name, if you want to use domain credentials you need to replace the @ComputerName with the name of your domain.

[fr0stbit3]

initially i set that to the actual Domain Name and that red number 2 there was 0 (zero).. but it didn't work when i tested it...

the first trial and error i did was the profile flag (the red number 2), the program did work on my computer when i set the flag to 2.. but didn't work on one of the pc which i intended this for.. the copy code did work as i can see the file on the local destination folder i set it to..

the only part that's missing was for that file to be executed with elevated rights using the username and password i provided..

given that i restore the codes back to the first version;

;username and password with elevated rights

Local $sUserName = "username"

Local $sPassword = "password"

;Copy updateinstaller file to local destination folder

Local $pid = FileCopy ("network source path for the installer.exe", "destination folder to store the installer.exe", 9)

If $pid = 1 Then

;Install update file with admin rights

RunAs ($sUsername, "DomainName", $sPassword, 0, "directory where the installer.exe was stored")

Endif

ProcessWaitClose("updateinstaller.exe")

FileDelete ("C:tempupdateinstaller.exe")

what am i missing on the codes that prevent the execution of the updateinstaller.exe with elevated rights?

as mentioned on my first post... if i set the profile flag to 2 instead of 0.. the entire script runs on my computer but not on any of the client computers.

this script is intended for the users (with limited access) on the client pcs.. so they can just execute the .exe i made everytime there's an update on certain programs that is related to their work.

PS: i realized the file format of the script when compiled is .exe, would it be possible that the script file (in .exe form) also require elevated rights itself in order to execute the last part of the code?

Edited May 28, 2012 by fr0stbit3

[BrewManNH]

Are you actually putting the "directory where the installer.exe was stored" in the 5th parameter, or are you putting the pathfilename of the installer program? I see in your examples that you've put that line every time, so I have to ask this. Because the program name with full path has to go in that parameter and the working directory goes in the 6th parameter of RunAs.

[fr0stbit3]

my apologies if my descriptions are not clear..

if im understanding your instructions correctly, that line there should be in this format;

RunAs($sUsername, $sDomain, $sPassword, 0, "full pathupdateinstaller.exe", "working directory", "", "")

another newbie question, i want to be sure i will be understanding this clearly... "working directory" simply is the "installation path" for the updateinstaller.exe? or its a destination directory where the updateinstaller.exe will be putting its contents "temporarily" as it beings the installation procedure?

if its the latter then what comes up to my mind is this;

RunAs($sUsername, $sDomain, $sPassword, 0, "full pathupdateinstaller.exe", @TempDir, "", "")

is it really necessary for me to set a "working directory" when the updateinstaller.exe itself already has its own pre-defined codes and directory paths? all i need is for the script to execute the updateinstaller.exe file with Admin Rights so that the users can just use it in case one of the programs they use for work needs update.

Edited June 3, 2012 by fr0stbit3

[BrewManNH]

my apologies if my descriptions are not clear..

if im understanding your instructions correctly, that line there should be in this format;

RunAs($sUsername, $sDomain, $sPassword, 0, "full pathupdateinstaller.exe", "working directory", "", "")

Correct, the program to be Run has to be in the 5th parameter.

another newbie question, i want to be sure i will be understanding this clearly... "working directory" simply is the "installation path" for the updateinstaller.exe? or its a destination directory where the updateinstaller.exe will be putting its contents "temporarily" as it beings the installation procedure?

if its the latter then what comes up to my mind is this;

RunAs($sUsername, $sDomain, $sPassword, 0, "full pathupdateinstaller.exe", @TempDir, "", "")

is it really necessary for me to set a "working directory" when the updateinstaller.exe itself already has its own pre-defined codes and directory paths? all i need is for the script to execute the updateinstaller.exe file with Admin Rights so that the users can just use it in case one of the programs they use for work needs update.

WorkingDirectory is optional, and usually not needed for something like this, it's usually only needed if running a DOS based program that has to be "Run" from where it is on the disk so it can find all the support files/folders. You can leave it blank by using "" , or if you're not using any of the parameters that follow it, just don't include anything there and end the statement at the 5th parameter.

[fr0stbit3]

appreciate all the help.. i think i managed to make it work now BUT not entirely the way i wanted it because the "automation" part is still not achieved with the UAC that keeps popping up when the compiled script is executed.. that's the only thing that's left to work on.. but i guess the best approach for that would be creating another script that would make the call to make the this script run under admin rights.

[Inverted]

You can use #RequireAdmin statement, check the help file.