DLL He... adache with SAP and IE mshtml controls
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.
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
Answers (6)
Please log in to answer
Posted by:
AngelD
15 years ago
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?
Why not update the MSI and then reinstall it?
Posted by:
Digitalweezil
15 years ago
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).
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).
Posted by:
MicrosoftBob
15 years ago
AngelD:
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.
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.
Posted by:
Digitalweezil
15 years ago
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.
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.
Posted by:
AngelD
15 years ago
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
Posted by:
Digitalweezil
15 years ago
/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.
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.