12
WMI lastet Server CPU voll aus
Hallo,
Ich Habe einen Win Server 2016 Standard als Terminal Server in Verwendung.
Leider hat dieser das Problem das die WMI-Provider immer wieder den Server zu 100%(CPU) auslastet.
Temporäre Behebung WMI-Verwaltungsdienst neu starten. Was auf Dauer keine Lösung ist.
Ich konnte herausfinden das in der Ereignisanzeige unter WMI activity eine Prozess ID immer Fehler aufweist diese Prozess ID verweist im Taskmanager auf die SCVHOST.exe. Diese Wiederum weißt auf den Dienst gpsvy Gruppenrichtlinien Client.
Nun steh ich ein bisschen an. Hab schon einiges probiert aber nichts hat gefruchtet.
Hattet ihr das schonmal?
Danke im Voraus!!
Ich Habe einen Win Server 2016 Standard als Terminal Server in Verwendung.
Leider hat dieser das Problem das die WMI-Provider immer wieder den Server zu 100%(CPU) auslastet.
Temporäre Behebung WMI-Verwaltungsdienst neu starten. Was auf Dauer keine Lösung ist.
Ich konnte herausfinden das in der Ereignisanzeige unter WMI activity eine Prozess ID immer Fehler aufweist diese Prozess ID verweist im Taskmanager auf die SCVHOST.exe. Diese Wiederum weißt auf den Dienst gpsvy Gruppenrichtlinien Client.
Nun steh ich ein bisschen an. Hab schon einiges probiert aber nichts hat gefruchtet.
Hattet ihr das schonmal?
Danke im Voraus!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2535256000
Url: https://administrator.de/forum/wmi-lastet-server-cpu-voll-aus-2535256000.html
Ausgedruckt am: 21.12.2024 um 17:12 Uhr
12 Kommentare
Neuester Kommentar
Diese Wiederum weißt auf den Dienst gpsvy Gruppenrichtlinien Client.
Da hat wohl jemand GPOs mit WMI-Abfragen gefiltert. Ist generell keine gute Idee, da WMI von Haus aus viel Performance bei der Gruppenrichtlienverarbeitung verschlingt und auch Logins erheblich verzögern kann. Hier sollte man besser auf GPP oder anderweitige Filter (Security-Filterung/OU-Organisation anpassen) ausweichen.Besonders fatal ist wenn man die WMI Abfrage auf die Klasse Win32_Product los lässt, das triggert gerne eine Installer-Neukonfiguration aller installierten Programme und lastet das System gerne mal zu 100% aus, wenn sich dann noch mehrere User gleichzeitig anmelden, bumms ....
Zitat von @1915348599:
Besonders fatal ist wenn man die WMI Abfrage auf die Klasse Win32_Product los lässt, das triggert gerne eine Installer-Neukonfiguration aller installierten Programme und lastet das System gerne mal zu 100% aus, wenn sich dann noch mehrere User gleichzeitig anmelden, bumms ....
Diese Wiederum weißt auf den Dienst gpsvy Gruppenrichtlinien Client.
Da hat wohl jemand GPOs mit WMI-Abfragen gefiltert. Ist generell keine gute Idee, da WMI von Haus aus viel Performance bei der Gruppenrichtlienverarbeitung verschlingt und auch Logins erheblich verzögern kann. Hier sollte man besser auf GPP oder anderweitige Filter (Security-Filterung/OU-Organisation anpassen) ausweichen.Besonders fatal ist wenn man die WMI Abfrage auf die Klasse Win32_Product los lässt, das triggert gerne eine Installer-Neukonfiguration aller installierten Programme und lastet das System gerne mal zu 100% aus, wenn sich dann noch mehrere User gleichzeitig anmelden, bumms ....
AH ok. So ganz weiß ich nicht was was ich damit anfangen soll aber ich werde mal in diese Richtung forschen.
Danke für die Schnelle Antwort!
Zitat von @MaxHax:
AH ok. So ganz weiß ich nicht was was ich damit anfangen soll aber ich werde mal in diese Richtung forschen.
Danke für die Schnelle Antwort!
Das meine ichAH ok. So ganz weiß ich nicht was was ich damit anfangen soll aber ich werde mal in diese Richtung forschen.
Danke für die Schnelle Antwort!
Gruppenrichtlinien mit WMI-Filter auf bestimmte PCs und User beschränken
Wenn du damit auch nichts anfangen kannst, dann solltest du diese Aufgabe eurem tatsächlichen Admin übergeben ... Wenn du das selbst bist, dann hilft wohl nur zurück auf die GPO Grundlagen-Schulbank...
Zitat von @1915348599:
Gruppenrichtlinien mit WMI-Filter auf bestimmte PCs und User beschränken
Wenn du damit auch nichts anfangen kannst, dann solltest du diese Aufgabe eurem tatsächlichen Admin übergeben ... Wenn du das selbst bist, dann hilft wohl nur zurück auf die GPO Grundlagen-Schulbank...
Zitat von @MaxHax:
AH ok. So ganz weiß ich nicht was was ich damit anfangen soll aber ich werde mal in diese Richtung forschen.
Danke für die Schnelle Antwort!
Das meine ichAH ok. So ganz weiß ich nicht was was ich damit anfangen soll aber ich werde mal in diese Richtung forschen.
Danke für die Schnelle Antwort!
Gruppenrichtlinien mit WMI-Filter auf bestimmte PCs und User beschränken
Wenn du damit auch nichts anfangen kannst, dann solltest du diese Aufgabe eurem tatsächlichen Admin übergeben ... Wenn du das selbst bist, dann hilft wohl nur zurück auf die GPO Grundlagen-Schulbank...
Stimmt!
Ich habe nun ein paar Altlasten gefunden was das betrifft. Ich lasse heute die Server neu starten und schaue morgen nochmal drüber.
Wenn nun ein WMI-Filter der Grund wäre, dann lastet der doch kein System (Terminalserver) mit mehreren CPUs länger als ein paar Sekunden voll aus. Wenn Du nun hunderte GPOs mit WMI-Filtern hättest, dann gerne, aber nicht bei einigen wenigen.
Stelle doch zunächst einmal sicher, dass es einen Zusammenhang zur GPO-Verarbeitung gibt, also mach auf einem elevated command prompt
gpupdate /force
Schau in den Taskmanager dabei und prüfe, ob es wirlich über mehr als ein paar Sekunden diese Vollauslastung gibt.
Wenn ja, schau am Terminalserver ins Log der Gruppenrichtlinineverarbeitung rein, da steht wahrscheinlich Zielführendes drin: eventvwr ->Application and services Logs ->Microsoft-Windows-GroupPolicy/Operational
Stelle doch zunächst einmal sicher, dass es einen Zusammenhang zur GPO-Verarbeitung gibt, also mach auf einem elevated command prompt
gpupdate /force
Schau in den Taskmanager dabei und prüfe, ob es wirlich über mehr als ein paar Sekunden diese Vollauslastung gibt.
Wenn ja, schau am Terminalserver ins Log der Gruppenrichtlinineverarbeitung rein, da steht wahrscheinlich Zielführendes drin: eventvwr ->Application and services Logs ->Microsoft-Windows-GroupPolicy/Operational
Hallo,
Erstmal danke für die Hilfe.
Leider ist trotz neu gestarteter Maschinen und entfernter WMI Filter die CPU heute wieder hoch. Siehe anbei.
So wie es aussieht liegt es nicht am WMI Filter den die Auslastung ist ziemlich Konstant und geht nicht nur bei der Anmeldung hoch.
Erstmal danke für die Hilfe.
Leider ist trotz neu gestarteter Maschinen und entfernter WMI Filter die CPU heute wieder hoch. Siehe anbei.
So wie es aussieht liegt es nicht am WMI Filter den die Auslastung ist ziemlich Konstant und geht nicht nur bei der Anmeldung hoch.
Geh dies mal durch:
https://docs.microsoft.com/de-de/troubleshoot/windows-server/system-mana ...
https://docs.microsoft.com/de-de/troubleshoot/windows-server/system-mana ...
Hi,
ich habe hier einen virtualisierten Terminalserver 2019 mit dem gleichen Problem.
Das ist ein Arzt-Server auf dem die Medatixx Isynet läuft. Dann kam das unsägliche Doctolib (als Desktop Anwendung installiert) und schwupps war die WMI Provider Auslastung sehr hoch.
Alles durchexerziert was man so finden konnte und es deutete auf den ESET hin - jedoch war der nicht schuld. (wurde entfernt, dann war es was anderes)
Nach langem hin und her mit den Entwicklern von Doctolib ist bei uns die Schnittstelle Isynet + Doctolib Schuld. Ist kein Doctolib auf den RDP Sitzungen aktiv kein Problem. Kommen ca. 10 Instanzen hinzu steigt die Last exponentiell an.
Durch Umverteilung von Ressourcen konnte ich es ein wenig abmildern.
Ich hoffe ich konnte ein wenig beitragen...
ich habe hier einen virtualisierten Terminalserver 2019 mit dem gleichen Problem.
Das ist ein Arzt-Server auf dem die Medatixx Isynet läuft. Dann kam das unsägliche Doctolib (als Desktop Anwendung installiert) und schwupps war die WMI Provider Auslastung sehr hoch.
Alles durchexerziert was man so finden konnte und es deutete auf den ESET hin - jedoch war der nicht schuld. (wurde entfernt, dann war es was anderes)
Nach langem hin und her mit den Entwicklern von Doctolib ist bei uns die Schnittstelle Isynet + Doctolib Schuld. Ist kein Doctolib auf den RDP Sitzungen aktiv kein Problem. Kommen ca. 10 Instanzen hinzu steigt die Last exponentiell an.
Durch Umverteilung von Ressourcen konnte ich es ein wenig abmildern.
Ich hoffe ich konnte ein wenig beitragen...
Ja Interessant.
Aber ich habe mal alle Dienste die vom VerwaltungsInstrumentation einzeln neu gestartet doch da ändert sich leider nichts. Ist mir echt ein Rätsel wir haben mittlerweile noch jemanden gefunden bei dem das Problem auftritt.
So gut wie keine Gemeinsamkeiten was die installierten Programme betrifft.
Aber ich habe mal alle Dienste die vom VerwaltungsInstrumentation einzeln neu gestartet doch da ändert sich leider nichts. Ist mir echt ein Rätsel wir haben mittlerweile noch jemanden gefunden bei dem das Problem auftritt.
So gut wie keine Gemeinsamkeiten was die installierten Programme betrifft.
Hast Du den MS-Artikel durch, den ich verlinkt hatte? Klang doch vielversprechend.
Zitat von @DerWoWusste:
Hast Du den MS-Artikel durch, den ich verlinkt hatte? Klang doch vielversprechend.
Hast Du den MS-Artikel durch, den ich verlinkt hatte? Klang doch vielversprechend.
Wenn ich den Befehl tasklist /m wmiperfclass.dll eingebe wird mir eine PID ausgegeben von einem WMI Provider Host der 0% CPU Auslastung braucht die stimmen also nicht wie im Bericht beschrieben überein.
Somit hilft das leider auch nicht.
Aber Danke!
Ich habe mich nun mal hingesetzt und alle User angemeldet.
Der WMI stieg sofort an auf die 100% CPU.
Dann habe ich das einzige Programm das mit startet beendet WMI ist sofort gesunken.
Es muss also an der Telefonie Software liegen läuft ist die WMI Auslastung sehr hoch beendet ist nichts mehr zu sehen.
Ich werde in diese Richtung weiter forschen.
Der WMI stieg sofort an auf die 100% CPU.
Dann habe ich das einzige Programm das mit startet beendet WMI ist sofort gesunken.
Es muss also an der Telefonie Software liegen läuft ist die WMI Auslastung sehr hoch beendet ist nichts mehr zu sehen.
Ich werde in diese Richtung weiter forschen.
