Geheimnisse von Windows Management Instrumentation Problembehandlung und Tipps

Veröffentlicht: 28.07.2004 | Aktualisiert: 09. Okt 2004

Hinweis: Dieses Dokument wurde ursprünglich unter dem Titel "Windows Management Instrumentation: Häufig gestellte Fragen" veröffentlicht.


Auf dieser Seite

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 1. Was ist WMI, und wozu kann ich es verwenden?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 2. Auf welchen Plattformen ist WMI verfügbar?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 3. Woran kann ich erkennen, ob WMI eine bestimmte Funktionalität aufweist?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 4. Wie kann ich vorgehen, wenn WMI die benötigten Funktionen nicht bereitstellt?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 5. Wo kann ich Beispielskripts finden, in denen WMI verwendet wird?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 6. Warum wird mein Skript unter einer Windows-Version ausgeführt, unter einer anderen jedoch nicht?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 7. Warum wird bei einem WMI-Vorgang ein Fehler zurückgegeben?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 8. WMI funktioniert nicht. Welche Problembehandlung ist möglich?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 9. Wie kann ich die WMI-Namespacesicherheit festlegen?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 10. Wie kann ich Remotecomputer mithilfe von WMI verwalten?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 11. Warum schlägt mein Remotevorgang fehl, wenn ein dritter Computer beteiligt ist?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 12. Warum dauert die Ausführung meiner Abfragen so lange?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 13: Wie kann ich alle auf einem bestimmten Computer installierten Anwendungen auflisten?

Dn151197.ACDCF196BC98A92A7E35715F19C8C405(de-de,TechNet.10).png F 14. Wie kann ich Leistungsindikatorendaten abrufen?


F 1. Was ist WMI, und wozu kann ich es verwenden?

Windows Management Instrumentation (WMI) ist eine grundlegende Windows-Verwaltungstechnologie; mithilfe von WMI können Sie sowohl lokale Computer als auch Remotecomputer verwalten. WMI bietet einen einheitlichen Ansatz für die Ausführung täglicher Verwaltungsaufgaben mit Programmier- oder Skripterstellungssprachen. Beispiele:

  • Starten eines Prozesses auf einem Remotecomputer
  • Planen eines Prozesses, der an bestimmten Tagen zu bestimmten Uhrzeiten ausgeführt werden soll
  • Remoteneustart eines Computers
  • Abrufen einer Liste von Anwendungen, die auf einem lokalen Computer oder einem Remotecomputer installiert sind
  • Abfragen der Windows-Ereignisprotokolle auf einem lokalen Computer oder einem Remotecomputer

