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.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Odd...

The first stage - as ever - is to verbosely log the various install scenarios and compare the logs. Something should hopefully jump out.
Answered 08/04/2011 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 08/04/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
0
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.
Answered 08/04/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
0
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.
Answered 08/04/2011 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 08/04/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
0
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.
Answered 08/04/2011 by: VBScab
Red Belt

Please log in to comment
0
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
Answered 08/04/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
0
If you want to refer to it as local group policy that's fine OK. That'll only be me, Microsoft and everybody else, then! :-)
Answered 08/04/2011 by: VBScab
Red Belt

Please log in to comment
0
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:
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 :)
Answered 08/04/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
0
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'.
Answered 08/05/2011 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 08/05/2011 by: jwiz
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity