HeizungAuf5 13 Geschrieben 6. Oktober 2020 Melden Geschrieben 6. Oktober 2020 (bearbeitet) Hallo zusammen, wir haben unsere "Arbeitsplätze" mittlerweile komplett zu Terminalserver im Rechenzentrum migriert. Funktioniert auch alles wunderbar, bis auf die Drucker. Kurz zum Aufbau: Im Rechenzentrum befindet sich ein DC, ein Printserver und eben auch mehrere Terminalserver (alles Windows Server 2019). Die Terminalserver und der Printserver haben als DNS nur den DC im RZ eingetragen. Die Terminalserver bekommen die Drucker per GPO vom Printserver im Rechenzentrum eingebunden, der diese wiederum per TCP/IP Anschluss verbunden hat. Die Server im Rechenzentrum haben dort ihr eigenes LAN, welches per Side-to-Side VPN mit dem LAN am Standaort verbunden ist. Ein durchschleifen der Drucker per RDP ist nicht vorgesehen und auch teilweise nicht umsetzbar. Die müssen vom Printserver direkt an den Terminalserver. Dabei haben wir nun folgendes Problem: Soll auf den Terminalservern gedruckt werden, dauert es teilweise extrem lange, bis die Drucker dort angesprochen werden können. Z. B. möchte ich eine PDF drucken, klicke also im PDF Viewer auf das Drucken-Symbol, muss ich ca. 10 Sekunden warten, bis ich das "Druckfenster" sehe. Wechsle ich danach den Drucker kann ich nochmal ca. 5 Sekunden warten. Das selbe, wenn eine Einstellung im Druckdialog verändert wird. Das bedeutet, dass ein Ausdruck von einer PDF gerne mal 2 Minuten in Anspruch nimmt. Wenn ich etwas auf Office drucken möchte, sehe ich schon eher woher der Wind weht. Klicke ich dort auf Drucken steht der Dialog erstmal für ca. 30 Sekunden auf "Suche nach verfügbaren Druckern", bevor der Standarddrucker angezeigt wird und ich darauf drucken könnte. In der Zeit ploppen auch immer wieder die kleinen Fenster "Verbindung zu Drucker wird hergestellt" auf. Will ich dann statt dem Standarddrucker einen anderen haben, klicke also auf die Auswahlliste dauert es wieder ca. 30 Sekunden, bis die Drucker erscheinen. Meine Vermutung dabei ist: Wenn der Terminalserver etwas drucken will, verbindet er sich nicht "nur" bis zum Printserver, sondern bis zu den Druckern bei uns am Standort (dabei muss er über eine sehr langsame VPN Verbindung (Internetverbindung am Standort ist nicht wirklich gut, deswegen ja alles ins RZ)) und braucht deshalb ewig um mit den Druckern zu sprechen. Kann ich das dem Terminalserver irgendwie austreiben? Ziel wäre, dass sich der Terminalserver nur noch bis zum Printserver verbindet und dort die Aufträge abgibt ("Prüf nicht erst, mach einfach!"). Somit würde die "Wartezeit" beim Verbinden auf den Printserver wandern und nicht mehr die Programme auf dem Terminalserver zum Absturz bringen. Hat hier jemand einen Vorschlag für mich? Noch kurz zum Verständnis, nicht dass wir uns falsch verstehen: Dass der gesamte Vorgang (also Benutzer will drucken bis hin zu Benutzer hält das Blatt in der Hand) nicht schneller werden kann ist mir klar, ich möchte die Wartezeit nur eben von den Benutzern weg bringen und auf den Printserver verlagern. Danke! Noch als Nachtrag: Testweise habe ich mal einen PDF Reader direkt auf dem Printserver installiert. Dort funktioniert die Druckerei ohne diese ewigen Wartereien. bearbeitet 6. Oktober 2020 von HeizungAuf5 Zitieren
testperson 1.761 Geschrieben 6. Oktober 2020 Melden Geschrieben 6. Oktober 2020 Hi, da könnte das https://gpsearch.azurewebsites.net/#12120 helfen. Ebenfalls solltest du prüfen, ob die Drucker auf dem Printserver im Treiber Optionen angehakt haben, um Zubehör / Papierformate / etc. automatisch bei jedem Druckjob zu erkennen bzw. ob das bei den Usern im Drucker hinterlegt ist. Gruß Jan Zitieren
HeizungAuf5 13 Geschrieben 6. Oktober 2020 Autor Melden Geschrieben 6. Oktober 2020 Moin, Am 6.10.2020 um 15:03 schrieb testperson: da könnte das https://gpsearch.azurewebsites.net/#12120 helfen Mehr Hab ich gerade angeschaut, bei mir gibts weder den "Pfad" in den lokalen Gruppenrichtlinien, noch den Registry Pfad. Oder bin ich in der Beziehung zu doof zum suchen? ;) Wenn ich die Richtlinie richtig interpretiere, ist die auch Primär "nur" fürs Office Paket gültig, richtig? Am 6.10.2020 um 15:03 schrieb testperson: ob die Drucker auf dem Printserver im Treiber Optionen angehakt haben, um Zubehör [...]automatisch bei jedem Druckjob zu erkennen Mehr Also Ausstattungsmerkmale (Hat der Drucker nen Finisher und die Papierschächte) sind bei jedem Drucker fix. Grüße und Danke! Zitieren
NorbertFe 2.177 Geschrieben 6. Oktober 2020 Melden Geschrieben 6. Oktober 2020 (bearbeitet) Am 6.10.2020 um 15:51 schrieb HeizungAuf5: Oder bin ich in der Beziehung zu doof zum suchen? ;) Mehr Fangfrage? :) Dann definier die Policy doch einfach. bearbeitet 6. Oktober 2020 von NorbertFe Zitieren
testperson 1.761 Geschrieben 6. Oktober 2020 Melden Geschrieben 6. Oktober 2020 Am 6.10.2020 um 15:51 schrieb HeizungAuf5: Hab ich gerade angeschaut, bei mir gibts weder den "Pfad" in den lokalen Gruppenrichtlinien, noch den Registry Pfad. Oder bin ich in der Beziehung zu doof zum suchen? ;) Mehr Hast du denn die Office ADMX im PolcyDefinitions bzw. im CentralStore? Am 6.10.2020 um 15:51 schrieb HeizungAuf5: Wenn ich die Richtlinie richtig interpretiere, ist die auch Primär "nur" fürs Office Paket gültig, richtig? Mehr Ja. Aber wäre doch schonmal ein Anfang, wenn Office "flotter" drucken kann. Evtl. gibts ja in den Optionen des PDF Viewers ähnliche Möglichkeiten oder ebenfalls Policies. Am 6.10.2020 um 15:51 schrieb HeizungAuf5: Also Ausstattungsmerkmale (Hat der Drucker nen Finisher und die Papierschächte) sind bei jedem Drucker fix. Mehr Wichtig wäre, dass der Drucker halt nicht bei jeder Verwendung versucht sämtliche Einstellungen / Optionen zu aktualisieren. Zitieren
MurdocX 965 Geschrieben 6. Oktober 2020 Melden Geschrieben 6. Oktober 2020 Am 6.10.2020 um 14:15 schrieb HeizungAuf5: Dabei haben wir nun folgendes Problem: Soll auf den Terminalservern gedruckt werden, dauert es teilweise extrem lange, bis die Drucker dort angesprochen werden können. Z. B. möchte ich eine PDF drucken, klicke also im PDF Viewer auf das Drucken-Symbol, muss ich ca. 10 Sekunden warten, bis ich das "Druckfenster" sehe. Wechsle ich danach den Drucker kann ich nochmal ca. 5 Sekunden warten. Das selbe, wenn eine Einstellung im Druckdialog verändert wird. Das bedeutet, dass ein Ausdruck von einer PDF gerne mal 2 Minuten in Anspruch nimmt. Mehr Ich hab schon gesehen das einfache Druckaufträge von 200kb auf 700MB Druckauftrag aufgebläht wurden. Sind diese vielleicht einfach zu groß, dass sie einfach länger dauern? Das könnte auch an alten/defekten Treibern liegen. Zitieren
HeizungAuf5 13 Geschrieben 7. Oktober 2020 Autor Melden Geschrieben 7. Oktober 2020 Hallo Zusammen, Am 6.10.2020 um 16:32 schrieb testperson: Hast du denn die Office ADMX Mehr Jup. Die hab ich. Hab die von hier genommen und importiert. Diese werden auch im Gruppenrichtlinieneditor angezeigt, allerdings habe ich unter Benutzerkonfiguration kein Miscellaneous (was ich einfach mal mit "Verschiedenes" oder "sonstiges" übersetzt hätte): Installiert ist auf dem Terminalserver ein Office 365. Am 6.10.2020 um 16:32 schrieb testperson: dass der Drucker halt nicht bei jeder Verwendung versucht sämtliche Einstellungen / Optionen zu aktualisieren Mehr Gibts noch andere Stellen, an denen man das einstellen kann? Wie es scheint führt der Terminalserver trotz "fixer" Einstellungen erst mal die Prüfung auf Toner- /Papierstand durch. Am 6.10.2020 um 17:57 schrieb MurdocX: Ich hab schon gesehen das einfache Druckaufträge von 200kb auf 700MB Druckauftrag aufgebläht wurden Mehr Habe ich gerade getestet, kann ich nicht bestätigen. Ein Druckauftrag, wo ich sicherlich 3 Minuten im Auswahldialog hing, hatte am Ende 82kb. Grüße! Zitieren
testperson 1.761 Geschrieben 7. Oktober 2020 Melden Geschrieben 7. Oktober 2020 Am 7.10.2020 um 10:15 schrieb HeizungAuf5: Diese werden auch im Gruppenrichtlinieneditor angezeigt, allerdings habe ich unter Benutzerkonfiguration kein Miscellaneous (was ich einfach mal mit "Verschiedenes" oder "sonstiges" übersetzt hätte): Mehr Da scheint es im Office-Zweig der GPSearch ein Problem zu geben, dass auf der rechten Seite bei der Erklärung "Microsoft Office 2016" (User Configuration\Administrative Templates\<Microsoft Office 2016\>Miscellaneous\) rausoptimiert ist. Am 7.10.2020 um 10:15 schrieb HeizungAuf5: Gibts noch andere Stellen, an denen man das einstellen kann? Wie es scheint führt der Terminalserver trotz "fixer" Einstellungen erst mal die Prüfung auf Toner- /Papierstand durch. Mehr Das hängt vom Drucker und Treiber ab. Da müsstest du dich selber durchklicken oder den Support einschalten. Am 6.10.2020 um 14:15 schrieb HeizungAuf5: Meine Vermutung dabei ist: Wenn der Terminalserver etwas drucken will, verbindet er sich nicht "nur" bis zum Printserver, sondern bis zu den Druckern bei uns am Standort (dabei muss er über eine sehr langsame VPN Verbindung (Internetverbindung am Standort ist nicht wirklich gut, deswegen ja alles ins RZ)) und braucht deshalb ewig um mit den Druckern zu sprechen. Mehr Welche Bandbreite habt ihr denn im VPN / WAN bei wie vielen gleichzeitigen Usern und welchen Applikationen? In einer solchen Konstellation ist "auslagern in ein RZ" auch nicht immer der goldene Weg. Zitieren
Weingeist 165 Geschrieben 7. Oktober 2020 Melden Geschrieben 7. Oktober 2020 (bearbeitet) Am 6.10.2020 um 16:32 schrieb testperson: Ja. Aber wäre doch schonmal ein Anfang, wenn Office "flotter" drucken kann. Evtl. gibts ja in den Optionen des PDF Viewers ähnliche Möglichkeiten oder ebenfalls Policies. Wichtig wäre, dass der Drucker halt nicht bei jeder Verwendung versucht sämtliche Einstellungen / Optionen zu aktualisieren. Mehr Office hat seit 2007 seine eigene, +-systemunabhängige oder auf einer anderen Auflistung basierende Drucker-Geschichte als andere Programme am Start. Insofern gut möglich, dass nicht alles identisch funktioniert wie in anderen Programmen. Bildirektionale Kommunikation ist heute fast Standard bei den Drucker. Und wenn es nur Telemetrie-Quatsch ist. Wenn da viel und her geht, wirds übers I-netz lahm -->Auf herstellerspezifische Treiber verzichten und den Generik-Kram von MS verwenden oder mal versuchsweise die Ports nach aussen sperren (Nur eine Idee, keine Ahnung obs besser ist). Eventuell spielt in solchen Szenarien auch der "neumodische Kram" seine Stärken aus mit dem man sonst nur Ärger hat? ThinPrint und wie auch immer das Zeug alles heisst. Da sehe ich mittlerweile den Wald vor lauter Bäumen nicht mehr. ;) --> Ports sperren endet gerne in Ärger mit Hintergrundbilder/Overlay Auflistungen oder wie auch immer die Hersteller das jeweilsung nennen. Drucken funktioniert aber trotzdem nach Fire-Forget Prinzip (z.Bsp. bei Canon) wenn die Einstellungen vordefiniert sind oder aufs geratewohl getätigt werden. Vielleicht wird es aber genau schneller, weil eben kommuniziert werden kann statt X-mal zu versuchen. Evtl. kriegst ja mit einem Netzwerk-Analyse mehr raus was auf was wartet oder wie die Zugriffe ablaufen, wieviel Daten effektiv wohin übertragen werden? Ansonsten: Ich habe noch nicht ganz begriffen wo der Client sich befindet und wohin Du genau drucken möchtest und wann es eben langsam ist. zbsp. V1: Du bist zu Hause und druckst aus einer TS-Session heraus auf einen Drucker zu Hause, Kommunikation: DeinPC>VPN>TS>PrintServer>VPN>DeinPC>DeinDrucker zu Hause V2: Du bist zu Hause und druckst aus einer TS-Session auf einen Drucker im Geschäft, Kommunikation: DeinPC>VPN>TS>PrintServer>Drucker im Geschäft V3: ..... Dann gibt es noch zig-Möglichkeiten welche Drucker in der Auflistung sind, also nur lokale oder eben auch solche im RZ und wie sie angebunden werden. Ich würde nen Testclient aufsetzen und die verschiedenen möglichen Varianten durchspielen. Dürfte das schnellste sein. bearbeitet 7. Oktober 2020 von Weingeist Zitieren
Dominik Weber 19 Geschrieben 7. Oktober 2020 Melden Geschrieben 7. Oktober 2020 Das mit dem dauern aktualisieren ist gerade bei Xerox Geräten mühsam. Die Automatische Konfiguration kann aber bei fast jeden Hersteller im Druckertreiber ausgeschaltet werden. Zum testen eventuell den Drucker über TCP/IP direkt auf einem TS einrichten. Hat bei kleinen Kunden (1-2 TS) bei uns auch viele Probleme gelöst. Zitieren
HeizungAuf5 13 Geschrieben 14. Oktober 2020 Autor Melden Geschrieben 14. Oktober 2020 Hallo zusammen, ich habe die letzten Tage ein bisschen rumgetestet und dadurch etwas erkenntnissreicher geworden. Auf dem Printserver selbst funktioniert ein Druck problemlos in wenigen Sekunden. Testweise habe ich im Rechenzentrum einen zweiten Server (Ebenfalls Windows 2019) installiert und die Drucker dort vom Printserver eingebunden (Gleiche Treiber, gleiche Drucker). Dort funktioniert der Druck problemlos! So wie ich das sehe, liegt die Problematik also weniger auf dem Printserver, sondern eher auf dem Terminalserver. Hier jemand eine Idee, was den Druck so dermaßen ausbremsen kann? Installiert ist auf dem Terminalserver größtenteils Standardzeug und auch keine Software, die wir nicht wo anders auch einsetzen und wo die Drucker funktionieren. Am 7.10.2020 um 14:28 schrieb Dominik Weber: Zum testen eventuell den Drucker über TCP/IP direkt auf einem TS einrichten. Hat bei kleinen Kunden (1-2 TS) bei uns auch viele Probleme gelöst. Mehr Hab ich getestet, funktioniert leider auch nicht. Selbst wenn ich alle Drucker entferne, dass ich nur noch den Microsoft PDF Printer und den OneNote Printer hab, sind die Druckdialoge kaum bedienbar. Danke! Zitieren
Weingeist 165 Geschrieben 14. Oktober 2020 Melden Geschrieben 14. Oktober 2020 Hast Du Clientseitige oder Serverseitige Aufbereitung? Client-Seitig verursacht eine ziemliche hohe HDD-Last. Wäre ein Ansatzpunkt, allerdings müssten dann auch die sonstigen Zugriff lahmars***ig sein. Dann ist TS 2016/2019 bezüglich Printer im Moment eh noch etwas schwierig soviel Probleme wie da im Netz rumschwirren. MS ist da aber wohl nicht alleine Schuld, auch wenn sie es verursacht haben. Ich tippe daher mal auf Druckerleichen in der Registry. Hier schwirrt irgend ein Script rum, welches den ganzen Krempel beim anmelden/abmelden rauslöscht und neu verbindet. Das sind teilweise viel mehr als dann tatsächlich in der Auflistung erscheinen. Ähnlich wie mit den Firewallregeln auf App-Basis welche auch ein totales Desaster auf einem TS sind. (Auch sonst, da nicht steuerbar) Habe "leider" nur 2012R2 im Einsatz, daher das Script irgendwie in der Verskung. Habe immer noch die Hoffnung, dass die Probleme gelöst sind bis zum Ende des Supports. =) Zitieren
testperson 1.761 Geschrieben 14. Oktober 2020 Melden Geschrieben 14. Oktober 2020 Am 14.10.2020 um 05:57 schrieb HeizungAuf5: Auf dem Printserver selbst funktioniert ein Druck problemlos in wenigen Sekunden. Testweise habe ich im Rechenzentrum einen zweiten Server (Ebenfalls Windows 2019) installiert und die Drucker dort vom Printserver eingebunden (Gleiche Treiber, gleiche Drucker). Dort funktioniert der Druck problemlos! Mehr Aus welchen Anwendungen hast du am Printserver / Testserver gedruckt? Viele Anwendungen werden vor dem Druck zumindest den Standarddrucker, wenn nicht sogar alle Drucker, "prüfen" und bei dieser Prüfung werden je nach Einstellungen im Treiber / den Eigenschaften diverse Dinge (Druckerzubehör, Papierformat, Tonerstandt, ...) vom Drucker abgefragt. Je nach Anzahl an Druckern kann das eben dauern. Ausgeschaltete bzw. nicht erreichbare (verbundene) Drucker verzögern diesen Vorgang nochmals. Zitieren
HeizungAuf5 13 Geschrieben 26. Oktober 2020 Autor Melden Geschrieben 26. Oktober 2020 Hallo zusammen, sorry für die späte Antwort! Nach einigem hin und her und ausprobieren auf dem Terminalserver, sowie Printserver hat sich herausgestellt, dass der Terminalserver der alleinige Verursacher der Probleme ist. Testweise auf einem der Testserver ein Office Paket installiert, dort ohne jegliche Probleme. Sogar die bidirektionale Kommunikation funktioniere innerhalb von wenigen Sekunden. Daher haben wir uns dazu entschieden, den Terminalserver neu aufzusetzen, bevor er zu "voll" wird. Das getan haben wir keinerlei Probleme mehr mit den Drucken. Sogar das ansprechen von treiberspezifischen Einstellungen (wie z. B. Finisher) funktioniert nun reibungslos und ohne Verzögerung. Office ist zwar immer noch das Langsamste, aber die Wartezeit von aktuell ca. 2-3 Sekunden ist verkraftbar. Interessant wäre natürlich noch, was bei der "alten" Installation schief gelaufen ist, dass das so ausgeartet ist. Der Server hat jetzt wieder exakt die selbe Software wie vorher auch. Aber naja. Windows halt Danke für eure Mühen! Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.