Freigeben über

Szenariohandbuch: Behandeln von Problemen mit WMI-Konnektivität und Zugriff

In diesem Artikel wird beschrieben, wie Sie die WMI-Konfiguration (Windows Management Instrumentation) überprüfen und wie Sie WMI-Konnektivitäts- oder Zugriffsprobleme diagnostizieren und beheben.

Hier sind einige Beispiele für WMI-Konfigurations- oder Konnektivitätsprobleme, die auftreten können. Die Probleme stammen aus verschiedenen Produkten und Anwendungen, die WMI verwenden oder davon abhängen.

  • Der Assistent zum Erstellen von Clustern versucht, eine Verbindung mit einem Remotecomputer (dem Clusterknoten) herzustellen, jedoch keine Daten abzurufen.

    Screenshot des Assistenten zum Erstellen von Clustern, der den Computer anzeigt, kann kein Fehler erreicht werden.

    Screenshot des Assistenten zum Hinzufügen von Knoten mit einem Fehler beim Abrufen der maximalen Anzahl von Knotenfehlern.

  • Wenn das Active Directory-Rolleninstallationsprogramm versucht, mit seinem Hostcomputer zu kommunizieren, schlägt der Konfigurations-Assistent für Active Directory-Domäne Dienste mit dem folgenden Fehler fehl:

    Adprep konnte keine Daten vom Server testbox.contoso.com über die Windows-Verwaltungsinstrumentation (WMI) abrufen.

    Screenshot des Konfigurations-Assistenten für Active Directory-Domäne Dienste mit Adprep konnte keine Datenfehler abrufen.

  • Die lokale WMI-Abfrage kann das Get-WmiObject PowerShell-Cmdlet nicht verwenden und empfängt den Fehler "Zugriff verweigert".

    Screenshot des Cmdlet-Ergebnisses

Verbindungsfluss

Es gibt mehrere Komponenten und Ebenen, die an einer WMI-Verbindung beteiligt sind. Die folgenden Komponenten sind auf hoher Ebene beteiligt:

  • Die Client- oder Verwaltungsanwendung, die die WMI-Verbindung oder -Abfrage initiiert

  • Die Komponente Object Model (COM) oder die DCOM-Komponente (Distributed Component Object Model), die für die lokale und Remote-Kommunikation zwischen Prozessen (IPC) verwendet wird.

  • Die Transport- oder Netzwerkebene (Remote Procedure Call (RPC))

  • WMI-Repository und WMI-Dienst

  • Der WMI-Anbieter

  • Die verwalteten Objekte

    Diagramm des WMI-Verbindungsflusses.

Identifizieren des Problems

Basierend auf dem Fehler oder Fehler oder der Komponente, die den Fehler zurückgibt, können die Probleme wie folgt kategorisiert werden:

  • Verbindungsprobleme
  • Zugriffsprobleme
  • Kernfehlercodes für WMI-Anbieter

Verbindungsprobleme

Ein WMI-Verbindungsfehler, der vor dem Herstellen der Verbindung mit der WMI-Infrastruktur entweder lokal oder remote auftritt, wird als Verbindungsproblem angesehen.

Das Problem oder der Fehler wird von der COM/DCOM-Architektur lokal oder remote, der Transportschicht (RPC) oder der Firewall zurückgegeben. Verschiedene Fehler können bei Verbindungsproblemen auftreten, aber die häufigsten Fehler sind:

  • 0x800706BA
    HRESULT_FROM_WIN32(RPC_S_SERVER_UNAVAILABLE)

  • 0x80041015
    Ein Netzwerkfehler ist aufgetreten, der verhindert, dass der Vorgang normal ausgeführt wird.

Zugriffsprobleme

Ein Zugriffsproblem tritt auf, wenn eine WMI-Verbindung oder Abfrage aufgrund eines Zugriffsfehlers oder fehlender Berechtigungen für eine oder mehrere WMI-Komponenten fehlschlägt.

