2012 R2 RDS - extreme Druckerprobleme

[sheeva 10]

kann ich auch bestätigen - nach lokaler Installation der drucker auf den rds-Hosts sind alle Probleme beseitigt.

 

da ich fast 30 drucker auf 4 rds-Hosts installieren musste, hab ich diese über ein powershell-script ausgerollt.

 

die druckernamen u. verwendeten treiber (müssen auf dem rds-Hosts vorinstalliert werden) hab ich in eine csv-Datei eingetragen.

da ich sämtliche drucker auch im DNS eingetragen habe, konnte ich als hostadresse den druckernamen angeben.

 

Printer.csv:

name;driver;
drucker01;Lexmark Universal v2 XL;
drucker02;Xerox Phaser 6180MFP-D PCL 6;

usw.

 

Printer.ps1

$printers = Import-Csv -Delimiter ";" -Path "printer.csv" -Encoding UTF8

foreach ($printer in $printers)

{

$printername = $printer.name

$driver = $printer.driver

　

add-printerport -name $printername -printerhostaddress $printername

add-printer -name $printername -drivername $driver -port $printername

}

 

evtl. hilfts ja jemanden

[sheeva 10]

hat schon jemand neue Erkentnisse bzgl. der Druckerprobleme?

 

Seit meinem letzten Beitrag hatte ich keine Probleme mehr mit der lokalen Druckerinstallation. Mittelfristig würde ich aber doch gerne wieder auf einen Printserver zurückgreifen

[twenty 12]

Hallo,

 

derzeit sind wir gemeinsam mit MS noch dabei, den einen oder anderen Reghive auszutesten. Die Zufriedenheit des Kunden sinkt dabei von Tag zu Tag. Mir persönlich kommt die ganze Geschichte ziemlich planlos und unausgegoren vor. Laut MS gibt es keine Universallösung, sondern jedes Problem/jeder Kunde muss gesondert betrachtet werden.

 

Bei MS ist man sich nicht darüber im Klaren, was diese Situation für IT Dienstleister bedeutet. Es gibt auch keinerlei Einsicht seitens MS, dass hier ein Fehler im System vorhanden ist und es sich dabei nicht um Fehlkonfigurationen handelt. Wir bleiben dran.

[Leuchtkondom 17]

Genau dieses Gefühl hatte ich bei meinen Ticket auch.

Ich habe viele Registry Änderungen durchführen müssen, die aber alle samt entweder nichts, oder wieder nur zeitlich Besserung brachten.

 

Aber wirklich ernst wurde ich und mein Problem glaube ich nicht genommen.

[twenty 12]

Hallo,

 

nach einigem herum probieren von der diversenen Reghives, haben wir folgende "Lösung" gefunden:

 

Ab Windows 2012 wird der Drucker via RPC vom Printserver verbunden. Um dieses Verhalten abzustellen und den Drucker via SMB zu verbinden, ist dieser Reghive nötig. Momentan ist bei uns alles ruhig.

 

HKLM\Software\Policies\Microsoft\Windows NT\Printers\

EnabledProtocols

Type: DWORD

Data: 6

 

 

Folgender Reghive wurde ebenfalls gesetzt und löscht beim Abmeldevorgang des Users, die Reghives der verbundenen Drucker unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\***SID des Users***\Printers\Connections. Die verbundenen Drucker werden aber weiterhin im Userprofile gespeichert.

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\

RemovePrintersAtLogoff

Type: DWORD

Data:1

bearbeitet 20. Februar 2015 von twenty

[Leuchtkondom 17]

Okay würde Mich freuen wenn du berichtest wie es nach einer Woche aussieht. Den Key RemovePrintersAtLogoff hat mir MS bei meinen Call auch genannt, der. brachte aber nur Besserung von 3 Tagen.

 

Den Key zwecks RPC / SMB wurde mir damals nicht genannt, ich bin gespannt :-)

[bob645 0]

Kann dazu jemand etwas sagen? --> http://digitalzombies.com/2014/07/03/print_issues_rds_2012/

Ich bin noch nicht zum testen gekommen da die Server dazu leer sein sollten, aber es kliengt viel versprechend.

 

Problem scheint der Druckprozessor UND das 2 malige erscheinen vom Printeserver unter "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider\Servers" zu sein.

