Jump to content

Uninstall call not working.


Recommended Posts

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

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

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 by vyperhand
Link to comment
Share on other sites

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

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

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

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

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 by Earthshine

My resources are limited. You must ask the right questions

 

Link to comment
Share on other sites

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

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 by vyperhand
additional information.
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

  • 2 weeks later...

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

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
 Share

×
×
  • Create New...