Mit anderen Worten, es gibt mehrere Bereiche in der WMI-Infrastruktur, z. B. COM/DCOM, WMI-Namespaces, WMI-Repository und Anbieter, und Benutzer benötigen entsprechende Berechtigungen für den Zugriff, die Verwendung oder interaktion mit diesen. Fehlende Berechtigungen oder Einschränkungen führen zu WMI-Verbindungsfehlern, und möglicherweise erhalten Sie die folgenden Fehler:

  • 0x80070005
    E_ACCESS_DENIED
    Zugriff durch DCOM-Sicherheit verweigert

  • 0x80041003
    WBEM_E_ACCESS_DENIED
    Zugriff durch einen Anbieter verweigert

Kernfehlercodes für WMI-Anbieter

Selbst nach einer erfolgreichen Verbindung mit dem WMI und der richtigen Berechtigungen kann eine WMI-Abfrage oder Verbindung aufgrund eines zugrunde liegenden Problems mit der Abfrage fehlschlagen, ein vom Anbieter zurückgegebener Fehler, eine ungültige Klasse oder ein ungültiger Namespace.

Das Problem kann aus verschiedenen Gründen auftreten, und Fehler werden hauptsächlich vom WMI-Dienst zurückgegeben.

In solchen Fällen hilft der zurückgegebene Fehlercode, das Problem zu verstehen. Hier sind einige Fehlercodes:

  • 0x80041002 - WBEM_E_NOT_FOUND

  • 0x80041004 - WBEM_E_PROVIDER_FAILURE

  • 0x80041062 - WBEM_E_PRIVILEGE_NOT_HELD

  • 0x8004100E - WBEM_E_INVALID_NAMESPACE

  • 0x80041010 - WBEM_E_INVALID_CLASS

  • 0x80041011 - WBEM_E_PROVIDER_NOT_FOUND

  • 0x80041012 - WBEM_E_INVALID_PROVIDER_REGISTRATION

  • 0x80041013 - WBEM_E_PROVIDER_LOAD_FAILURE

Die vollständige Liste der fehler, die von der WMI-Infrastruktur zurückgegeben werden, ist in WMI-Fehlerkonstanten aufgeführt.

Überprüfen der Konfiguration

Wenn Sie bestätigen können, dass es sich bei dem Problem um ein Verbindungs- oder Zugriffsproblem handelt, das auf dem Fehler oder dem zurückgegebenen Fehler basiert, überprüfen Sie die vorhandene Konfiguration von WMI, oder stellen Sie sicher, dass der Benutzer über die entsprechenden Berechtigungen verfügt.

  • Standardmäßig können nur Mitglieder der Gruppe "Administratoren " remote auf den WMI-Namespace zugreifen.
  • Um eine Verbindung mit einem Remotecomputer mit WMI herzustellen, stellen Sie sicher, dass die richtigen DCOM-Einstellungen und WMI-Namespacesicherheitseinstellungen für die Verbindung aktiviert sind.
  • WMI verfügt über Standardeinstellungen für Identitätswechsel, Authentifizierung und Authentifizierungsdienst (NTLM oder Kerberos), die der Zielcomputer in einer Remoteverbindung erfordert. Auf Ihrem lokalen Computer werden möglicherweise unterschiedliche Standardwerte verwendet, die vom Zielsystem nicht akzeptiert werden. Sie können diese Einstellungen im Verbindungsaufruf ändern.
  • Verbindungen mit WMI auf dem lokalen Computer weisen eine Standardauthentifizierungsstufe auf PktPrivacy.
  • WMI-Remoteverbindungen sind von der Benutzerkontensteuerung (User Account Control, UAC) und der Windows-Firewall betroffen.

Festlegen der DCOM-Sicherheit, damit ein Nicht-Administrator-Benutzer remote auf einen Computer zugreifen kann

Sie können DCOM-Einstellungen für WMI konfigurieren, indem Sie das DCOM-Konfigurationshilfsprogramm (DCOMCnfg.exe) in den Verwaltungstools in Systemsteuerung verwenden.

