Hallo Forum, mich wurmt seit geraumer Zeit ein Problem mit den Druckern auf einem Terminal-Server. Dabei sind 3 Netzwerke über VPN miteinander verbunden. In einem Netzwerk steht der Terminal-Server der sowohl die lokalen Drucker, als auch die in den entfernten Netzwerken ansteuern können muss, damit die Leute in den Außenstellen ihre Arbeit ausdrucken können. Obwohl in den Außenstellen IP-Drucker angeschlossen sind, die direkt über das Netzwerk angesteuert werden können, kommt es immer wieder vor, dass die Drucker nicht drucken obwohl die Netzwerkverbindung besteht. Der Terminalserver zeigt die Drucker als Offline an und daran ist auch nichts zu ändern. Lösche ich die Schnittstelle und verbinde den Drucker neu, klappt alles wie es soll. Zwischenzeitlich habe ich den Drucker schon mit lpt3 verbunden und LPT3 via net use Befehl persistent:yes an die entsprechende IP-Adresse umgeleitet. Das Problem bleibt das gleiche "LPT3 getrennt". Neu verbinden geht nicht, nur löschen und neue Verbindung erstellen. Auch nachdem eine neue Verbindung erstellt wurde, gehen die noch anstehenden Druckaufträge nicht raus. Es müssen erst alle Druckaufträge gelöscht werden. Da ich das Problem jetzt sowohl bei den IP-Druckern als auch bei den früher an den lokalen Rechnern via USB angeschlossenen und freigegebenen Druckern habe gehe ich davon aus, dass der Fehler irgend wo bei mir liegt. Aber wo?
Du meinst mir fällt auf die Füße, dass ich im Server-Netzwerk mit 9000er Jumbo-Blocks arbeite? Kann das denn sein? Und wieso funktioniert es dann monatelang und dann plötzlich nicht mehr?
Wie genau hast du die Drucker auf dem TS eingerichtet? Mittels StandardTCP- bzw. LPR-Port? Wenn ja, sind die IP-Adressen eingetragen oder DNS-Namen?
Es sind die IP-Adressen eingetragen, weil ich ja den Namen via VPN im entfernen Netz nicht sehe. also \\192.168.1.13\LP2
tex schrieb: > Es sind die IP-Adressen eingetragen, weil ich ja den Namen via VPN im > entfernen Netz nicht sehe. Das ist schon mal richtig. Mach ich grundsätzlich auch so, weil Namensauflösung zwar prinzipiell möglich ist, aufgrund der Latenzen aber nicht wirklich gut funktioniert. > also \\192.168.1.13\LP2 Ich verstehe immer noch nicht, wie der Drucker auf dem TS installiert ist. Hast du ihn als lokalen Drucker per Standard-TCP/IP-Port eingerichtet oder ist er auf dem entfernten System freigegeben und in der Sitzung als Netzwerkdrucker verbunden?
Ursprünglich war er als Netzwerkdrucker über TCP/IP Port eingebunden. Das hat auch wochenlang super funktioniert. Dann gab es ein bis heute ungeklärtes Phänomen bei einem Client, das dazu führte, dass der Terminalserver neu gestartet wurde. Soweit kein Problem, nur seither kann man auf dem Drucker nur noch drucken, wenn ich ihn neu verbinde. Darum ist er derzeit mit LPT3 verbunden und LPT3 verweist via Net use Befehl auf \\192.168.1.13\LP2 . Das hat den Vorteil das ich über net use lpt3 /delete die Verbindung trennen und dann neu aufbauen kann. Dann nur noch die alten Druckaufträge löschen und schon geht es wieder für eine undefinierte Weile bis wieder erscheint: "LPT3 nicht verbunden" Ich habe den verdacht dass es ein Timing Problem wäre, weil ich etwas Ähnliches bei nahezu allen Rechner habe. Beim hochfahren können die seit XP SP2 nicht mehr die Netzwerklaufwerke verbinden. Ich habe das bei den Clients so gelöst, dass ich die Netzwerkanmeldung durch eine Batch-Datei ausführen lasse nachdem Firefox und Thunderbird gestartet wurden, was natürlich hochgradig unelegant ist, weil in den Batch-Dateien die Netzwerk-Passwörter im Klartext stehen.
Hmm, ihr habt offensichtlich grundsätzliche Probleme mit der Qualität bzw. der Konfiguration des Netzwerkes. Das Verhalten des Druckers ist wahrscheinlich nur ein Symptom davon. Mit Schüssen ins Blaue kommt man hier nicht weiter, da zu viele Ursachen möglich sind. Plötzliches Auftreten von Problemen, ohne daß an der Config was geändert wurde, kann auch auf Schadsoftware hindeuten. Bist du selbst der Admin oder habt ihr einen Dienstleister?
Das Netzwerk läuft soweit sehr stabil. Es sind bloß so nervige Macken, die immer dann auftauchen, wenn Kleinweich mal wieder was verschlimmbessern mußte. Unter WIN2K und WINXP SP1 waren die Netzwerklaufwerke nie ein Thema, egal ob Windows-Freigaben oder Samba-Server. Schadsoftware können wir ausschließen. Desinfec't sagt das System ist sauber. Ich habe ehr den Verdacht, dass es ein Windows-Problem ist. Der Drucker ist ja da, er ist online und er kann angesprochen werden. Windows aber erkennt auf Grund irgend einer Macke, vielleicht wegen einer zu spät kommenden Antwort, dass der Drucker offline ist, ist dann aber von dieser Idee so überzeugt, dass es sich einfach nicht mehr auf eine veränderte Situation einstellen mag. Die Information an sich scheint auch den Druckaufträgen inne zuwohnen, denn wenn man einen deaktivierten Drucker im Windows aktiviert, werden die noch anstehenden Aufträge gedruckt. Hier ist das anders. und ja, ich bin der Admin, sofern man das so nennen darf.
tex schrieb: > Schadsoftware können wir ausschließen. Desinfec't sagt das System ist > sauber. Der war gut. Wenn Desinfec't sagt das System ist sauber, heißt das nur, es hat nichts gefunden. > Ich habe ehr den Verdacht, dass es ein Windows-Problem ist. Ich müßte jetzt nachzählen, wieviele Windows-Netzwerke ich da draußen laufen habe. Aber Probleme dieser Art kann ich nicht bestätigen. hin und wieder treten zwar Druckprobleme auf, die Ursachen liegen aber fast immer in schlechten Treibern oder der Anwendungssoftware begründet. > wenn Kleinweich mal wieder was verschlimmbessern mußte. Gerade im Netzwerk- und Serverbereich hat sich die Stabilität kontinuierlich verbessert. Mit W2K gab es noch regelmäßig Probleme, besonders auf Terminalservern, mit XP/2003 nur noch wenig und seit W7/2008R2 würde ich die Lage als sehr entspannt bezeichnen. Auf den TS funktionieren jetzt sogar Multifunktionsdrucker und dergleichen, die ich vorher nie zum Laufen bekommen habe. > ich bin der Admin Na herzlichen Glückwunsch. Hast du schon versucht, die Drucker ganz einfach als (RDP-) Sitzungsdrucker einzubinden? Das ist eigentlich der Standard und funktioniert recht gut, insofern die passenden Treiber zur Verfügung stehen.
Ich würde einfach mal die Daten von und zum Drucker mitlesen (Wireshark, Microsoft Network Monitor) mitlesen. Der Zustand vom Drucker wird teilweise über SNMP mit ausgewertet. Ich würde das Ursache auch im Netzwerk suchen, Netzwerkdrucker laufen recht sauber unter Windows. Auch wenn der Drucker ausgeschaltet ist und gedruckt wird, dann eingeschaltet wird bekommt Windows recht zeitnah mit und druck selbständig los.
@icke Das mit dem RDP Drucker haut leider nicht hin, weil auch die anderen Teilnehmer aus anderen Netzzweigen auf dem Drucker drucken müssen. Die RDP-Drucker der mobilen Nutzer funktionieren übrigens alle einwandfrei. Nur die Netzwerkdrucker zicken und auch nur, wenn sie aus dem benachbarten Netz vom TS angesprochen werden. Lokal laufen sie und von anderen Rechnern angesprochen laufen sie auch. Darum kann das Problem eigentlich nur beim TS liegen.
tex schrieb: > Da ich das Problem jetzt sowohl bei den IP-Druckern als auch bei den > früher an den lokalen Rechnern via USB angeschlossenen und freigegebenen > Druckern habe gehe ich davon aus, dass der Fehler irgend wo bei mir > liegt. Aber wo? Stehen TCP-Verbindungen zum Druckserver?
oeffne auf den server mal eine command shell und fuehre ipconfig /all aus und poste den ausdruck.
condi schrieb: > oeffne auf den server mal eine command shell und fuehre > > ipconfig /all > > aus und poste den ausdruck. blöde frage, was soll das bringen? Warum sie soll den ständig da sein, sie wird doch nur aufgebaut wenn ein Druckauftrag gesendet wird.
Das Druckerprotokoll LPR arbeitet mit UDP, also "verbindungslos" - könnte das ein Problem sein? Irgend ein Router nicht sauber eingestellt? VPN vlt. doch nicht so "transparent" wie angenommen?
Peter II schrieb: > condi schrieb: >> oeffne auf den server mal eine command shell und fuehre >> >> ipconfig /all >> >> aus und poste den ausdruck. > > blöde frage, was soll das bringen? > > Warum sie soll den ständig da sein, sie wird doch nur aufgebaut wenn ein > Druckauftrag gesendet wird. Idealerweise faengt man an einem Ende an zu suchen und stochert nicht in der Mitte rum. Da die anderen Rechner immer drucken koennen, liegt es wohl an dem Server. Ich tippe mal auf den Knotentyp, sowas und auch andere notwendige Sachen sieht man nunmal bei ipconfig ganz gut.
condi schrieb: > Idealerweise faengt man an einem Ende an zu suchen und stochert nicht in > der Mitte rum. Da die anderen Rechner immer drucken koennen, liegt es > wohl an dem Server. Ich tippe mal auf den Knotentyp, sowas und auch > andere notwendige Sachen sieht man nunmal bei ipconfig ganz gut. aus dem Grund würde ich das Netzwerk mitlesen.
tex schrieb: > Darum kann das Problem eigentlich nur beim TS liegen. Würde ich nicht behaupten. Die Druckdaten können durchaus auch beim Routing zwischen den Netzen blockiert werden. Steht irgendwas in der Ereignisanzeige? Wasassiert, wenn du anstatt den Drucker neu zu verbinden, den Druckwarteschlangendienst auf dem TS neustartest?
Ich habe hier nur RDP Drucker. Kann man diese im TS freigeben? Evtl. Kann man so auf verbundene entfernte RDP Drucker drucken? Vielleicht eine andere Möglichkeit?
Jörg Esser schrieb: > Ich habe hier nur RDP Drucker. Kann man diese im TS freigeben? Das macht keinen Sinn, weil die am Sitzungsende gelöscht werden. Wenn Freigabe, dann am Client-PC, wo der Drucker lokal installiert ist. Generell bin ich kein Freund von Druckerfreigaben. Als Behelf im Heimnetzwerk mag es OK sein, aber in professionellen Netzen ist die Verwendung von Printservern der bessere Weg.
Icke ®. schrieb: > Als Behelf im > Heimnetzwerk mag es OK sein, aber in professionellen Netzen ist die > Verwendung von Printservern der bessere Weg. was meinst du mit Printservern? Ein Windows Server mit Freigabe bestimmt nicht oder? Freigaben haben den Vorteil das man Rechte für Drucker vergeben kann. Auch die Übersicht der Druckerwarteschlange geht nur wenn es über eine Freigabe läuft (nicht das ein andere Mitarbeiter gerade 10.000 Seiten druckt und man warten auf sein Dokument). Habe mit Freigaben noch nie Probleme gehabt.
Icke ®. schrieb: > Jörg Esser schrieb: >> Ich habe hier nur RDP Drucker. Kann man diese im TS freigeben? > > Das macht keinen Sinn, weil die am Sitzungsende gelöscht werden. Wenn > Freigabe, dann am Client-PC, wo der Drucker lokal installiert ist. > Generell bin ich kein Freund von Druckerfreigaben. Als Behelf im > Heimnetzwerk mag es OK sein, aber in professionellen Netzen ist die > Verwendung von Printservern der bessere Weg. Stimmt sie werden gelöscht. Denkfehler. Professionell ist wenns funktioniert ;)
Peter II schrieb: > was meinst du mit Printservern? Ein Windows Server mit Freigabe bestimmt > nicht oder? Natürlich nicht. Unter Printserver verstehe ich die kleinen Boxen, die den Drucker direkt ans Netzwerk anbinden und per Raw-IP oder LPR angesprochen werden. Inzwischen haben die meisten Drucker, sogar im Consumerbereich, bereits eingebaute "Printserver". > Freigaben haben den Vorteil das man Rechte für Drucker vergeben kann. Die Rechte kann ich auch dort vergeben, wo der Drucker installiert ist.
:
Bearbeitet durch User
Icke ®. schrieb: > Die Rechte kann ich auch dort vergeben, wo der Drucker installiert ist. nur dumm das jeder sich einen neuen Drucker einrichten kann und damit das Rechtesystem aushebelt.
Peter II schrieb: > nur dumm das jeder sich einen neuen Drucker einrichten kann und damit > das Rechtesystem aushebelt. Das kann keineswegs jeder, außer er verfügt über Administratorrechte. Oder er verbindet sich zu einem freigegebenen Drucker.
Icke ®. schrieb: > Das kann keineswegs jeder, außer er verfügt über Administratorrechte. nein, da der Treiber und die Port schon vorhanden ist kann es jeder Nutzer.
Läuft der Server in einer VM? Da gibt es das öfter. Gibt es die Probleme nur, wenn der Druckauftrag über das VPN läuft oder kommt es auch vor, wenn der Druckauftrag im lokalen Netz bleibt?
ist ICMP blockiert? Path-MTU-Discovery abgeschaltet? 95% der Druckerprobleme über VPN/TS haben mit der MTU zu tun. Versuch mal in ping mit 1500 Byte vom Server zum Drucker zu machen.
1500 Byte Packet Size nicht Payload Size. Allenfalls musst du bei der Angabe den TCP und ICMP-header abziehen.
Angehängte Dateien:
-
drucker.jpg
30 KB
Peter II schrieb: > nein, da der Treiber und die Port schon vorhanden ist kann es jeder > Nutzer. Und abermals nein, der eingeschränkte User kann es nicht. Versucht er es (siehe Bild), muß er im nachfolgenden Dialogfeld Name und Kennwort eines Administrators eingeben.
@EMV Bis 500 Byte geht alles auber durch. Bei mehr als 500 Byte ist schluss mit lustig Bei 1500 Byte beklagt er sich, dass die Daten fragmentiert werden müßten. Wenn das das Problem ist, wie sieht die Lösung aus?
Icke ®. schrieb: > Und abermals nein, der eingeschränkte User kann es nicht. Versucht er es > (siehe Bild), muß er im nachfolgenden Dialogfeld Name und Kennwort eines > Administrators eingeben. kann ich nicht nachvollziehen, Unter Win7 (ohne Domaine) kann ein lokalen Benutzer nur mit "Benutzer" Rechten einen lokalen Drucker einrichten. Sonst würde auch keine USB Drucker ohne Admin funktionieren.
Peter II schrieb: > Unter Win7 (ohne Domaine) kann ein > lokalen Benutzer nur mit "Benutzer" Rechten einen lokalen Drucker > einrichten. Eben probiert, auf einem Einzelplatzrechner geht es.
Daraus lässt sich nichts ableiten. Warum sollte der Drucker auf große Pings reagieren? Warum funktioniert es dann nach dem löschen und neu einrichten? Schickt der Server dann die Druckjob erstmal in kleinen Häppchen und dann nur noch in großen Paketen? Hast du schon mal den Haken bei SNMP- Status aktiviert unter den Anschlusseinstellungen deaktiviert? Welcher Netbios Knotentyp wird verwendet?
na Icke, bist ja wieder voll dabei: Dein Kommentar" > Na herzlichen Glückwunsch. Hast du schon versucht, die Drucker ganz > einfach als (RDP-) Sitzungsdrucker einzubinden? Das ist eigentlich der > Standard und funktioniert recht gut, insofern die passenden Treiber zur > Verfügung stehen. " Tolle Wurst. Mach das mal mit 50 Usern inkl. lokaler Drucker um Netzwerk ! Das dann noch auf 4 TS, und der Admin hat einen Fulltimejob. Viel Spaß dabei ! Aber wer Viren ohne Antivirensoftware killen kann, der kann auch das. SOOOO nicht ! IP Drucker gehören in das AD und nicht in die RDP Sitzung.. PUNKT Wenn dem TO/TE etwas hilft, ist es ein Druckserver auf dem TS. Der spoolt bis die Verbindung wieder da ist. Gerade und vor allem, wenn der TS in der Wolke steht. Der Rest ist reine Glaskugelkuckerei. Ohne Protokolle ....? Ich sehe noch nicht einmal wie das VPN realisiert wird. VPN Router, oder Router mit VPN Pass True, oder, oder oder,.....
:
Bearbeitet durch User
Stephan Henning schrieb: > Tolle Wurst. Mach das mal mit 50 Usern inkl. lokaler Drucker um Netzwerk > Das dann noch auf 4 TS, und der Admin hat einen Fulltimejob. ??? Der Admin installiert einmalig die passenden Treiber für alle vorhandenen Drucker auf den Terminalservern, das wars. Kein abendfüllendes Programm. > IP Drucker gehören in das AD und nicht in die RDP Sitzung.. PUNKT Hehe, Glückwunsch, ich stimme dir 100%ig zu! Nur funktioniert das hier eben nicht richtig, weil der Drucker in einem entfernten VPN-Netz steht und die Verbindung, aus welchen Gründen auch immer, regelmäßig abkackt. Mit den RDP-Sitzungen scheint jedoch alles OK zu sein, daher wäre es einen Versuch wert, die Druckerei ebenfalls über RDP abzuwickeln. > Der Rest ist reine Glaskugelkuckerei. Allerdings, das habe ich weiter oben schon bemerkt. Zumal mit dem Netz einiges nicht zu stimmen scheint.
Stephan Henning schrieb: > Ich sehe noch nicht einmal wie das VPN realisiert wird. > VPN Router, oder Router mit VPN Pass True, oder, oder oder,..... Rein theoretisch dürfte das doch vollkommen egal sein, funktionieren sollte es doch immer. Oder?
Das Netz geht auch, sonst würde RDP nicht klappen. Außerdem scheinen die Clients ja keine Probleme beim drucken zu haben. AD scheint es nicht zu geben, sonst gaebe es auch mindestens einen brauchbaren DNS Server.
für eine fundierte Aussage sind hier einfach zu wenige Fakten bekannt. Das RDP funktioniert heißt nicht automatisch daß das Netzwerk i.O. ist. RDP auf einem Server in der Wolke kann auch ein PC per DSL Modem an der Telekomdose.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.