2012 R2 RDS - extreme Druckerprobleme

[sheeva 10]

Ich glaub das wird mit 2012 R2 ein Klassiker. Also wenn man hier viele Lösungsvorschläge abarbeitet und die Updates einigermassen regelmässig auf die Server nachführt, genauso wie konsequent Treiberupdates durchführt, lassen sich einige Fehler dauerhaft eindämmen. Leider, nicht wirklich alle und einige tauchen immer mal wieder auf.

 

Ein paar der Probleme, die immer irgendwie hängenbleiben:

1) Standarddrucker wird geändert (sporadisch, selten, unterschiedliche Benutzer)

2) Plötzlich mehrfach gleicher Drucker vorhanden, System erkennt nicht, das es der selbe Drucker ist

3) Registry-Eintragungen sind ein wenig wirr, führen nicht vorhandene Printserver auf oder falsche Eintragungen

 

Lösungen dazu sind dann meist eh nur Registry-Bereinigen, Drucker entfernen neu installieren in der User-Session und bei 1) prüfen ob die MSTSC über den Sessionbroker das Deployment sauber zieht.

Unter 2003 und 2008 hatte ich mit den ganzen Druckern nie derartige Probleme. Soll aber unter 2016, wie einige sagen, auch nicht besser werden.

 

Korrekt!

Auch ich habe sämtliche in diesen Thread vorgeschlagenen Lösungsansätze durchgearbeitet. Manchmal war dann auch ein paar Tage alles in Ordnung, aber irgendwann sind wieder die von dir geschilderten Probleme aufgetaucht. Leider fand ich auch keine Möglichkeit die Probleme irgendwie gezielt zu reproduzieren und so war auch nur sehr oberflächliches Troubleshooting möglich.

Irgendwann hab ich kapituliert u. die Drucker alle lokal auf den Terminalservern installiert. Das ist zwar nicht wirklich hübsch und verwaltungstechnisch bissl aufwendig, aber zumindest gibts nun seit mehreren Monaten keine Probleme mehr.

bearbeitet 10. März 2016 von sheeva

[Forseti2003 14]

Korrekt!

Auch ich habe sämtliche in diesen Thread vorgeschlagenen Lösungsansätze durchgearbeitet. Manchmal war dann auch ein paar Tage alles in Ordnung, aber irgendwann sind wieder die von dir geschilderten Probleme aufgetaucht. Leider fand ich auch keine Möglichkeit die Probleme irgendwie gezielt zu reproduzieren und so war auch nur sehr oberflächliches Troubleshooting möglich.

Irgendwann hab ich kapituliert u. die Drucker alle lokal auf den Terminalservern installiert. Das ist zwar nicht wirklich hübsch und verwaltungstechnisch bissl aufwendig, aber zumindest gibts nun seit mehreren Monaten keine Probleme mehr.

 

Bringt aber leider auch nicht wirklich viel. Wir haben versuchsweise die Drucker lokal aufgesetzt, die am meisten fehlerauffällig waren. Auch hier, ging eine ganze Zeit lang gut, so das wir dachten, okay Problem könnte damit umgangen werden, aber nach einigen Wochen haben sich dann auch da wieder Probleme eingeschlichen. Besonders auffällig, das die Druckgeschwindigkeit oder das Rendern bei der Vorschau in den Anwendungen sehr lang dauert.

 

Irgendwie ist es derzeit so, als wenn man wirklich nur den Teufel mit dem Belzebub austreiben würde. Extrem frustrierend.

[aRanIoN 0]

Hallo noch mal an alle :) 
 

Nachdem ich alle Lösungsansätze die hier beschrieben wurden angewendet habe und zusätzlich folgendes beim Abmelden ausführen lasse funktioniert die Verteilung seit 7 Tagen mehr oder weniger problemlos:

Windows Registry Editor Version 5.00


[-HKEY_CURRENT_USER\Printers\Connections]

Jetzt ist aber ein anderes Problem entstanden. Jeden zweiten bis jeden Tag erzeugt die SpoolerSubsystem-Anwendung eine EXTREM hohe RAM-Auslastung auf allen Servern.

Im Durchschnitt so 3 GB aber es waren auch schon mal 6 GB Auslastung auf den RDS Servern. Nach einem Neustart des Spoolers ist alles wieder normal, aber der wird eigentlich eh jede Nacht durch ein Skript neugestartet.

Kann das vielleicht damit zusammenhängen, das bei den Druckern der Haken "Druckauftragsaufbereitung auf Clientcomputern durchführen" draußen ist? Aber dann müsste doch eigentlich das Gegenteil der Fall sein, da ja eben das nicht auf den RDS bearbeitet wird oder? 

Außerdem tritt das auf ALLEN Servern auf, auch auf denen wovon gar nicht gedruckt wird, sondern die Drucker nur verbunden werden.

Ich bin etwas ratlos momentan, ich bin für jede Hilfe dankbar. 

bearbeitet 17. März 2016 von aRanIoN

[aRanIoN 0]

Hallo,

 

