Drucken - Optimierung und Troubleshooting (4)

Lesezeit
3 Minuten
Bis jetzt gelesen

Drucken - Optimierung und Troubleshooting (4)

18.07.2011 - 14:00
Veröffentlicht in:

In den meisten Fällen verrichten Drucker und Druckserver klaglos ihren Dienst im Unternehmensnetzwerk. Doch wenn einmal Probleme auftreten, sind die Ursachen oft schwer zu lokalisieren und die Auswirkungen - nicht nur für den Anwender - weitreichend. In diesem auf Windows XP und Server 2003 zugeschnittenen, vierteiligen Online-Workshop erklären wir, wie Sie solche Fehler finden und mit welchen Einstellungen Sie diese dauerhaft beheben. Im vierten Teil erklären wir, wie Sie am besten bei einem Timeout des Druckers vorgehen und dass Service Packs Probleme nicht nur lösen, sondern auch neue Schwierigkeiten verursachen können.

So gehen Sie bei Druckertimeouts vor
Bei der Betrachtung dieser Problematik sollten wir grundsätzlich zwischen lokal angeschlossenen und Netzwerkdruckern unterscheiden. Lokal angeschlossene Drucker unterliegen keinen nennenswerten Timeout-Problemen, es sei denn der Rechner ist mit zu wenig Speicher ausgestattet oder es wird überdurchschnittlich stark von der Pagefile Gebrauch gemacht. Daher gibt es hier kaum sinnvolle Optimierungsmaßnahmen über die Registry, eventuelle Probleme wären somit eher auf die Treiber selbst zurück zu führen. In diesem Zusammenhang kann gerade beim Einsatz von Windows 2003 (alle Versionen) sehr oft das Phänomen beobachtet werden, dass bestimmte Treiber gängiger Druckermodelle in der Windows-Ausgabe bereits nach der Installation bis zu 100 Prozent Dauerlast an der Rechner-CPU erzeugen.

Bei Netzwerkdruckern kann die Timeoutproblematik recht komplex ausfallen. Die Zeit für das physikalische Ansprechen eines Druckers kann dafür verantwortlich sein. Damit ist die Zeit gemeint, welche der Client benötigt, um den Printserver im Netzwerk zu finden und von diesem eine Antwort zu bekommen. Prinzipiell sieht das Betriebssystem für die Netzwerkkommunikation Default-Werte in der Größenordnung von zwei Sekunden vor. Innerhalb dieser Zeit muss/soll ein Netzwerkgerät antworten. Das Problem tangiert nicht nur Netzwerkdrucker und den Printserver, sondern zum Beispiel auch die Benutzerprofile. Es geht also darum, die Toleranz des (lokalen) Systems für die Netzwerkantwort pauschal zu erhöhen. Dieses erfolgt über die Registry im Schlüssel "HKLM \ Software \ Microsoft \ Windows NT \ CurrentVersion \ Win-logon" über zwei neue Werte – "SlowLinkDetect" und "SlowLinkDetectTimeout" (beide vom Typ REG_Dword):

 

 

  • SlowLinkDetectTimeout übergibt dem System eine höhere Wartezeit (in Millisekunden) als die per Default eingestellten 2.000 Millisekunden (zwei Sekunden).
  • SlowLinkDetect ermöglicht es dem System, diese Einstellungen auch zu erkennen. Es ist sehr wichtig, immer beide Werte der Registry hinzuzufügen, da jeder Wert für sich alleine nicht wirksam ist. SlowLinkDetect hätte demzufolge die Wertigkeit 0x1 (hex) als REG_Dword-Wert.

Auch wenn in der MS-Beschreibung diese beiden Werte im Zusammenhang mit langsamen Netzwerken erwähnt werden, haben sie  nichts mit der Netzwerkgeschwindigkeit zu tun, sondern mit den Antwortzeiten im Netz. Diese Antwortzeiten können unmittelbar mit der Bandbreite zusammenhängen, dieses ist jedoch kein zwingender Zusammenhang.

Erhöhen der Antwortzeiten in der Registry
Ein weiteres Problem sind die Drucker-eigenen Transmit- und Receive-Werte (Tx und Rx). Diese werden auch häufig mit den Antwortzeiten der lokalen LPT-Schnittstellen verwechselt, tangieren jedoch die Übertragung im Netzwerk. Im Printer-Schlüssel der Registry, unter dem Namen des jeweiligen Druckers finden sich zwei Werte – "TxTimeout" (REG_Dword) und "dnsTimeout" (auch Typ REG_Dword); beide Werte spiegeln Zeitwerte in Millisekunden wieder. TxTimeout liegt bei 45.000 ms (45 Sekunden) und gibt die Zeit für das Ansprechen des Druckers an. Diese Zeit beinhaltet nicht die für den Ausdruck benötigte Zeit, sondern die Zeit, innerhalb welcher der Drucker (nicht der Printserver) die Kommunikation mit dem Client (dem Sender des Druckauftrages) abwickeln muss. Wenn sich jetzt der Drucker gerade im Sleep-Modus befinden sollte, kann je nach Modell die Aufwachphase durchaus länger als 45 Sekunden dauern.