Dieses Hilfsprogramm macht die Einstellungen verfügbar, mit denen bestimmte Benutzer remote über DCOM eine Verbindung mit dem Computer herstellen können. Mit diesem Hilfsprogramm können Sie die Sicherheit festlegen, um den WMI-Dienst zu starten, darauf zuzugreifen und zu konfigurieren.

Im folgenden Verfahren wird beschrieben, wie Sie bestimmten Benutzern und Gruppen DCOM Remotestart- und Aktivierungsberechtigungen erteilen.

Wenn Computer A eine Remoteverbindung mit Computer B herstellt, können Sie diese Berechtigungen auf Computer B festlegen, damit ein Benutzer oder eine Gruppe, die nicht Teil der Gruppe "Administratoren " auf Computer B ist, DCOM-Start- und Aktivierungsaufrufe auf Computer B ausführen kann.

Führen Sie die folgenden Schritte aus, um DCOM Remotestart- und Aktivierungsberechtigungen manuell einem Benutzer oder einer Gruppe zu erteilen:

  1. Wählen Sie "Start ausführen"> aus, geben Sie "DCOMCNFG" ein, und wählen Sie dann "OK" aus.
  2. Erweitern Sie im Fenster "Komponentendienste" Komponentendienstecomputer>. Klicken Sie mit der rechten Maustaste auf Arbeitsplatz, und wählen Sie Eigenschaften aus.
  3. Wählen Sie im Dialogfeld "Meine Computereigenschaften " die Registerkarte "COM-Sicherheit " aus.
  4. Wählen Sie unter "Start- und Aktivierungsberechtigungen" die Option "Grenzwerte bearbeiten" aus.
  5. Wählen Sie im Dialogfeld "Start" und "Aktivierungsberechtigung " die Option "Hinzufügen" aus, wenn Ihr Name oder Ihre Gruppe nicht in der Liste " Gruppen- oder Benutzernamen " angezeigt wird. Fügen Sie im Dialogfeld "Benutzer, Computer oder Gruppen auswählen" Ihren Namen und ihre Gruppe in das Feld "Objektnamen eingeben" ein, und wählen Sie dann "OK" aus.
  6. Wählen Sie im Dialogfeld "Start" und "Aktivierungsberechtigung " Ihren Benutzer und Ihre Gruppe in der Liste " Gruppe" oder "Benutzernamen " aus. Aktivieren Sie unter Berechtigungen für <Benutzer- oder Gruppenberechtigungen>" zulassen" für die Remotestart- und Berechtigungen für die Remoteaktivierung, und wählen Sie dann OKaus.

Im folgenden Verfahren wird beschrieben, wie Sie bestimmten Benutzern und Gruppen DCOM-Remotezugriffsberechtigungen erteilen. Wenn Computer A eine Remoteverbindung mit Computer B herstellt, können Sie diese Berechtigungen auf Computer B festlegen, damit ein Benutzer oder eine Gruppe, die nicht Teil der Gruppe "Administratoren " auf Computer B ist, eine Verbindung mit Computer B herstellen kann.

Führen Sie die folgenden Schritte aus, um DCOM-Remotezugriffsberechtigungen zu erteilen:

  1. Wählen Sie "Start ausführen"> aus, geben Sie "DCOMCNFG" ein, und wählen Sie dann "OK" aus.
  2. Erweitern Sie im Fenster "Komponentendienste" Komponentendienstecomputer>. Klicken Sie mit der rechten Maustaste auf Arbeitsplatz, und wählen Sie Eigenschaften aus.
  3. Wählen Sie im Dialogfeld "Meine Computereigenschaften " die Registerkarte "COM-Sicherheit " aus.
  4. Wählen Sie unter "Zugriffsberechtigungen" die Option "Grenzwerte bearbeiten" aus.
  5. Wählen Sie im Dialogfeld "Zugriffsberechtigung" im Feld "Gruppe" oder "Benutzernamen" die Option "ANONYME ANMELDUNG" aus. Überprüfen Sie unter "Berechtigungen für ANONYME ANMELDUNG" die Berechtigung "Remotezugriff zulassen", und wählen Sie dann "OK" aus.

