6
Ewige "Hänger" beim Drucken - Terminalserver
Hallo Forum,
wir haben seit einigen Monaten Probleme mit unserer Umgebung. 80 User, 3TS 2016, DC, Navision, 12 Standorte, via VPN, aber alles TS. Probleme kamen vor längerer Zeit ohne Vorankündigung von einem auf den anderen Tag.
_____________________________________________
Urplötzlich und mehrfach am Tag hängt das System. Mir kommt es vor, als würde es mit den Druckern zu tun haben. Ein User ruft an, dass sein Navision-Client unmittelbar nach der Buchungstaste (F9) hängt. Normal kommt nach Druck auf F9 die Maske mit der Druckerauswahl und irgendwelchen Buchungsdetails.
Dieser Hänger dauert bis zu 15Minuten. Derweilen liegt auf den Tablellen des Navision auch eine Sperre, wohl damit keiner dazwischenbucht. Nur wird die Sperre erst wieder freigegeben (sieht man recht schön im SQL-Manager) wenn der Druckdialog erscheint. Leider müssen sich alle anderen User hinter anstellen und können demnach auch nicht mehr buchen.
Während des Hängers ist (bei dem Betreffenden user, ob der versursacht ist weiß und glaub ich nicht) kein öffnen der Systemsteuerung/Drucker möglich und auch Netzlaufwerke bleiben hängend. Ich sah bei einem User während der betroffenen Zeit auch, dass beim Acrobat das gleiche Passiert, PDF lese geht wunderbar, klickt er auf das Drucksymbol hängt er - und zwar genau so lange wie alle anderen auch.
Nach Ablauf der "Zeit" (zwischen 3 und 15Minuten) gibts dann einen großen "Knall", alles wird sofort Verbucht, Netzlaufwerke gehen wieder und das System verhält sich wie wenn nie was gewesen wäre. Ereingisanzeige ohne Eintrag (zumindest für mein Verständnis)
_____________________________________________
Folgendes hab ich schon zur Fehlerbehebung erledigt.
Neuer Printserver (W2016), 80 Drucker, alle geshared und via Startskript verteilt
Beide ursprungsDC herabgestuft weggeworfen und einen Frischen DC(W2016) aufgesetzt
DNS neu aufgesetzt
Alle drei Terminalserver neu installiert
Separate TS für 2 einzelne Standorte angelegt
Neue Hardware für SQL besorgt (Eig. aus anderm Grund, klar)
Alle Maschinen auf dem VmWare-Cluster hin und hergeschoben
Alles das hat nichts geholfen: Die Umgebung ist durch diese Kur wieder sehr performant geworden, aber wenns steht, dann stehts wie angenagelt.
Hat wer einen Tipp?
wir haben seit einigen Monaten Probleme mit unserer Umgebung. 80 User, 3TS 2016, DC, Navision, 12 Standorte, via VPN, aber alles TS. Probleme kamen vor längerer Zeit ohne Vorankündigung von einem auf den anderen Tag.
_____________________________________________
Urplötzlich und mehrfach am Tag hängt das System. Mir kommt es vor, als würde es mit den Druckern zu tun haben. Ein User ruft an, dass sein Navision-Client unmittelbar nach der Buchungstaste (F9) hängt. Normal kommt nach Druck auf F9 die Maske mit der Druckerauswahl und irgendwelchen Buchungsdetails.
Dieser Hänger dauert bis zu 15Minuten. Derweilen liegt auf den Tablellen des Navision auch eine Sperre, wohl damit keiner dazwischenbucht. Nur wird die Sperre erst wieder freigegeben (sieht man recht schön im SQL-Manager) wenn der Druckdialog erscheint. Leider müssen sich alle anderen User hinter anstellen und können demnach auch nicht mehr buchen.
Während des Hängers ist (bei dem Betreffenden user, ob der versursacht ist weiß und glaub ich nicht) kein öffnen der Systemsteuerung/Drucker möglich und auch Netzlaufwerke bleiben hängend. Ich sah bei einem User während der betroffenen Zeit auch, dass beim Acrobat das gleiche Passiert, PDF lese geht wunderbar, klickt er auf das Drucksymbol hängt er - und zwar genau so lange wie alle anderen auch.
Nach Ablauf der "Zeit" (zwischen 3 und 15Minuten) gibts dann einen großen "Knall", alles wird sofort Verbucht, Netzlaufwerke gehen wieder und das System verhält sich wie wenn nie was gewesen wäre. Ereingisanzeige ohne Eintrag (zumindest für mein Verständnis)
_____________________________________________
Folgendes hab ich schon zur Fehlerbehebung erledigt.
Neuer Printserver (W2016), 80 Drucker, alle geshared und via Startskript verteilt
Beide ursprungsDC herabgestuft weggeworfen und einen Frischen DC(W2016) aufgesetzt
DNS neu aufgesetzt
Alle drei Terminalserver neu installiert
Separate TS für 2 einzelne Standorte angelegt
Neue Hardware für SQL besorgt (Eig. aus anderm Grund, klar)
Alle Maschinen auf dem VmWare-Cluster hin und hergeschoben
Alles das hat nichts geholfen: Die Umgebung ist durch diese Kur wieder sehr performant geworden, aber wenns steht, dann stehts wie angenagelt.
Hat wer einen Tipp?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 667242
Url: https://administrator.de/contentid/667242
Printed on: April 27, 2024 at 10:04 o'clock
6 Comments
Latest comment
Ohjje, kann viele Ursachen haben.
Wie sind die Drucker verbunden?
Bidirektionale Unterstützung bei den Druckern deaktiviert?
Passiert es immer zu gleichen Zeit?
Server / Netzwerk / Festplatten ... ausgelastet?
@rhg-rottal:
Hallo.
Ich tippe mal auf falsche Druckertreiber. Terminalserver sind da extrem empfindlich. Hier ein paar Regeln für Druckertreiber, die ich mir mal in Jahren der Terminalserverbetreuung zusammengeschustert habe (bei meinem vorletzten AG):
- sind die Druckertreiber bei Microsoft auf den zu TS zugehörigen (W)HCL-Listen zu finden (also von Microsoft für TS getestet und für gut befunden)?
- auch ohne (W)HCL: nur die Standard-/Basis-/Classic-Treiber verwendet?
- niemals irgendwelche "Supertreiber" der Druckerhersteller verwenden, die mit eigenem Setup und noch manch anderem Schmankerl (z. B. 4 Seiten auf ein Blatt o. Ä.) oder irgendwelchen zusätzlichen Queue-Monitoring-Tools daherkommen
- immer nur den einfach(st)en Standard-/Classic-Treiber verwenden! Treiber mit (weit) darüber hinausgehenden Fähigkeiten/Funktionen machen am Terminalserver nur Ärger!
- Alternativ: Universaltreiber (des jew. Druckerherstellers, natürlich passend für das Druckermodell) verwenden, aber auch hierbei auf einfachste Standards achten
Ich würde am Printserver die Treiber putzen, restlos. Die Drucker müssen, glaube ich, nicht gelöscht werden, die Warteschlangen funktionieren wieder, sobald im Register "Erweitert" wieder der (dann passende) Treiber hinzugefügt wurde. Selbiges auf allen Terminalservern. Zum Putzen (da gehört einiges dazu, z. B. auch Registry-Einträge) gibt es Tools, z. B. den Kyocera-Driver-Deleter (funktioniert auch für andere Drucker/Druckerhersteller, sogar, wenn kein einziger Kyo im Einsatz ist, einfach mal googeln). Danach Neustart. In der Zeit sollte niemand versuchen, auf die Terminalserver und/oder den Druckserver (druckend) zuzugreifen.
Dann für jeden Drucker den einfachsten Standard- oder Universaltreiber, im besten Falle mit Bezug zur "Windows Hardware Compatibility List", für die verschiedenen Drucker frisch herunterladen (natürlich Betriebssystem beachten, für 2016 gehen mitunter auch 2012-/2012R2-Treiber, manchmal sogar Windows 8.1/Windows 10) und installieren (kein Setup, nur entpackten Treiber ansteuern und eine enthaltene *.inf auswählen, Windows zeigt dann schon den richtigen Drucker/Druckertyp an).
Das wäre mein Tip dazu.
Viele Grüße
von
departure69
Hallo.
Neuer Printserver (W2016), 80 Drucker,
Ich tippe mal auf falsche Druckertreiber. Terminalserver sind da extrem empfindlich. Hier ein paar Regeln für Druckertreiber, die ich mir mal in Jahren der Terminalserverbetreuung zusammengeschustert habe (bei meinem vorletzten AG):
- sind die Druckertreiber bei Microsoft auf den zu TS zugehörigen (W)HCL-Listen zu finden (also von Microsoft für TS getestet und für gut befunden)?
- auch ohne (W)HCL: nur die Standard-/Basis-/Classic-Treiber verwendet?
- niemals irgendwelche "Supertreiber" der Druckerhersteller verwenden, die mit eigenem Setup und noch manch anderem Schmankerl (z. B. 4 Seiten auf ein Blatt o. Ä.) oder irgendwelchen zusätzlichen Queue-Monitoring-Tools daherkommen
- immer nur den einfach(st)en Standard-/Classic-Treiber verwenden! Treiber mit (weit) darüber hinausgehenden Fähigkeiten/Funktionen machen am Terminalserver nur Ärger!
- Alternativ: Universaltreiber (des jew. Druckerherstellers, natürlich passend für das Druckermodell) verwenden, aber auch hierbei auf einfachste Standards achten
Ich würde am Printserver die Treiber putzen, restlos. Die Drucker müssen, glaube ich, nicht gelöscht werden, die Warteschlangen funktionieren wieder, sobald im Register "Erweitert" wieder der (dann passende) Treiber hinzugefügt wurde. Selbiges auf allen Terminalservern. Zum Putzen (da gehört einiges dazu, z. B. auch Registry-Einträge) gibt es Tools, z. B. den Kyocera-Driver-Deleter (funktioniert auch für andere Drucker/Druckerhersteller, sogar, wenn kein einziger Kyo im Einsatz ist, einfach mal googeln). Danach Neustart. In der Zeit sollte niemand versuchen, auf die Terminalserver und/oder den Druckserver (druckend) zuzugreifen.
Dann für jeden Drucker den einfachsten Standard- oder Universaltreiber, im besten Falle mit Bezug zur "Windows Hardware Compatibility List", für die verschiedenen Drucker frisch herunterladen (natürlich Betriebssystem beachten, für 2016 gehen mitunter auch 2012-/2012R2-Treiber, manchmal sogar Windows 8.1/Windows 10) und installieren (kein Setup, nur entpackten Treiber ansteuern und eine enthaltene *.inf auswählen, Windows zeigt dann schon den richtigen Drucker/Druckertyp an).
Das wäre mein Tip dazu.
Viele Grüße
von
departure69
Zitat von @tagol01:
Ohjje, kann viele Ursachen haben.
Wie sind die Drucker verbunden? Alle als freigegebene Netzwerkdrucker
Bidirektionale Unterstützung bei den Druckern deaktiviert? Ist überall GRAU
Passiert es immer zu gleichen Zeit? Nein, das ist es ja, manchmal 2 Tage nicht, dann 15x am Tag, öfters nachmittag als Vormittag, daher auch evtl. ein User.
Server / Netzwerk / Festplatten ... ausgelastet? Nein, dümpelt alles fast im Idle
Ohjje, kann viele Ursachen haben.
Wie sind die Drucker verbunden? Alle als freigegebene Netzwerkdrucker
Bidirektionale Unterstützung bei den Druckern deaktiviert? Ist überall GRAU
Passiert es immer zu gleichen Zeit? Nein, das ist es ja, manchmal 2 Tage nicht, dann 15x am Tag, öfters nachmittag als Vormittag, daher auch evtl. ein User.
Server / Netzwerk / Festplatten ... ausgelastet? Nein, dümpelt alles fast im Idle
Guten Morgen,
bei uns siehts aus wie im Screenshot, es sind (samt drittfächern und Spezialdrucker) sinds doch 126 Stück. Screenshot stellt nicht alle dar.
Wenn wir treiber brauchen, laden wir eh immer den einfachsten Basistreiber runter und installieren den auch nicht via SetupRoutine sondern entpacken und manuell installieren.
Aber ich denke mal, dass es einfacher ist, ich setze eine frische W2016-Maschine auf und lege alle Drucker neu mit den Universaltreibern an.
Da wir die Drucker eh via Anmeldeskript verteilen, ist es danach in dem Skript nur eine Sache von Suchen und Ersetzen.
Problem sind halt auch die vielen Hersteller. Wir haben in der letzten Zeit viele andere Betriebe übernommen. Dementsprechend ist Kraut&Rüben bei den Druckern.
bei uns siehts aus wie im Screenshot, es sind (samt drittfächern und Spezialdrucker) sinds doch 126 Stück. Screenshot stellt nicht alle dar.
Wenn wir treiber brauchen, laden wir eh immer den einfachsten Basistreiber runter und installieren den auch nicht via SetupRoutine sondern entpacken und manuell installieren.
Aber ich denke mal, dass es einfacher ist, ich setze eine frische W2016-Maschine auf und lege alle Drucker neu mit den Universaltreibern an.
Da wir die Drucker eh via Anmeldeskript verteilen, ist es danach in dem Skript nur eine Sache von Suchen und Ersetzen.
Problem sind halt auch die vielen Hersteller. Wir haben in der letzten Zeit viele andere Betriebe übernommen. Dementsprechend ist Kraut&Rüben bei den Druckern.
1
Hallöchen,
nur mal zum Verständnis:
Werden die Drucker per Script beim Anmelden auf dem Terminalserver erzeugt oder werden die lokalen Drucker in die TS-Session gemapt?
Falls die Drucker gemapt werden, wird Esayprint verwendet oder werden die Drucker mit Originaltreiber erstellt?
Bei der großen Anzahl an unterschiedlichen Druckermodellen ist die Installation aller Treiber auf dem RDS-Host nicht zu empfehlen!
Manche Treiber behindern sich gegenseitig, manche sind für den RDS-Einsatz absolut ungeeignet.
Bei meinen Terminalservern habe ich die Problematik durch den Einsatz von Thirdparty-Software gelöst. Schon zu Zeiten von Windows Server 2003 habe ich da verschiedene Software,
wie Thinprint, Tricerat Screwdriver, TS-Print und Slimprinter, ausprobiert.
Mit Druckern, die nur Standardparameter haben und benutzen (wenige Papierformate, Schächte, Auflösungen etc.) schlagen sich eigentlich alle Softwarepakete gleich gut.
Problematischer wird es, wenn z.B. Bondrucker mit exotischen Parametern dazu kommen. Ein weiteres Problem bei Terminalservern mit gemapten Druckern sind die sich bei jeder Anmeldung ändernden Druckernamen.
Es gibt nur eine mir bekannte Software, die all diese Probleme im Blick hat: SLIMPRINTER
a) gezielte Auswahl von in die Session mitzunehmenden Druckern.
b) Drucker mit Standardparametern können einen der zur Software gehörigen Universaltreiber verwenden.
c) Für Drucker mit speziellen Eigenschaften kann der (dann auf dem RDS-Host erforderliche) Originaltreiber verwendet werden
d) die Druckernamen aus dem Namen des lokalen PC's und dem lokalen Druckernamen gebildet.
e) Beim Erstellen der Drucker in der Sitzung wird die ACL des Druckers bearbeitet, so dass dieser nur für Admins und den Benutzer selbst sichtbar ist. Dies erzeugt Übersicht auch bei vielen Usern
Slimprinter kann man mieten oder die Lizenz kaufen (Einmalpreis mit allen Updates und Upgrades, kostenloser Support).
Die downloadbare Version kann für 5 konkurrierende User 20 Tage ohne Einschränkungen getestet werden.
Vielleicht ist das ein Denkanstoss?
Gruß Crazy
nur mal zum Verständnis:
Werden die Drucker per Script beim Anmelden auf dem Terminalserver erzeugt oder werden die lokalen Drucker in die TS-Session gemapt?
Falls die Drucker gemapt werden, wird Esayprint verwendet oder werden die Drucker mit Originaltreiber erstellt?
Bei der großen Anzahl an unterschiedlichen Druckermodellen ist die Installation aller Treiber auf dem RDS-Host nicht zu empfehlen!
Manche Treiber behindern sich gegenseitig, manche sind für den RDS-Einsatz absolut ungeeignet.
Bei meinen Terminalservern habe ich die Problematik durch den Einsatz von Thirdparty-Software gelöst. Schon zu Zeiten von Windows Server 2003 habe ich da verschiedene Software,
wie Thinprint, Tricerat Screwdriver, TS-Print und Slimprinter, ausprobiert.
Mit Druckern, die nur Standardparameter haben und benutzen (wenige Papierformate, Schächte, Auflösungen etc.) schlagen sich eigentlich alle Softwarepakete gleich gut.
Problematischer wird es, wenn z.B. Bondrucker mit exotischen Parametern dazu kommen. Ein weiteres Problem bei Terminalservern mit gemapten Druckern sind die sich bei jeder Anmeldung ändernden Druckernamen.
Es gibt nur eine mir bekannte Software, die all diese Probleme im Blick hat: SLIMPRINTER
a) gezielte Auswahl von in die Session mitzunehmenden Druckern.
b) Drucker mit Standardparametern können einen der zur Software gehörigen Universaltreiber verwenden.
c) Für Drucker mit speziellen Eigenschaften kann der (dann auf dem RDS-Host erforderliche) Originaltreiber verwendet werden
d) die Druckernamen aus dem Namen des lokalen PC's und dem lokalen Druckernamen gebildet.
e) Beim Erstellen der Drucker in der Sitzung wird die ACL des Druckers bearbeitet, so dass dieser nur für Admins und den Benutzer selbst sichtbar ist. Dies erzeugt Übersicht auch bei vielen Usern
Slimprinter kann man mieten oder die Lizenz kaufen (Einmalpreis mit allen Updates und Upgrades, kostenloser Support).
Die downloadbare Version kann für 5 konkurrierende User 20 Tage ohne Einschränkungen getestet werden.
Vielleicht ist das ein Denkanstoss?
Gruß Crazy
Hey, vielen Dank für deine / eure Antworten
Also, wir verbinden die Drucker als Netzwerkdrucker. Vorher bestimmt eine Variable, welcher Maschinenname und damit welchen Standort der Thinclient hat. Dann werden die Drucker verbunden: Hier mal ein Skriptauszug aus einem direkten Maschinenteil, gibts analog auch für weniger granularität also sprich alle PC´s mit pcvw***
if /i %rhgclient% equ pcvw009 (
echo %date% %time% Drucker fuer %rhgclient% installieren
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW001
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW002
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW004
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW008
goto standard
)
Sie Sprungmarke standard führt dann zu dem Bereich in dem entschieden wird, welcher der vier vorher installierten Drucker der Standarddrucker ist.
Die rhgclient-variable ist quasi der clientname von dem aus die RDP Sitzung angetoßen wird. Der rest ist dann recht einfach.
Mein Problem ist eigentlich, dass wir das Skript seit rund 7 Jahren benutzen und der Fehler erst seit einem Jahr besteht.
Wir ersetzen jetzt grad im Moment ALLE Druckertreiber durch die jeweiligen Universaltreiber der Hersteller. (Dank an departure69)
So gibts dann nur noch 5-6 Treiber und nicht 50.
Wir werden heute Mittag wohl damit fertig sein und beobachten dann Morgen bzw. nächste Woche ob die Probleme weiter bestehen. Falls dem so ist, werd ich mich auf dem Markt für Drittanbietersoftware konzentrieren.
Wobei es halt komisch ist, es ging alles einwandfrei und ich will eigentlich am Konzept nix ändern, da das jahrelang gut geklappt hat.
Schönes WE
Also, wir verbinden die Drucker als Netzwerkdrucker. Vorher bestimmt eine Variable, welcher Maschinenname und damit welchen Standort der Thinclient hat. Dann werden die Drucker verbunden: Hier mal ein Skriptauszug aus einem direkten Maschinenteil, gibts analog auch für weniger granularität also sprich alle PC´s mit pcvw***
if /i %rhgclient% equ pcvw009 (
echo %date% %time% Drucker fuer %rhgclient% installieren
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW001
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW002
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW004
rundll32 printui.dll,PrintUIEntry /in /n \\172.16.1.4\DRVW008
goto standard
)
Sie Sprungmarke standard führt dann zu dem Bereich in dem entschieden wird, welcher der vier vorher installierten Drucker der Standarddrucker ist.
Die rhgclient-variable ist quasi der clientname von dem aus die RDP Sitzung angetoßen wird. Der rest ist dann recht einfach.
Mein Problem ist eigentlich, dass wir das Skript seit rund 7 Jahren benutzen und der Fehler erst seit einem Jahr besteht.
Wir ersetzen jetzt grad im Moment ALLE Druckertreiber durch die jeweiligen Universaltreiber der Hersteller. (Dank an departure69)
So gibts dann nur noch 5-6 Treiber und nicht 50.
Wir werden heute Mittag wohl damit fertig sein und beobachten dann Morgen bzw. nächste Woche ob die Probleme weiter bestehen. Falls dem so ist, werd ich mich auf dem Markt für Drittanbietersoftware konzentrieren.
Wobei es halt komisch ist, es ging alles einwandfrei und ich will eigentlich am Konzept nix ändern, da das jahrelang gut geklappt hat.
Schönes WE
1