Geheimnisse von Windows Management Instrumentation
Problembehandlung und Tipps
Hinweis: Dieses Dokument wurde ursprünglich unter dem Titel "Windows Management Instrumentation: Häufig gestellte Fragen" veröffentlicht.
Auf dieser Seite
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.asp 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.
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. |
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/library/default.asp?url=/library/en-us/wmisdk/wmi/wmi_reference.asp (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.
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?.
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:
| • | TechNet Script Center |
| • | MSDN |
| • | WMI Software Developers Kit (SDK) |
| • | Das Microsoft Windows 2000 - Scripting-Handbuch online |
| • | Die Rubrik "Tales from the Script" in TechNet |
| • | Die Rubrik "Scripting Clinic" in MSDN |
| • | Newsgroups Microsoft.public.windowsxp.wmi Microsoft.public.windows.server.scripting |
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.asp) (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?
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.asp 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.asp 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.asp 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
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:
| ||||
2. | Beenden Sie den WMI-Dienst. Der WMI-Dienst hat den Namen "winmgmt". Zum Beenden des Dienstes führen Sie den folgenden Befehl aus: | ||||
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"
Manuelles erneutes Erstellen des WMI-Repositorys
| ||||||||||||
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.
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. |
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. |
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> Benutzer: kenmyer |
3. | Zur Verwendung der Kerberos-Authentifizierung geben Sie Folgendes ein: Benutzer: <domäne>\<Benutzer> Benutzer: kenmyer |
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://www.microsoft.com/germany/msdn/default.mspx 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).
| ||||||||||
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://www.microsoft.com/germany/msdn/default.mspx 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.asp 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.asp 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):
|
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/library/default.asp?url=/library/en-us/wmisdk/wmi/swbemlocator_connectserver.asp) (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. |
Weitere Informationen zu Delegierung und Remoteverbindungen finden Sie unter "Connecting to a 3rd Computer-Delegation" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting_to_a_3rd_computer-delegation.asp) und unter "Securing a Remote WMI Connection" (http://msdn.microsoft.com/library/en-us/wmisdk/wmi/securing_a_remote_wmi_connection.asp) (nur auf Englisch verfügbar).
Lesen Sie außerdem die Fragen Wie kann ich Remotecomputer mithilfe von WMI verwalten? und Wie kann ich die WMI-Namespacesicherheit festlegen?
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/library/en-us/wmisdk/wmi/making_a_semisynchronous_call_with_vbscript.asp) (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/library/en-us/wmisdk/wmi/invoking_an_asynchronous_query.asp) und unter "Setting Security on an Asynchronous Call" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/setting_security_on_an_asynchronous_call.asp) (nur auf Englisch verfügbar).
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
|
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. Weitere Informationen hierzu finden Sie unter "Example: Obtaining Cooked Performance Data" (http://msdn.microsoft.com/library/en-us/wmisdk/wmi/making_a_semisynchronous_call_with_vbscript.asp) (nur auf Englisch verfügbar).
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. Details zum Arbeiten mit Rawdaten der Leistungsindikatoren finden Sie unter "Example: Obtaining Raw Performance Data" (http://msdn.microsoft.com/library/en-us/wmisdk/wmi/example__obtaining_raw_performance_data.asp) (nur auf Englisch verfügbar).
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. Die Formel für diesen Indikatortyp finden Sie unter "WMI Performance Counter Types" (http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_performance_counter_types.asp) (nur auf Englisch verfügbar).
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. Weitere Informationen hierzu finden Sie unter "Monitoring Performance With the Performance Monitoring Provider" (http://msdn.microsoft.com/library/en-us/wmisdk/wmi/monitoring_performance_with_the_performance_monitoring_provider.asp) (nur auf Englisch verfügbar).