SAP 7.20 and mscomct2.ocx
Hello all, I seek your expert advices on an existing conflict in one of our environment.
Current environment includes:
Office 2003 (to be upgraded to office 2010 later this year)
VBRuntime
SAP 7.20 Patch5
No wise conflict management
Since Sap upgrade from 7.1 P12, we are having a conflict with office 2003 that was not caught during UAT. The actual conflict involves mscomct2.ocx that was upgraded from version 6.0.84.18 to 6.1.98.12 by SAP 7.20 itself.
Since this file upgrade, in Word, Microsoft Script Editor, Microsoft Date and Time Picker Com control can no longer be selected. This control is binded to mscomct2.ocx.
For testing purposes, we did a quick test on a VM and selfreg the new version of the ocx and now the control is selectable in the list. The problem is, script using this control still not work (this is our main problem).
Anyway, long story short, SAP 7.2 overwrite many system32 files. SAP was not repackaged and was deployed according to SAP deployment guide. Microsoft does not seems to provide updated MSM files for packaging anymore. I am now faced with a conflict and I am wondering if anybody faced similar problem before.
What looks strange to me is SAP upgraded that mscomct2.ocx file and Microsoft Date and Time picker control was not available in the list as if the OCX was not even on the machine at all.
Anybody have suggestions?
Thanks
Current environment includes:
Office 2003 (to be upgraded to office 2010 later this year)
VBRuntime
SAP 7.20 Patch5
No wise conflict management
Since Sap upgrade from 7.1 P12, we are having a conflict with office 2003 that was not caught during UAT. The actual conflict involves mscomct2.ocx that was upgraded from version 6.0.84.18 to 6.1.98.12 by SAP 7.20 itself.
Since this file upgrade, in Word, Microsoft Script Editor, Microsoft Date and Time Picker Com control can no longer be selected. This control is binded to mscomct2.ocx.
For testing purposes, we did a quick test on a VM and selfreg the new version of the ocx and now the control is selectable in the list. The problem is, script using this control still not work (this is our main problem).
Anyway, long story short, SAP 7.2 overwrite many system32 files. SAP was not repackaged and was deployed according to SAP deployment guide. Microsoft does not seems to provide updated MSM files for packaging anymore. I am now faced with a conflict and I am wondering if anybody faced similar problem before.
What looks strange to me is SAP upgraded that mscomct2.ocx file and Microsoft Date and Time picker control was not available in the list as if the OCX was not even on the machine at all.
Anybody have suggestions?
Thanks
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
SAP was not repackagedHerein is an object lesson in why we re-package. If you *had* re-packaged, fed the MSI into Wise and then CMed it, you'd have spotted the issue straight away.
SAP 7.2 overwrite many system32 files...and, in the process, corrupts your build. Oops.
From your description, it sounds like the SAP installer unregistered the OCX before replacing it then failed to register it. So, you can either re-package the entire install (not hard - it's a big package but from memory there are no real "gotchas") or build a "fix" MSI which includes the OCX you want - not necessarily SAP's - and registers it. Do try to avoid using RegSvr32 or MSIEXEC /Y for that. Do it properly via the advertising tables. Of course, you will already have Wise set up to do that by default, right?
Posted by:
aogilmor
13 years ago
I usually agree with you Ian but I think repackaging SAP is a recipe for pulling ones hair out. I used Sap's admin install to package 7.1 and had no issues; if I did, I would have fixed it by (in this case) registering the problem ocx. OTOH, repackaging 6.4 really sucked - Wise tried to self reg lots of files that wouldn't. Maybe your above setting would have fixed that, or the current version of wise.
Posted by:
PackagerWannaBe
13 years ago
Hello again,
thks for the input.
INvestigation team had to react quickly on this and decided to launch script that will register the old ocx file.
I am sure its not the best way to fix this and wondering how would have been the best practice for such issue, lets say using wise without the selfreg table so I can apply the best method in the future.
Thks,
thks for the input.
INvestigation team had to react quickly on this and decided to launch script that will register the old ocx file.
I am sure its not the best way to fix this and wondering how would have been the best practice for such issue, lets say using wise without the selfreg table so I can apply the best method in the future.
Thks,
Posted by:
jjh1
13 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.