Einmal als "Printerserver" und einmal als "Printserver.Domäne.com"

bearbeitet 24. Februar 2015 von bob645

[Weingeist 157]

 

 

Das Problem das es MS nicht unbedingt juckt, kenne ich auch. Gabs früher nie. Etwas grössere Problem = Nächstes Support-Level, egal wie gross der Kunde war. Bis man zu den Top Cracks kam die einem in den Dumps nach Fehler durchsucht haben und unter Umständen sogar nen Hotfix in die Pipeline geschickt haben, wenn Sie selber das Gefühl hatten, das sei grosser Käse. Kann man heute ohne dicken Supportvertrag vergessen, da werden ja selbst grobe Sicherheitslücken teilweise über Monate nicht geschlossen (Siehe von Google veröffentliche Löcher).

 

Dieses Gefühl wird in Zukunft sicher noch verstärkt werden. Heute muss man froh sein am Firstlevel jemand dranzukriegen, der weiss, wohin er einem weiterverbinden muss. Dank Miete ist nicht nur der Innovationsdruck sondern auch der Druck guten Support zu leisten deutlich geschmälert. Dafür wird kräftig in die ausspionierung und Lizenzprüfung investiert. Nicht alles von früher ist besser, die Mentalität von MS aber mit Sicherheit.

 

 

 

Puuh, da begrabe ich doch glatt den Plan wieder die Loginscripts mit GPO bzw. GPP Einstellungen zu ersetzen. Bis dato hatte ich das Problem nämlich noch nicht. Hoffentlich kommt es auch nicht, sonst würde ichs wohl früher oder später bittter bereuen die Printserver bei mir und den Kunden auf 2012 R2 gezogen zu haben.

 

Was ich aber schon öfter feststellen konnte: Reboots sind absolut zwingend notwendig bei den modernen Treiber. Egal ob Neuinstallation oder Update. Und zwar auf dem Client und auch auf dem Print-Server. Sonst geht unter Umständen einfach gar nix mehr richtig.

 

Was aber generell hilft bei Problemen: Kräftig auszmisten. Da wird gerne so viel Schrott erzeugt in der Registry das man meint, das gibts nicht. Manchmal die einzige Lösung um alte Printer, Ports etc. überhaupt komplett loszuwerden. Ist nur Käse, dass man mit nem Script eigentlich durch alle USER-SID's laufen müsste, das macht das ganze ziemlich mühsam

[sheeva 10]

Kann dazu jemand etwas sagen? --> http://digitalzombies.com/2014/07/03/print_issues_rds_2012/

 

 

ich habe die anleitung vor mehreren wochen penibel abgearbeitet. allerdings brachte das nur für ein paar tage besserung.

 

@twenty

kannst du nochmal kurz rückmelden, ob die 2 regkeys das problem bei dir lösen konnten?

die keys werden vermutlich auf den terminalservern gesetzt?

über welche methode werden die drucker bei dir eingebunden (logonscript, gpo, gpp)?

 

lg sheeva

[twenty 12]

Hallo,

 

wir löschen jede Nacht (auf Anraten von Microsoft) zusätzliche alle Keys unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider" und restarten den Spooler. Bis jetzt (knappe 3 Wochen) sind keine Probleme mehr gemeldet worden.

 

Gruß Twenty

[Mannzrl 0]

So ich habe mich nun auch mal angemeldet, ich habe hier mehrere Kunden mit dem genau gleichen Problem.

Hat jemand die Anpassungen von twenty ausprobiert und kann positives berichten?

 

@twenty: Wie löscht ihr die Keys unter "Client Side Rendering Print Provider"? Einfach den ganzen Schlüssel löschen und einen leeren wieder importieren oder gibt es eine elegantere Variante?

[twenty 12]

Hallo,

 

wir löschen alle darunter liegenden Keys. Diese Vorgangsweise wurde uns von Microsoft so empfohlen. Täglich wird ein Script gestartet, das die Reghives via reg delete löscht.

 

 

Unser Script - *.cmd - ist eigentlich nur ein 3 Zeiler. Am Anfang wird der Spooler beendet und am Ende wird der Spooler gestartet. Dazwischen befindet sich die Anweisung zum Löschen der Reghives.

 

