vyperhand Posted July 26, 2018 Share Posted July 26, 2018 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. Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 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. Link to comment Share on other sites More sharing options...
Earthshine Posted July 30, 2018 Share Posted July 30, 2018 I think it takes Domain Name from the help, try @LogonDomain instead of the computer name? My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 (edited) 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. Edited July 30, 2018 by vyperhand Link to comment Share on other sites More sharing options...
Earthshine Posted July 30, 2018 Share Posted July 30, 2018 let me axe you this if you do it from the command line, it works as an elevated user? My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 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. Link to comment Share on other sites More sharing options...
AdamUL Posted July 30, 2018 Share Posted July 30, 2018 RunAsWait and RunAs does not give the Admin Token, and will not run a process with full admin rights. It will only run the process under the context of the user with limited rights, even if they are an admin. There are workarounds on the forum, depending on how you want to do it. Adam Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 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. Link to comment Share on other sites More sharing options...
Earthshine Posted July 30, 2018 Share Posted July 30, 2018 have you tried all the different options, I think you want something like $RUN_LOGON_INHERIT (4) $RUN_LOGON_NOPROFILE (0) - Interactive logon with no profile. $RUN_LOGON_PROFILE (1) - Interactive logon with profile. $RUN_LOGON_NETWORK (2) - Network credentials only. $RUN_LOGON_INHERIT (4) - Inherit the calling process's environment instead of the user's environment. My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 (edited) Haven't tried that. Trying it now, will advise. **EDIT - Same result. Command prompt open and empty. No sign of the msiexec command. Edited July 30, 2018 by vyperhand Link to comment Share on other sites More sharing options...
Earthshine Posted July 30, 2018 Share Posted July 30, 2018 (edited) try no space after the /x RunWait("MsiExec.exe /X{GUID} /qn") If @error Then MsgBox($MB_OK, "Error", @error) Edited July 30, 2018 by Earthshine My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 No change, still just opens the command prompt empty. Link to comment Share on other sites More sharing options...
Earthshine Posted July 30, 2018 Share Posted July 30, 2018 (edited) can i get a copy of the msi to install in a vm and see if i can get it to work? Runwait won't show it I don't believe, but get me that exe or some demo version and I can play with it in a vm Edited July 30, 2018 by Earthshine My resources are limited. You must ask the right questions Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 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 Link to comment Share on other sites More sharing options...
AdamUL Posted July 30, 2018 Share Posted July 30, 2018 Where is the location of the MSI? It may be in a directory that the RunAs user does not have permissions to access. Check the permissions, and make sure the user has access to the file. Adam Link to comment Share on other sites More sharing options...
Developers Jos Posted July 30, 2018 Developers Share Posted July 30, 2018 Also remember you likely run the autoit3 script in x86 mode and the cmd in x64. Jos SciTE4AutoIt3 Full installer Download page - Beta files Read before posting How to post scriptsource Forum etiquette Forum Rules Live for the present, Dream of the future, Learn from the past. Link to comment Share on other sites More sharing options...
vyperhand Posted July 30, 2018 Author Share Posted July 30, 2018 (edited) 34 minutes ago, AdamUL said: Where is the location of the MSI? It may be in a directory that the RunAs user does not have permissions to access. Check the permissions, and make sure the user has access to the file. Adam 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. 22 minutes ago, Jos said: Also remember you likely run the autoit3 script in x86 mode and the cmd in x64. Jos 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. Edited July 30, 2018 by vyperhand additional information. Link to comment Share on other sites More sharing options...
AdamUL Posted July 30, 2018 Share Posted July 30, 2018 Good point Jos. I totally forgot about that. Have a look at Running under Windows 64-bit Edition in the Help File. Try adding the following to the the top of your script. #include <WinAPIFiles.au3> ;Disable x86 redirection mechanism for a 32-bit script. If @OSArch = "X64" And Not @AutoItX64 Then _WinAPI_Wow64EnableWow64FsRedirection(False) Adam vyperhand and Earthshine 2 Link to comment Share on other sites More sharing options...
vyperhand Posted August 8, 2018 Author Share Posted August 8, 2018 Thanks Adam - been away at Gen-Con, so just seeing this response. Will try that later today and see if it works, thanks! Link to comment Share on other sites More sharing options...
vyperhand Posted August 8, 2018 Author Share Posted August 8, 2018 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 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