Jump to content

vyperhand

Active Members
  • Posts

    38
  • Joined

  • Last visited

Recent Profile Visitors

329 profile views

vyperhand's Achievements

Seeker

Seeker (1/7)

1

Reputation

  1. 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.
  2. 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.
  3. 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
  4. Thanks Adam - been away at Gen-Con, so just seeing this response. Will try that later today and see if it works, thanks!
  5. 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.
  6. 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
  7. No change, still just opens the command prompt empty.
  8. Haven't tried that. Trying it now, will advise. **EDIT - Same result. Command prompt open and empty. No sign of the msiexec command.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...