WMI が動作しない

WMI スクリプトと WMI サービスに関する問題のトラブルシューティング

トピック

	スクリプトからまったくデータが返されない
	リモート コンピュータに接続できない
	0x8004100E ("無効な名前空間です") エラーが発生する
	0x80041010 ("無効なクラスです") エラーが発生する
	プロパティまたはメソッドがサポートされていないことを示すエラー (0x800A01B6) が表示される
	名前空間名、クラス名、およびプロパティ名が正しいことを確認しても、まだスクリプトが動作しない
	0x80041013 ("プロバイダが見つかりません") エラーまたは 0x80041014 ("Component failed to initialize") エラーが発生する
	プロバイダの登録に関するエラーが表示される
	スクリプトが有効で、WMI サービスが実行されていて、さらにすべての .dll を再登録しても、まだスクリプトが動作しない
	WMI リポジトリを再構築しても、まだスクリプトが動作しない

スクリプトからまったくデータが返されない

まずは、落ち着いてください。WMI スクリプトが完璧に動作したとしてもデータが返されないことは起こり得ます。そのような状況を説明しましょう。次のスクリプトを考えてみましょう。これは、コンピュータに取り付けられた各テープ ドライブの名前を返すスクリプトです。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

For Each objItem In colItems
    Wscript.Echo "Name: " & objItem.Name
Next

もしも、コンピュータにテープ ドライブが取り付けられていないとしたらどうでしょうか。その場合、スクリプトから情報はまったく返されません。これは予想どおりです。つまり、コンピュータにテープ ドライブが取り付けられていなければ、スクリプトはコンピュータに取り付けられているテープ ドライブの名前を返すことはできません。

スクリプトが正しく動作していてもデータが返されないことをチェックする方法の 1 つは、Count プロパティの値を取得することです。WMI クエリによって返される各コレクションには、そのコレクション内のアイテム数を示す Count プロパティがあります。コレクション内にアイテムが存在しない場合でもこのプロパティは含まれています (この場合、Count には 0 が設定されます)。たとえば、次のようなスクリプトがあるとします。これは、コンピュータに取り付けられているテープ ドライブの数 (つまり、Win32_TapeDrive インスタンスの数) を報告するスクリプトです。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery("Select * from Win32_TapeDrive")

Wscript.Echo colItems.Count

Count の値が 0 であれば、スクリプトはおそらく正常に動作しています。Count の値が 1 以上 (1 つ以上のテープ ドライブが取り付けられていることを意味します) 場合は、問題が発生しています。その場合は、WQL クエリの条件が多すぎて、その条件を満たすアイテムが存在しなかった可能性があります。たとえば、次のスクリプトを実行すると、現在実行されているすべての Alerter という名前のサービスに関する情報が返されます。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_Service Where Name = 'Alerter' and State = 'Running'")

For Each objItem In colItems
    WScript.Echo "Name: " & objItem.Name
Next

もちろん、コンピュータで Alerter サービスが停止していれば、このスクリプトからデータは返されません。これは、サービスの Name が Alerter、かつ State が Running という条件の一方が満たされていないためです。

スクリプトからデータが返されないという問題の場合、まず WQL クエリを簡単にすることから着手してください。たとえば、次のようなスクリプトでは Where 句を削除し、単にコンピュータにインストールされている各サービスの Name と State を返します。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery ("Select * from Win32_Service")

For Each objItem In colItems
    WScript.Echo objItem.Name, objItem.State
Next

このスクリプトを実行することで、Alerter サービスの名前と状態を確認してから、必要に応じて Where 句を調整して再実行できます。すべての Windows コンピュータ (Windows 98 コンピュータは除きます) には何らかのサービスがインストールされているため、上記のスクリプトを実行すると何らかのデータが必ず返されます。データがまったく返されなければ、問題は深刻なので、このまま資料を読み進めてください。

ページのトップへ

リモート コンピュータに接続できない

ローカル コンピュータではスクリプトが正常に動作するのに、実行対象をリモート コンピュータに変えた途端、次のようなエラー メッセージが表示されるといったことがよくあります。

このようなエラー メッセージが表示された場合、ローカル コンピュータまたはリモート コンピュータのいずれかの WMI サービスで問題が発生している可能性があります。ただし、すべての場合がこれに当てはまるわけではありません。通常、リモート コンピュータへの接続に関する問題は、次のようなシナリオで発生します。

