Prolog
Manchmal dauern Lösungen etwas länger. An einem Druckproblem über 2 Monate zu grübeln und mitunter auch zu verzweifeln sollte nicht die Regel sein.
Hier ist leider geschehen.
Problem
Ein Kunde hatte einen neuen virtuellen Terminalserver mit Windows Server 2016 bekommen. Darunter schöne neue Hardware, die auch alle VMs darauf zum brummen bringen.
Bedauerlicherweise begannen nach 2-3 Wochen die Druckerqueues bei manchen Benutzern ihren Dienst zu quittieren. Jeder Druckerauftrag kam nicht einmal bis zum Druckserver. Manchmal war er in der lokalen Warteschlangen-Anzeige zu sehen, manchmal nicht.
Als “quick and dirty”-Workaround funktionierte immer den betreffenden Netzwerk-Drucker am Client löschen und neu anlegen.
Dabei war es egal, ob die Drucker über den UNC-Pfad zum Druckserver verbunden wurde oder über “Geräte und Drucker – Netzwerkdrucker” oder dem neuen Assistenten unter “Einstellungen”.
Danach war für Tage mitunter Wochen bei diesem Benutzer wieder alles in Ordnung. Dafür hatte ein anderer Benutzer das Problem mit einem anderen Drucker.
Es gab kein festes Schema oder Muster.
Erste Lösungsansätze
Also machte ich das Übliche, was sich in der Vergangenheit bei Druckerproblemen bewährt hat: Den Druckertreiber wechseln. Von Postscript auf PCL, von PCL auf den Universalen, vom Universalem zurück zum Postscript. Dann eine aktuelle Version des Treibers und das Spielchen wieder von vorn.
Eine Besserung war nicht in Sicht.
Es eskaliert
Über die Zeit häuften sich die Probleme. Es schien schneller und irregulärer zu passieren. Die Abstände wurden kürzer und es waren auch mehr Benutzer betroffen.
Zwar fand sich im Event-Log die Fehler-ID 221, Quelle PrintService, “Fehler beim Abrufen der CSR-Cacheinformationen für Drucker”, aber Suchmaschinen-Anfragen brachten nichts rechtes als Ergebnis.
Einzig ein Foreneintrag riet das Clientrendering zu deaktivieren.
Dadurch wurde es nicht besser, aber auch nicht schlimmer.
Nächste Lösungsansätze
Beim nächsten Auftreten übernahm ich bei einem Benutzer die Terminalserver-Sitzung und spielte mit etwas PowerShell.
Interessanterweise gab “Get-WmiObject -class32 Win32_Printer |where-object {$_.network -eq $true}” genau “0” Netzwerkdrucker zurück. Laut Druckerverwaltung waren die Drucker aber noch korrekt im Profil eingebunden. Sehr mysteriös. So richtig weiter half das aber auch nicht.
Ich war kurzzeitig versucht im Loginskript per PowerShell die Drucker auszulesen, die Drucker zu löschen und neu anzulegen, da das Problem ja nur alle Tage mal bei manchen Usern auftrat. Somit sollte ein tägliches Einbinden das Problem eventuell lösen?
Zwischenzeitlich telefonierte ich mit dem Drucker-Betreuer des Kunden. Deren tägliches Brot sind schließlich Druckerprobleme. Der dortige Mitarbeiter, der die serverseitigen Fehler bearbeitet, konnte leider ebenfalls nicht weiterhelfen.
Im weiteren installierte ich einen dieser Drucker auch mal lokal am Terminalserver und umging den Druckserver. Das Verhalten blieb gleich. Weder eine Verbesserung, noch eine Verschlechterung.
Es eskaliert weiter
Der direkte Ansprechpartner beim Kunden berichtete inzwischen, dass an manchen Tagen dreimal an einem Vormittag kein Drucken möglich war. Dann wieder etliche Tage gar nicht. Jedesmal funktionierte Drucker entfernen neu hinzufügen.
Die Loginskriptlösung war damit aus dem Rennen, wenn schon untertags der Fehler mehrmals auftrat. Ich war an diesem Punkt hinreichend ratlos. Ein Austausch mit Kollegen über die ganze Zeit brachte mittlerweile auch keine Ansätze, die nicht schon getestet wurden. Wilde Registry-Einträge wollte ich nicht ausprobieren, die das eine oder andere Mal geraten wurden.
Licht am Horizont
An einem der Brückentage im Oktober fand ich etwas Zeit, um mir den Terminal- und Druckserver noch einmal anzusehen.
Da ich wusste, dass der direkte Ansprechpartner zusammen mit einer Kollegin stets den Drucker A verwendete habe ich für diesen Drucker die Treiberisolierung aktiviert.
Damit druckt das Gerät in einem separaten Prozess und ist von der Druckerwarterschlange (spooler) getrennt.
Lösung
Nach zwei Wochen habe ich den Kunden kontaktiert. Das Problem würde immer noch auftreten. Glücklicherweise habe ich explizit nachgefragt, ob es auch Drucker A beträfe und er antwortete, dass könne er nicht sagen, denn er habe das Büro gewechselt und würde nun immer auf Drucker B drucken. Eine kurze Nachfrage bei der Kollegin ergab: keine Störungen seit zwei Wochen.
Als kleinen Test habe ich den Treiber für Drucker B ebenfalls isoliert und eine Woche später gab es auch hier keine Störungen mehr.
Somit wurde bei allen Druckern auf dem Druckserver die Treiber isoliert und das Drucken war wieder dauerhaft problemfrei.
[Update: 04.02.2018] Hurra! Das Problem ist wieder da. Somit die die o.a. Lösung dafür sinnfrei.
Wie es weiter ging.