falls es wen interessiert, bei uns ist mittlerweile alles wieder auf lokale Drucker umgestellt. Das ist ein Loch ohne Boden, man denkt es ist endlich geschafft und schon tut sich das nächste Problem auf, nur schlimmer.

Wer auch immer das hier liest und darüber nachdenkt von lokalen Druckern wegzugehen, tut es nicht. Einfach nein.

BG aRanIoN

[Leuchtkondom 17]

Meine Rede seit gefühlt der 3. Seite in diesem Thread :-)

Ich finde leider nur den Umgang durch MS mit diesem Thema sehr traurig, aber naja....

[lefg 276]

Ich hatte auch solche Probleme ... da der Kunde nur einen RDS Host hat und 3 Drucker, habe ich die Drucker nun lokal am RDS Host installiert. Nun klappt es

 

Moin,

 

ich möchte dazu nachfragen. Wird nun gedruckt mit dem Drucker auf dem Host installiert? Oder wird benutzt der mit dem von Client mit in die Sitzung gebrachte Drucker? Handelt es sich um einen Netzwerkdrucker an Ethernet oder um einen Drucker per USB an den Client geschlossen?

bearbeitet 24. März 2016 von lefg

[aRanIoN 0]

Hallo,

 

nochmal eine kleine Ergänzung von mir. Die RDS laufen wie gesagt jetzt wieder mit lokalen Druckern. Auf den Citrix Servern und auf Workstations habe ich mittlerweile wieder auf die Verteilung per GPP umgestellt.

Das funktioniert wunderbar ohne Fehler. Damit die GPP auch nur auf den Workstations und nicht auf den RDS angewendet wird, ist folgender WMI-Filter aktiv:

select * from Win32_OperatingSystem where ProductType="1"

Die User der Citrix-Server sind einfach in einer separaten OU.

Vielleicht hilft das ja irgendwann noch irgendwem.

 

Mit freundlichen Grüßen,

aRanIoN

[Forseti2003 14]

Auch noch ein Feedback von meinerseite, überwiegend haben wir nun das ganze in den Griff bekommen, Standarddrucker verstellen sich nun im Regelfall nicht mehr und Druck funktioniert auch.

Wir gehen aktuell sogar über Druckserver und lassen die Aufbereitung über diesen und nicht am RDS laufen.

 

Viele Fehler scheinen am Anfang so auszusehen, als gehören sie zusammen, was aber scheinbar überhaupt nicht der Fall ist. Man sollte sich am besten eine Checkliste zu legen und diese in jedem einzelnen Fall zwingend abarbeiten. Wir stellten dabei nämlich fest, das plötzlich, Stück für Stück und User für User, die Fehler abnahmen, einige bestimmte Fälle sogar recht rapide.

 

Aktuell haben wir eigentlich nur noch zwei Arten von Fehlern, die aber auch nur noch gelegentlich auftreten:

1) Am Druckserver (!) verstellt sich bei einigen bestimmten Druckern (selber Hersteller) der Druckprozessor. Ist uns bisher 2x in den letzten 2 Monaten aufgefallen. Fehler lässt sich aber recht schnell beheben.

2) Einmal sporadisch will ein Drucker (meist einer der unter 1) sich bei einem Benutzer nicht mehr regulär anlegen lassen. Wird der Drucker neu verbunden sind die Eigenschaften doppelt und führt je nach Anwendung dazu, das kein Druck mehr erfolgt. Die Umstellung von einem NETBIOS-Namen auf einen FQDN erzielt dann aber die gewünschte Wirkung also anstelle von \\printserver\Drucker dann \\printserver.domain.tld\Drucker.

 

Wer noch massive Probleme hat bei seinen Druckern kann mir auch gerne eine PN senden, allgemeine Erläuterungen find ich eher problematisch, da wirklich jeder Drucker und davon auch jedes Problem eine eigene Fehlersuche erfordert. Das reicht von Firmware am Drucker, über Universal-Treiber vom Hersteller, v3 und v4-Versionen müssen ein wenig getestet werden, auch hier gibt es starke Unterschiede. Die Benutzerprofile säubern, Registry reinigen, Druckwarteschlangen prüfen, Rechte nachsetzen, GPO prüfen und und und....es ist ein riesiger Rattenschwanz, wobei ich feststelle, je weniger Drucker-MischMasch vorliegt, desto niedriger sind auch die Probleme.

 

Grüße

Forseti

[kirschi68 10]

Hallo Leute,

unser System:

• 2012R2 Printerserver
• 2012R2 Terminalserverfarm (2 Server)
• Kyocera-Drucker mittels Loginscript eingebunden ala %Logonserver%\Netlogon\con2prt.exe /c "\\mgmt\K3920-G"
• großteils IGEL, teilweise PC als Client

2 Probleme:

1. verschwindende Standard-Drucker und das teilweise Fehlen der Drucker bei den Benutzern (im Word aber da)
2. Problem mit Kyocera Prescribe: Drucker eingebunden wie oben genannt, sowohl beim Benutzer mit PC als auch beim Login über den Terminalserver. Wir benötigen die Kyocera Prescribe-Sprache, um aus verschiedenen Schächten Kopien unserer Dokumente zu drucken. Das klappt auch soweit vom PC aus. Die Prescribe-Kommandos werden aber komplett ignoriert, wenn derselbe Benutzer am TS angemeldet ist und auf demselben Drucker dasselbe Dokument druckt. Nur Office-Dokumente und unser NAV sind betroffen. PDF und aus dem Editor heraus kann ich problemlos mit Prescribe mein Original + automatische Kopie drucken. Ebenso kommt die Testseite vom Printserver mit Kopie.

 

zum Problem 1 bezüglich Verzeichnisfreigabe für system32\spooler. Mach ich das auf den Terminalservern oder/und dem Printerserver?

 

Zum Problem 2: habt ihr eine Idee? Office Einstellungen scheinen gleich, GPO-Einstellungen wirken ebenso auf TS-Benutzer und PC-Benutzer (andere Richtlinien aber gleicher Inhalt, was Office betrifft)

 

Gruß

Andreas

[Forseti2003 14]

zum Problem 1 bezüglich Verzeichnisfreigabe für system32\spooler. Mach ich das auf den Terminalservern oder/und dem Printerserver?

 

Auf dem Terminalserver - die Verzeichnisfreigabe dient eigentlich nur dazu, das die authentifizierten Benutzer auch die Möglichkeit haben bei der Verbindung die Treiberkopien vom Druckserver auf den TS abzulegen.

 

Zum Problem 2: habt ihr eine Idee? Office Einstellungen scheinen gleich, GPO-Einstellungen wirken ebenso auf TS-Benutzer und PC-Benutzer (andere Richtlinien aber gleicher Inhalt, was Office betrifft)

GPO sind ein Thema für sich. In einigen Fällen hilft es, wenn es alte GPO's sind diese zu löschen und komplett neu aufzusetzen. Aber auch gänzlich ohne Einsatz der GPO kann man je nach Mitarbeiteranzahl und Druckern gute Ergebnisse erzielen. Verschwindende Drucker ist meist ein Hinweis auf noch nicht bereinigte Registry-Einträge. Welche in Frage kommen wurden in diesem Thread ja schon ausführlich besprochen. Vorallem nicht vergessen, wenn Du einen TS bereinigst, mach Dir gleich die Mühe und säuber alles, danach erst die Druckwarteschlangen neustarten oder auch den TS neustarten. Sollten sich bereits Treiberfragmente verheddert haben, muss wirklich alles akribisch abgesucht werden.

 

Das plötzliche Verschwinden deutet aber auf GPO's hin, die im Intervall ja sich ausführen und dann dabei die Drucker "killen" - ich würde eh empfehlen die Drucker in einer eigenen GPO zu bündeln.

[kirschi68 10]

Danke an alle, meine beiden Probleme von oben scheinen seit dem Abarbeiten dieses Threads gelöst.

[kirschi68 10]

Wohl zu früh gefreut, das mit dem Prescribe funktionierte nur einen Tag.

[kirschi68 10]

Für alle, die hier immer noch mit dem Problem kämpfen (bei einer Kollegin verstellt es fast täglich den Standarddrucker): ein erster Test nach dieser Prozedur (Beitrag von Scott798) war erfolgreich.

bearbeitet 18. August 2016 von kirschi68

[Pipeline 12]

Moin zusammen,

 

wir haben auch das Problem, dass die User ihren Standarddrucker verlieren.

 

Ich habe etwas den Überblick in diesem Thread verloren und möchte deswegen vielleicht "doppelt" Fragen.

 

Hat jemand Erfahrungen mit dem Versuch für eine RDS 2012 R2 Umgebung einen Windows Server 2008 R2 Printserver einzusetzen?

 

Grüße, Stefan

 

[Weingeist 159]

Nimm doch einfach ein gutes altes Login-Script für die Printer. Normalerweise sind die Probleme dann gelöst. Ich habe jedenfalls keinerlei Sorgen mit verschiedensten Drucker.

 

 

 

Set PrintingServer=\\SV-Printer-2012

rundll32 printui.dll,PrintUIEntry /in /n %PrintingServer%\PrinterName1
rundll32 printui.dll,PrintUIEntry /in /n %PrintingServer%\PrinterName2
 
REM Standardrucker setzen
rundll32 printui.dll,PrintUIEntry /y /n %PrintingServer%\StandardruckerName1
 
 
REM alte löschen (ich aktualisiere die Liste bzw. entferne nach einiger Zeit die Einträge wenn mehr oder weniger alle mal wieder angemeldet waren, gleichzeitig pro Umgebung eine Liste mit allen alten Druckern wenn sich mal wieder einer ne Ewigkeit nicht angemeldet hat und jammert er habe inaktive Drucker)
rundll32 printui.dll,PrintUIEntry /q /gd /n \\%PrintingServer%\PrinterNameZuLoeschen1
rundll32 printui.dll,PrintUIEntry /q /gd /n \\%PrintingServer%\PrinterNameZuLoeschen2

 

Ist auch für einige Arbeitsplätze gut geeignet, meistens pro Abteilung nen Script.