リモート コンピュータへの接続に関する問題が発生した場合、最初にすべきことは、問題がスクリプトと接続のどちらにあるかを判断することです。これを行うには、リモート コンピュータの場所まで行き、スクリプトをローカルに実行します (つまり、そのリモート コンピュータから直接スクリプトを起動します)。スクリプトが動作すれば、問題は接続にある可能性が高いので、おそらくファイアウォールか DCOM の設定に原因があります。スクリプトが動作しなければ、リモート コンピュータの WMI サービスに問題があります。この場合、別のリモート接続を試す前に、スクリプトをローカルに実行してみてください。

WMI とリモート マシンの詳細については、WMI SDK の「Connecting to WMI on a Remote Computer」(英語) を参照してください。

ページのトップへ

0x8004100E ("無効な名前空間です") エラーが発生する

通常、名前空間が無効であることを示すエラーは、次の 2 つの問題のうちのいずれかが原因で発生します。1 つ目の問題は、単なる名前空間名の綴り間違いです。たとえば、次のスクリプトでは root\cim2v 名前空間に接続しようとしていますが、この名前空間は存在しないため、スクリプトは 0x8004100E エラーで失敗します。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cim2v")

この場合、"root\cim2v" を正しい名前の "root\cimv2" に変更すると、問題は解決します。

2 つ目の問題は、接続を試みている名前空間が、一部のコンピュータには存在しても、存在しないコンピュータがあることです。たとえば、root\RSOP 名前空間は Windows XP と Windows Server 2003 には存在しますが、Windows 2000 には存在しません。これは、Windows 2000 を実行しているコンピュータでは、次のスクリプトが失敗することを意味します。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\rsop")

さらに、特定のアプリケーションは独自の名前空間を作成します。つまり、オペレーティング システムの既定のインストールに含まれていないカスタム名前空間です。コンピュータで SMS クライアントを実行している場合、そのコンピュータには root\SMSDm 名前空間が存在しますが、SMS がインストールされていない場合、その名前空間はコンピュータに存在しません。コンピュータ A で正しく動作するスクリプトが、コンピュータ B で名前空間が無効であることを示すエラーで失敗する場合、オペレーティング システムの違いや、インストールされているアプリケーションとハードウェアの違いを調べると原因がわかることがよくあります。

名前空間が無効であることを示すエラーが表示された場合、結論を急ぐ前に、これら 2 つの可能性 (名前空間名の綴りが間違っているか、名前空間が特定のコンピュータに存在しない可能性) を排除する必要があります。名前空間が存在することと、名前空間の綴りが正しいことを簡単に確認する方法の 1 つとして、Scriptomatic 2.0 を使用できます。Scriptomatic ユーティリティは、簡単な WMI スクリプトの作成を支援するためにデザインされましたが、WMI サービスに関する問題の診断にも使用できます。

Scriptomatic をダウンロードおよびインストールした後に起動し、WMI 名前空間に関する情報が読み込まれるまで待機します。次に、"WMI Namespace" というラベルの付いた次のようなドロップダウン リストをクリックします。

このドロップダウン リストには、コンピュータに含まれるすべての WMI 名前空間が表示されるため、1) 名前空間が実際にコンピュータに存在することと、2) 名前空間名の綴りを正しく記述したことを簡単に確認できます。

しかし、名前空間が存在していて、さらにその名前の綴りも正しく記述していた場合はどうすればよいでしょうか。その場合は、root\default 名前空間へのバインドを行う次のスクリプトを実行してみてください。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\default")

このスクリプトが成功した場合、WMI サービスは正しく動作しているため、おそらく問題があるのは上記で確認した名前空間だけです。その場合、問題の名前空間の MOF ファイルを再コンパイルする必要があります。MOF ファイルの再コンパイルの詳細については、「プロバイダの登録に関するエラーが表示される」を参照してください。root\default への接続が失敗した場合、問題はさらに深刻です。その場合は、WMI サービスを停止してから再起動し (「名前空間名、クラス名、およびプロパティ名が正しいことを確認しても、まだスクリプトが動作しない」を参照してください)、もう一度接続してください。

また、コマンド プロンプトから次のコマンドを使用して、root\default 名前空間への接続を試みることもできます。

wmic /interactive:on /namespace:\\root\default

"対話モードが設定されます" というメッセージが表示された場合は、root\default 名前空間に接続できたことを意味します。"無効な名前空間です" というメッセージが表示された場合は、接続が失敗したことを意味します。

