Software Deployment

hi dm1,

well i would be pretty confident in saying the component235 is your trouble area.

just for interests sake more often that not I mark these components not to uninstall to avoid this issue you are currently experiencing. i have some macro code around that identifies these items i will see if i can dig it up for future reference.

now you have 3 or 4 options to sort out here. none of which I have tried.

1) find the content of the component which is causing this break (we have already identified that) create a reg script to drop those keys after uninstallation (I don't really like this but it would work)

2) write some code for the automation object to manipulate the component state prior to running the uninstall of the old version.

something along the lines of this should be about right.

set objInstaller = CreateObject("WindowsInstaller.Installer")
set objProduct = objInstaller("<product code>")
..
..
objSession.ComponentCurrentState("Registry235")
objSession.ComponentRequestState("Registry235") = 3 '(value for leave installed)


from there you could pull the product data of the cached app and hopefully rewrite the uninstall attributes of the component to make it permanent. (again I have not tried this but it should work)

or

grab the database and update the table data which is probably a better option then run the uninstall

3) try using msiexec /x <path to msi or GUID> COMPONENTADDLOCAL=<comp guid>

4) for the migrate feature states deal you would need to match the component code of a dummy component with same identity as the previous one from previous version. the run the installation of hte new app as an upgrade but change the RemoveExistingProducts action close to the FindRelatedProducts action. This would have the effect of not removing the old component which is the desired result.

on another note i have plenty more articles on my blog at johnmcfadyen.spaces.live.com

this highlights a fairly common problem in your packaging process.

1) always test uninstall's prior to releasing your apps.

however all that aside I'm guessing its a little late for that advice to moving on lets try to solve this.

What is the packaging tool you are using.

If it is wise I would say you have merge modules configured on a wise server. A way to test this assumption out would be to look for a component in the component table / view to see if there is a component marked with a name such as

RegistryXXX if there is i would say this is your problem child. The interesting part here is how are you going to fix this.

If you have this component get back to me and we can decide on a way forward to fix the issues. But somehow or rather we are going to need to find a way to keep the component installed during uninstall. Because the app is already installed it sort of limits the options somewhat.

Perhaps we can fool it using a migrate feature / component state trickery to solve the solution.

John,

First of all thanks for your reply. It's not often I get someone in the same time zone replying! (I'm a fan of your articles on Juice). [:D]

I agree with you with regards to having a limited packaging process in place. I'm a contractor and have only been here a number of months, the original v6.4 package having been packaged 2/3 years ago, and deployed company wide (5,000 machines, 10 Citrix servers). The UAT and regression testing here is almost non existant and there's no conflict management in place - again not ideal.

With reference to your RegistryXXX component, I'm assuming you are referring to the "catch-all" component, generated by Wise (which is what we use here..v7.0) when it can't figure out where to assign the registry entries to components in the MSI. I hadn't thought of looking at this as our main problem area, but now that you mention it it makes perfect sense.

As you suspected in the v6.4 package we do indeed have a Registry235 component with lots of registry entries in there. I'd be very interested to hear your ideas on migrate feature/component state trickery!

Thanks mate.

John,

Just getting back to you on this - I've managed to resolve the problem. It transpired that the problem wasn't SAPGUI6.4 at all but a 'dodgy' package created to bundle SAP Single Signon and some other SAP InfoPak Training package.

I had originally created a batch file to remove all SAP related products from the machine. This proved to break several apps as discussed. I incorrectly made the assumption that it must be SAP6.4 as it wasn't packaged in the way I'd have liked, and it was a fairly brutish package. After some further testing I discovered that it was the SSO package as for some reason the original packager decided it would be a good idea to include several System DLLs in the application folder. Hence removing the application breaks anything that uses those DLLs. No isolation or intelligence was applied to this package.

It leaves us with an application we're going to have to keep installed on our base build and support it until we rollout a new O/S. It's a fair inconvenience, but I'm currently just glad I can move forward with this.

Many thanks for your assistance. It was a useful and interesting conversation at the very least.

well you just gave me a thought to write another macro at least, by maintaining a list of SOE based dll's I can whip up a script which will alert the packager when core dll's are to be registered into application based locations.

so yeah it was useful for me too, u just alerted me to another problem area for my automated training scripts.

I hoping some of these "dodgy" legacy MSIs created by inexperienced packagers will be problem solved when we move to Softgrid in 6-ish months. Til then it's make do with what we've got.

SoftGrid won't *solve* those problems, of course: it'll just mean we will no longer need to worry about them!

Where I work... that's "problem solved"....

Crappy packages wrapped in their own little security blanket.