Notiz

Sie können den Benutzer auch lokal auf dem Zielcomputer der Gruppe "Verteilte COM-Benutzer " hinzufügen. Standardmäßig verfügt diese Gruppe über alle Berechtigungen für den Zugriff auf COM/DCOM auf jedem Windows-Computer.

Zulassen, dass Benutzer auf einen bestimmten WMI-Namespace zugreifen können

Sie können Benutzern den Zugriff auf einen bestimmten WMI-Namespace gestatten oder verbieten, indem Sie die Berechtigung "Remoteaktivierung " im WMI-Steuerelement für einen Namespace festlegen. Wenn ein Benutzer versucht, eine Verbindung mit einem Namespace herzustellen, auf den der Benutzer nicht zugreifen darf, erhält der Benutzer eine Fehlermeldung 0x80041003.

Diese Berechtigung ist standardmäßig nur für Administratoren aktiviert. Ein Administrator kann den Remotezugriff auf bestimmte WMI-Namespaces für einen Nicht-Administrator-Benutzer aktivieren.

Im folgenden Verfahren werden remoteaktive Berechtigungen für einen Nicht-Administrator-Benutzer festgelegt.

  1. Stellen Sie mithilfe von WMIMGMT.msc eine Verbindung mit dem Remotecomputer her.

  2. Klicken Sie mit der rechten Maustaste auf das WMI-Steuerelement, und wählen Sie "Eigenschaften" aus.

  3. Wählen Sie auf der Registerkarte "Sicherheit" den Namespace und dann "Sicherheit" aus.

    Notiz

    Root\cimv2 ist der Standardnamespace.

  4. Suchen oder hinzufügen Sie das entsprechende Konto, und überprüfen Sie in der Berechtigungsliste remote enable and Read Security .

    Notiz

    Um sicherzustellen, dass dieselben Berechtigungen an den Unterordner oder Unternamen geerbt werden, wählen Sie "Erweitert" aus. Wählen Sie dann den vorgesehenen Benutzer aus, und stellen Sie sicher, dass dieser Namespace und Unternamespace unter dem Abschnitt "Gilt für" ausgewählt ist.

    Screenshot des Berechtigungseintrags für CIMV2 mit ausgewählten Berechtigungen.

Um die Verbindung mit einer bestimmten Klasse in einem bestimmten Namespace zu überprüfen, können Sie das Tool für die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation Tester, WBEMTEST) verwenden, indem Sie die folgenden Schritte ausführen:

  1. Öffnen Sie WBEMTEST als Administrator, und wählen Sie "Verbinden" aus. Standardmäßig stellt die Konsole eine Verbindung mit dem lokalen WMI Root\cimv2-Namespace bereit.
  2. Ändern Sie den Namespace in den Namespace, mit dem Sie versuchen, die Verbindung zu testen. Wenn es sich um einen Remotecomputer handelt, geben Sie ihn im Format " \\<machinename>\Root\cimv2" ein.

Wenn die Verbindung erfolgreich ist, wird das Hauptfenster von WBEMTEST mit dem nicht standardmäßig bereitgestellten Namespace verbunden.

Standardmäßig verwendet die WBEMTEST-Verbindung die angemeldeten Benutzeranmeldeinformationen. Wenn Sie eine Verbindung mit einem anderen Konto herstellen, werden die Anmeldeinformationen angezeigt, bevor Sie versuchen, eine Verbindung herzustellen.

Das folgende Beispiel zeigt einen Versuch, mithilfe der Anmeldeinformationen von User1 eine Verbindung mit dem Namespacestamm \ccm auf "RemoteMachine1" herzustellen.

Screenshot des Fensters

Um eine WMI-Verbindung zwischen einem in die Domäne eingebundenen Computer und einem Arbeitsgruppencomputer einzurichten, sollten Sie einen lokalen Benutzer des Zielcomputers in Betracht ziehen.

Notiz

