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)
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 to 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?

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


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?
Answered 08/11/2011 by: VBScab
Red Belt

Please log in to comment
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.
Answered 08/17/2011 by: aogilmor
Ninth Degree Black Belt

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

Answered 08/17/2011 by: PackagerWannaBe
Orange Senior Belt

Please log in to comment
A solution that worked for us was to unregister MSCOMCT.ocx version and replace it with a newer version from the Microsoft site: MSCOMCT2 version
Everything started working again, including the date picker.

Going back to an older version of MSCOMCT2.ocx did not work
Answered 10/27/2011 by: jjh1
Yellow Belt

Please log in to comment