Auch wenn der Drucker gerade einen größeren Auftrag bedient, kann unter Umständen innerhalb dieser Zeit keine Antwort gesendet werden. Gerade dieses Phänomen erkennen Sie daran, dass ein Druckauftrag gesendet, vom Printserver angenommen und im Spool-Manager angezeigt wird – jedoch erfolgt am Drucker selbst keine Ausgabe. Fehlermeldungen werden dabei keine angezeigt. Hier können Sie sinnvoller Weise die Default-Werte auf bis zu 900.000 ms (15 Minuten), teilweise sogar (etwa bei Canon, Minolta, Brother und einigen HP- und Lexmark-Druckern) auf 1.800.000 ms (30 Minuten) erhöhen. TxTimeout definiert also die Antwortzeit des Druckers hinsichtlich des gesendeten Druckauftrages und trifft keine Aussage darüber, ob der betreffende Drucker überhaupt gefunden wurde, sondern darüber ob der Drucker den Druckauftrag angenommen hat oder nicht.

Für das Auffinden des Druckers (Hardwareantwort) ist der Wert "dnsTimeout" verantwortlich. DnsTimeout kommuniziert über den Printserver mit dem über den Printserver angeschlossenen Drucker. DnsTimeout ist mit 15.000 ms (15 Sekunden) auch häufig zu knapp bemessen und Sie sollten den Wert pauschal um den Faktor 10 auf 150.000 ms (150 Sekunden) erhöhen. Manche Hersteller empfehlen auf deren Internetseiten sogar, diesen Wert auf bis zu eine Stunde (in ms) hoch zu setzten, dies ist jedoch nicht sinnvoll. Der Grund dafür ist die Tatsache, dass der Druckersuchdienst selbst alle 3.600 Sekunden (eine Stunde) die Verfügbarkeit der einzelnen Drucker im Netz aktualisiert. Wir empfehlen, die dnsTimeout-Zeit mit der Zeit des Druckersuchdienstes gleich zu setzen und beide Zeiten bei maximal 15 Minuten (900 Sekunden, 900.000 ms) anzusetzen.

Ein weiteres, wenig beachtetes Problem ist gerade beim Betrieb von einigen hundert Netzwerkdruckern an einem Server zu beobachten. Windows 2003 ist für den Einsatz als Printserver nicht explizit optimiert. Hier können zwei physikalische Limitierungen zu negativen Ergebnissen führen. Es handelt sich nicht um spezielle Timeouts des Systems, die Sie anders einstellen könnten, sondern um die Art und Weise, wie das System (in diesem Falle der Printserver) mit den einzelnen Druckaufträgen umgeht.

Hintergrund ist das übliche Ablegen von Spool-Daten auch in Pagefile.sys (zusätzlich zu den SPL-Dateien im jeweiligen Spool-Verzeichnis). Hier macht bei reinen Printservern folgende Optimierungsmaßnahme Sinn: reduzieren Sie die Größe der Pagefile ganz drastisch auf minimale 300 oder 800 MByte. Diese Empfehlung widerspricht natürlich allen MS-Konventionen und Empfehlungen, hat sich jedoch in der Praxis erstaunlich gut bewährt. Das Ganze macht natürlich nur dann Sinn, wenn der Printserver keine weiteren Aufgaben im Netzwerk wahrnimmt und über reichlich RAM (ab etwa einem GByte) verfügt.



 

 

 

                                                Seite 1 von 2                     Nächste Seite>>






ln/dr/Nikolay Taschkow

 

 

 

Ähnliche Beiträge

Im Test: SQL Sentry von SolarWinds

"SQL Sentry" von SolarWinds ist ein Überwachungswerkzeug für Datenbanken auf Basis von Microsoft SQL Server. Das Tool liefert den Administratoren Leistungsdaten des Servers und der überwachten Datenbankinstanzen in einem einzigen Dashboard. Abgesehen davon bringt es auch noch einige weitere nützliche Funktionen mit. Wir haben uns im Testlabor angesehen, wie sich die Lösung in Betrieb nehmen lässt und wie die tägliche Arbeit mit ihr abläuft.