Das Wort "Instrumentation" in WMI bezieht sich auf die Tatsache, dass WMI Informationen zum internen Status von Computersystemen abruft, ähnlich wie die Instrumente im Armaturenbrett von Autos Informationen zum Motorstatus abrufen und anzeigen können. Die Instrumentation in WMI erfolgt durch das Modellieren von Objekten wie Datenträgern, Prozessen oder anderen Objekten in Windows-Systemen. Diese Computersystemobjekte werden mithilfe von Klassen, z. B. Win32_LogicalDisk oder Win32_Process, modelliert; dabei modelliert die Klasse Win32_LogicalDisk die auf einem Computer installierten logischen Datenträger und der Prozess Win32_Process alle Prozesse, die momentan auf einem Computer ausgeführt werden. Klassen basieren auf einem erweiterbaren Schema namens "Common Information Model" (CIM): Beim CIM-Schema handelt es sich um einen öffentlichen Standard der Distributed Management Task Force (http://www.dmtf.org).

Zu den WMI-Funktionen zählen unter anderem auch Ereignis-, Remote- und Abfragefunktionen, Sichten, Benutzerererweiterungen zum Schema und Instrumentation.

Weitere Informationen zu WMI erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach dem Stichwort "About WMI" (nur auf Englisch verfügbar) suchen oder auf der deutschen MSDN-Website http://www.microsoft.com/germany/msdn/default.mspx nach WMI suchen.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).png Zum Seitenanfang

F 2. Auf welchen Plattformen ist WMI verfügbar?

WMI steht unter allen neuen Windows-Versionen zur Verfügung. Es wird zusammen mit Windows Me, Windows 2000, Windows XP und Windows Server 2003 installiert.

Für Windows 98 und Windows NT 4.0 steht WMI als Internetdownload unter http://www.microsoft.com/downloads zur Verfügung. Suchen Sie nach dem Download "Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0)".

Beachten Sie, dass für Windows NT 4.0 Service Pack 4 oder höher erforderlich ist, bevor Sie WMI installieren und ausführen können.

Die zusätzlichen Softwareanforderungen für WMI umfassen:

  1. Microsoft(r) Internet Explorer, Version 5.0 oder höher.
  2. Windows Script Host (WSH). WSH ist im Lieferumfang von Windows 2000, Windows XP, Windows Server 2003 und Windows Me enthalten, nicht jedoch von Windows NT 4 oder Windows 98. Sie können WSH unter http://www.microsoft.com/downloads downloaden. Die neueste Version - im Lieferumfang von Windows XP und Windows Server 2003 enthalten - ist WSH 5.6.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).png Zum Seitenanfang

F 3. Woran kann ich erkennen, ob WMI eine bestimmte Funktionalität aufweist?

MSDN ist die beste Informationsquelle, wenn Sie detaillierte Referenzinformationen zu WMI und dessen Funktionen suchen. Sie finden die WMI-Referenz unter http://msdn.microsoft.com/de-de/library/windows/desktop/aa394582(v=vs.85).aspx (nur auf Englisch verfügbar). Die WMI-Referenz enthält Informationen zu den meisten Klassen, Objekten für Skripterstellung und APIs, die bei einer WMI-Standardinstallation verfügbar sind. WMI-Anbieter, die nicht zum Betriebssystem gehören, erstellen möglicherweise Klassen, die entweder in MSDN nicht dokumentiert sind oder die an einer anderen Stelle des Platform SDKs dokumentiert werden.

Nachdem Sie sich mit der Kategorisierung der Informationen vertraut gemacht haben, können Sie problemlos nach der benötigten Klasse suchen und nachsehen, ob die gewünschte Funktionalität verfügbar ist. Seien Sie sich dabei bewusst, dass Sie u. U. mehrere Klassen verwenden müssen, um eine bestimmte Aufgabe auszuführen. Angenommen beispielsweise, Sie möchten grundlegende Systeminformationen zu einem Computer erhalten. Dann können Sie Informationen zum verfügbaren Arbeitsspeicher über die Klasse Win32_OperatingSystem abrufen, müssen aber eine zweite Klasse (z. B. Win32_LogicalDisk) verwenden, wenn Sie außerdem Informationen zum freien Festplattenspeicher des Computers benötigen. Weitere Informationen zu den möglichen und nicht möglichen Funktionen von WMI finden Sie unter der Frage Warum wird mein Skript unter einer bestimmten Windows-Version ausgeführt, unter einer anderen jedoch nicht?.

Mithilfe des Tools CIM Studio können Sie WMI-Klassen unter Windows 2000 und späteren Plattformen durchsuchen. Informationen zu diesem Tool und dem entsprechenden Download (bei CIM Studio handelt es sich um eine Reihe von Tools, die durch WMITools.exe installiert wurden) erhalten Sie auf der Microsoft-Website unter http://www.microsoft.com (nur auf Englisch verfügbar). Suchen Sie dort nach dem Stichwort "WMI tools". Zum Prüfen von WMI-Daten können Sie auch das nicht unterstützte Dienstprogramm Wbemtest.exe ausführen, das automatisch zusammen mit WMI installiert wird.

Unter Windows XP oder Windows Server 2003 können Sie das folgende Skript zum Suchen nach Klassen verwenden, deren Name ein bestimmtes Wort enthält. Speichern Sie das Skript in einer Textdatei namens Search.vbs, und führen Sie es dann unter Angabe des gesuchten Stichworts aus. Wenn Sie z. B. nach Klassen suchen, deren Name das Wort
"service" enthält, führen Sie an der Eingabeaufforderung den folgenden Befehl aus:

cscript search.vbs service
' Script for finding a class in WMI Repository
 Set args = wscript.arguments
If args.Count <= 0 Then
    Wscript.Echo "Tool to search for a matching class in the WMI Repository. " 
    Wscript.Echo "USAGE: <keywordToSearch> [<namespaceToSearchIn>]"
    Wscript.Echo "Example1: Cscript search.vbs service"
    Wscript.Echo "Example2: Cscript search.vbs video root\cimv2"
Else
    ' If no Namespace is specified then the Default is the ROOT namespace
    rootNamespace = "\\.\ROOT"
    keyword = args(0)
    If args.Count > 1 Then
        rootNamespace = args(1)
    End If        EnumNameSpace rootNamespace 
    Wscript.Echo vbNewLine
End if
  ' Subroutine to recurse through the namespaces
 Sub EnumNameSpace(parentNamespaceName)
 Set objService = GetObject("winmgmts:" & parentNamespaceName)
 Set collMatchingClasses = objService.Execquery _
    ("Select * From meta_class Where __class " & _
    "Like '%" & keyword & "%'")
If (collMatchingClasses.count > 0) Then
    Wscript.Echo vbNewLine 
    Wscript.Echo vbNewLine
    Wscript.Echo "Matching Classes Under Namespace: " & parentNamespaceName
     For Each matchingClass in collMatchingClasses 
        Wscript.Echo "    " & matchingClass.Path_.CLASS
    Next    End if
 Set collSubNamespaces = objService.Execquery _
    ("select * from __namespace")
For Each subNameSpace in collSubNamespaces 
    EnumNameSpace subNameSpace.path_.namespace + _
        "\" + subNameSpace.Name
Next
 End Sub

Dieses Skript wird nur unter Windows XP oder Windows Server 2003 ausgeführt. Der LIKE-Operator, ein Element der WMI-Abfragesprache, steht nämlich nur auf diesen beiden Plattformen zur Verfügung.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 4. Wie kann ich vorgehen, wenn WMI die benötigten Funktionen nicht bereitstellt?

Früher oder später möchten Sie ein Skript für eine Aufgabe erstellen, die WMI überhaupt nicht oder nicht besonders effizient ausführen kann. In derartigen Fällen sollten Sie zunächst nachsehen, ob die erforderlichen Funktionen durch eine andere Technologie zur Skripterstellung im Betriebssystem bereitgestellt werden. So ermöglicht Ihnen z. B. Active Directory Service Interfaces (ADSI) das Verwalten von Active Directory, und mithilfe von Collaboration Data Objects (CDO) können Sie E-Mails aus einem Skript heraus senden. Wenn im Windows-Betriebssystem keine geeignete Skriptschnittstelle zur Verfügung steht, werden die benötigten Funktionen möglicherweise durch die Software eines anderen Anbieters ausgeführt.

Falls keine Skriptschnittstelle vorhanden ist, können Sie (theoretisch) einen WMI-Anbieter schreiben, der diese Funktionalität bereitstellt. Allerdings können WMI-Anbieter nicht in einer Skriptsprache geschrieben werden; dies muss in C++ oder C# geschehen. Informationen zu den dazu erforderlichen Verfahren finden Sie auf der MSDN-Website unter "Using WMI" (nur auf Englisch verfügbar); von dort werden Sie zu Themen weitergeleitet, die sich mit dem Schreiben herkömmlicher WMI-Anbieter befassen. Wenn Sie einen Anbieter mithilfe der .NET Frameworks schreiben möchten, suchen Sie in der MSDN Library nach "Managing Applications Using WMI".

Darüber hinaus wird die WMI-Funktionalität durch die Verwaltungssoftware vieler anderer Hersteller erweitert. Sie können im Internet nach Drittanbietertools suchen. Möglicherweise können Sie die erforderlichen Informationen auch durch Fragen bei Newsgroups erhalten. Lesen Sie hierzu die Antwort auf die Frage Wo kann ich Beispielskripts finden, in denen WMI verwendet wird?.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 5. Wo kann ich Beispielskripts finden, in denen WMI verwendet wird?

Sowohl das Microsoft Developers Network (MSDN) als auch TechNet enthalten zahlreiche Beispielskripts. Hier sind einige Links zu nützlichen Adressen auf diesen Websites:

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 6. Warum wird mein Skript unter einer Windows-Version ausgeführt, unter einer anderen jedoch nicht?

Dies beruht normalerweise darauf, dass Klassen, Eigenschaften oder Methoden, die in neueren Windows-Versionen eingeführt wurden, in früheren Versionen des Betriebssystems möglicherweise nicht verfügbar sind. Wenn Sie die Verfügbarkeit überprüfen möchten, lesen Sie im WMI Software Developer Kit (SDK) im Abschnitt "Requirements" für die einzelnen Klassen nach. Sie finden es in der MSDN Library (http://msdn.microsoft.com/library/default.aspx) (nur auf Englisch verfügbar). Beispielsweise geben die Anforderungen für die Klasse Win32_PingStatus an, dass Windows XP oder Windows Server 2003 erforderlich ist. Aus diesem Grund schlagen Skripts, die den Zugriff auf die Klasse Win32_PingStatus unter Windows 2000 versuchen, mit einer "Class not found"-Fehlermeldung (Klasse nicht gefunden) fehl.

Entsprechend sind einige WMI-Datenanbieter, wie z. B. der SNMP-Anbieter, entweder nicht unter allen Betriebssystemen verfügbar, oder sie gehören nicht zur Standardinstallation von WMI. Bei den SDK-Themen, die sich auf diese Anbieter beziehen, gibt es einen Hinweis, der auf das Thema "Operating System Availability of WMI Components" im Abschnitt "About WMI" zeigt.

Eine Liste der WMI-Standardanbieter finden Sie unter "WMI Providers" im Abschnitt "WMI Reference".

Allgemein gilt: Wird ein neuer Anbieter einer neuen Windows-Version hinzugefügt, wird dessen Funktionalität früheren Windows-Versionen nicht zur Verfügung gestellt. So wird beispielsweise die durch den PING-Anbieter definierte Klasse Win32_PingStatus Windows 2000 höchstwahrscheinlich nicht zur Verfügung gestellt. Dies beruht in der Regel darauf, dass der Anbieter Funktionen der neuen Windows-Version nutzt, die in früheren Versionen nicht vorhanden sind.

Was ist zu unternehmen, wenn Sie über zwei Computer mit identischer Windows-Version verfügen, ein Skript aber nur auf einem der beiden Computer ausgeführt werden kann? Informationen zur Fehlerbehandlung bei solchen Problemen finden Sie unter Warum wird bei einem WMI-Vorgang ein Fehler zurückgegeben?

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 7. Warum wird bei einem WMI-Vorgang ein Fehler zurückgegeben?

Vergewissern Sie sich zunächst, ob es sich tatsächlich um einen WMI-Fehler handelt. WMI-Fehlernummern beginnen mit "8004xxxx" (z. B. "80041001"). Sie können die WMI-Fehlernummern und Rückgabecodes nachschlagen, indem Sie zu http://msdn.microsoft.com/library/default.aspx wechseln und nach "WMI Return Codes" (nur auf Englisch verfügbar) suchen. Wenn Sie die benötigten Informationen nicht finden können, suchen Sie nach der spezifischen Fehlernummer in MSDN.

Falls Sie bei Ausführung des Skripts keine Fehlernummer empfangen, können Sie in den WMI-Protokolldateien im Ordner %windir%\system32\wbem\logs nach Fehlern suchen. Es ist schwierig zu ermitteln, welche Fehler sich aus dem soeben ausgeführten Skript ergeben haben, alle Protokolle zu löschen und das Skript erneut auszuführen. Diese Vorgehensweise sollte Ihnen jedoch die Suche nach Fehlern im Zusammenhang mit Ihrem Skript erleichtern.

Wenn Sie keine Fehler in den Protokolldateien finden können, müssen Sie u. U. die Protokollierungsstufe für die Protokolle zurücksetzen. Zum Erhalten der umfassendsten Informationen legen Sie die Protokollierungsstufe auf ausführlich fest. Unter Windows 2000, Windows NT und Windows Me/98/95 müssen Sie WMI erneut starten, nachdem Sie die Protokollierungsstufen geändert haben; dies ist unter Windows XP und Windows Server 2003 nicht erforderlich. Detaillierte Informationen zum Konfigurieren der Protokollierungsstufen erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach dem Stichwort "Logging WMI Activity" (nur auf Englisch verfügbar) suchen.

Fehler werden eventuell auch in den Windows-Ereignisprotokollen aufgezeichnet. Suchen Sie nach Ereignissen mit der Quelle Winmgmt.

Unter Windows XP oder Windows Server 2003 können Sie die MSFT_WMIProvider-Klassen für die Problembehandlung bei Anbietervorgängen wie dem Laden und Entladen des Anbieters, dem Antworten auf eine Abfrage, dem Ausführen einer Methode usw. verwenden. WMI erstellt z. B. eine Instanz der Klasse MSFT_WmiProvider_CancelQuery_Pre , unmittelbar bevor der Anbieter die Antwort auf eine Abfrage abbricht. Nach dem erfolgten Abbruch wird eine Instanz von MSFT_WmiProvider_CancelQuery_Post generiert. Wenn ein Abfragevorgang in einem bestimmten Skript fehlschlägt, können Sie ein Skript schreiben, mit dem auf das Generieren von Instanzen dieser Ereignisklassen gewartet werden soll. Wenn das Überwachungsskript eines dieser Ereignisse empfängt, umfassen die angezeigten Daten den beteiligten Anbieter, den Anbietertyp, die momentan verarbeitete Abfrage sowie den betroffenen Namespace.

Weitere Informationen hierzu erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach "Troubleshooting Classes" (nur auf Englisch verfügbar) suchen.

Das nachstehende Beispielskript dient zur Behandlung von Problemen mit dem PING-Anbieter. Das Skript meldet alle Aktionen, die im Rahmen eines PING-Vorgangs stattfinden, einschließlich Laden des Anbieters, Abfrageempfang und Fehlergenerierung. Anhand dieser Informationen können Sie ermitteln, ob die Probleme im Anbieter oder im WMI-Dienst aufgetreten sind. Suchen Sie in der Ausgabe nach Ereignissen, bei denen der Wert für ResultCode nicht 0 lautet; im Allgemeinen weist ein anderer Fehlercode als 0 auf einen fehlgeschlagenen Vorgang hin.

Speichern Sie den folgenden Code in einer VBS-Datei, und führen Sie anschließend das Skript aus.

Option Explicit
 Sub Sink_OnObjectReady(oInst, oCtx)
    instcount = instCount+1
    Wscript.echo "Event " & cstr(instCount) & vbTab & _
        oInst.GetObjectText_ & vbNewLine        End Sub
 Sub Sink_OnCompleted(Hresult, oErr, oCtx)    End Sub
 'msftTroubleShooting.vbs starts here
 DIM oLctr, oSvc, OSink, instCount, SrvName, SrvUserName, SrvPswd, args, argcount 
 Set args = wscript.arguments
 SrvName = "."
SrvUserName = Null
SrvPswd = Null
instcount = 0
 argcount = args.Count
 If (argcount > 0)  Then
    If args(0) = "/?" or args(0) = "?"   Then
        Wscript.Echo "Usage:        cscript msftTroubleShooting.vbs " _
            [ServerName=Null|?] [UserName=Null] [Password=Null]"
        Wscript.Echo "Example:    cscript msftTroubleShooting.vbs "
        Wscript.Echo "Example:    cscript msftTroubleShooting.vbs computerABC"
        Wscript.Echo "Example:    cscript msftTroubleShooting.vbs "
        Wscript.Echo "computerABC admin adminPswd"
        Wscript.Quit 1
    End If 
End If
 Set oLctr = createObject("WbemScripting.Swbemlocator")
 On Error Resume Next
If argcount = 0 Then
    Set oSvc = oLctr.ConnectServer(,"root\cimv2") 
    SrvName = " Local Computer "
Else
    srvname = args(0)
    If argcount >= 2 Then 
        SrvUserName = args(1)
    End If
    If argcount >= 3 Then 
        SrvPswd = args(2)
    End If
    Set oSvc = oLctr.ConnectServer(srvname,"root\cimv2",SrvUserName,SrvPswd)
End If
 If Err = 0 Tthen
    Wscript.Echo "Connection to " & srvname & " is thru"  & vbNewLine
Else
    Wscript.Echo "The Error is " & err.description & _
        " and the Error number is " & err.number
    Wscript.Quit 1
End If
 On Error Goto 0
 Set oSink = WScript.CreateObject("WbemScripting.SWbemSink","Sink_")
oSvc.ExecNotificationQueryAsync oSink, _
    "Select * From MSFT_WmiProvider_OperationEvent Where " & _
        "provider = 'WMIPingProvider'"
 Wscript.Echo "To stop the script press ctrl + C" & vbNewLine
Wscript.Echo "Waiting for events......"  & vbNewLine
 While True
    Wscript.Sleep 10000     Wend

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 8. WMI funktioniert nicht. Welche Problembehandlung ist möglich?

Probleme mit dem WMI-Dienst können bei der Ausführung eines Skripts oder eines WMI-Tools (z. B. CIM Studio) oder bei Verwendung der WMI-Steuerung auftreten. Das Skript wird vielleicht nicht ausgeführt, oder Sie erhalten einen "Access denied"-Fehler (Zugriff verweigert); dieser Fehler kann auftreten, weil WMI nicht ausgeführt wird oder weil ein Namespace nicht richtig konfiguriert wurde. Fehler können auch auftreten, wenn die von einem WMI-Anbieter bereitgestellten Klassen nicht geladen werden oder wenn das WMI-Repository (in dem die Klassendefinitionen gespeichert werden) beschädigt wurde.

Führen Sie die folgenden Schritte aus, um Probleme mit dem WMI-Dienst zu behandeln:

  1. Wenn Probleme beim Herstellen der Verbindung mit einem Remotecomputer auftreten, probieren Sie das Skript auf dem lokalen Computer aus.
  2. Starten Sie den WMI-Dienst erneut.
  3. Erstellen Sie das WMI-Repository erneut.
  4. Registrieren Sie alle WMI-Komponenten erneut.
  5. Installieren Sie das Betriebssystem erneut.
  6. Wenden Sie sich (in englischer Sprache) an Microsoft Product Support Services.

Wenn Probleme beim Herstellen der Verbindung mit einem Remotecomputer auftreten, probieren Sie das Skript auf dem lokalen Computer aus.

Dies sollte geschehen, bevor Sie irgendeinen anderen Vorgang einleiten. Wenn das Skript auf dem lokalen Computer ausgeführt wird, lesen Sie das Thema Wie kann ich Remotecomputer mithilfe von WMI verwalten? Wenn das Skript auf dem lokalen Computer aber fehlschlägt, führen Sie als Nächstes die folgenden Schritte zur Problembehandlung aus:

Wenn ein lokaler WMI-Vorgang mit einem unerwarteten Fehlercode fehlschlägt oder wenn Sie die WMI-Steuerung nicht starten können, vergewissern Sie sich, dass der lokale WMI-Dienst ausgeführt wird. Speichern Sie den folgenden Code in einer VBS-Datei, und führen Sie das Skript über die Eingabeaufforderung aus.

Set Svc = GetObject ("winmgmts:root\default")

Wenn das Skript erfolgreich ausgeführt wird, funktioniert der WMI-Dienst und ist wahrscheinlich nicht die Ursache des Problems.

Schlägt das Skript fehl, überprüfen Sie, ob der im Skript angegebene Namespace gültig ist. Im Beispielskript wird versucht, eine Verbindung mit dem Namespace root\default herzustellen. Falls dieser Namespace nicht vorhanden ist, wird wahrscheinlich der Fehler WBEM_E_INVALID_NAMESPACE (0x8004100E) angezeigt.

Doch wie sieht es aus, wenn der Namespace vorhanden ist, aber nicht die Klasse, mit der Sie eine Verbindung herzustellen versuchen? In diesem Fall wird beim Zugriffsversuch auf die Klasse möglicherweise einer der folgenden Fehlercodes angezeigt:

  • WBEM_E_NOT_FOUND (0x80041002)
  • WBEM_E_OUT_OF_MEMORY (0x80041006)

Eine fehlgeschlagene Verbindung mit einer Klasse könnte auch darauf hinweisen, dass das WMI-Repository beschädigt wurde. In diesem Fall wird möglicherweise einer dieser Fehlercodes angezeigt:

  • WBEM_E_INITIALIZATION_FAILURE (0x80041014)
  • WBEM_E_CRITICAL_ERROR (0x8004100a)
  • WBEM_E_FAILED (0x80041001)

Wenn Sie annehmen, dass das Repository beschädigt wurde, sollte es erneut erstellt werden.

Erneutes Starten des WMI-Dienstes

Normalerweise wird der WMI-Dienst (winmgmt) immer ausgeführt; er wird bei jedem Start des Computers gestartet und bis zum Herunterfahren des Computers nicht beendet. Wenn der Dienst unerwartet beendet wurde, können Sie ihn erneut starten, indem Sie an der Eingabeaufforderung net start winmgmt eingeben. Außerdem wird der WMI-Dienst immer dann automatisch erneut gestartet, wenn Sie eine Verbindung zu einem WMI-Namespace mithilfe eines WMI-Tools (z. B. Wbemtest) oder eines Skripts herstellen. Wenn der WMI-Dienst beendet wird und Sie ein Skript mit WMI ausführen, wird der Dienst normalerweise automatisch erneut gestartet.

Falls beim WMI-Dienst Probleme auftreten, müssen Sie ihn u. U. manuell beenden und erneut starten. Führen Sie dazu folgende Schritte aus:

  1. Aktivieren Sie zunächst die WMI-Option für ausführliche Protokollierung. Diese stellt zusätzliche Informationen in den WMI-Fehlerprotokollen bereit, die beim Diagnostizieren des Problems hilfreich sein können. Sie können die ausführliche Protokollierung durch Konfigurieren der folgenden Registrierungswerte aktivieren:
    1. Legen Sie HKLM\Software\Microsoft\WBEM\CIMOM\Logging auf 2 fest.
    2. Legen Sie HKLM\Software\Microsoft\WBEM\CIMOM\Logging file Max Size auf 4000000 fest.
  2. Beenden Sie den WMI-Dienst. Der WMI-Dienst hat den Namen "winmgmt". Zum Beenden des Dienstes führen Sie den folgenden Befehl aus:
    winmgmt /kill
    Unter Windows XP oder Windows Server 2003 wird der WMI-Dienst in einem Prozess namens Svchost ausgeführt; dieser Prozess enthält weitere Dienste, die unter demselben Konto ausgeführt werden. Darüber hinaus werden auf dem Computer wahrscheinlich mehrere Instanzen von Svchost angezeigt. Versuchen Sie nicht, Svchost zu beenden; beenden Sie stattdessen den WMI-Dienst mit einem der Befehle winmgmt /kill oder net stop winmgmt.
  3. Wenn Schritt 2 erfolgreich ausgeführt wurde, überspringen Sie diesen Schritt, und wechseln Sie zu Schritt 4. Schlägt Schritt 2 fehl, beenden Sie den Dienst winmgmt, starten Sie den Computer erneut, und fahren Sie dann mit Schritt 4 fort.
  4. Führen Sie das Skript erneut aus. Wenn es fehlschlägt, müssen Sie das WMI-Repository möglicherweise erneut erstellen.

Erneutes Erstellen des Repositorys

Das WMI-Repository ist der zentrale Speicherbereich für Klassendefinitionen, die durch WMI-Anbieter erstellt wurden. Es befindet sich im Ordner %systemDrive%\%windir%\system32\wbem\Repository. Wenn Sie vermuten, dass das Repository beschädigt wurde, können Sie es erneut erstellen. Beachten Sie, dass dieser Vorgang zum Verlust von WMI-Informationen in dem Repository führen kann, das nicht zusammen mit WMI (oder dem Betriebssystem) installiert wurde. Sie müssen diese Informationen möglicherweise selbst wiederherstellen, indem Sie die Anwendungen ausführen, mit denen die Informationen zuerst im Repository abgelegt wurden. Gehen Sie wie folgt vor, um das Repository erneut zu erstellen:

  1. Beenden Sie den WMI-Dienst.
  2. Geben Sie dazu an der Eingabeaufforderung die folgenden Befehle ein:

    cd /d %windir%\system32\wbem

    rename Repository Rep_bak

  3. Mit diesen Befehlen wird die Datei mit dem WMI-Repository umbenannt. Nachdem die Datei umbenannt wurde, wird das Repository vom Betriebssystem nicht mehr gefunden. In diesem Fall versucht Windows, das Repository bei Ihrem nächsten Zugriff auf WMI erneut zu erstellen. Wenn der AutoRecover-Mechanismus für automatische Wiederherstellung fehlschlägt, können Sie versuchen, das Repository manuell erneut zu erstellen.

    Erneutes Erstellen des Repositorys über den WMI-Mechanismus "AutoRecover"

    • Stellen Sie eine WMI-Verbindung mit root\default her, indem Sie entweder ein Skript ausführen oder ein WMI-Tool wie Wbemtest.exe verwenden. Wenn die Verbindung erfolgreich hergestellt wurde, wird das Repository erneut erstellt. Schlägt die Verbindung fehl, versuchen Sie, das Repository manuell erneut zu erstellen.

    Manuelles erneutes Erstellen des WMI-Repositorys

    • Zum manuellen erneuten Erstellen des Repositorys sollten Sie zunächst eine Batchdatei kompilieren, die dann die im Repository gespeicherten Informationen erneut kompiliert. Der Registrierungsschlüssel HKLM\Software\Microsoft\WBEM\CIMOM\Autorecover MOFs enthält eine Liste aller MOF-Dateien (Managed Object Format), die während der Installation von WMI (oder des Betriebssystems) kompiliert wurden. Zum erneuten Erstellen des Repositorys kopieren Sie die in diesem Registrierungswert aufgelisteten Dateinamen in eine neue Batchdatei namens WMI_Recover.bat. Stellen Sie dabei sicher, dass sowohl alle MOF-Dateien als auch alle MFL-Dateien mit einbezogen werden. (Die MFL-Dateien enthalten die lokalisierten Beschreibungen der Klassen, Eigenschaften und Methoden.)
      In Editor sieht eine Batchdatei ungefähr aus:
      C:\WINDOWS\system32\WBEM\cimwin32.mof
      C:\WINDOWS\system32\WBEM\cimwin32.mfl
      C:\WINDOWS\system32\WBEM\system.mof
      C:\WINDOWS\system32\WBEM\wmipcima.mof
      C:\WINDOWS\system32\WBEM\wmipcima.mfl
      
    • Fügen Sie den Befehl Mofcomp am Anfang jeder Zeile der Batchdatei hinzu. Bei Mofcomp.exe handelt es sich um ein Dienstprogramm des Betriebssystems zum Kompilieren von MOF-Dateien, durch das die Informationen in diesen Dateien dem WMI-Repository hinzugefügt werden. Nun sieht die Batchdatei beispielsweise ähnlich wie hier aus:
      Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mof
      Mofcomp C:\WINDOWS\system32\WBEM\cimwin32.mfl
      Mofcomp C:\WINDOWS\system32\WBEM\system.mof
      Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mof
      Mofcomp C:\WINDOWS\system32\WBEM\wmipcima.mfl
      
    • Führen Sie die Batchdatei aus.
    • Sie können auch alle MOF- und MFL-Dateien mit den folgenden Befehlen kompilieren:

      cd /d %windir%\system32\wbem

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

    • Überprüfen Sie .\Logs\Mofcomp.log nach Abschluss des Vorgangs auf Kompilierungsfehler.
  4. Führen Sie das Skript erneut aus.

Erneutes Registrieren aller WMI-Komponenten

Wenn die Verbindung zu root\default weiterhin fehlschlägt, wurde das Problem möglicherweise durch eine falsch registrierte WMI-Komponente verursacht. Die von WMI verwendeten DLL- und EXE-Dateien befinden sich in %windir%\system32\wbem. Möglicherweise müssen Sie sämtliche DLL- und EXE-Dateien in diesem Verzeichnis erneut registrieren. Bei einem 64-Bit-System müssen Sie eventuell auch prüfen, ob %windir%\sysWOW64\wbem DLL- und EXE-Dateien enthält.

  1. Zum erneuten Registrieren der WMI-Komponenten führen Sie an der Eingabeaufforderung die folgenden Befehle aus:

    cd /d %windir%\system32\wbem

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

    for %i in (*.exe) do %i /RegServer

  2. Führen Sie das Skript erneut aus.

Erneutes Installieren des Betriebssystems

Wenn es auch jetzt noch nicht möglich ist, eine Verbindung mit root\default herzustellen, müssen Sie das Betriebssystem erneut installieren. Installieren Sie Windows erneut, und versuchen Sie anschließend, das Skript erneut auszuführen.

Kontaktaufnahme mit Microsoft Product Support Services

Falls WMI weiterhin nicht funktioniert, müssen Sie mit Microsoft Product Support Services (PSS) (in englischer Sprache) Kontakt aufnehmen. Weitere Informationen hierzu finden Sie unter http://support.microsoft.com/default.aspx.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 9. Wie kann ich die WMI-Namespacesicherheit festlegen?

Festlegen der Namespacesicherheit über die WMI-Steuerung

Die WMI-Steuerung bietet eine Möglichkeit zum Verwalten der Namespacesicherheit. Sie können die WMI-Steuerung an der Eingabeaufforderung mit dem folgenden Befehl starten:

wmimgmt

Bei Computern unter Windows 9x oder Windows NT4 mit installiertem WMI geben Sie stattdessen diesen Befehl ein:

wbemcntl.exe

Alternativ können Sie mit den folgenden Schritten auf die WMI-Steuerung und die Registerkarte Sicherheit zugreifen:

  1. Klicken Sie mit der rechten Maustaste auf Arbeitsplatz, und klicken Sie dann auf Verwalten.
  2. Doppelklicken Sie auf Dienste und Anwendungen und dann auf WMI-Steuerung.
  3. Klicken Sie mit der rechten Maustaste auf WMI-Steuerung, und klicken Sie dann auf Eigenschaften.
  4. Klicken Sie im Dialogfeld Eigenschaften von WMI-Steuerung auf die Registerkarte Sicherheit.
  5. Es sollte nun der Ordner root mit einem Pluszeichen (+) davor angezeigt werden. Erweitern Sie diese Struktur bei Bedarf, um den Namespace zu suchen, für den Sie Berechtigungen festlegen möchten.
  6. Klicken Sie auf die Schaltfläche Sicherheit. Eine Liste von Benutzern und deren Berechtigungen wird angezeigt. Wenn der Benutzer in dieser Liste aufgeführt wird, ändern Sie die Berechtigungen entsprechend. Ist der Benutzer in der Liste nicht enthalten, klicken Sie auf die Schaltfläche Hinzufügen, und fügen Sie ihn von der Position (lokaler Computer, Domäne usw.) hinzu, an der das Konto gespeichert ist.

Hinweise:

  • Damit der Benutzer die Namespacesicherheit anzeigen und festlegen kann, muss er über die Berechtigungen Sicherheit lesen und Sicherheit bearbeiten verfügen. Administratoren verfügen standardmäßig über diese Berechtigungen und können sie bei Bedarf anderen Benutzerkonten zuweisen.
  • Wenn ein Benutzer Remotezugriff auf den Namespace benötigt, müssen Sie die Berechtigung Remoteaktivierung auswählen.
  • Standardmäßig gelten die für einen Namespace festgelegten Benutzerberechtigungen nur für diesen Bereich. Wenn der Benutzer die Möglichkeit haben soll, auf diesen Namespace und alle untergeordneten Namespaces in der Struktur darunter oder nur in untergeordneten Namespaces zuzugreifen, klicken Sie auf die Schaltfläche Erweitert. Klicken Sie auf Bearbeiten, und geben Sie im daraufhin angezeigten Dialogfeld den Zugriffsbereich an.

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 10. Wie kann ich Remotecomputer mithilfe von WMI verwalten?

Im Allgemeinen lässt sich jeder Vorgang, der von WMI auf dem lokalen Computer ausgeführt werden kann, auch auf einem Remotecomputer ausführen, für den Sie über lokale Administratorrechte verfügen. Sofern Sie über Rechte für den Remotenamespace verfügen (siehe hierzu Wie kann ich die WMI-Namespacesicherheit festlegen?) und der Remotecomputer für den Remotebetrieb aktiviert ist, sollten Sie in der Lage sein, eine Verbindung mit einem Remotecomputer herzustellen und alle Vorgänge auszuführen, für die Sie über die erforderlichen Berechtigungen verfügen. Darüber hinaus können Sie Delegierung verwenden, wenn der Remotecomputer für Delegierung aktiviert ist. Über Delegierung kann der Remotecomputer Informationen von einem dritten Computer erhalten, wozu die vom Client bereitgestellten Anmeldeinformationen verwendet werden. Mit anderen Worten: Sie können ein Skript auf Computer A ausführen und eine Verbindung mit Computer B herstellen; Computer B kann dann eine Verbindung mit Computer C herstellen und dazu den Benutzernamen und das Kennwort verwenden, die von dem auf Computer A ausgeführten Skript geliefert wurden. Delegierungsszenarien werden unter Warum schlägt mein Remotevorgang fehl, wenn ein dritter Computer beteiligt ist? behandelt.

So stellen Sie eine Verbindung zu einem Remotenamespace über WMI-Tools her

  1. Zum Herstellen von Remoteverbindungen über Tools wie CIM Studio oder Wbemtest müssen Sie einen Namespace in der Form "\\<computername >\root\<namespace>" angeben.
    Beispiel: \\myserver\root\cimv2
  2. Die Authentifizierung wird durch Kerberos oder NTLM durchgeführt. Wenn Sie die NTLM- oder die Standardauthentifizierung (nicht Kerberos) verwenden möchten, geben Sie Folgendes an:

    Benutzer: <domäne>\<Benutzer>
    Kennwort: <kennwort>
    Autorität: Lassen Sie dieses Feld entweder leer, oder geben Sie "NTLMDomain:<domäne>" ein. Wenn Sie den Parameter Autorität einbeziehen, lassen Sie "<domäne>\" bei der Angabe für den Parameter Benutzer weg, und geben Sie nur den Benutzernamen ein. Beispiel:

    Benutzer: kenmyer
    Kennwort: 45Tgfr98q
    Autorität: NTLMDomain:fabrikam

  3. Zur Verwendung der Kerberos-Authentifizierung geben Sie Folgendes ein:

    Benutzer: <domäne>\<Benutzer>
    Kennwort: <kennwort>
    Autorität: Geben Sie hier "Kerberos:<domäne>\<computername>" ein. Beispiel:

    Benutzer: kenmyer
    Kennwort: 45Tgfr98q
    Autorität: Kerberos:fabrikam\atl-ws-01


So stellen Sie eine Verbindung mit WMI auf einem Remotecomputer unter Verwendung eines Skripts her

  1. Stellen Sie zunächst sicher, dass Sie über die entsprechenden Berechtigungen für den Remotenamespace verfügen. Wenn diese Berechtigungen vorhanden sind, können Sie eine Verbindung zum Remotecomputer ohne Angabe von Benutzeranmeldeinformationen herstellen. WMI stellt eine Verbindung her und verwendet dazu automatisch die Informationen, mit denen Sie sich angemeldet haben.
  2. Wenn Sie keine Benutzeranmeldeinformationen angeben müssen, können Sie eine Verbindung zu einem Remotecomputer herstellen und dazu die kurze Syntax für Verbindungen, die so genannte Monikerzeichenfolge, verwenden. Weitere Informationen hierzu erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach "Constructing a Moniker String" (nur auf Englisch verfügbar) suchen. Der folgende Moniker beispielsweise stellt eine Verbindung mit dem Standardnamespace auf dem Remotezielcomputer TargetComputer her (weil kein Namespace angegeben wurde, wird die Verbindung automatisch mit dem Standardnamespace hergestellt).
    Set objWMIService = GetObject("winmgmts:\\TargetComputer")
    
    • Falls sich der Zielcomputer TargetComputer in einer anderen Domäne befindet als derjenige Computer, an dem Sie angemeldet sind, müssen Sie den Domänennamen in den Moniker einschließen. Andernfalls erhalten Sie eine "Access Denied"-Fehlermeldung (Zugriff verweigert). Der folgende Beispielmoniker stellt eine Verbindung mit dem Computer TargetComputer in der Domäne DomainName her:
      Set objWMIService = GetObject("winmgmts:\\DomainName\TargetComputer")
      
    • Obwohl es nicht in allen Fällen erforderlich ist, können Sie im Moniker selbst auch den WMI-Namespace angeben. Diese Angabe ist beim Arbeiten mit verschiedenen Plattformen zweckmäßig, weil der Standardnamespace unter verschiedenen Versionen des Betriebssystems nicht immer identisch ist. So lautet der Standardnamespace unter Windows 2000, Windows XP und Windows Server 2003 beispielsweise root\cimv2, während er unter Windows NT 4.0 und Windows 98 root\default lautet.

      Der folgende Moniker stellt eine Verbindung mit dem Namespace root\cimv2 auf dem Remotecomputer TargetComputer her:

      Set objWMIService = GetObject("winmgmts:\\TargetComputer\root\cimv2)
      
    • Beim Arbeiten mit mehreren Plattformen müssen Sie möglicherweise auch die Ebene für Identitätswechsel angeben. Während die Standardebene für Identitätswechsel unter Windows 2000 und höheren Windows-Versionen Identität wechseln lautet, lautete sie unter früheren Windows-Versionen Identifizieren. Wenn Sie mit Computern unter Windows NT 4.0 und/oder Windows 98 arbeiten, müssen Sie die Ebene für Identitätswechsel in die Monikerzeichenfolge einbeziehen; dies ist auch erforderlich, wenn Sie Delegierung verwenden.

      Der folgende Moniker stellt eine Verbindung mit dem Namespace root\cimv2 auf dem Computer TargetComputer her und gibt Identität wechseln als Ebene für Identitätswechsel an.

      Set objWMIService =    GetObject _
          ("winmgmts:{impersonationLevel=Impersonate}!\\TargetComputer\root\cimv2")
      
    • Und schließlich müssen Sie u. U. die Authentifizierungsebene festlegen. Dies hängt davon ab, von welcher Betriebssystemversion aus mit welcher Version die Verbindung hergestellt wird. Die Authentifizierungsebene ermöglicht es Ihnen, den DCOM-Authentifizierungs- und Datenschutztyp anzufordern, der während des Bestehens einer Verbindung verwendet werden soll. Die Einstellungen reichen von keiner Authentifizierung bis zur paketweisen verschlüsselten Authentifizierung.

      Der folgende Moniker stellt eine Verbindung mit dem Namespace root\cimv2 auf dem Computer TargetComputer her und gibt Identität wechseln als Ebene für Identitätswechsel an. Darüber hinaus konfiguriert er die Authentifizierungsebene als pkt:

      Set objWMIService = GetObject("winmgmts:" _
          & "{impersonationLevel=impersonate," _ &    
               "authenticationLevel=pkt}!\\  _ 
                  TargetComputer\root\cimv2")
      
  3. Es ist auch möglich, in einem Skript Benutzeranmeldeinformationen anzugeben; auf diese Weise können Sie sich z. B. über ein Standardbenutzerkonto an einem Computer anmelden, dabei aber weiterhin ein Skript ausführen, für das Administratorrechte erforderlich sind. Weitere Informationen hierzu erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach "Leitfaden für WMI-Skripting" suchen.
    wbemImpersonationLevelImpersonate = 3
    wbemAuthenticationLevelPktPrivacy = 6
    
    Set objLocator = CreateObject("WbemScripting.SWbemLocator")
    Set objService = objLocator.ConnectServer _
        ("TargetComputer", "root\cimv2", "UserName", "Password")
    objService.Security_.ImpersonationLevel = wbemImpersonationLevelImpersonate
    objservices.Security_.AuthenticationLevel = wbemAuthenticationLevelPktPrivacy
    

Hinweis. Allgemein wird davon abgeraten, ein hardcodiertes Administratorkennwort in einem Skript zu verwenden. Besser ist es festzulegen, dass das Skript bei jeder Ausführung zur Eingabe des Kennworts auffordert.

Weitere Informationen hierzu erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach "Connecting Between Different Operating Systems" (nur auf Englisch verfügbar) suchen.

So stellen Sie eine Verbindung mit WMI über WMIC her

Wenn Sie über Rechte für den Remotenamespace verfügen und der betreffende Computer für den Remotebetrieb aktiviert ist, brauchen Sie beim Herstellen einer Verbindung keinen Benutzernamen und kein Kennwort anzugeben. Stattdessen verwendet WMIC automatisch Ihre aktuellen Benutzeranmeldeinformationen. Beispiel:

WMIC /NODE:"computer1" OS GET Caption,CSDVersion,CSName

Falls Sie Delegierung verwenden müssen, sollten Sie die Einstellungen /IMPLEVEL:Delegate und /AUTHORITY in die WMIC-Verbindungszeichenfolge einschließen. Beispiel:

WMIC /NODE:"computer1" /IMPLEVEL:Delegate /AUTHORITY:"Kerberos:domain\computer1" OS

Alternativ können Sie ein Benutzerkonto und Kennwort angeben, das beim Herstellen einer Verbindung über WMIC verwendet werden soll (genauso wie bei der WMI-Skripterstellung verfügen nur Administratoren standardmäßig über WMI-Remoteverbindungsrechte). Beispiel:

WMIC /NODE:"computer1" /USER:"domainname\username" OS GET Caption,CSDVersion

Der folgende Beispielbefehl umfasst sowohl ein Kennwort als auch einen Benutzernamen:

WMIC /NODE:"computer1" /USER:"domainname\username" /PASSWORD:"userpassword" OS GET Caption,CSDVersion,CSName

Weitere Informationen zum Herstellen von Remoteverbindungen erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library/default.aspx aufrufen und nach "Connecting to WMI on a Remote Computer" (nur auf Englisch verfügbar) suchen.

Bedeutung von "Access Denied"-Fehlern

Möglicherweise wird eine "Access Denied"-Fehlermeldung angezeigt, wenn Sie eine Verbindung mit einem WMI-Remotenamespace oder einem WMI-Remoteobjekt herzustellen versuchen. Es gibt verschiedene "Access Denied"-Fehler:

0x80041003 (WBEM_E_ACCESS_DENIED)
Dieser Fehler wird normalerweise angezeigt, wenn der Prozess, mit dem der Zugriff auf den Namespace versucht wird, nicht über die erforderlichen WMI-Rechte verfügt. Das Konto, über das der Remotezugriff versucht wird, sollte ein Administrator auf dem Zielcomputer sein; bei diesem Konto muss u. U. ein bestimmtes Recht aktiviert sein.
Überprüfen Sie zur Behandlung dieses Fehlers die Namespacesicherheit für den Remotenamespace auf die für das Konto aktivierten Rechte.

0x80070005 (DCOM ACCESS_DENIED)
Dieser Fehler tritt auf, wenn der verbundene Benutzer nicht erkannt oder auf irgendeine Weise durch den Remoteserver eingeschränkt wird (z. B. sein Konto gesperrt ist). Dies geschieht am häufigsten, wenn sich Konten in unterschiedlichen Domänen befinden. Auch kürzlich vorgenommene Änderungen der WMI-Sicherheit können diesen Fehler verursachen:

  • Leere Kennwörter, die unter früheren Windows-Versionen zulässig waren, sind unter Windows XP und Windows Server 2003 nicht mehr erlaubt.
  • WMI erlaubt keine asynchronen Rückrufe bei einem Windows 98-Client. Ein Aufruf wie SWbemServices.ExecNotificationQueryAsync von einem Computer unter Windows 98 an einen Computer unter Windows XP führt zur Rückgabe eines "Access Denied"-Fehlers an den Computer unter Windows 98.
  • Möglicherweise wurde die Zugriffseinstellung für die DCOM-Konfiguration geändert.
  • Wenn auf dem Zielcomputer Windows XP ausgeführt wird, wurde der Forceguest-Wert unter dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa möglicherweise so festgelegt, dass die Abmeldung des Gastkontos durchgesetzt wird (der Wert lautet 0, null).

0x800706xx (DCOM RPC-Fehler)

Dieser Fehler tritt häufig auf, wenn auf dem Remotecomputer eine Firewall konfiguriert ist. Sie müssen die entsprechenden Ports der Firewall öffnen, um Remoteverwaltung mithilfe von DCOM zuzulassen.

Alternativ treten auf dem Computer möglicherweise Probleme beim Zuordnen der IP-Adresse und des Hostnamens auf. Versuchen Sie zum Testen dieser Möglichkeit, die IP-Adresse statt des Hostnamens in der Verbindungszeichenfolge zu verwenden.

Set objWMIService = GetObject("winmgmts:\\192.168.1.1")

So führen Sie die Problembehandlung bei Fehlern des Remotecomputers durch

  1. Überprüfen Sie, ob der Benutzer Zugriff auf den Remotecomputer hat. Führen Sie an der Eingabeaufforderung den folgenden Befehl aus:

    net user \\<remotecomputer>\\C$ /u:<domäne\benutzername> *

  2. Aktivieren Sie die ausführliche Protokollierungsstufe auf dem Remotecomputer, und führen Sie das Skript erneut aus. Prüfen Sie nach Ausführung des Skripts die Protokolle auf dem Remotecomputer (%windir%\system32\wbem\Logs\).
  3. Aktivieren Sie die Überwachungsereignisse, um zu ermitteln, welches Konto für die fehlgeschlagene Verbindung verantwortlich ist. Nach dem Aktivieren der Überwachung werden im Ereignisprotokoll ähnliche Ereignisse wie das folgende angezeigt:

    Ereignistyp: Fehlerüberwachung

    Ereignisquelle: Sicherheit

    Ereigniskategorie: Anmelden/Abmelden

    Ereigniskennung: 529

    Datum: 6/14/2004

    Uhrzeit: 10:52:35 Uhr

    Benutzer: NT-AUTORITÄT\SYSTEM

    Computer: <remotecomputer>

    Beschreibung:

    Anmeldung fehlgeschlagen:

    Grund: Unbekannter Benutzername oder falsches Kennwort

    Benutzername: xuser

    Domäne: NTDEV

    Anmeldetyp: 3

    Anmeldevorgang: NtLmSsp

    Authentifizierungspaket: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

    Name der Arbeitsstation: <Konsolencomputer>

  4. Überprüfen Sie die DCOM-Konfiguration auf die Berechtigung Zugriff\Start; der Benutzer, der das Skript ausführt, muss über diese Berechtigung verfügen.
  5. Wenn alle vorherigen Prüfungen OK sind, der Benutzer vom Remotecomputer erkannt wird und die Verbindung dennoch mit einem DCOM-Fehler "Access Denied" fehlschlägt, wenden Sie sich mit den folgenden Informationen an Microsoft Product Support Services (http://support.microsoft.com/default.aspx):
  6. Betriebssystem der einzelnen Computer
  7. Installationsverlauf
  8. Schritte zum Reproduzieren des Problems
  9. Skript oder Toolcode, in dem der Fehler auftrat
  10. Benutzeranmeldeinformationen zum Herstellen der WMI-Verbindung, einschließlich Authentifizierungsebene und Ebene für Identitätswechsel
  11. ZIP-Datei des Verzeichnisses %windir%\system32\wbem\logs von beiden Computern

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 11. Warum schlägt mein Remotevorgang fehl, wenn ein dritter Computer beteiligt ist?

Wenn ein Clientcomputer (Computer A) Anmeldeinformationen für die Domäne von einem Remoteserver (Computer B) an einen dritten Computer (Computer C) weiterleiten muss, ist Delegierung erforderlich. Dies trifft zu, wenn zwei oder mehr Netzwerkhops für einen bestimmten Vorgang ausgeführt werden müssen. Ohne Delegierung kann Computer B keine von Computer A empfangenen Anmeldeinformationen weiterleiten; deshalb schlägt die Verbindung mit Computer C fehl.

In den beiden folgenden Situationen ist Delegierung erforderlich.

  • Auflisten der Drucker von einem WMI-Servercomputer aus: In diesem Fall versucht WMI, Eigenschaften von dem an einen Druckserver angeschlossenen Remotedrucker zu erfassen; für diesen Vorgang ist Delegierung erforderlich. Sie führen ein Skript auf Clientcomputer A aus, der eine Verbindung mit Druckserver B herstellt. Druckserver B wiederum versucht, auf einen an Computer C angeschlossenen Drucker zuzugreifen.
  • Herstellen einer Verbindung mit SQL Server über NT-Authentifizierung vom WMI-Server aus: Delegierung ist erforderlich, damit WMI die Anmeldeinformationen vom Server an SQL Server weiterleiten kann. Wenn SQL Server statt der NT-Authentifizierung die SQL Server-Standardauthentifizierung (SQL Server-basierte Sicherheit) verwendet, erfordert die Verbindungszeichenfolge für die Verbindung mit SQL Server keine Delegierung.

Damit Delegierung in ähnlichen Szenarien wie den vorstehenden funktioniert, müssen folgende Voraussetzungen zutreffen:

  • Auf allen drei Computern muss Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden. Delegierung ist bei Computern unter Windows NT 4.0 oder Windows 98 nicht möglich.
  • Die Delegierung für Computer B muss in Active Directory aktiviert werden.
  • Kerberos muss als Authentifizierungsautorität in der Verbindung vom WMI-Clientprozess (Computer A) mit dem WMI-Server (Computer B) angegeben werden. Zum Angeben einer Authentifizierungsautorität ist ein Aufruf von SWbemLocator.ConnectServer erforderlich. Diese Methode ist ein Bestandteil der WMI-Skripting-API (http://msdn.microsoft.com/de-de/library/windows/desktop/aa393258(v=vs.85).aspx) (nur auf Englisch verfügbar).

Nach Abschluss dieser Schritte ist Computer B für Delegierungszwecke vertrauenswürdig. Angenommen beispielsweise, Computer B sendet eine Anforderung an eine Remotedateifreigabe, die sich auf Computer C befindet. In diesem Fall kann Computer C die weitergeleiteten Anmeldeinformationen zum Authentifizieren des Benutzers verwenden, der im Clientprozess auf Computer A ursprünglich angegeben wurde.

Obwohl die Delegierung als Verwaltungsoption verfügbar ist, wird von der Verwendung normalerweise abgeraten, weil Computer A Anmeldeinformationen für Computer B bereitstellt. Dann bietet die Delegierung Computer B die Möglichkeit, die bereitgestellten Informationen anderweitig zu verwenden, und dies könnte ein Sicherheitsrisiko sein.

Mit dem folgenden Skript wird ein Computerkonto für Delegierung in Active Directory aktiviert. Das Skript wurde über ein Domänenadministratorkonto in einer Windows Server 2003-Domäne getestet. Darüber hinaus traf Folgendes zu:

  • Auf dem WMI-Clientcomputer (Computer A) wurde Windows XP SP1 Professional ausgeführt.
  • Auf dem WMI-Servercomputer (Computer B) wurde Windows Server 2003 ausgeführt.
  • Alle drei Computer befanden sich in derselben Active Directory-Domäne. Für Delegierung müssen sich sämtliche Computer in derselben Domäne befinden.
  • In diesem Beispiel befindet sich die Dateiserverfreigabe (Computer C) auf demselben physischen Computer wie der WMI-Client. Die Freigabe könnte sich jedoch auch auf einem anderen Computer in derselben Domäne befinden.
    'Purpose:    Script to enable delegation on a computer and 
    'then perform an operation that requires delegation
    
    'Requirements:  The client computer must be a member of the same Active Directory 
    'domain as the WMI Server specified in the argument to this script
    
    'Permissions required:  The user that runs this script should be a member of 
    'the Domain Administrators group in the Active Directory
     Const UF_TRUSTED_FOR_DELEGATION  = &H80000
    Set args  = Wscript.Arguments
     ' Terminate unless two arguments are specified when starting
    'the script
    If args.Count <> 2 then
        Wscript.Echo "You must provide a server name and delegation command line."
        Wscript.Echo "For example, start the script using syntax similar to this:"
        Wscript.Echo "cscript.exe this.vbs <WMI Server> <Delegation Command Line>"
        Wscript.Echo "cscript.exe this.vbs computer2 "
        Wscript.echo "\\computer1\c$\windows\system32\calc.exe"
        Wscript.Quit 1
    end if
     serverName = args(0)
    argCommandLine = args(1)
     ' Connect locally and get the domain and DS_Computer object to 
    ' examine and/or modify
    Set svc = GetObject("winmgmts:root\cimv2")
     ' Get some local machine variables to understand the environment we are working in
    
    Set objEnum = svc.ExecQuery _
        ("Select domain, name From win32_computerSystem", "WQL", 48)
     For Each obj in objEnum
        domain = obj.Domain
        computerName = obj.Name
    Next
     ' Get the connection to the root\directory\ldap namespace to enable delegation
    ' on the remote computer from the local machine
    
    Set svc = GetObject("Winmgmts:root\directory\ldap")
     ' Create the required context object
    
    Set octx = CreateObject("wbemscripting.swbemnamedvalueset")
    octx.Add "__PUT_EXT_PROPERTIES", Array("ds_userAccountControl")
    octx.Add "__PUT_EXTENSIONS", true
    octx.Add "__PUT_EXT_CLIENT_REQUEST", true
     ' Variable to determine whether or not we have modified the userAccountControl 
    'and whether or not we have to modify it back when we are done
    
    modified = False
     Set objEnum = svc.ExecQuery _
        ("Select * From ds_computer Where ds_cn = '" & serverName & "'", "WQL", 48)
     For Each obj in objEnum
     ' Store this variable to memory for restoration after this operation completes
    
        userAccountControlOriginal = obj.ds_userAccountControl
     ' Test to see if the computer is already trusted for delegation
        If CBool(userAccountControlOriginal And UF_TRUSTED_FOR_DELEGATION ) = False Then
             Wscript.Echo "Computer account not trusted for delegation yet"
                            
            ' Resume On Error while we try this initially
            On Error Resume Next
             ' Add this constant value to the value contained already
            obj.ds_userAccountControl = userAccountControlOriginal + _
                UF_TRUSTED_FOR_DELEGATION
             ' This should trust the computer account for delegation                
            obj.Put_ 1, octx
             If (Err.Number = 0) Then
            ' Set the flag so we know to modify it back to original setting
                modified = True             
            Else 
                Wscript.Echo Hex(Err.Number) & " " & _
                    Err.Description
                Wscript.Quit 1
            End If
                     On Error Goto 0:
         Else
        ' Already trusted for delegation so 
        ' continue with delegation code here
            Wscript.Echo "Computer account is trusted for delegation already"
         End If
         ' Get the locator object 
        Set lctr = CreateObject("WbemScripting.SWbemLocator")
         ' Get the service object from the remote server specifying the Kerberos authority
        Set delegationService = lctr.ConnectServer _
            (serverName, "root\cimv2", , , , _
                "kerberos:" & trim(domain) & "\" & Trim(serverName))
         ' Delegation level impersonation
        delegationService.Security_.ImpersonationLevel = 4 
         ' Get the object that will be used to test the delegation hop
        Set process = delegationService.Get("win32_process")
         ' Get the inparameter object for the method
        Set inparams = process.methods_("Create").inparameters
                
        ' Set the inparameter commandline value
        inparams.CommandLine = argCommandLine
         ' Execute the method
        Set oReturn = process.ExecMethod_("Create", inparams)
         ' Echo the output
        If (oReturn.ReturnValue = 0) Then
            Wscript.Echo oReturn.ProcessId & _
                " is the Process ID from the process " & _
                    "creation using delegation"
        Else 
            Wscript.Echo "An error occurred, the return value for the " & _
                "Win32_Process.Create method is " & _
                    oReturn.ReturnValue
        End If
         ' Set the value back to the original value
        If modified = True Then
                
            ' Subtract the added delegation privilege from the computer account       
            obj.ds_userAccountControl = _
                userAccountControlOriginal - UF_TRUSTED_FOR_DELEGATION
             ' Restore the original setting
            obj.put_ 1, octx
         End If                        
    Next
    

Das vorstehende Skript funktioniert nicht, wenn auf einem der beiden Mitgliedscomputer Windows NT 4.0 oder Windows 98 ausgeführt wird. Das Skript schlägt auch fehl, wenn sich das Ziel auf einer Windows NT 4.0-Dateifreigabe befindet.

Sie können einem Computer für Delegierungszwecke manuell vertrauen, indem Sie die folgenden Schritte ausführen:

  1. Klicken Sie auf die Schaltfläche Start und dann auf Alle Programme.
  2. Zeigen Sie auf Verwaltung, und klicken Sie auf Active Directory-Benutzer und -Computer.
  3. Erweitern Sie in Active Directory-Benutzer und -Computer den Knoten Computer, und suchen Sie den Computer, dem Sie für Delegierungszwecke vertrauen möchten.
  4. Klicken Sie mit der rechten Maustaste auf diesen Computer, und klicken Sie dann auf Eigenschaften.
  5. Aktivieren Sie Computer für Delegierungszwecke vertrauen, und klicken Sie auf OK.

Lesen Sie außerdem die Fragen Wie kann ich Remotecomputer mithilfe von WMI verwalten? und Wie kann ich die WMI-Namespacesicherheit festlegen?

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 12. Warum dauert die Ausführung meiner Abfragen so lange?

Der Grund hierfür sind typischerweise Abfragen, die große Datenmengen zurückgeben. Wenn durch die Abfrage ein sehr großes Dataset angefordert wird und Sie nur an einer Teilmenge der Daten interessiert sind, können Sie den Vorgang oft beschleunigen, indem Sie die zurückgegebenen Informationen begrenzen. Mithilfe von WQL (der WMI-Abfragesprache) können Sie die Gruppe von Instanzen (Datensätzen) sowie die zurückgegebenen Eigenschaften (Felder) filtern. Beispiele hierzu erhalten Sie, indem Sie die MSDN Library-Website unter http://msdn.microsoft.com/library aufrufen und nach "Querying with WQL" (nur auf Englisch verfügbar) suchen.

In einigen Fällen wurden Anbieter optimiert, um auf der Grundlage bestimmter Eigenschaften filtern zu können. Durch die Angabe dieser Eigenschaften in der WHERE-Klausel kann die Leistung verbessert werden. Der Anbieter kann das Resultset nämlich aktiv filtern, statt sich darauf zu verlassen, dass WMI die Auflistung erst filtert, nachdem der gesamte Datenbereich aufgelistet wurde. Die Optimierungsfunktionen finden Sie unter der jeweiligen Klassendefinition. Beispiele für optimierte Eigenschaften sind Drive und Path von CIM_DataFile.

Standardmäßig geben WMI-Abfragen einen Enumerator zurück, der die mehrmalige Traversierung der Auflistung in beiden Richtungen ermöglicht; dies bedeutet unter anderem, dass Sie sämtliche Elemente der Auflistung in einer Schleife durchlaufen und diesen Schleifendurchlauf bei Bedarf ein zweites oder drittes Mal wiederholen können. Wenn das zurückgegebene Dataset groß ist, benötigt dieser Enumeratortyp u. U. so viel Speicherplatz, dass die Leistung dadurch beeinträchtigt wird. Sie können dieses Problem umgehen, indem Sie beim Ausgeben der Abfrage das Flag WBEM_FLAG_FORWARD_ONLY festlegen. Obwohl Sie die Auflistung mithilfe dieses Enumeratortyps nur einmal in einer Schleife durchlaufen können, wird der Speicher für jedes Objekt nach der Verwendung freigegeben und die Leistung somit nicht verringert. Weitere Details hierzu finden Sie unter "Making a Semisynchronous Call with VBScript" (http://msdn.microsoft.com/en-us/library/windows/desktop/aa392301(v=vs.85).aspx) (nur auf Englisch verfügbar).

Während die Leistung halbsynchroner Abfragen in den meisten Fällen mit derjenigen asynchroner Abfragen vergleichbar ist, kann der Hauptanwendungsthread durch sehr umfangreiche Abfragen möglicherweise vollkommen beansprucht oder diese können durch WMI gedrosselt werden, um eine Überlastung des Systems zu verhindern. In diesen Fällen lässt sich die Leistung verbessern, indem aus einer halbsynchronen eine asynchrone Abfrage gemacht wird. Sie sollten sich jedoch bewusst sein, dass die asynchronen Aufrufe unter den meisten Betriebssystemen weniger sicher sind. Weitere Informationen hierzu finden Sie unter "Invoking an Asynchronous Query" (http://msdn.microsoft.com/en-us/library/windows/desktop/aa391396(v=vs.85).aspx) und unter "Setting Security on an Asynchronous Call" (http://msdn.microsoft.com/en-us/library/windows/desktop/aa393614(v=vs.85).aspx) (nur auf Englisch verfügbar).

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 13: Wie kann ich alle auf einem bestimmten Computer installierten Anwendungen auflisten?

Die WMI-Klasse Win32_Product stellt Anwendungen dar, die durch Windows Installer installiert wurden. Allerdings werden durch diese WMI-Klasse möglicherweise nicht alle installierten Anwendungen aufgelistet, die in Software angezeigt werden. Eine Lösung für dieses Problem besteht darin, die Daten zu installierten Anwendungen aus der Registrierung zu erfassen (beachten Sie, dass nicht alle Anwendungen bei der Installation Einträge in die Registrierung schreiben). In diesem Thema werden zwei mögliche Erfassungsverfahren gezeigt: mithilfe eines Skripts zum direkten Lesen von Informationen aus der Registrierung sowie mithilfe einer MOF-Datei und eines Skripts zum Abrufen dieser Informationen aus WMI.

  1. Mit dem folgenden Skript werden die auf einem Computer installierten Anwendungen aufgelistet. Mithilfe des WMI-Anbieters für die Systemregistrierung werden Informationen direkt aus der Registrierung erfasst.
    strHost = "."
    Const HKLM = &H80000002
    Set objReg = GetObject("winmgmts://" & strHost & _
        "/root/default:StdRegProv")
    Const strBaseKey = _
        "Software\Microsoft\Windows\CurrentVersion\Uninstall\"
    objReg.EnumKey HKLM, strBaseKey, arrSubKeys
     For Each strSubKey In arrSubKeys
        intRet = objReg.GetStringValue(HKLM, strBaseKey & strSubKey, _
            "DisplayName", strValue)
        If intRet <> 0 Then
            intRet = objReg.GetStringValue(HKLM, strBaseKey & strSubKey, _
            "QuietDisplayName", strValue)
        End If
        If (strValue <> "") and (intRet = 0) Then
            WScript.Echo strValue
        End If
    Next
    
  2. Alternativ bietet die nachstehende MOF-Datei mit zugehörigem Skript eine Möglichkeit zum Abrufen aller installierten Anwendungen, die sich automatisch in die Registrierung eintragen. Gehen Sie wie folgt vor, um die MOF-Datei zu verwenden:

    Schritt 1: Kopieren Sie die nachstehende MOF-Syntax in Editor, und speichern Sie sie als MOF-Datei (z. B. products.mof).

    qualifier dynamic:ToInstance;
    qualifier ProviderClsid:ToInstance;
    qualifier ClassContext:ToInstance;
    qualifier propertycontext:ToInstance; 
     [dynamic, provider("RegProv"),
    ProviderClsid("{fe9af5c0-d3b6-11ce-a5b6-00aa00680c3f}"),
    ClassContext
    ("local|HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall")
    ] 
    class Products {
       [key] string KeyName;
       [read, propertycontext("DisplayName")]      string DisplayName;
       [read, propertycontext("DisplayVersion")]      string  DisplayVersion;
       [read, propertycontext("InstallLocation")]      string InstallLocation;
    };
    

    Schritt 2: Geben Sie an der Eingabeaufforderung mofcomp products.mof ein. Damit wird die MOF-Datei im WMI-Repository gespeichert.

    Schritt 3: Während die MOF-Datei im Repository gespeichert ist, verwenden Sie das nachstehende Skript zum Abrufen der Daten.
    strComputer = "." 
    Set WMI = GetObject("winmgmts:\\" & strComputer & _
        "\root\default")
    Set colItems = WMI.ExecQuery("Select * from Products")
    For Each objItem In colItems
        WScript.Echo "DisplayName: "  & objItem.DisplayName
        WScript.Echo "DisplayVersion: " & objItem.DisplayVersion
        WScript.Echo "InstallLocation: " & objItem.InstallLocation
        WScript.Echo "KeyName: " & objItem.KeyName
    Next
    

Dn151197.590B5404BFEA7F06684DB47B00539355(de-de,TechNet.10).pngZum Seitenanfang

F 14. Wie kann ich Leistungsindikatorendaten abrufen?

Die Unterstützung für den Anbieter berechneter Indikatoren - das schnellste, einfachste Verfahren zum Abrufen von Leistungsdaten mithilfe von WMI - wurde zum ersten Mal in Windows XP hinzugefügt. Unter Windows 2000 können Sie Leistungsdaten weiterhin abrufen; weil diese Daten im "nicht berechneten" Format angezeigt werden, müssen Sie sie jedoch selbst formatieren, um brauchbare Werte für die meisten Indikatoren zu erhalten. Im Gegensatz dazu können Leistungsdaten unter Windows XP und Windows Server 2003 direkt über die Win32_PerfFormattedData-Klassen erhalten werden.

Weil der Anbieter für berechnete Indikatoren unter Windows 2000 nicht verfügbar ist, müssen Berechnungen an den Rawdaten der Leistungsindikatoren durchgeführt werden, um sinnvolle Leistungsinformationen zu erhalten.

Zum Suchen nach der richtigen Formel für jeden Indikatortyp geben Sie zuerst den numerischen Indikatortyp für die Eigenschaft ein und verwenden dazu entweder das WMI SDK (Thema "Performance Counter Classes") oder den Qualifizierer "countertype" für die betreffende Eigenschaft.

Bei Systemen unter Windows NT 3.5x/4.0 muss der Anbieter für Leistungsüberwachung verwendet werden, um Leistungsindikatoren mithilfe von WMI zu erhalten.

Incorrectly formatted figure.


Anzeigen: