Hello! I have a package that installs, works and uninstalls properly. But when it is installed via GPO , the removal from Add/Remove programs fails. Nothing happens and the Remove icon remains. I tried to play with the HKLM\Software\Microsoft\Windows\CurrentVersion\uninstall\{GUID} reg key, but without success. I also tried to suppress it by adding ARPSYSTEMCOMPONENT=1 and creating a new uninstall key. Even that didn't help. If I install the msi manually (double click), I am able to remove it later without any issues. But it fails to remove the application, when the installation has been done via GPO. Have any of you faced this situation? Where else should I look at to figure out this difference in behavior?
0 Comments   [ - ] Hide 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.
Answer this question or Comment on this question for clarity


Hey Pack,

Have you tried looking at the msi log file in your temp directory? That's usually where I start first.
Answered 04/16/2008 by: Estes
Second Degree Blue Belt

Please log in to comment
Have you tried looking at the msi log file in your temp directory?
...advice which presume that the OP has the MSI Logging policy enabled, of course. This isn't something which is on by default, or something that one would want to leave permanently on because a user's local drive would pretty soon be full of MSI[blah].LOG files, because the MSI Logging policy logs EVERYTHING, including advertisements.

So, yes, the first stage is to enable that policy. It's probably quickest to apply it to one machine at first whilst testing. Easiest route is to merge in this .REG:

Logs end up in %TEMP%, prefixed 'MSI' and named with a 4- to 6-character alphanumeric name and .LOG extension. I always use the DOS FIND utility to seek out which file belongs to the MSI I'm interested in, as it's a lot quicker than Windows Search:

FIND /C /I "text to search for" MSI*.LOG

where "text to search for" is the name of the MSI in full.

Next, does GPRESULT show that the policy got applied successfully?
Next, is the user's DC properly synchronised with the DC where the policy was defined (if you recently changed the policy)? At my current client, we frequently have to use GPUPDATE /FORCE to ensure that users/machines have a policy applied and even then we have to wait, sometimes up to 30 minutes, before THAT'S successful. From my experience here, I'm not a big fan of GPO deployment. It just seems so....wing-and-prayer. Still, the client's too cheap to go for a proper system and we're stuck with it so...

When your testing is complete, don't forget to turn off logging.
Answered 04/17/2008 by: VBScab
Red Belt

Please log in to comment