7
Druckkonzeption für Terminalserver mittels einer virtuellen Maschine
Gerade im Bereich Terminalserver gibt es immer wieder Probleme mit dem Drucken.
Hervorgerufen wird dieses Problem duch viele fehlerhafte Treiber. Dadurch stürzt der TS
im ungünstigsten Fall beim Spoolen samt der Sessions ab.
Dieser Beitrag, ist ein grober Tip, mitels der Virtualisierung dieses Problem zu minimieren.
1. Alle Drucker, auch die einfachen Desktopdrucker, bekommen einen extra Hardware-
Printerserver und erhalten dadurch eine separate IP im Netz.
2. Einrichtung einer VM, respektive VMware, als OS reicht eine alte Windows2000-Lizenz
schon aus. Vista würde auch gehen, aber aufgrund der Gesamtproblematik mit dem
OS nicht unbedingt zu empfehlen und daher auch nicht getestet.
3. An dieser VM werden die Drucker per IP fest installiert.
4. Die TS-Sessions greifen zum Drucken immer auf die Drucker zu, die in dieser VM
installiert sind zu. Diese müssen natürlich für die TS-Session vorher eingerichtet werden.
Vorteile:
- Es muss kein Drucker auf dem TS installiert werden und gespoolt wird über die VM.
- Geht ein Druck kpl. daneben, stürzt der TS im ungünstigsten Fall mit Sessions nicht
gleich ab.
- Sogar Rettungsversuche, bei höherwertigen und aufwendigeren Drucken mittels
Postscript, ist damit halbwegs gewährleistet, da die Spooldateien separiert werden
können.
- Bei Einrichtung der VM mit einem Server-OS, Windows Server 2000-2008 entfällt die
Grenze mit den 10 gleichzeitigen Usern.
Nachteile:
- Nur bis zu 10 User können gleichzeitig darauf zugreifen (gilt nur für OS, W2k-XP).
- Geschwindigkeitseinbußen bei Desktop-Druckern, durch die indirekte Ansteuerung,
ist natürlich von der Hardware des Printerservers abhängig.
Anmerkung:
Dieses Verfahren läuft im Einsatz unter Firmenbedingungen mit
TS Svr2003 R2 Standard in einem Domänenverbund.
Hervorgerufen wird dieses Problem duch viele fehlerhafte Treiber. Dadurch stürzt der TS
im ungünstigsten Fall beim Spoolen samt der Sessions ab.
Dieser Beitrag, ist ein grober Tip, mitels der Virtualisierung dieses Problem zu minimieren.
1. Alle Drucker, auch die einfachen Desktopdrucker, bekommen einen extra Hardware-
Printerserver und erhalten dadurch eine separate IP im Netz.
2. Einrichtung einer VM, respektive VMware, als OS reicht eine alte Windows2000-Lizenz
schon aus. Vista würde auch gehen, aber aufgrund der Gesamtproblematik mit dem
OS nicht unbedingt zu empfehlen und daher auch nicht getestet.
3. An dieser VM werden die Drucker per IP fest installiert.
4. Die TS-Sessions greifen zum Drucken immer auf die Drucker zu, die in dieser VM
installiert sind zu. Diese müssen natürlich für die TS-Session vorher eingerichtet werden.
Vorteile:
- Es muss kein Drucker auf dem TS installiert werden und gespoolt wird über die VM.
- Geht ein Druck kpl. daneben, stürzt der TS im ungünstigsten Fall mit Sessions nicht
gleich ab.
- Sogar Rettungsversuche, bei höherwertigen und aufwendigeren Drucken mittels
Postscript, ist damit halbwegs gewährleistet, da die Spooldateien separiert werden
können.
- Bei Einrichtung der VM mit einem Server-OS, Windows Server 2000-2008 entfällt die
Grenze mit den 10 gleichzeitigen Usern.
Nachteile:
- Nur bis zu 10 User können gleichzeitig darauf zugreifen (gilt nur für OS, W2k-XP).
- Geschwindigkeitseinbußen bei Desktop-Druckern, durch die indirekte Ansteuerung,
ist natürlich von der Hardware des Printerservers abhängig.
Anmerkung:
Dieses Verfahren läuft im Einsatz unter Firmenbedingungen mit
TS Svr2003 R2 Standard in einem Domänenverbund.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 120275
Url: https://administrator.de/contentid/120275
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
7 Kommentare
Neuester Kommentar
Ohne Dir jetzt zu nahe treten zu wollen, aber hast Du schon mal an einen Druckserver unter Linux gedacht?
- keine Userbeschränkung
- auch kein Abstürzen
- keine Extra-Lizenzkosten
So macht unsere Firma das zumindest...
Lonesome Walker
- keine Userbeschränkung
- auch kein Abstürzen
- keine Extra-Lizenzkosten
So macht unsere Firma das zumindest...
Lonesome Walker
Hallo Lonesome Walker,
ohne Dir jetzt zu nahe treten zu wollen, hast du schon mal über eine Uniform Operating Environment nachgedacht?
- kein Patchmanagement für einen ansonsten nutzlosen Linux-Host
- keine Notwendigkeit für zusätzliche Expertise
- kein zusätzlicher Backup Agent
So denk ich über deinen Einwand.
Grüße, Steffen
ohne Dir jetzt zu nahe treten zu wollen, hast du schon mal über eine Uniform Operating Environment nachgedacht?
- kein Patchmanagement für einen ansonsten nutzlosen Linux-Host
- keine Notwendigkeit für zusätzliche Expertise
- kein zusätzlicher Backup Agent
So denk ich über deinen Einwand.
Grüße, Steffen
- Patchmanagement wenn Druckserver im Intranet liegt ist _sehr_ aufwändig weil unnötig
- Backup-Agent läßt sich auf File-Ebene mit bissel Shell-Scripting erledigen, und das ganze dann als SMB-Share zur Verfügung stellen
Summa summarum einen Haufen Zeit und Geld gespart.
(setzt allerdings Wissen im Bereich Unix voraus; ich weiß, sowas ist für viele Admins einfach too much...)
Lonesome Walker
- Backup-Agent läßt sich auf File-Ebene mit bissel Shell-Scripting erledigen, und das ganze dann als SMB-Share zur Verfügung stellen
Summa summarum einen Haufen Zeit und Geld gespart.
(setzt allerdings Wissen im Bereich Unix voraus; ich weiß, sowas ist für viele Admins einfach too much...)
Lonesome Walker
Du verstehst es wirklich nicht? Warum soll zusätzliches Unix-Knowhow bemüht werden, wenn es doch auch ohne geht (für ein 'bissel Shell-Scripting' nehmen die meisten - zu recht - Geld)?
Grüße, Steffen
Nachtrag:
Wie sparst du Zeit beim zusätzlich notwendigen Scripten?
Grüße, Steffen
Nachtrag:
Wie sparst du Zeit beim zusätzlich notwendigen Scripten?
@lonesome Walker, Diese Konzeption kann durchaus auch mit einem Linux OS funktionieren, falls man wegen der häufig fehlenden Treiber Zeit und Kosten mit extra Scripten etc. verbringen möchte.
Das Problem indes kann gerade zwischen der Windows- und der Linux Umgebung liegen. Hetrogene Netzumgebungen haben so ihre Tücken. Ganz zu schweigen von dem Gefrickel mit Samba. Wir nutzen auch verschieden Linux-Devirate, aber für andere Einsatzzwecke.
Die Debatte Linux und/oder Windows ist grotesk. Beide Systeme können sich ergänzen, müssen es aber nicht in
jedem Fall.
Interessehalber würde ich aber gern von Dir ein Konzept mit einem Linux-Devirat hier gern erfahren.
Dieser Tip bezieht sich ausschließlich auf ein homogenes Windows TS und Client-Konzept.
Über Scipting-Fähigkeiten zu debattieren gibt es andere Unterforen.
Das Problem indes kann gerade zwischen der Windows- und der Linux Umgebung liegen. Hetrogene Netzumgebungen haben so ihre Tücken. Ganz zu schweigen von dem Gefrickel mit Samba. Wir nutzen auch verschieden Linux-Devirate, aber für andere Einsatzzwecke.
Die Debatte Linux und/oder Windows ist grotesk. Beide Systeme können sich ergänzen, müssen es aber nicht in
jedem Fall.
Interessehalber würde ich aber gern von Dir ein Konzept mit einem Linux-Devirat hier gern erfahren.
Dieser Tip bezieht sich ausschließlich auf ein homogenes Windows TS und Client-Konzept.
Über Scipting-Fähigkeiten zu debattieren gibt es andere Unterforen.
Zitat von @51705:
Wie sparst du Zeit beim zusätzlich notwendigen Scripten?
Wie sparst du Zeit beim zusätzlich notwendigen Scripten?
Zeitverhältnis Installation Windows XP zu Linux (Debian): ungefähr 2:1 (wenn nicht sogar mehr...)
Thema Imaging lasse ich nicht gelten, denn das geht mit Linux auch... (dann steht es zumindest hier 1:1)
Das Shell-Script, die notwendigsten Daten für einen Printserver zu sichern, und die auf einem Samba-Share zur Verfügung zu stellen, hat man i.d.R. in 30 Minuten zusammengestellt.
Eine aktuelle XP-Lizenz (wenn man mit der User-Beschränkung leben kann... *sehr professionell* ) kostet meines Wissens noch immer um die 100 Euro... von der Server-Lizenz, welche im Enterprise-Umfeld aber wohl zum Einsatz kommen sollte, wollen wir jetzt gar nicht mal reden...
Du siehst, alleine der finanzielle Aufwand für gleiche Leistung ist ungleich höher...
Vom administrativen Aufwand halten sich beide im Enterprise-Umfeld die Waage, denn man hat da ja meist zentrales Patch-Management, und bei Linux einmal im Monat (oder wann auch immer) ein Update laufen zu lassen ist genauso langweilig.
(nein, lustigerweise gehöre ich zu den wenigen Admins, die bisher noch keine nennenswerten Stillstände nach Updates von Kernel oder sonstigen unternehmenskritischen Applikationen wie z.B. Postfix hatten...)
@bartlebi:
es war kein Vorwurf gegen Dein Lösungs-Szenario!
Übrigens hinkt Dein Vergleich mit Shell-Skripting wegen Treiber-Problemen mit der Hardware, weil...?
Röchtöch, wir haben ja virtualisiert... *kopfschüttel*
(oder zielst Du auf das Feature "kein Drucker-Treiber auf Client" ab...? Bei einem Terminal-Server? Im Enterprise-Bereich? Office?)
Vielmehr sollte es ein Wink mit dem Zaunpfahl sein, wenn man schon mit Virtualisierung arbeitet, um das Thema Druck und Terminal abzufackeln, dann evtl. auch so, wie es viele Manager von ihrer IT-Abteilung immer haben wollen: UMSONST
Aber nachdem es nach wie vor sehr viele Administratoren wie srmerlin gibt, werden wir wohl weiterhin in einer heterogenen IT-Landschaft leben, in der manche Administratoren mehr Ausfälle haben, als andere *g*
Ich will hier keinen zu Linux bekehren, dazu gibt es zu viele Unterschiede, zu große KnowHow-Lücken bei vielen Admins...
Aber für jene, welche bereits Erfahrung im Linux-Umfeld gesammelt haben, ist es sicherlich ein sehr interessanter Anreiz, Dein Lösungs-Szenario der "Absturz-Sicherheit" mit der Freiheit von einem Linux-Druckserver zu kombinieren.
Lonesome Walker
Zitat von @16568:
@bartlebi:
es war kein Vorwurf gegen Dein Lösungs-Szenario!
Übrigens hinkt Dein Vergleich mit Shell-Skripting wegen
Treiber-Problemen mit der Hardware, weil...?
Röchtöch, wir haben ja virtualisiert...
*kopfschüttel*
(oder zielst Du auf das Feature "kein Drucker-Treiber auf
Client" ab...? Bei einem Terminal-Server? Im Enterprise-Bereich?
Office?)
Aber für jene, welche bereits Erfahrung im Linux-Umfeld
gesammelt haben, ist es sicherlich ein sehr interessanter Anreiz, Dein
Lösungs-Szenario der "Absturz-Sicherheit" mit der
Freiheit von einem Linux-Druckserver zu kombinieren.
Lonesome Walker
@bartlebi:
es war kein Vorwurf gegen Dein Lösungs-Szenario!
Übrigens hinkt Dein Vergleich mit Shell-Skripting wegen
Treiber-Problemen mit der Hardware, weil...?
Röchtöch, wir haben ja virtualisiert...
*kopfschüttel*
(oder zielst Du auf das Feature "kein Drucker-Treiber auf
Client" ab...? Bei einem Terminal-Server? Im Enterprise-Bereich?
Office?)
Aber für jene, welche bereits Erfahrung im Linux-Umfeld
gesammelt haben, ist es sicherlich ein sehr interessanter Anreiz, Dein
Lösungs-Szenario der "Absturz-Sicherheit" mit der
Freiheit von einem Linux-Druckserver zu kombinieren.
Lonesome Walker
Das habe ich auch nicht so aufgefasst, allerdings würde ich einen sachlichen Dialog ohne "Röchtöch" bevorzugen.
Auch wenn ein OS virtualisiert ist, gibt es für etliche
Drucker nicht immer die passenden Treiber für ein Linux dafür und genau da liegt das Problem. Fairerweise muss
man sagen, dass es aber schon erheblich besser geworden ist. Leider kommen im zwei Wochen Takt
neue Drucker auf den Markt, wobei nicht immer Linux-Treiber vorhanden sind. Warum wohl ?
Noch hat MS immer noch einen Marktanteil von 90 %
plus x.
Natürlich ist ein virtueller Printer Server auf Linux Basis
eine höchst interessante Alternative und wenn dieser
virtualisiert ist kann man das Patchmanagment außen
vor lassen. Warum auch, soll ja nur mit dieser Funktion arbeiten.
Wir haben mehrere verschiedene Linux-Devirate mit unterschiedlichen Server-Diensten im Einsatz.
Nach wie vor denke ich, dass hetrogene Netzumgebungen
immer noch zum Repertoire der meisten Firmen gehören.
Um auf einen Konsens zu kommen, ist eines doch zu
sehen, dass Mircrosoft gerade durch Linux immer
mehr im Bereich der Serverdienste an Boden verliert.
Die Zuverlässigkeit und Sicherheit bei z.B. einem reinen MySql-Srv. unter einem Debian-System möchte ich nicht
mehr missen.
Das Werben für Linux kann ich von meiner Seite
aus nur unterstützen, nur nicht den zuweilen manischen Zwang einiger typischen Linux-Admins zum exessiven
Scipting um jeden Preis.