Wenn Sie den integrierten lokalen Administrator des Zielcomputers verwenden, verfügt dieser Benutzer bereits über die entsprechenden Rechte für den Remotezugriff auf WMI von anderen Computern und benötigt keine zusätzliche Konfiguration.

Die Firewall des Zielcomputers sollte die eingehende WMI-Verbindung zulassen, für die die oben genannte Firewallkonfiguration ausgeführt werden kann, wie im Abschnitt mit den Windows-Firewalleinstellungen dargestellt. Konfigurieren Sie dann den DCOM-Sicherheits- und WMI-Namespace wie in der Einstellung der DCOM-Sicherheit gezeigt, damit ein Nicht-Administrator-Benutzer remote auf einen Computer zugreifen kann und Benutzern den Zugriff auf einen bestimmten WMI-Namespaceabschnitt ermöglicht.

Windows-Firewall-Einstellungen

WMI-Einstellungen für Windows-Firewalleinstellungen aktivieren nur WMI-Verbindungen anstelle anderer DCOM-Anwendungen.

Eine Ausnahme muss in der Firewall für WMI auf dem Remotezielcomputer festgelegt werden.

Die Ausnahme für WMI ermöglicht es WMI, Remoteverbindungen zu empfangen. Wenn eine Clientanwendung eine eigene Spüle erstellt, muss diese Spüle explizit den Firewall-Ausnahmen hinzugefügt werden, damit Rückrufe erfolgreich ausgeführt werden können.

Sie können WMI-Datenverkehr über die Windows-Firewall-Benutzeroberfläche aktivieren oder deaktivieren. Gehen Sie dazu wie folgt vor:

  1. Wählen Sie in Systemsteuerung die Sicherheits-Windows-Firewall> aus.
  2. Klicken Sie auf Einstellungen ändern, und klicken Sie dann auf die Registerkarte Ausnahmen.
  3. Aktivieren Sie im Fenster "Ausnahmen " das Kontrollkästchen "Windows-Verwaltungsinstrumentation(WMI) ", um WMI-Datenverkehr über die Firewall zu aktivieren. Deaktivieren Sie das Kontrollkästchen, um WMI-Datenverkehr zu deaktivieren.

Sie können WMI-Datenverkehr über die Firewall an der Eingabeaufforderung mithilfe der WMI-Regelgruppe aktivieren oder deaktivieren.

  • Verwenden Sie den folgenden Befehl an einer Eingabeaufforderung, um WMI-Datenverkehr über die Firewall zu aktivieren.

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

  • Verwenden Sie den folgenden Befehl, um WMI-Datenverkehr über die Firewall zu deaktivieren.

    netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=no

Statt einen einzelnen WMI-Regelgruppenbefehl zu verwenden, können Sie auch einzelne Befehle für jeden DCOM-, WMI-Dienst und -Sink verwenden.

So aktivieren Sie WMI-Datenverkehr mithilfe separater Regeln für DCOM, WMI, Rückrufsenke und ausgehende Verbindungen:

  • Verwenden Sie den folgenden Befehl, um eine Firewall-Ausnahme für DCOM-Port 135 einzurichten:

    netsh advfirewall firewall add rule dir=in name="DCOM" program=%systemroot%\system32\svchost.exe service=rpcss action=allow protocol=TCP localport=135

  • Verwenden Sie den folgenden Befehl, um eine Firewall-Ausnahme für den WMI-Dienst einzurichten:

    netsh advfirewall firewall add rule dir=in name ="WMI" program=%systemroot%\system32\svchost.exe service=winmgmt action = allow protocol=TCP localport=any

  • Verwenden Sie den folgenden Befehl, um eine Firewall-Ausnahme für die Spüle einzurichten, die Rückrufe von einem Remotecomputer empfängt:

    netsh advfirewall firewall add rule dir=in name ="UnsecApp" program=%systemroot%\system32\wbem\unsecapp.exe action=allow

  • Verwenden Sie den folgenden Befehl, um eine Firewall-Ausnahme für ausgehende Verbindungen mit einem Remotecomputer herzustellen, mit dem der lokale Computer asynchron kommuniziert:

    netsh advfirewall firewall add rule dir=out name ="WMI_OUT" program=%systemroot%\system32\svchost.exe service=winmgmt action=allow protocol=TCP localport=any

