Vendor MSI not getting uninstalled from ARP
I'm working with a vendor supplied MSI that's giving me some problems uninstalling. When I hit the remove button in Add/Remove programs it's removed from the list but it doesn't actually get uninstalled. I checked the uninstall and modify strings in the registry and they are correct, when I paste it into a command line I get the option to repair or remove as expected and msiexec /x {GUID} uninstall works too. I'm not sure where else to look for what would be causing this.
I opened the msi in package studio and ran validation on it and there is a bunch of ice82 errors (action has a duplicate sequence number) and 2 ice83 (action should not be present in AdvtExecuteSequence table, since it does nothing). I'm not sure if theses errors would cause the problem with ARP since it works from the command line.
Any ideas would help. I don't really want to repack it since it includes some custom actions to install some drivers. I did run it through setup capture once too see and it had hundreds of ice errors.
I opened the msi in package studio and ran validation on it and there is a bunch of ice82 errors (action has a duplicate sequence number) and 2 ice83 (action should not be present in AdvtExecuteSequence table, since it does nothing). I'm not sure if theses errors would cause the problem with ARP since it works from the command line.
Any ideas would help. I don't really want to repack it since it includes some custom actions to install some drivers. I did run it through setup capture once too see and it had hundreds of ice errors.
0 Comments
[ + ] Show comments
Answers (11)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
Odd...
The first stage - as ever - is to verbosely log the various install scenarios and compare the logs. Something should hopefully jump out.
The first stage - as ever - is to verbosely log the various install scenarios and compare the logs. Something should hopefully jump out.
Posted by:
jwiz
13 years ago
I have installer logging turned on through registry but no log file is generated when hitting remove through add/remove.
I'm going to keep digging and see what else I can find.
I'm going to keep digging and see what else I can find.
Posted by:
jwiz
13 years ago
I figured it out. The MSI installs a driver package along with other components and one of them wasn't showing up in ARP. I think I can't fix that either with a transform or I'll add a separate task to my distribution job to clean it up.
I hate messy vendor msi's.
I hate messy vendor msi's.
Posted by:
anonymous_9363
13 years ago
Are you looking in the right place? When logging is enabled by Group Policy (which is what you've done, I suspect, if your registry change begins 'HKLM\Software\Policies...') the log files are written to %SystemRoot%\TEMP and are named with random names beginning with 'MSI'. You'll need to search these for unique text to find the one's your interested in. I normally use the package's ProductCode.
Posted by:
jwiz
13 years ago
Yeah, I'm looking in the right place. Installer logging is not turned on via group policy I manually enabled it on my test pc. Our %temp% variable is mapped to c:\temp. I found the log file there when doing an uninstall from the command line using the ProductCode. What the problem was is the MSI calls another exe to install some usb drivers and that wasn't showing up in ARP.
Thanks for the help.
-Jason
Thanks for the help.
-Jason
Posted by:
anonymous_9363
13 years ago
Installer logging is not turned on via group policy I manually enabled it on my test pcCall me pedantic but you have indeed applied it via Group Policy. It just happens to be a local GP rather than a domain GP.
Posted by:
jwiz
13 years ago
Just to be clear I added the reg key "Logging" type REG_SZ data: "voicewarmup" and I tried "/l*vx" to "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer". If you want to refer to it as local group policy that's fine, I just wanted to avoid confusion.
Thanks
Thanks
Posted by:
anonymous_9363
13 years ago
If you want to refer to it as local group policy that's fineOK. That'll only be me, Microsoft and everybody else, then! :-)
Posted by:
jwiz
13 years ago
Funny how Microsoft or anywhere/anyone else that I can find doesn't refer to it as a "Local Group Policy" then.
To quote Microsoft:
Symantec Connect:
Maybe the documentation is different in the UK? Just because it's a policy you can set via "Local Group Policy" doesn't mean it needs to be referred to as such.
I understand being pedantic but not just for the sake of being pedantic :)
To quote Microsoft:
Windows includes a registry-activated logging service to help diagnose Windows Installer issues.
Symantec Connect:
Windows Installer can use logging to help assist in troubleshooting issues with installing software packages. This logging is enabled by adding keys and values to the registry.
Maybe the documentation is different in the UK? Just because it's a policy you can set via "Local Group Policy" doesn't mean it needs to be referred to as such.
I understand being pedantic but not just for the sake of being pedantic :)
Posted by:
anonymous_9363
13 years ago
LOL...Given some of the idiotic questions posed here (not yours, I hasten to add!), I think it's important to be precise in what we say. I was correcting your assertion that you aren't setting a Group Policy (post #6) which TechNet seems to think you are. It's a common enough convention to refer to changes made on one machine as opposed to domain-wide as 'local'.
Posted by:
jwiz
13 years ago
Well you got me there, it is in a policies subkey and it was done "locally" :). At the end of the day though it doesn't matter, as long as everyone knows what we are talking about.We all know in this field there is more than one way to do things and in a Medical environment, there is at least 5 names for the same thing.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.