vyperhand

All my issues were from using Shift +F5 to test run on my dev station. The commands never executed there at all until I added the line for x64 mode, at which time they generated an error in Event Viewer indicating that windows installer couldn't access the network profile desktop for the logged on user. After compiling the code into an exe, the exe uninstalled the app and replaced it cleanly. Moved the exe to a sandbox machine where it also worked. I then reverted to my original code from before starting this thread and compiled, tested again in sandbox and my original code worked when compiled.

Thank you all for the help. Turns out it was an SciTE issue all along. Compiled, it works as expected even in its original form, as well as in most of the iterations I had tried to date. I appreciate all of the assistance, and GL in your own projects.

OK, That changed the behavior at least - now, I briefly get a command prompt that shows the MSI command in the title bar, but I see no output in the command window. The software is still not uninstalled. Dug in a bit, and I'm starting to think it's a problem with the test run feature in SciTE now. This version at least generated a message in the event log, however that message makes little sense. The MSI call says it couldn't access the network profile for the logged-in user... which it has no reason to be doing. Going to compile and move it to a different sandbox for further testing. This is the full (sanitized) version of the code now. #include <AutoItConstants.au3> #include <WinAPIFiles.au3> #RequireAdmin ;Disable x86 redirection mechanism for a 32-bit script. If @OSArch = "X64" And Not @AutoItX64 Then _WinAPI_Wow64EnableWow64FsRedirection(False) FileInstall("C:\My Files\Projects\Avatier Upgrade\Product.msi", @ScriptDir & "\Product.msi") Sleep (5000) RipRep() Func RipRep() Local $XPass = "password" Local $XUser = "user" Local $rProg = @ComSpec & ' /k "MsiExec.exe /x {DB7DE612-0D4F-49B5-B6B3-A42340856F7D} /qn"' Local $aProg = @ComSpec & " /k " & @ScriptDir & "\Product.msi /qn" RunAsWait($XUser, @ComputerName, $XPass, 2, $rProg) Sleep (2000) RunAsWait($XUser, @ComputerName, $XPass, 2, $aProg) Sleep (5000) EndFunc Exit

Thanks Adam - been away at Gen-Con, so just seeing this response. Will try that later today and see if it works, thanks!

Good idea - location's good. Same results from several locations actually. Also, please keep in mind that the script is never making it to the install element - the problem is at the uninstall right at the beginning. Could you explain that a bit further? That's at least new info. To elaborate, I'm using the SciTE editor for AutoIT, and I'm using the Tools > Test Run function right now for testing.

I would love to, but because it's a custom app with some protected data in it, I can't. However, if you can get *any* msi-based uninstall to work via the method I'm trying to use, I should be able to use that code. The requirements are: Must use RunAs or RunAsWait (That's the whole reason I'm using AutoIT for this effort, to prevent the passing of credentials "in the clear" by our management software) Must uninstall via msiexec /x or wmic This project started life as a simple batch file until I discovered that the product simply would not uninstall when the commands were run as SYSTEM. The batch still runs perfectly under literally any other admin credentials. == :: Remove Existing Credential Provider MsiExec.exe /x {DB7DE612-0D4F-49B5-B6B3-A42340856F7D} /qn PING 1.1.1.1 -n 1 -w 5000 > NUL ::Install New Version %~dp0program.msi /qn

No change, still just opens the command prompt empty.

Haven't tried that. Trying it now, will advise. **EDIT - Same result. Command prompt open and empty. No sign of the msiexec command.

The overall script is using the #RequireAdmin element. Again, the command prompt is launching, and in the correct user context. It just sits there blank, and the command that's supposed to be running afterwards does not even try.