So deaktivieren Sie WMI-Datenverkehr mithilfe separater Regeln für DCOM, WMI, Rückrufsenken und ausgehende Verbindungen:

  • Verwenden Sie den folgenden Befehl, um die DCOM-Ausnahme zu deaktivieren:

    netsh advfirewall firewall delete rule name="DCOM"

  • Verwenden Sie den folgenden Befehl, um die WMI-Dienst-Ausnahme zu deaktivieren:

    netsh advfirewall firewall delete rule name="WMI"

  • Verwenden Sie den folgenden Befehl, um die Sink-Ausnahme zu deaktivieren:

    netsh advfirewall firewall delete rule name="UnsecApp"

  • Verwenden Sie den folgenden Befehl, um die ausgehende Ausnahme zu deaktivieren:

    netsh advfirewall firewall delete rule name="WMI_OUT"

Behandeln von Problemen mit verschiedenen Szenarien

Die meisten Konnektivitätsprobleme sind auf falsche Berechtigungen, keine Berechtigungen oder externe Faktoren wie Firewalls oder Antivirensoftware zurückzuführen. Daher kann die Überprüfung der Konfiguration das Problem beheben.

Abgesehen von der Standardkonfiguration können sich einige zusätzliche Einstellungen auf die Konnektivität auswirken.

  • Überprüfen Sie die Anwendungs- und Systemereignisprotokolle auf fehler, die von der Clientanwendung oder von der Quelle (Microsoft-Windows-DistributedCOM) protokolliert werden, und suchen Sie nach relevanten Fehlern oder Ereignissen, die je nach Szenario auf dem Quell- oder Zielcomputer angemeldet sein können.

  • Überprüfen Sie ereignisprotokolle der Windows-Firewall unter Ereignisanzeige> Applications and Services Logs>Windows>Firewall für alle Verbindungen von WMI, die von der Firewall blockiert werden.

    Bestimmte Gruppenrichtlinieneinstellungen sind aktiviert, um das Standardverhalten und die Berechtigungen von RPC und DCOM zu ändern. Zum Beispiel:

    • Diese Gruppenrichtlinie kann nicht authentifizierte RPC-Aufrufe einschränken, was den Fehler verursachen kann:

      Der RPC-Server ist nicht verfügbar. (Ausnahme von HRESULT: 0x800706BA)

      Computerkonfiguration\administrative Vorlagen\System\Remoteprozeduraufruf\Einschränken nicht authentifizierter RPC-Clients

      Diese Einstellung steuert, wie die RPC-Serverlaufzeit nicht authentifizierte RPC-Clients verarbeitet, die eine Verbindung mit RPC-Servern herstellen. Diese Richtlinieneinstellung wirkt sich auf alle RPC-Anwendungen aus, einschließlich WMI.

    • Diese Gruppenrichtlinie kann benutzerdefinierte DCOM-Berechtigungen konfigurieren:

      Sicherheitsoptionen\– DCOM: Computerstarteinschränkungen in der SDDL-Syntax (Security Descriptor Definition Language)

      Mit dieser Einstellung können Sie eine ACL auf zwei Arten angeben. Sie können den Sicherheitsdeskriptor in die SDDL eingeben oder lokale Zugriffs- und Remotezugriffsberechtigungen für Benutzer und Gruppen erteilen oder verweigern.

  • Überprüfen Sie den dynamischen RPC-Portbereich auf dem Zielcomputer:

    • netsh int ipv4 show dynamicport tcp
    • netsh int ipv4 show dynamicport udp
    • netsh int ipv6 show dynamicport tcp
    • netsh int ipv6 show dynamicport udp

    Vergleichen Sie sie mit einem Arbeitscomputer. Wenn der Portbereich nicht standardmäßig oder auf einen kleinen Bereich beschränkt ist, kann sich dies auf die WMI-Verbindung auswirken. Die Dienstübersicht und die Netzwerkportanforderungen für Windows zeigen den Standardportbereich an, der für RPC erforderlich ist.

