Windows 7 では、タイトルにリストされているコンポーネントは、デフォルトで「killbit」が COMPAT_EVIL_DONT_LOAD に設定されているように見えます ( MSDNと比較してください)。つまり、HKLM\SW\IE\ActiveX Compatibility\{<CLSID>}\ の互換性フラグです。デフォルトでその値に設定されます:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000400
値を 0 に設定すると (これはNirsoft の ActiveX Compatibility Managerがコンポーネントを「アクティブ化」するときに行うことです)、すべて正常に動作します。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000000
ただし、これは 1 台のワークステーション用の GUI ソリューションにすぎません。ソフトウェアをデプロイするには、ソフトウェアに同梱する安全で安定した手順 (スクリプトまたはツール) が必要です。必要がない場合は何もしません。できれば、ソリューションはファイル名またはファイルのリストを介して渡され、それ以外の必要なすべての処理を単独で実行します。
ここから、より大きな疑問が始まります。
- COM オブジェクトに関して、レジストリは、ocx ファイル名 ( Windows レジストリのInProcServer32エントリ) や(VersionIndependent)ProgID ( HKLM\Software\Classes\CLSID\{<CLSID>}\ ) ではなく、CLSID によってクエリされます。方法、つまり、バッチ / (PowerShell) スクリプト / ツール / ocx ファイルまたは少なくとも ProgID ラジカルに関連する CLSID をクエリする方法を知っていますか?
- CLSID が Windows 2000 から 7 まで一定であることを理解していますか?
- SlayOCX.vbsは、 SlayOCX.vbsおよびhereで説明されているように、グループ ポリシーとして呼び出される低レベルのアプローチのようであり、ネットワーク全体のソリューションとして機能する可能性があります。ただし: これは vbs であり、一部の環境ではオフになっています。さらに、このスクリプトによってチェックされる CLSID のかなりのリストが作成されます。たとえば、バッチでラップされた場合、顧客の管理者が説明した方法で展開することはおそらくできないでしょうが、ログオン スクリプトまたはレジストリの runonce キーなどによって展開することはできません。あまりエレガントではありません。それで、あなたは何を提案しますか?最初の情報に関する質問を不要にする解決策 (ツール、まだわからない 7 の新しいグループ ポリシー、システムやセキュリティ構成の問題への依存度が低い、より洗練されたスクリプトなど) があればいいのにと思います。