That's correct. The uninstall works as local admin, domain user with local admin rights, etc. I can psexec to a target box with these creds and run the uninstall successfully. I feel like I have to be making a syntax error around how I'm passing the msiexec string, because even when I leave the command prompt open to debug (that's what the /k is for), it just leaves a blank command prompt. No sign it even tried to run the msiexec portion at all.

Will try, it's a local account though. And if the creds were the problem, wouldn't it not be launching the command prompt at all? **EDIT - Yep, that at least caused a clear failure. Reverted. Thank you for the suggestion though.

Have tried a number of iterations of this with still no success. Per another thread tried encapsulating the uninstall command into a variable to make it more intuitive with RunAsWait, but still no success. Again, the code generates no errors but fails to work. Version 1: This opens the command prompts, but doesn't seem to actually even try to run the msiexec commands: Local $XPass = "password" Local $XUser = "username" Local $rProg = @ComSpec & ' /k "MsiExec.exe /x {GUID} /qn"' Local $aProg = @ComSpec & " /k " & @ScriptDir & "\program.msi /qn" RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, $rProg) Sleep (2000) RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, $aProg) Sleep (5000) Version 2: This seems to do literally nothing. Just completes with no feedback and no system changes. Local $XPass = "password" Local $XUser = "username" Local $rProg = "MsiExec.exe /x {GUID} /qn" Local $aProg = @ScriptDir & "\program.msi /qn" RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, $rProg) Sleep (2000) RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, $aProg) Sleep (5000) I've stared at my syntax so long it's starting to look wrong, even the parts I know are right. Any help from fresh eyes will be greatly appreciated.

I have an application that due to strange architecture will NOT uninstall as the system account. As such, I have to pass credentials in order to uninstall it. The commands I am trying run to accomplish this do not generate any errors, but they're not actually completing successfully. The $XUser and $XPass are defined as Local variables inside my function and are the username and password for a local admin account. I have tried these variants on the command with no success: RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, "MsiExec.exe /x {DB7DE612-0D4F-49B5-B6B3-A42340856F7D} /qn") RunAsWait($XUser, @ComputerName, $XPass, $RUN_LOGON_NOPROFILE, @ComSpec & " /k " & "MsiExec.exe /x {DB7DE612-0D4F-49B5-B6B3-A42340856F7D} /qn") Simply calling "MsiExec.exe /x {DB7DE612-0D4F-49B5-B6B3-A42340856F7D} /qn" from a command prompt removes the software, so I know that command and GUID are correct. Any help would be greatly appreciated.

Yep, that looks familiar all right. #RequireAdmin RunWait (@ComSpec & " /c " & 'cscript.exe offscrub07.vbs ALL /Q /NoCancel') Run (@ComSpec & " /c " & "shutdown /r /t 30 /d P:4:1") But for some reason, the first step of the VBS fails with a perms error regarding the registry when called from AutoIt. Still digging into what might be causing that. So the VBS fails, the sandbox system reboots, and I'm back to the drawing board. I'll dig into this more tomorrow for sure.

Let me try #RequireAdmin - the .vbs I'm trying to run isn't one I made myself, unfortunately. It's one of MS's pre-published Office Removal .VBS monstrosities. 3926 lines, more than a minor effort to convert to AutoIt. Happy to provide the file if you're feeling froggy, but it seems effort-prohibitive to me. **Edit - # RequireAdmin didn't change the outcome. Just for grins, used psexec to kick the .exe off under the system account, same issue.

Thanks Water and Subz. Combining those two got the scripts to fire and leave the screen up for troubleshooting - but then for no explicable reason, the VBS gives a permissions error on trying to remove some registry keys. This is extremely confusing, as the script works both when called manually from a command line or from a batch. Just for grins, I even moved the batch into the auto-deployment folder where the .exe landed, and the batch works great... but calling it via the EXE I made with AutoIt doesn't. I'll dig deeper into that, appreciate the help that at least got me this far.

Thanks Water. Tried that, no change. Still just a flash of a command window and the .vbs does not execute.

I'm struggling to launch a VBS file via autoit using RunWait. Due to the nature of the deployment tool I am using for said script, I only know that the .vbs files will be in the same directory as my AutoIt-generated .exe, but not what that path will be. The path will look something like this: c:\programdata\vendor\lots\of\folders\randomnumber This is generated during deployment and I have no way of predicting the path - therefore, I am not sure how to call back to "same directory" in order to successfully launch the .vbs. This line is as close as I have gotten - this fires off the cmd window, but it closes immediately with out information, and the .vbs is not launched. RunWait (@ComSpec & " /c" & 'cscript.exe WORKPLEASE.vbs ALL /Q /NoCancel') I thought /c might be the problem, but leaving out the /c element causes me not to even see the momentary CMD window flash by. Any help will be greatly appreciated, and thanks in advance.

And as I was chopping through this, I had another thought - if AutoIT doesn't have an equivalent function to what I am looking for, can it instead call out to the .VBS and somehow read back the output into a variable? Using my original snippet of VBS in the initial question, could I execute that VBS and get back the value of strinfo(3) as a variable in my autoIT script? If I can do that, I can just call that VBS twice - once with each search parameter - and input back the needed data to compare and take appropriate action. I don't like having the .vbs out there - I hesitate to put anything in production that can be fubar'ed by a curious user that figured out how to open it in notepad - but if it's the only way, then that's what I'll have to do.

That may be the part I am missing, czardas. It seems like this has to be done in two steps instead of one? I have to search for my known element, then get positional values instead of data values, and compare them that way? I hadn't even considered that approach. I was trying to do something similar to the VBS, where the search and the split of the line into variables were all part and parcel of the same action, and then I could manipulate the variables directly. I'll mess with that line of attack later today.

I will investigate that CSV parser. In regards to FileReadToArray, the challenge I have had is that the search functions such as _ArraySearch only seem to return positional information rather than the string value at the found position, and I was unable to decipher how to get the value from another column in the same row based on that information. For the sake of clarity, let's imagine a table like this: Site,District,Region 1,1,1 2,1,1 3,1,2 4,2,2 5,2,1 The user at site 1 inputs that they want to connect to Site 3 at a prompt. I need to make sure that the value for District is the same for both lines before proceeding. In this case, I would need it to evaluate to true/OK if the user at site 1 put in site 1, 2, or 3, and generate an error if they put in site 4 or 5.

I am trying to upgrade an existing script, and after some time scouring the forums and the helpfiles, I don't feel any closer to figuring it out. I wrote a script that allows a user to input a different site number into an InputBox to connect to a remote system instead of their local system - So for example, a manager at site A can launch this script, input site B, and connect to their system instead. he can then disconnect, re-launch, input site D and connect to their system, etc. This is all working brilliantly. What I would like to do now is to make sure that the user only connects to a site in the same district. In order to enable this, I have available a .CSV of 4 columns - Site,Network, District, Region. Therefore, I can read the local IP and from there identify the right line for the current site in the .CSV. I would then need to read the value for district from that line and store it to a variable. Then I would also need to find the line in the CSV where the Site# matches the value received from the input box, and write that district# to a new variable. Then, I can compare those two variables and generate an error if they do not match, or proceed if they do. I cannot for the life of me figure out how to parse the .CSV, find the right line, and then make the comparison. I have something very similar in .vbs, but I cannot figure out an equivalent function in AutoIT - and I would much rather have this in a compiled .exe to make it at least a tiny bit more tamper-proof. Any help on this, even just a pointer to the right kind of function would be vastly appreciated. Here is the extraction code in VBS that I am trying to replicate in AutoIT: Set objFS = CreateObject("Scripting.FileSystemObject") roster = "C:\bin\roster.csv" Set objFile = objFS.OpenTextFile(roster) Do Until objFile.AtEndOfStream strLine = objFile.ReadLine intLength = Len(strLine) intZeros = 5 - intLength If InStr(strLine, strIP)> 0 Then strinfo = split(strLine, ",") siteNumA = strinfo (0) siteNumB = string(5 - Len(siteNumA), "0") & siteNumA siteIP = strinfo (1) siteDist = strinfo (2) siteReg = strinfo (3) End If(Note that the strIP variable was initally set earlier in the script by reading the IP of the local machine) TL;DR - I need to compare two values from Column A by making sure the value in Column B is the same in a .CSV.

I was debating that - I was thinking I could put in the guts of the batch file as a series of @‌ComSpec strings, but I was hoping not to have to. The .cmd is being provided from another department, and I was hoping to be able to just call it as-is rather than re-construct it each time they update the script. However, I have yet to get this working as expected any other way, so I will try that next. @‌SkySnake - this is in a thinclient /windows embedded environment with EWF enabled, so no AV and no UAC as such. AdamUL's solution looks promising though. Will add that to the list. I have temporarily brute-forced a solution using PSExec to run the batch as system, but I would rather not have that be the final solution.

That is actually everything except the comments - with the actual username and password removed, of course.

Trying to do a very simple script that will run a batch file as a specified account. The batch will remove one icon from the desktop and replace it with another one. This has to be done in a limited user context, thus I am trying to use autoit to make a quick exe so that the password for an account with elevated rights will not be sitting on the device in plain text. The script is a total of three lines: $uname = "Username" $pwd = "Password" RunAs ($uname, @ComputerName, $pwd, 0, "c:\testme\loopit.cmd") This debugs cleanly, but when I compile and run it, it generates the error Line 3 Error: Error Parsing function call. Any help at all would be appreciated EDIT/UPDATE: I tried changing the third line as follows: RunAsWait($uname, @ComputerName, $pwd, 0, @ComSpec & " /c" & "c:\testme\loopit.cmd")And it no longer generates the function call error, but it also does not actually run the script. I should add that if I do this the manual way - command prompt, run as, launch the .cmd that way, everything works as expected. I just need AutoIT to elevate privleges for the script without exposing the password.