ページのトップへ

0x80041010 ("無効なクラスです") エラーが発生する

0x80041010 エラー メッセージは、存在しない WMI クラスの参照を試みていることを意味します。通常、このエラーは次のような場合に発生します。

無効なクラスに関するエラーが発生した場合は、もう一度 Scriptomatic を使用します。Scriptomatic をダウンロードおよびインストールした後に起動し、WMI 名前空間に関する情報が読み込まれるまで待機します。情報が読み込まれたら、"WMI Namespace" というラベルの付いたドロップダウン リストをクリックし、適切な名前空間を選択します (たとえば、クラスが明らかに root\wmi 名前空間に存在する場合は、root\wmi を選択します)。クラス情報が読み込まれたら、[WMI Class] ドロップダウン リストをクリックし、目的のクラスが存在するかどうかを確認して、存在する場合はそのクラス名の綴りを正しく記述したかどうかを確認します。

一覧に目的のクラスが表示されない場合、そのクラスは存在しないか、他の名前空間に存在します。WMI リポジトリ全体を眺めて目的のクラスを探す場合は、ドロップダウン リストから他の名前空間を選択します。

指定した名前空間に目的のクラスが存在する場合 (かつ名前空間名とクラス名の綴りを正しく記述している場合)、WMI サービスに関してさらに深刻な問題が発生している可能性があります。その場合は、Win32_Process クラスへのバインドを行う次のスクリプトを実行してください。

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")

このスクリプトが成功すれば、WMI サービスは正しく動作しているため、おそらく問題があるのはこの目的のクラスだけです。その場合、問題のクラスの MOF ファイルを再コンパイルする必要があります。MOF ファイルの再コンパイルの詳細については、「プロバイダの登録に関するエラーが表示される」を参照してください。Win32_Process クラスへの接続が失敗した場合、問題はより深刻です。その場合は、WMI サービスを停止してから再起動し (「名前空間名、クラス名、およびプロパティ名が正しいことを確認しても、まだスクリプトが動作しない」を参照してください)、もう一度接続してください。

コマンド プロンプトから次のコマンドを実行して、Win32_Process クラスへの接続を試すこともできます。

wmic path “Win32_Process” get Name

接続が成功すれば、現在コンピュータで実行されているすべてのプロセスの一覧がコマンド ウィンドウに表示されます。接続に失敗すると、無効なクラスであることを示すエラーが表示されます。

ページのトップへ

プロパティまたはメソッドがサポートされていないことを示すエラー (0x800A01B6) が表示される

スクリプトを実行すると、次のようなエラー メッセージが表示される場合があります。

一般に、このエラーは次の 2 つの場合のいずれかに発生します。多くの場合は、単にプロパティ名やメソッド名の綴りを間違えて入力しています。上記の例では、"Name" という名前のプロパティではなく、存在しない "Namex" という名前のプロパティに関する情報を返そうとしています。この問題のトラブルシューティングを行うときは、ダイアログ ボックスに表示されている情報を使用します。通常、このダイアログ ボックスには、エラーが発生したコード行 (ここでは行 5) と無効なプロパティ名またはメソッド名 (Namex) が表示されます。その後、Scriptomatic か Wbemtest.exe を使用して、実際のプロパティ名を確認できます。

この問題は、異なるバージョンの Windows を実行しているコンピュータで作業しているときにも発生する場合があります。たとえば、Windows XP と Windows Server 2003 の Win32_UserAccount クラスには、LocalAccount という名前のプロパティが含まれています。Win32_UserAccount クラスは Windows 2000 にもありますが、Windows 2000 にインストールされている WMI のバージョンには LocalAccount プロパティが含まれていません。異なるバージョンの Windows で作業している場合は、Scriptomatic を使用して、双方のコンピュータのプロパティを比較してください。

プロパティ名が正しくても、まだスクリプトが失敗する場合は、この資料の「名前空間名、クラス名、およびプロパティ名が正しいことを確認しても、まだスクリプトが動作しない」を参照してください。

コマンド プロンプトから次のコマンドを入力して、WMI クラスのすべてのプロパティとメソッドの一覧を XML 形式で取得することもできます。

wmic class "win32_useraccount"

ページのトップへ

名前空間名、クラス名、およびプロパティ名が正しいことを確認しても、まだスクリプトが動作しない

