Crazy57

Hallo GTRDRIVER, das Drucken über EasyPrint wird immer langsam sein, denn 1. Anwendung schreibt per GDI ins Spoolfile 2. EasyPrint rendert via XPS-Driver in ein XPS-File 3. XPS-File wird via rdp zum Client übertragen 4. XPS-File wird von lokalen Treiber für den Zieldrucker passend gerendert. wird direkt auf einen Drucker am TS gedruckt passiert nur 1. Anwendung schreibt per GDI ins Spoolfile 2. Druckertreiber rendert passend für Zieldrucker Ein weiterer Nachteil von EasyPrint besteht darin, dass Druckerinformationen immer per RPC vom Client angefordert werden und das kostet Zeit. Besonders ist das zu bemerken, wenn Office oder der Acrobat den Druckdialog aufrufen. Da kann schon mal einige Sekunden nichts passieren. Seit Server 2008R2 gibt es immer Probleme, wenn der festgelegte Standarddrucker gespeichert bleiben soll. Gravierend tritt dies bei 2012R2 auf und wie Tests zeigten hat sich das auch bei Server 2016 nicht verbessert. Sicher kann man hier beim Login etwas händeln, aber es bleibt immer ein zeitkritisches Verhalten, da nie genau festgestellt werden kann wann der Drucker erstellt ist. Bei den Terminalservern, die ich betreue, wurde die gesamte Problematik durch den Einsatz einer Thirdparty-Software Slimprinter gelöst. Hier können gezielt die zu erstellenden Drucker und ein Standarddrucker unabhängig vom lokalen Standarddrucker gesetzt werden. Da dieses Programm nicht ein XPS-File sondern die GDI-Befehle aus dem Spoolfile zum Client überträgt geht das Drucken sehr flott. Gruß Crazy

Hallo Boardveteran, sicher hat datev Probleme mit rdp oder citrix, da hier nicht das windows spoolsystem straight verwendet wird im Gegensatz zu auf dem TS lokal installierten Druckern. Mit Tricerat, thinprint oder Slimprinter ist dieses Problem aber ausgeklammert. Nur solltest Du es mal vom Grundansatz her sehen, das eine Windowsanwendung immer nur in einen Devicecontext druckt, indem emf-Anweisungen zunächst in den Spooler schickt, die geräteunabhängig sind. Sollte Datev es auf andere Art tun, dann ist deine Aussage korrekt und Datev versucht etwas eigenes das nicht konform zum zugrundeligenden Betriebssystem ist. Crazy

Da bin ich auch noch mal und grüße alle anderen 'teilnehmer' des Threads. Es wurde ja schon einiges zu Easyprint geschrieben. Easyprint ist für mich die ungeeignetste Mehode zum Drucken unter RDP. Microsoft hat's mal wieder gut gemeint und hat auf die 'nervigen user' reagiert, allerdings nicht gerade positiv. Easyprint ist einfach zu träge, da die Anwendung auf dem TS in den Spooler druckt (also emf erstellt), der Easyprinttreiber daraus XPS rendert, das XPS-File zum Client transportiert wird und dann auf den Devicecontext des Zieldruckers rendet. Also kein Wunder, wenn eine Seite 20sec. dauert. Thirdpartydruckprogramme, wie im Thread oben angegeben, nehmen hingegen gleich das emf-spoolfile, schickes auf die eine oder andere Weise komprimiert zum Client und rendern dann in den Devicecontext des Zieldruckers. Das bringt natürlich speed und klammert irgendwelche Treiberprobleme auf dem TS aus. Wenn beim 'normalen' rdp-Drucker-Mapping die clietseitigen Einstellungen nicht übernommen werden, ist entweder der spezifische Druckertreiber des Zieldruckers schuld oder auch die Technik des microsoftmäßigen Druckermappings schuld. Wenn 'Boardveteran' davon spricht, irgenwann kommt eine Software die mit Easyprint oder RDP-Mapping nicht mehr zu rande kommt, geht das an der Realität vorbei und zeigt Verständnisprobleme der gesamten Drucktechnik des Windowsspoolersystems. Wenn man betrachtet, wie lange Microsoft an der gesamten Problematik 'forscht' und mit dem emf-Spoolsystem eigentlich die Lösung in der Hand hat, aber nur schlecht oder nicht funktionierende Nachbesserungen anbietet, muß man auch dem gegenüber Unverständnis haben. Weder mit Server2012R2 noch mit der technical preview von Server 2016 hat sich da etwas gebessert, im Gegenteil. Ich bin froh meine Lösung gefunden zu haben. Crazy

Hallo rt1970, sicher kann man den Drucker auch lokal auf dem TS installieren. Da ergeben sich aber zwei Probleme: 1. Der Client muß direkten Netzwerkszugriff haben (wenn der Drucker via TCP/IP angeschlossen ist) und muß natürlich geografisch für den Clientstandort verfügbar sein. befindet sich der Drucker am Client muß der gerenderte Datenstrom zum Drucker übertragen werden, was bei einer schmalbandigen WAN-Anbindung zu Wartezeiten führt. 2. Der Drucker kann durch andere Nutzer mit größeren Druckjobs blockiert werden. In unserer Firma gibt es Außenstellen, die einige 100km vom Hauptstandort entfernt sind und mit z.T. langsamer DSL-Verbindung auf den Terminalserver zugreifen. Schon vor Jahren habe ich nach Auswegen aus diesem Dilemma gesucht und habe anderweitige Lösungen wie Tricerat Screwdrivers, Thinprint und Slimprinter getestet. Letztendlich hat sich die Firma für Slimprinter entschieden. Ausschlaggebend war dabei das Preis/Leistungsverhältnis und die Fähigkeit auch zusätzliche Papierfächer korrekt anzusteuern. Es dürfte auch Dein Problem lösen. Crazy