Software Deployment

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?

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

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?

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

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 see so everything in the fixed package stays the same with the exception of the messed up custom action that will be removed?

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. [;)]

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 [;)] )

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.