Hi all,

I've recently had the task of repackaging SAP GUI 7.10 for all desktops and Citrix servers in my Organisation. Although mildly challenging, everything has gone well and it seems to work well on it's own. The trouble I've experienced relates to the removal of the previous package - it breaks up to TEN applications on the machine, including Outlook, IE, IPFX, Word, etc etc. So MAJOR issues moving forward.

I've examined the original 6.4 package and it seems to have been a dodgy capture with about 30,000 registry keys. We don't have a conflict database so no component GUIDs syncronised and any attempts to run Wise Upgrade Sync lead to major problems. I was looking at deploying this through SMS with a msiexec /x {6.4 GUID} followed by msiexec /i "7.10.msi" but removing 6.4 absolutely wrecks the machine.

Two methods I've thought of using so far have been:

1. Maybe using MSIZAP for the 6.4 MSI and then installing 7.10 over the top, but it doesnt work well, and running the SAP Installation Check tool red flags about 14/15 incorrectly versioned DLLs/OCXs. So I've binned that idea.

2. Repackaging 7.10 but installing to a different folder other than C:\Program Files\SAP\FrontEnd (or whatever 6.4 uses as default). I'm thinking that the DLLs will register in different folders and therefore work side by side with the old version. then just remove the old 6.4 directory and application entry points, retaining all of the old registry. I'm sure this isn't prefect though as a self heal is likely to occur at some point sure enough. Maybe combining this with an MSIZAP might work?

Either way I'm going to have to hack this to death. If anyone has come across this type of problem before, I'd really appreciate some practical advice.

Many Thanks.
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


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.
Answered 05/25/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment

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.
Answered 05/25/2008 by: dm1
Blue Belt

Please log in to comment
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.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)


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
Answered 05/26/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment

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.
Answered 05/27/2008 by: dm1
Blue Belt

Please log in to comment
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.
Answered 05/27/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
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.
Answered 05/28/2008 by: dm1
Blue Belt

Please log in to comment
SoftGrid won't *solve* those problems, of course: it'll just mean we will no longer need to worry about them!
Answered 05/29/2008 by: VBScab
Red Belt

Please log in to comment
Where I work... that's "problem solved"....

Crappy packages wrapped in their own little security blanket.
Answered 05/29/2008 by: dm1
Blue Belt

Please log in to comment