Hi,

I have an issue, I'm due to release a new package via GPO, my package installs & removes fine. The problem I have is that a current package that my package will supersede fails to remove.

The way we handle installs is that we create user based group policy installs for each package so essentially each package is a new one. We tie a AD group to the group policy object so our installs are managed by adding/removing users from the group.

Basically an uninstall custom action on a package this is to be remove fails on removal. What would be the best way to remove the package as the current one will just fail.


What would be the best way to get around the uninstall problem?
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
What you describe is exactly how my current client's apps are deployed.

GP will trigger a proper uninstall when users are moved out of the GPO's scope so why are you using a CA for removal?
Answered 11/25/2009 by: VBScab
Red Belt

Please log in to comment
0
Ian,

I think what he means is that one of the CA's executed during uninstall of the MSI fails, so the uninstall doesn't complete successfully.

Anyway, what you can do is make a new version of your bad package without the offending CA, copying it over to the target machines and updating Window's Installer's LocalPackage data for this product at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<Mashed ProductCode>\InstallProperties\LocalPackage

It's dirty but it works.

PJ
Answered 11/25/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
Yup, that's what I mean, so I assume I can give the package the same MSI name, the only thing I would need to change would be the product code right?

Also the part about the registry key, could you possibly explain that in more detail as I'm a bit unclear?
Answered 11/25/2009 by: cowley
Orange Belt

Please log in to comment
0
I'll try :)

When you install an application on your machine, Windows Installer places a minimal version of your MSI on the machine, usually in C:\Windows\Installer\<somejunk>.msi
This is a stripped version of your msi, not containing any files, but everything else needed for repairs and uninstalls. In the registry key I mentioned above, Windows Installer notes which file it has "cached" for the application.

When you uninstall, it's this stripped down MSI that gets executed. You can change the reference that Windows Installer has stored in the registry for your package, making it point to a new MSI you created, that for example does not execute that bad custom action during uninstall, but is otherwise IDENTICAL to the old one (this is rather important, same productcode, packagecode, ...). Now when you trigger an uninstall of the application, your new fixed MSI will run, not the old cached version in C:\Windows\Installer that contains the bad CA. And all should be well...

Hope this makes sense.

PJ
Answered 11/25/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
Whilst that's a neat strategy and would undoubtedly work, it adds one more student to the school of thought which says "I can't work out what's gone wrong so I'm simply going to ignore it and build a way around it."

A verbose log of the uninstall (you can enable logging via GP) should show you which CA is at fault and you can work backwards from there. My suspicion is that the CA isn't conditioned to run only for installations and relies on one or more files from the package being present. When uninstalling, the file (or files) no longer exists so the CA fails.
Answered 11/25/2009 by: VBScab
Red Belt

Please log in to comment
0
I see so everything in the fixed package stays the same with the exception of the messed up custom action that will be removed?
Answered 11/25/2009 by: cowley
Orange Belt

Please log in to comment
0
ORIGINAL: VBScab

Whilst that's a neat strategy and would undoubtedly work, it adds one more student to the school of thought which says "I can't work out what's gone wrong so I'm simply going to ignore it and build a way around it."

A verbose log of the uninstall (you can enable logging via GP) should show you which CA is at fault and you can work backwards from there. My suspicion is that the CA isn't conditioned to run only for installations and relies on one or more files from the package being present. When uninstalling, the file (or files) no longer exists so the CA fails.



I can work out where it's going wrong and which custom action is failing, the issue I have is that time isn't really on my side, it's a very important production system I'm dealing with too :(

The CA is a script to remove xladdins, the logic doesn't make sense, god only knows who passed it in the QA phase.

I'm just looking for a quick and easy route out. [;)]
Answered 11/25/2009 by: cowley
Orange Belt

Please log in to comment
0
Whilst that's a neat strategy and would undoubtedly work, it adds one more student to the school of thought which says "I can't work out what's gone wrong so I'm simply going to ignore it and build a way around it."

I totally agree with you Ian, but the situation being as it is, i.e. I assume the older version is loose in the field and needs to get removed somehow, I still think this is (unfortunately) the better solution. You're right in pointing out the first step is identifying the rogue Custom Action, but if you cannot trigger an uninstall in the field without running into errors your options for fixing it are severely limited, hence this dirty solution. If there is another way to make the CA execute correctly, then by all means...

And cowley, yes, leave everything the same but properly condition your custom action (or remove it if you really must [;)] )
Answered 11/25/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
I've just realised, my only issue with the installing over the top method is that the users will need to stay in the Group tied to the package that fails to uninstall, otherwise the package will continually try and uninstall and fail.
Answered 11/25/2009 by: cowley
Orange Belt

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