通常、WMI サービス (winmgmt) は常時実行されています。このサービスはコンピュータの起動と同時に開始され、コンピュータがシャットダウンされるまで停止しません。停止することもできますが、このサービスは、ツール (Wbemtest.exe など) や WMI スクリプトを使用して WMI 名前空間に接続するたびに自動的に再起動するようにデザインされています。

可能性は低いですが、スクリプトの実行時に、WMI サービスの停止と再起動が失敗する場合があります。スクリプトで問題が発生した場合、このサービスを明示的に停止して再起動することで、問題を解決できる場合があります。"WMI リポジトリの再構築などの思い切った手段を取る前に、必ず WMI サービスの停止と再起動を試すようにしてください。"

WMI サービスの再起動

WMI サービスは、コマンド プロンプトから次のコマンドを入力して再起動できます。

net start winmgmt

サービスの再起動に失敗したり、再起動しても問題が解決されない場合は、次のセクションの手順を試してください。

WMI サービスの停止と再起動

WMI サービスに関する問題が発生した場合、手動でこのサービスを停止して再起動する必要が生じることがあります。この操作を行う前に、WMI の詳細ログ オプションを有効にしてください。これにより、WMI エラー ログに詳細情報が記録され、問題の診断に役立つ場合があります。WMI コントロールを使用して詳細ログを有効にするには、次の操作を行います。

または、次のレジストリ値を変更できます。

詳細ログを有効にしたら、コマンド プロンプトで次のコマンドを入力して WMI サービスを停止します。

net stop winmgmt

net stop コマンドが失敗した場合は、次のコマンドを入力して強制的に WMI サービスを停止できます。

winmgmt /kill

その後、次のコマンドを入力して WMI サービスを再起動できます。

net start winmgmt

WMI サービスが再起動されない場合は、コンピュータを再起動して、問題が解決するかどうかを確認します。解決しない場合は、さらに資料を読み進めてください。

ページのトップへ

0x80041013 ("プロバイダが見つかりません") エラーまたは 0x80041014 ("Component failed to initialize") エラーが発生する

率直に言うと、このようなエラーの解決はやや困難です。エラー番号 0x80041013 は、"COM がスキーマで参照されるプロバイダの場所を特定できない" ことを示しています。また、エラー番号 0x80041014 は、コンポーネント (WMI プロバイダなど) を "内部の理由で初期化できなかった" ことを示しています。これら 2 つのエラーのいずれかが表示された場合は、WMI に関連付けられているすべての .DLL ファイルと .EXE ファイルの再登録が必要になる可能性が高くなります。

まず、%windir%\System32\Wbem フォルダにあるすべての .DLL ファイルを再登録する必要があります。コマンド ウィンドウを開き、cd コマンドを使用して、%windir%\System32\Wbem ディレクトリに移動します。次に、コマンド プロンプトで次のコマンドを入力し、Enter キーを押します。

for %i in (*.dll) do RegSvr32 –s %i

.DLL ファイルを再登録したら、Wbem フォルダにある、Mofcomp.exe と Wmic.exe を除くすべての .EXE ファイルを再登録する必要があります。たとえば、実行可能ファイルの Scrcons.exe を再登録するには、コマンド プロンプトで次のコマンドを入力します。

regsvr32 –s scrcons.exe

.EXE ファイルを再登録したら、もう一度スクリプトを実行します。スクリプトがエラー番号 0x80041011、0x80041012、または 0x80041085 で失敗した場合は、この資料の「プロバイダの登録に関するエラーが表示される」を参照してください。

ページのトップへ

プロバイダの登録に関するエラーが表示される

WMI コンポーネントを再登録 (「0x80041013 ("プロバイダが見つかりません") エラーまたは 0x80041014 ("Component failed to initialize") エラーが発生する」を参照してください) しても、スクリプトを実行できない場合があります。具体的には、次のいずれかのエラーが表示されます。

これらのうち、いずれかのエラーが表示された場合は、1 つ以上の .MOF ファイルを再コンパイルする必要があります。MOF (マネージ オブジェクト形式) ファイルは、WMI クラスに関する情報を WMI リポジトリに入力するメカニズムです。現在リポジトリにあるクラス定義は、何らかの理由で壊れている可能性があります。この場合、.MOF ファイルを再コンパイルすると、このようなクラス定義を、オペレーティング システムのインストール時に使用された、壊れていないクラス定義で上書きおよび置換します。

