/build/static/layout/Breadcrumb_cap_w.png

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

0 Comments   [ + ] Show comments

Answers (4)

Posted by: anonymous_9363 13 years ago
Red Belt
0
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
9th Degree Black Belt
0
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
Orange Senior Belt
0
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,
Posted by: jjh1 13 years ago
Yellow Belt
0
A solution that worked for us was to unregister MSCOMCT.ocx version 6.1.98.12 and replace it with a newer version from the Microsoft site: MSCOMCT2 version 6.1.98.16.
Everything started working again, including the date picker.

Going back to an older version of MSCOMCT2.ocx did not work
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