I have recently deployed a copy of an application (namely SAP GUI Front End 7.10) to about 40 users. During my WSI Capture, I had a crazy amount of Self-Reg files that I went back and cleaned up by injecting the registry components using wisecomcapture.

In the process, it would seem that several of the DLLs used by SAP (one violator is dmutils.dll [note the 's' at the end, not to be confused with dmutil.dll]) created entries into existing IE dependent CLSID/Interfaces/Typelib tables such as urlmon.dll / ole32.dll / oleaut32.dll / and my favorite mshtml.dll.

When uninstalling the package, it now breaks Internet Explorer's 'Open in new window' - popup function. To resolve this, I have gone through and deleted the registry keys from the package (found by doing wisecomcapture on the previously listed DLLs, and a few others). Otherwise I could do a regsvr32 on each of these components to reregister and fix the IE function... for IE6. Unfortunately for IE7, one cannot re-register mshtml.dll.

So where this leads me to is the fact that I now have a new package with the IE control dll registry entries removed and a new GUID generated. This will work great for new installs of the software, and will not have issues once uninstalled.

Now that I have future installs addressed, I need to repair the existing 'Pilot' users so that they won't encounter the issue.

What happens during uninstall of the previous version is that since we had rogue registry entries installed, once the package uninstalls it removes these, thus breaking the registration, and the IE functions.

I was thinking of creating an MSP that may somehow update the existing MSI cache for the installed users so it won't delete the affected registry keys, but I am uncertain of how exactly I would do this.

Aside using Sapregsv.exe , regtlib.exe, or regsvr32.exe does anyone have some good recommendations to repair the existing installs so that they won't break during uninstall.
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
does anyone have some good recommendations to repair the existing installs so that they won't break during uninstall
Why not update the MSI and then reinstall it?
Answered 08/13/2008 by: AngelD
Red Belt

Please log in to comment
0
I think the main reason I was avoiding it is because I have a few machines that have msi addons that may be affected as well if I uninstall/reinstall the Front End (main) msi.

if I were to do this route - uninstall/reinstalling the msi - would you recommend calling a /fmousv from the server console to override the local cached msi as well as reinstall - OR - a full msiexec /x followed with a msiexec /i

*(additionally I could also call a /fmous on the addons after repairing the base msi if feasable)

There were a few other changes updated beyond the registry in the new version but not many (removed a few files, added a property).
Answered 08/13/2008 by: Digitalweezil
Orange Belt

Please log in to comment
0
AngelD:
Why not update the MSI and then reinstall it?

Are you referring to updating the package source and then executing msiexec -fv on each client?

Digitalweezil:
Just out of curiosity, why did you choose to repackage SAP GUI? They have a great Administrator tool for installing and applying their frequent updates and patches.
Answered 08/13/2008 by: MicrosoftBob
Blue Belt

Please log in to comment
0
I updated my response above...

Bob, we chose to do this because my company uses a custom saplgpad rather than saplogon, they wanted to limit the install size, take advantage of msi benifits such as self healing and such.
Answered 08/13/2008 by: Digitalweezil
Orange Belt

Please log in to comment
0
ORIGINAL: MicrosoftBob

AngelD:
Why not update the MSI and then reinstall it?

Are you referring to updating the package source and then executing msiexec -fv on each client?

Yes
Answered 08/13/2008 by: AngelD
Red Belt

Please log in to comment
0
/fv worked... mostly. now I am battling a 1907 (could not register font) error that occurs during the repair. a normal install doesn't error. Has anyone seen this before?

for the record there are several fonts in the package, and it only occurs when doing an /fv on the older version */fv the new version over itself works fine. I wonder if i killed one to many reg keys.
Answered 08/14/2008 by: Digitalweezil
Orange Belt

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