none
SCCM hohe CPU Auslastung durch SMS-Agent-Host RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe ein wirklich großes Problem auf unseren Windows 10 Clients. Alle PC haben über mehrere Stunden, jeden Tag eine hohe CPU Auslastung von etwa 25 bis 50%. Diese wird vom SMS-Agent-Host Service / CcmExec.exe verursacht. Leider kann ich nicht einmal sehen, was der Client gerade tut. Ich kann mir das Verhalten nicht erklären. Ich habe bereits alle Reoports auf ein Minimum reduziert oder ganz abgeschaltet. Es gibt keinen signifikanten Netzwerk Traffic oder hohe Schreibraten auf Datenträgern. Nur die CPU wird massiv und konstant belastet. Das Problem betrifft sowohl Virtuelle Maschinen als auch physische. Auf Laptops stellt dies ein großes Problem dar. Es begann etwa Mitte Dezember 2019. Zu diesem Zeitpunkt habe ich keine Veränderungen an der Umgebung vorgenommen oder Updates installiert.
    Kann mir bitte jemand einen Rat geben, was ich noch prüfen kann und wo ich weiter suchen kann?
    Ich nutze Configuration Manager 1910
    Vielen Dank im Voraus.

    Mittwoch, 8. April 2020 06:39
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden


    Wenn ich jetzt unterstelle, dass zu Zeiten der hohen Auslastungen Reports gezogen werden, warum dauert das dann so lang?


    Welche Reports meinst Du denn? \Monitoring\Overview\Reporting\Reports bzw die Reports auf dem Reporting Point? Falls ja: da gibts es dann überhaupt keinen Zusammenhang zwischen Anzeige der Reports und den Clients, denn die Reports beziehen die Daten aus der SQL Datenbank und nicht direkt von Clients.
    Außerdem sollte in irgend einem der Logfiles (%windir%\ccm\logs) korrespondierende Einträge zu der Aktivität zu finden sein (notfalls Debug Logging aktivieren: https://blog.meringer.de/2008/11/29/verbose-logging-sccm-client/ ) - DCM*.log (DCMReporting.log) oder CI*.log.

    Torsten Meringer | https://blog.meringer.de/

    • Als Antwort markiert MaGicApr Freitag, 12. Juni 2020 08:25
    Dienstag, 14. April 2020 11:35
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    vielen Dank für den Hinweis mit dem Debug Logging. Dies brachte mich letztendlich auf die Spur.

    Ich denke, ich habe in meinem Fall die Lösung gefunden. Der Configuration Manager Client kann offenbar nicht mit einer großen Anzahl von Ablösungen umgehen. Ich hatte leider den Fehler gemacht, diese Funktion für Applikationen zu verwenden, die häufig aktualisiert werden (Firefox, Chrome, FlashPlayer) Nachdem ich alle alten Pakete gelöscht und die Supersedences aus dem aktuellsten Paket entfernt habe, läuft derzeit wieder alles super!
    Das Problem war einfach, dass zu viele Supersedences überprüft werden mussten und der SCCM Client damit überfordert war. Erkannt habe ich das, nachdem ich das Debug Logging eingeschaltet habe und im "AppIntentEval.log" enorm viele Einträge erschienen.
    Zwischenzeitlich hatte ich einen Call beim Microsoft Support eröffnet. Leider war diese Lösung kein Resultat des Tickets bei Microsoft.

    Beste Grüße

    Marcel

    • Als Antwort markiert MaGicApr Freitag, 12. Juni 2020 08:25
    Freitag, 12. Juni 2020 08:24
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Ich hatte ähnliche Probleme durch die verzögerte Bereitstellung von Netzwerkressourcen durch Windows beim Booten.
    Aus irgendwelchen Gründen hängen sich die Prozesse beim TCP-Zugriff auf bzw. landen in einer Endlosschleife wenn ein Zugriff noch nicht möglich ist (Z.B. das rote Kreuz bei automtischen Netzlaufwerken).

    Dies ließ sich nur durch einen verzögerten Start der betroffenen Programme lösen.
    Bei Aufgabenplanungen kann man eine Verzögerung angeben (nach Boot, nach Anmeldung, ...).
    Bei Diensten geht dies meist nicht, allerdings kann man die auf "Manuell" setzen und per Powershell-Script verzögert die Dienste dann starten.

    https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-service?view=powershell-7

    Mittwoch, 8. April 2020 08:53
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo, danke für die Antwort.

    Leider glaube ich nicht, dass es sich hier um dasselbe Problem handelt. Mein Problem ist, dass der SMS-Agent-Host Service (er startet standardmäßig verzögert) sinnlose CPU-Last erzeugt. Mit dem Process Explorer betrachtet tut er nichts, außer mind. einen CPU-Kern auszulasten. Er greift nicht auf Dateien zu, schreibt teilweise auch minutenlang nichts in SCCM Log-Files. Ich habe alle möglichen Jobs, die zeitgesteuert laufen, reduziert oder ganz abgeschaltet.

    Software metering ist disabled
    Software inventory läuft nur einmal alle 7 Tage
    Hardware inventory läuft nur einmal alle 7 Tage (einmal monatl. auf Notebooks)
    Software deployment re-evaluation alle 7 Tage
    Software update scan alle 7 Tage
    Windows Analytics ist deaktiviert

    Aktuell weiß ich nicht mehr, wo ich noch suchen soll. Die User beklagen sich. Der VCenter Admin ebenfalls. Ich administriere zwei primary Sites, unsere eigene und die eines externen Kunden. In unserer Umgebung besteht das Problem, in der des Kunden nicht. Beide sind sehr ähnlich aufgebaut und unterscheiden sich hauptsächlich in der Anzahl der Clients.

    Mittwoch, 8. April 2020 10:05
    |
  • Question
    Anmelden
    0
    Anmelden
    Mittels Sysinternals ProcessExplorer kann man sich den Callstack ansehen um ggf. festzustellen auf welchen Routinen der da hängt.
    Mittwoch, 8. April 2020 10:23
    |
  • Question
    Anmelden
    1
    Anmelden

    Moin,

    in meiner Wahrnehmung hat jede SCCM-Version irgendwann mal dieses Problem gehabt, aus unterschiedlichen Gründen. Hier z.B, einer zur 1810: http://blog.configmatt.com/2019/02/high-cpu-utilization-by-ccmexec-after.html

    Schau mal, ob es Patches gibt, und roll diese aus. Hilft das nicht, Call aufmachen.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Mittwoch, 8. April 2020 11:26
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Suchender,

    ich habe mir den Callstack angesehen. Nur leider kann ich mit den Infos kaum etwas anfangen.

    ********************************************

    ntoskrnl.exe!KeSynchronizeExecution+0x5ce6
    ntoskrnl.exe!KeSynchronizeExecution+0x577f
    DCMReporting.dll+0x607e5
    DCMReporting.dll!DllUnregisterServer+0x9c08d
    DCMReporting.dll!DllUnregisterServer+0x9454d
    DCMReporting.dll!DllUnregisterServer+0x72b62
    DCMReporting.dll!DllUnregisterServer+0x72572
    DCMReporting.dll!DllUnregisterServer+0x7253a
    DCMReporting.dll!DllUnregisterServer+0x72572
    DCMReporting.dll!DllUnregisterServer+0x72b62
    DCMReporting.dll!DllUnregisterServer+0x72572
    DCMReporting.dll!DllUnregisterServer+0x79ecf
    DCMReporting.dll!DllUnregisterServer+0x98191
    DCMReporting.dll!DllUnregisterServer+0x934dd
    DCMReporting.dll!DllUnregisterServer+0x98efa
    DCMReporting.dll+0x7468f
    CIAgent.dll+0x5e233
    CIAgent.dll+0x59feb
    CIAgent.dll+0x52548
    CcmExec.exe+0x8c527
    CcmExec.exe+0x8c7e6
    ntdll.dll!LdrUnloadDll+0x325
    ntdll.dll!RtlInitializeResource+0xce4
    KERNEL32.DLL!BaseThreadInitThunk+0x14
    ntdll.dll!RtlUserThreadStart+0x21

    ********************************************

    Ich sehe, dass er sich ziemlich an der DCMReporting.dll abarbeitet. Auf einem normal funktionierenden Client sieht das nicht so aus.

    Wenn ich jetzt unterstelle, dass zu Zeiten der hohen Auslastungen Reports gezogen werden, warum dauert das dann so lang?

    Viele Grüße

    Marcel

    Donnerstag, 9. April 2020 06:05
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Evgenij,

    derzeit setzen wir die Verion 1910 ein. Ein Hotfix wäre noch verfügbar. Da sowohl dieser Hotfix als auch die neue Version 2002 ein Update des Clients benötigen, würde ich direkt auf die neue Version setzen. Ich glaube aber nicht, dass es an der Version an sich liegt, da das Problem Mitte bis Ende Dezember 2019 begann ganz plötzlich begann. In dieser Zeit habe ich keine Updates für die PC bereitgestellt, kein SCCM Upgrade installiert und auch keine Änderungen an der Konfiguration vorgenommen.

    Der Ansatz von "Der Suchende" ist noch vielversprechend. Wenn es aber am Erstellen von Reports liegen sollte, wäre jetzt noch hilfreich, zu wissen, wie lange typische Laufzeiten für diese Prozesse sind.

    SCCM hat viele Probleme, über die man als Admin immer wieder stolpert, welche aber nie gelöst werden. Bei MS wird völlig an den Problemen vorbei entwickelt.

    Viele Grüße

    Marcel

    Donnerstag, 9. April 2020 06:53
    |
  • Question
    Anmelden
    1
    Anmelden


    Wenn ich jetzt unterstelle, dass zu Zeiten der hohen Auslastungen Reports gezogen werden, warum dauert das dann so lang?


    Welche Reports meinst Du denn? \Monitoring\Overview\Reporting\Reports bzw die Reports auf dem Reporting Point? Falls ja: da gibts es dann überhaupt keinen Zusammenhang zwischen Anzeige der Reports und den Clients, denn die Reports beziehen die Daten aus der SQL Datenbank und nicht direkt von Clients.
    Außerdem sollte in irgend einem der Logfiles (%windir%\ccm\logs) korrespondierende Einträge zu der Aktivität zu finden sein (notfalls Debug Logging aktivieren: https://blog.meringer.de/2008/11/29/verbose-logging-sccm-client/ ) - DCM*.log (DCMReporting.log) oder CI*.log.

    Torsten Meringer | https://blog.meringer.de/

    • Als Antwort markiert MaGicApr Freitag, 12. Juni 2020 08:25
    Dienstag, 14. April 2020 11:35
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    hier hatte ich mich vielleicht etwas falsch ausgedrückt. Ich meinte das Einsammeln von Daten für die Erstellung der Reports.

    Mein aktuell bester Kandidat als Verursacher ist jedoch derzeit der Symantec Endpoint Protection Client.

    Viele Grüße

    Marcel

    Montag, 20. April 2020 08:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    vielen Dank für den Hinweis mit dem Debug Logging. Dies brachte mich letztendlich auf die Spur.

    Ich denke, ich habe in meinem Fall die Lösung gefunden. Der Configuration Manager Client kann offenbar nicht mit einer großen Anzahl von Ablösungen umgehen. Ich hatte leider den Fehler gemacht, diese Funktion für Applikationen zu verwenden, die häufig aktualisiert werden (Firefox, Chrome, FlashPlayer) Nachdem ich alle alten Pakete gelöscht und die Supersedences aus dem aktuellsten Paket entfernt habe, läuft derzeit wieder alles super!
    Das Problem war einfach, dass zu viele Supersedences überprüft werden mussten und der SCCM Client damit überfordert war. Erkannt habe ich das, nachdem ich das Debug Logging eingeschaltet habe und im "AppIntentEval.log" enorm viele Einträge erschienen.
    Zwischenzeitlich hatte ich einen Call beim Microsoft Support eröffnet. Leider war diese Lösung kein Resultat des Tickets bei Microsoft.

    Beste Grüße

    Marcel

    • Als Antwort markiert MaGicApr Freitag, 12. Juni 2020 08:25
    Freitag, 12. Juni 2020 08:24
    |