for /f "tokens=*" %%d in ('reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider" ^| findstr /i " S-1-5-21- servers"') do reg delete "%%d" /f

 

 

Bis jetzt haben wir keine negativen Erfahren damit gemacht. Die Ordnerstruktur wird beim Anmeldevorgang des Users wieder angelegt und kann daher gefahrlos gelöscht werden. Einen Import der Keys würde ich nicht empfehlen, denn damit beginnt das Problem gleich von neuem.

 

Seitens Microsoft gibt es derzeit keinen anderen Lösungsweg. Microsoft konnte keinen Fehler im Code entdecken und sieht daher auch keinen Handlungsbedarf.

 

Gruß Twenty

[Weingeist 157]

Wenn MS der Meinung ist, dass der Code korrekt ist, ist eigentlich die Wahrscheinlichkeit hoch, dass es irgendwo an einer Konfig liegen muss oder? Zumindest kann man davon ausgehen, dass es nicht nur durch den first Level ging, wenn solch eine Aussage kommt.

 

Ich glaube da war schon was in diesem Thread, aber habt ihr mal geschaut ob es einen Zusammenhang mit dem Namen gibt, mit dem man der Printer verbindet?

- also via NetBiosName oder FQDN verbunden? --> Gibts Unterschiede bei gleicher Art der Bereitstellung?

- Identischer Name und Freigabename des Printers? --> Gibts Unterschiede wenn nicht identisch bei gleicher Art der Bereitstellung?

- ist bei Anwesenheit eines Proxy die Nutzung deaktiviert im IE für interne Adressen und nicht nur "lokale Adressen umgehen", sondern explizit die Domäne und/oder IP-Range eingetragen?

- Ist der Drucker unter Umständen über Nacht ausgeschaltet und er versucht es am Morgen dann mit einer alternativen Route zum Drucker? also z.B. Umschalten von DNS auf WINS usw.

- beachtet er bei irgend einer Variante die Gross/Kleinschreibung? also überall identisch, sowohl beim verbinden als auch beim expliziten Namen als auch beim DNS?

 

Da man nicht so genau weiss, woher Windows seine Daten für die Verbindung am Ende holt, wäre das so meine Versuche.

bearbeitet 2. April 2015 von Weingeist

[muenster 16]

Moin,

 

nun habe ich alles aus dem Thread abgearbeitet und dabei folgendes festgestellt:

 

1. die Anleitung auf digitalzombie hilft auch über mehrere Tage

2. alle Clientdrucker, die auch auf Netzwerdrucker verweisen müssen weg

3. es gibt Programme, die Druckereinstellungen und damit auch den Drucker zentral verwalten, über diese Verweise tauchen die Drucker dann wieder in den Terminaserversitzungen auf.

4. ganz wichtig ist die Bereinigung der Treiberlandschaft

 

Bis jetzt läuft es rund (klopf auf Holz)...

[sheeva 10]

Hallo Zusammen

 

Will mich auch nochmal bzgl. der Druckerproblematik melden.

Wir haben in den letzten 3-4 Monaten sämtliche Empfehlungen und Tipps hier im Thread ausprobiert, allerdings hatte nichts davon nachhaltigen Erfolg. Früher oder später hatten wir wieder das Problem, dass Anwendungen keine Drucker fanden bzw. die Drucker vielfach in der Druckerverwaltung angezeigt wurden.

Da wir letztendlich keine zufriedenstellende Lösung finden konnten, haben wir die Drucker auf den RDS-Hosts (2012 R2) nun wieder lokal installiert. Dies ist zwar mühsam zu verwalten u. viele Features (globale Druckereinstellungen, einheitlicher Spooler für alle User, etc.) vermissen wir zwar, aber zumindest gibt es nun seit mehreren Wochen keine technischen Probleme mehr.

 

Ich für meinen Teil habe mich damit jetzt erstmal abgefunden, und will auch nicht zukünftig für jeden Regkey der vielleicht(!) das Problem behebt wieder einen Printserver in Betrieb nehmen und sämtliche Drucker für alle User neu ausrollen. Zumindest nicht solange MS das Problem nicht öffentlich adressiert und Lösungsvorschläge anbietet.