.MOF ファイルの再コンパイルを開始する前に、2 つの点に注意してください。1 つ目は、ほとんどの .MOF ファイルは %windir%\System32\Wbem フォルダにありますが、例外もあることです。再コンパイルを開始する前に、ハード ディスク上のすべての .MOF ファイルを検索しておくことをお勧めします。

2 つ目は、インストール中に自動的にリポジトリを作成するアプリケーションがあることです。これらのアプリケーションでは、.MOF ファイルが使用されません。このようなアプリケーションの 1 つが WMI サービスに関する問題の原因になっている (診断するのは確かに難しいですが) 場合、リポジトリのクラス定義を修復する唯一の方法は、アプリケーションを再インストールすることです。

.MOF ファイルと .MFL ファイル (多くの場合、.MOF ファイルには対応する .MFL ファイルが存在し、このファイルには、クラス、プロパティ、およびメソッドのローカライズされた説明が含まれています) を最も簡単に再コンパイルするには、コマンド ウィンドウを開き、cd コマンドを使用して %windir%\System32\Wbem フォルダに切り替えます。その後、次のコマンドを入力します。

for %i in (*.mof, *.mfl) do Mofcomp %i

スクリプトまたはバッチ ファイルを使用して .MOF ファイルを再コンパイルする場合、または手動で Mofcomp.exe を呼び出す場合は、.MOF ファイルをコンパイルしてから、対応する .MFL ファイルをコンパイルしてください。つまり、次の順番でアイテムをコンパイルします。

Mofcomp.exe cimwin32.mof
Mofcomp.exe cimwin32.mfl

正直に言うと、すべての MOF ファイルと MFL ファイルを再コンパイルするよりも、WMI リポジトリを再構築した方が速くて簡単です。リポジトリの再構築の詳細については、この資料の「スクリプトが有効で、WMI サービスが実行されていて、さらにすべての .dll を再登録しても、まだスクリプトが動作しない」を参照してください。.MOF ファイルと .MFL ファイルの再コンパイルは、レジストリの一部しか壊れていないと確信できる理由がある場合のみ役立ちます。その場合は、レジストリ全体を再構築しなくても、影響のある MOF ファイルと MFL ファイルだけを再コンパイルできます。

もちろん、これにより 2 つの疑問が浮かび上がります。1 つ目は、なぜ単純にリポジトリを再構築しないのかということです。リポジトリの再構築は可能ですが、リポジトリを削除して置換することにはいくつかの危険が伴います。たとえば、WMI リポジトリは主に WMI 自体のメタ情報を格納する場所です。しかしリポジトリには、一部の静的クラスのデータが格納されることもよくあります。リポジトリを再構築すると、そのようなデータがすべて失われます。こうしたデータの例には、WMI サービスと共に登録された永続的なイベント コンシューマがあります。確かに大部分のユーザーには影響しませんが、影響する可能性は残ります。

2 つ目は、リポジトリの一部だけを再構築する場合に、再コンパイルする MOF ファイルと MFL ファイルを知る方法です。最も簡単な方法は、.MOF ファイル (通常は %windir%\System32\Wbem フォルダにあります) で、問題が発生しているクラスの名前を探すことです。クラス名は、適切な .MOF ファイル内に記述されています。これは、.MOF ファイルが、クラスに関する情報を WMI リポジトリに追加する役割を担っているためです。

ページのトップへ

スクリプトが有効で、WMI サービスが実行されていて、さらにすべての .dll を再登録しても、まだスクリプトが動作しない

WMI リポジトリ (%windir%\System32\Wbem\Repository) は、WMI クラスのメタ情報と定義を格納するデータベースです。このリポジトリには、静的クラスのデータも格納される場合があります。リポジトリが壊れた場合、WMI サービスは正常に機能できなくなります。ここまで紹介したすべての解決策 (名前空間の確認から個別の .MOF ファイルの再コンパイルまで) を試しても解決しない場合は、リポジトリが壊れている可能性があります。幸運にも、リポジトリは修復できる場合があります。修復に必要な手順は、実行している Windows のバージョンによって異なります。

Windows Server 2003 Service Pack 1

Windows Server 2003 Service Pack 1 を実行しているコンピュータで問題が発生している場合、まずコマンド プロンプトで次のコマンドを入力して、整合性チェックを実行してください。

rundll32 wbemupgd, CheckWMISetup

このコマンドを実行した後、WMI セットアップ ログ (%windir%\System32\Wbem\Logs\Setup.log) を確認します。次のようなエントリが見つかった場合、整合性チェックに失敗しています。