Wenn das Problem ein Zugriffsproblem oder ein wichtiger WMI-Fehler ist, werden die eingehenden Abfragen im Protokoll Microsoft-Windows-WMI-Activity/Operational unter >WMI-Activity protokolliert.

In einigen Szenarien können lokale WMI-Verbindungen fehlschlagen.

Sie können WMIMGMT.msc verwenden, um die lokale WMI-Konnektivität zu überprüfen, indem Sie mit der rechten Maustaste auf das WMI-Steuerelement klicken und "Eigenschaften" auswählen.

Im Folgenden finden Sie einige Fehler, die auftreten, wenn der lokale WMI fehlschlägt:

  • Fehler beim Herstellen einer Verbindung mit <dem lokalen Computer> , da "WMI: Nicht gefunden"

    Screenshot des WMI-Steuerelements (lokal) Eigenschaftenfenster mit dem WMI-Fehler

  • Fehler beim Herstellen einer Verbindung mit <dem lokalen Computer> , da "Win32: Das System den angegebenen Pfad nicht finden kann".

    Screenshot des WMI-Steuerelements (lokal) Eigenschaftenfenster, das zeigt, dass das System den angegebenen Pfadfehler nicht finden kann.

  • Fehler beim Herstellen einer Verbindung mit <dem lokalen Computer> , da "WMI: Generischer Fehler"

    Screenshot des WMI-Steuerelements (lokal) Eigenschaftenfenster mit dem WMI Generic-Fehlerfehler.

Diese Arten von Fehlern können manchmal verursacht werden, wenn im WMI-Repository ein Fehler aufgetreten ist oder eine Beschädigung vorliegt.

Sie können den folgenden Befehl in einem Eingabeaufforderungsfenster mit erhöhten Rechten verwenden, um eine Konsistenzüberprüfung für das Live- oder aktuell verwendete WMI-Repository durchzuführen.

winmgmt /verifyrepository

Sie können diesen Befehl auch mit /verifyrepository <path>. Wenn Sie das Argument path angeben, können Sie jede gespeicherte Kopie des Repositorys überprüfen.

In diesem Fall sollte das Argument path den vollständigen Pfad zur gespeicherten Repositorykopie enthalten. Das gespeicherte Repository sollte eine Kopie des gesamten Repositoryordners sein.

Im folgenden Verfahren wird beschrieben, wie Sie die MOF-Dateien des WMI-Anbieters neu kompilieren und die WMI-Anbieter-DLLs erneut registrieren. Dazu gehören alle integrierten Anbieter und diejenigen, die sich im Standardpfad befinden. Führen Sie die folgenden Befehle in einem Eingabeaufforderungsfenster mit erhöhten Rechten aus.

Notiz

Die folgenden Schritte umfassen den Neustart des WMI-Diensts.

  1. Beenden Sie den WMI-Dienst, und legen Sie ihn auf :disabled

    sc config winmgmt start= disabled
net stop winmgmt /y

  2. Navigieren Sie zum WBEM-Ordner :

    %systemdrive%
cd %windir%\system32\wbem

  3. Registrieren Sie die WMI-Anbieter erneut:

    for /f %s in ('dir /b *.dll') do regsvr32 /s %s

  4. Setzen Sie den WMI-Dienst auf den Dienst zurück Auto , und starten Sie den Dienst:

    sc config winmgmt start= Auto
net start winmgmt

  5. Kompilieren Sie die MOF-Dateien neu:

    dir /b *.mof *.mfl | findstr /v /i uninstall > moflist.txt & for /F %s in (moflist.txt) do mofcomp %s

Notiz

Es gibt mehrere externe Blogs und Websites, um das WMI-Repository zurückzusetzen oder das WMI-Repository neu zu erstellen. Dadurch wird das WMI-Repository wieder auf den Anfangszustand zurückgesetzt, wenn das Betriebssystem installiert wurde. WMI verliert alle Informationen, die im Laufe der Zeit über das System selbst, Anwendungen, Dienste und andere Entitäten gesammelt wurden. Daher wird nicht empfohlen, das WMI-Repository neu zu erstellen, es sei denn, es wird vom Microsoft-Support ausgeführt.

