dataKEKS 11 Geschrieben Freitag um 08:44 Melden Geschrieben Freitag um 08:44 Hallo Freunde der Microsoft Welt, ich verzweifle gerade an unserem Management Server - er läuft im Schnitt etwa einmal die Woche auf 100% CPU Last, Auslöser Spooler.exe. Eckdaten: - Windows Server 2022 - kein DC - UniFi Manager, Axis Camera Station etc - Drucker von Develop, Epson, HP, und Lexmark werden über ihn gespoolt Wir können bislang nicht eingrenzen woher das kommt, es passiert sowohl innerhalb als auch außerhalb der Schulzeiten, sprich egal ob die Geräte an sein müssten oder nicht, ob gedruckt wird oder nicht - einfach null Ansatz. Durch die bunte Mischung an Aufgaben ist es leider leichter gesagt als getan die Maschine komplett neu aufzusetzen drum würden wir schon gerne versuchen der Ursache auf den Grund zu gehen - nur wie? Dank Monitoring mit Zabbix wissen wir, das die CPU Last gestern bis etwa 19:30 Uhr komplett friedlich war, dann aber sich stetig gesteigert hat und heute morgen war mit Dienstneustart der Spuck auch wieder vorbei, siehe Anlage. Die andere Spitze kommt durch die Datensicherung und erscheint damit in der Nacht jedes Werktags, somit ist das in Ordnung. Was ich schon gecheckt habe ist die Ereignisanzeige, unter den Drucker- und Dokumentdiensten ist die letzte Meldung vom 23. April 2025 und somit auch nicht zielführend Wenn euch nichts anderes einfällt würde ich alle Drucker Schritt für Schritt auf unseren zweiten Management Server auslagern und auf dem problematischen löschen, aber es wäre ja schon cool dem Problem auf den Grund gehen zu können.... Grüße aus BaWü Norbert Zitieren
cj_berlin 1.457 Geschrieben Freitag um 08:52 Melden Geschrieben Freitag um 08:52 Moin, habt ihr schon versucht, mit Treiberisolation herumzuspielen? Manchmal kann das helfen. Was auch helfen kann, ist das Rendering auf die Clients zu verschieben (da gibt es Gruppenrichtlinien für). Natürlich nur, wenn sie das können. Zitieren
dataKEKS 11 Geschrieben Freitag um 09:16 Autor Melden Geschrieben Freitag um 09:16 Haben wir noch nie gemacht, lese mich da gerade mal ein. Hast Du damit gute Erfahrungen? Zitieren
cj_berlin 1.457 Geschrieben Freitag um 11:08 Melden Geschrieben Freitag um 11:08 Sowas ist in der Regel entweder wegen blöder Treiber (da hilft Isolation) oder wegen blöder Druckjobs (da *kann* das Verlegen auf den Client helfen)... Aber manchmal sind Treiber so schlecht, dass da gar nichts hilft als einen generischen zu nehmen und auf irgendwelche fortschrittlichen Features zu verzichten. Spooler Logging hochsetzen: Two Minute Drill: Enabling Print Queue Logging | Microsoft Community Hub Zitieren
Weingeist 176 Geschrieben Freitag um 18:31 Melden Geschrieben Freitag um 18:31 Häufigste Ärger-Ursache seit MS-Security-Hardening: Verbinden mit Printserver-Name statt Print-Server FQDN. Das prüfe ich immer als erstes da alles an Fehlerbilder möglich ist. Dann würde ich noch das NTLM-Logging sowie Firewall-Logging auf Droped Pakete aktivieren sofern nicht bereits gemacht. Wenn z.B. NTLM systemweit deaktiviert wird, dann versuchen die Drucker sich nach Ablauf des Kerberos Tickets des Users sich permanent per NTLM zu verbinden. Was dann so halb funktioniert (aber nicht sollte) oder eben auch nicht (random). Das ist vor allem bei den Protected Users nach ~3h der Fall. Wenn das viele machen, könnte ich mir schon einen Anstieg der CPU-Last vorstellen. Ansonsten der beste Tipp den ich Dir punkto Drucker geben kann: Ausschliesslich die teure(re)n Business-Geräte der grossen Hersteller verwenden. Da passt auch das Treiberpaket inkl. Updates über viele Jahre. Dann: Printserver immer isoliert betreiben ohne anderen Krams. (einfache Rollbacks). Zitieren
dataKEKS 11 Geschrieben vor 9 Stunden Autor Melden Geschrieben vor 9 Stunden Heute Nacht war es mal wieder so weit: 100% CPU Last.... Also war in diesem die Treiber Isolation leider noch nicht die Lösung, also weiter suchen, denn von alten, nicht mehr benötigten Treibern habe ich den Server bereits befreit und jetzt im Schuljahr (hier an BaWü haben wir noch bis Ende des Monats Schule) darf ich die Treiber nicht aktualisieren... Gruß Norbert Zitieren
zahni 583 Geschrieben vor 2 Stunden Melden Geschrieben vor 2 Stunden Wenn man den Zustand hat,, kann man mit der Process Explorer den zuständigen Thread ermitteln, die CPU-Last verursacht. Wenn das nicht gerade eine OS-Thread ist, kann da Rückschlüsse auf den zuständigen Treiber finden. Ich könnte mir z.B. vorstellen, dass irgendein Consumer-Treiber eine interne Update- oder nach-Hause-Telefonier-Funktion hat und einfach seinen C&C-Server nicht erreichen kann. Wir hatten früher von Mutterkonzern DNS-Auflösung für alle Internetadresse, ohne dass die Server eine Verbindung herstellen konnten. Das kann zu Hängern führen, weil Verbindungsversuche in einen Timeout laufen.... https://learn.microsoft.com/de-de/sysinternals/downloads/process-explorer Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.