(Wed Oct 12 14:17:14 2005): Failing Connecting to Namespace [root\default] with result [80041002]

不整合が見つかった場合は、リポジトリが壊れていることを意味します。その場合、コマンド プロンプトで次のコマンドを入力すると、リポジトリの修復を試みることができます (ここでもパラメータ RepairWMISetup の大文字と小文字は区別されます)。

rundll32 wbemupgd, RepairWMISetup

修復コマンドが成功した場合、セットアップ ログに次のようなエントリが表示されます。

(Wed Oct 12 14:21:24 2005): ERROR: wbemupgd.dll. The WMI repository has failed to upgrade. 
The repository has been 
backed up to C:\Windows\System32\Wbem\Repository.001 and a new one created.

修復が失敗したり、スクリプトがまだ動作しない場合は、Microsoft 製品サポート サービスに問い合わせる必要があります。

Microsoft Windows XP Service Pack 2

Windows XP Service Pack 2 を実行している場合、1 つのコマンドを使用して、壊れている WMI リポジトリを検出および修復できます。これを行うには、コマンド プロンプトで次のコマンドを入力します。パラメータ UpgradeRepository では大文字と小文字が区別されるので、示したとおりに正確に入力してください。

rundll32 wbemupgd, UpgradeRepository

UpgradeRepository を実行した後、セットアップ ログで結果を確認できます。不整合が検出され、オペレーティング システムがリポジトリを再構築できなかった場合、次のような情報が Setup.log に表示されます。

(Wed Oct 12 13:46:36 2005): ===========================================================================
(Wed Oct 12 13:46:36 2005): Beginning WBEM Service Pack Installation
(Wed Oct 12 13:46:36 2005): Current build of wbemupgd.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:36 2005): Current build of wbemcore.dll is 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
(Wed Oct 12 13:46:52 2005): Inconsistent repository detected; it will be recreated
…
…
(Wed Oct 12 13:47:33 2005): Wbemupgd.dll Service Security upgrade succeeded (XP SP update).
(Wed Oct 12 13:47:33 2005): WBEM Service Pack Installation completed.
(Wed Oct 12 13:47:33 2005): ===========================================================================

修復が失敗したり、スクリプトがまだ動作しない場合は、Microsoft 製品サポート サービスに問い合わせる必要があります。

Windows のその他のバージョン

WMI リポジトリを再構築するための組み込みコマンドが含まれているのは、Windows Server 2003 Service Pack 1 と Windows XP Service Pack 2 だけです。その他のバージョンの Windows では、次の操作を行うことによってリポジトリを再構築できます。

それでもスクリプトが失敗する場合は、この資料の「プロバイダの登録に関するエラーが表示される」に記載されている手順を使用して、手動で WMI リポジトリを再構築してください。

問題が解決したら

WMI リポジトリを再構築し、スクリプトが動作するようになった場合、次のことを行ってください。まず、WMI サービスを停止し、現在の Repository フォルダの名前を (Repository_good などに) 変更してから、もう一度 Repository_bad を Repository に戻します (名前を Repository に変更します)。次に WMI サービスを再起動し、スクリプトが動作するかどうかを確認します。動作しない場合は、単純に Repository_good をもう一度 WMI リポジトリにします。

なぜこのような操作を行うのでしょうか。既に説明したように、リポジトリの再構築には特有の危険性があります。たとえば、インストール中のみ WMI リポジトリの更新を実行するアプリケーションを使用している場合があります。このようなアプリケーションには MOF ファイルがないか、使用しません。リポジトリを再構築すると、それらのアプリケーションの WMI データは、少なくともそのプログラムを再インストールしなければ、失われてしまいます。同様に、永続的なイベント コンシューマや、その他の種類のデータがリポジトリに格納されている場合があります。リポジトリを再構築すると、それらのデータは失われます。古いリポジトリが使用できれば、このようなデータの損失を防ぐことができます。

ページのトップへ

WMI リポジトリを再構築しても、まだスクリプトが動作しない

この資料の手順をすべて実行してもまだ WMI が動作しない場合はどうすればよいでしょうか。その場合は、Microsoft 製品サポート サービス (PSS) に問い合わせる必要があります。問い合わせる前に、次の情報を確認してください。

詳細については、http://support.microsoft.com/default.aspx を参照してください。

ページのトップへ