Verbindungsfluss auf Netzwerkebene

Die folgenden Ablaufverfolgungen sind die Ausgabe von Netzwerkablaufverfolgungen, die mithilfe des Netzwerkmonitors zwischen zwei Computern erfasst werden, während eine WMI-Abfrage mit WMIC.exe ausgeführt wird.

Dadurch kann ermittelt werden, ob das Problem ein Netzwerkkonnektivitätsproblem ist.

  • Verbindung mit der Endpunktzuordnung am Port 135 des Zielcomputers:

    65        9:07:30 AM 3/21/2017        6.2302032        svchost.exe        10.0.0.6        10.0.0.22        TCP        TCP:Flags=......S., SrcPort=49229, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=3759018265, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192        {TCP:8, IPv4:7}

  • Anfordern der RPC-Schnittstelle UUID für IRemoteSCMActivator:

    68        9:07:30 AM 3/21/2017        6.2366981        svchost.exe        10.0.0.6        10.0.0.22        MSRPC        MSRPC:c/o Bind: IRemoteSCMActivator(DCOM) UUID{000001A0-0000-0000-C000-000000000046}  Call=0x5  Assoc Grp=0x0  Xmit=0x16D0  Recv=0x16D0         {MSRPC:9, TCP:8, IPv4:7}

  • Verbindung mit einem der dynamischen Ports, die vom Endpunktzuordnungsgerät des Zielcomputers bereitgestellt werden:

    77        9:07:30 AM 3/21/2017        6.3539124        WMIC.exe        10.0.0.6        10.0.0.22        TCP        TCP:Flags=......S., SrcPort=49230, DstPort=49154, PayloadLen=0, Seq=2143969401, Ack=0, Win=8192 ( Negotiating scale factor 0x8 ) = 8192        {TCP:10, IPv4:7}

  • Verbindung mit dem Namespace Root\CIMV2 des Computers "TargetMachine":

    96        9:07:30 AM 3/21/2017        6.4702188        WMIC.exe        10.0.0.6        10.0.0.22        WMI        WMI:IWbemLevel1Login:NTLMLogin Request, NetworkResource=\\TargetMachine\ROOT\CIMV2 PreferredLocale=ms_409,en-US,en Flags=0        {MSRPC:11, TCP:10, IPv4:7}

  • Abfrageausführung:

    116        9:07:31 AM 3/21/2017        6.7577443        WMIC.exe        10.0.0.6        10.0.0.22        WMI        WMI:IWbemServices:ExecQuery Request, *Encrypted*        {MSRPC:11, TCP:10, IPv4:7}

Datensammlung

Bevor Sie einen Supportfall zur weiteren Untersuchung öffnen, können Sie Daten sammeln, indem Sie die folgenden Schritte ausführen:

Laden Sie TSS.zip herunter, und extrahieren Sie den Inhalt.

  1. Starten Sie die Ablaufverfolgung, indem Sie das folgende Cmdlet über eine PowerShell-Eingabeaufforderung mit erhöhten Rechten ausführen.

    .\TSS.ps1 -UEX_WMIAdvanced -WMIProvList RPC,DCOM -NetshScenario netconnection -noBasicLog

  2. Reproduzieren Sie den Verbindungsfehler, oder warten Sie, bis der Fehler reproduziert wird. Lassen Sie die Ablaufverfolgung länger als zwei Minuten laufen.

  3. Beenden Sie die Ablaufverfolgung, indem Sie anweisungen im PowerShell-Fenster befolgen, in dem das TSS-Tool ausgeführt wird.

Das Skript erstellt eine ZIP-Datei mit allen Ablaufverfolgungsergebnissen und Diagnoseinformationen. Nachdem ein Supportfall erstellt wurde, können Sie diese Datei zur Analyse in den sicheren Arbeitsbereich hochladen.