TS Printer redirection (Windows 2003 Server)

[Verwijderd]

Ik ben bezig met een project om 5 winkels met elk 2 thin clients te laten werken op een Windows 2003 Server via Terminal Services. (staat op een externe locatie)

Op de server draait een op ms-dos gebasseerd pakket. Op elke thin client zit een HP Laserjet 1300 printer aangesloten waarop lokaal geprint dient te worden.

Het mappen van de printers in Windows is geen probleem, alleen het printen vanuit de ms-dos applicatie wil maar niet werken.

Ik heb inmiddels al verschillende documenten geraadpleegd bij microsoft, maar nergens staat er iets over printen vanuit een ms-dos applicatie vanuit een TS-sessie.

Aangezien TS-sessie's gebruik maken van TSxxx poorten is het volgens mij niet mogelijk deze poorten makkelijk te mappen. Omdat het om thin clients gaat kan je ook niet even makkelijk een printer aan de client kant delen zodat deze benaderbaar is vanaf de server. Het bijkomde probleem is dat de TS-poorten ook nog eens variabel zijn. (dus niet elke winkel heeft een vaste TSxxx poort)

Heeft iemand hier ervaring mee?

PS. Citrix is voor ons geen optie vanwege de bijkomende kosten.

[seq_uence]

Citrix (XP) kan inderdaad je probleem oplossen.

Maar heb je al een lpt mapping in de sessie geprobeerd ?

Dus net use lpt1: \\server\printer ?

Printen vanuit een DOS applicatie in een terminal server omgeving is vaak erg lastig, er bestaat dus een redelijke kans dat dit niet gaat werken, of je moet toch Citrix gaan inzetten.

edit:

Had even gemist dat het om een thin client gaat, een andere optie is om toch pc's in te zetten en dan de printer te sharen.

[ Voor 18% gewijzigd door seq_uence op 20-11-2003 20:41 ]

[Verwijderd]

Omdat het hier om winkels in Duitsland gaat zijn Pc's voor mij geen optie. (ik heb namelijk geen zin om die mensen steeds aan de telefoon te hebben met een of ander windows probleem.)

Mappen heb ik ook geprobeerd, maar dit wil met een Thin Client nietecht lukken.
Het lijkt me toch dat meer mensen met hetzelfde probleem zitten, of kiezen die dan allemaal voor Citrix? (dan zou je dus dubbele licentiekosten hebben alleen vanwege het printen.....kan toch niet de bedoeling zijn.)

Volgens mij voegt Citrix nietecht meer veel meerwaarde toe ten opzichte van Windows 2003 TS.

[seq_uence]

Verwijderd schreef op 24 november 2003 @ 13:24:
Volgens mij voegt Citrix nietecht meer veel meerwaarde toe ten opzichte van Windows 2003 TS.

Citrix voegt heel veel toe aan Windows 2003 met terminal services, de vraag is alleen of je het nodig hebt......

Klik ff voor een overzicht van de verschillen:

http://www.thinworkplace.com/mfxpw2k3comp.pdf

[StevenK]

Ik heb eigenlijk nog nooit problemen gehad met printen vanuit DOS app's.

Maar dat was dan wel naar een netwerkprinter, dus ik weet niet of jouw probleem niet daar ligt ?

Heb je al getest of het wel werkt als je die printer aan een printserver hangt ?

[Verwijderd]

Ik heb een paar vragen en een antwoord.

- Hoe bouw je die verbinding op? Firewalls, vpn, ??.
- Heb je een apart printserver tot je beschiking?

- Voor de kosten zou je i.p.v. Citrix ook kunnen kiezen voor HOBlink met Xpert licences, kijk maar eens op www.hob.nl, op deze manier hebben wij het perfect werken.

[Verwijderd]

De TS sessie gaat niet via een VPN, maar direct naar poort 3389.
Ik heb geen printservers tot mijn beschikking, maar ik vraag me ook af wat dit uitmaakt. Het maakt toch niet uit of het een mapping is naar een lokale of een netwerkprinter?

Ik blijf met het probleem zitten dat ik niet kan printen naar een TSxxx poort. LPT's eraan hangen heeft volgens mij ook een beperking tot LPT9, of zeg ik nou iets raars? Aangezien ik er 10 nodig heb, heb ik aan LPT's dan tekort.

Een 2e pakket er bovenop installeren doe ik liever ook niet, ....het moet toch op een of andere manier op te lossen zijn zonder extra software.

[seq_uence]

offtopic:
Even voor mijn beeldvorming, heb je de terminal servers direct aan het internet hangen ? Zo ja, dan heb je toch een behoorlijk security probleem.

[StevenK]

Verwijderd schreef op 24 november 2003 @ 15:19:
De TS sessie gaat niet via een VPN, maar direct naar poort 3389.
Ik heb geen printservers tot mijn beschikking, maar ik vraag me ook af wat dit uitmaakt. Het maakt toch niet uit of het een mapping is naar een lokale of een netwerkprinter?

Ja dat maakt heel veel uit: in het éne geval moet er geredirect worden naar een lokale poort op je thin client (die waarschijnlijk onder Windows CE werkt, en daardoor geen echte LPT: poort kent), in het andere geval heb je op je server een queue die direct naar een lokale poort wijst.

Daarnaast ben je dan ook niet afhankelijk van die client voor het printen.

[StevenK]

seq_uence schreef op 24 november 2003 @ 15:54:

offtopic:
Even voor mijn beeldvorming, heb je de terminal servers direct aan het internet hangen ? Zo ja, dan heb je toch een behoorlijk security probleem.

Want ?

[RedRose]

StevenK schreef op 24 november 2003 @ 16:01:
[...]

Ja dat maakt heel veel uit: in het éne geval moet er geredirect worden naar een lokale poort op je thin client (die waarschijnlijk onder Windows CE werkt, en daardoor geen echte LPT: poort kent), in het andere geval heb je op je server een queue die direct naar een lokale poort wijst.

Daarnaast ben je dan ook niet afhankelijk van die client voor het printen.

Dat is het probleem ook niet. Het DOS-programma staat op de server en die LPTx poort (van de server dus) moet gemapped worden naar de thin-client, zodat daar lokaal geprint kan worden vanuit dat programma. (ala net use LPTx:\\<printer>/<host>/<session>)

Het probleem is dat je vrijwel altijd per sessie dynamisch een nieuwe TSxxx poort krijgt met een daarbijbehorende queue (<printer>/<host>/<session>). De vraag is of dat dan ook weer dynamisch te mappen is naar de eerste vrije LPT-poort op de server. Waarschijnlijk ontkom je niet aan een script of 3d-party software.

[ Voor 4% gewijzigd door RedRose op 24-11-2003 17:27 ]

[Verwijderd]

StevenK schreef op 24 november 2003 @ 16:02:
Want ?

http://www.printingsupport.com/tools/hackingcitrix.txt

(voor de verschrikte modjes; het is een doc over wat je dicht moet zetten op citrix, niet over hoe je het open breekt)

[ Voor 27% gewijzigd door Verwijderd op 24-11-2003 21:46 ]

[SED]

Verwijderd schreef op 24 november 2003 @ 21:44:
[...]

http://www.printingsupport.com/tools/hackingcitrix.txt

(voor de verschrikte modjes; het is een doc over wat je dicht moet zetten op citrix, niet over hoe je het open breekt)

Ik vermoed datr niet hier op gewezen werd.
Citrix en Terminal server zijn in die zin net zo veilig/onveilig.

terminal server draait standaards met 128 bit encryptie en dat is voor internet niet echt veilig.
Service pack 1 ( komt eraan) voegt daar ssl aan toe en dan zit je behoorlijk veilig.


Voor printen onder dos kijk bijv hier:

Keep client printer mappings

The terminal server has a way of losing the printer mappings for client printers, especially when you need these mapped to actual LPTx: ports. Here's the key to making this work:

1. You MUST have Active Directory installed and functioning on the Terminal Server machine. Odd, but true.

2. Set up File & Print sharing on your client computer, and share out your printer with the name you wish to use.

3. Log into the terminal server, and verify that you can see your printer in the Printers folder (Start, Settings, Printers). Right click on it, Sharing, and make sure it is shared with the proper name.

4. If you need LPTx: port mapping, go into DOS (Start, Programs, Accessories, Command Prompt), then type in:

net use lpt1: \\servername\printersharename

Example: net use lpt1: \\mainserv\okidata

5. Now exit the dos box, and log off the terminal server. It is critical that the share exist when you log off - this will cause it to "stick" once you log back on again.

You may also want to reinforce this a little more, with a login script that first releases the mapping (with something like: net use lpt1: /delete), then tries to map it (with the command in step 4 above). If that command fails, keep retrying until it works. I've seen Windows sometimes take up to a minute retrying this, but then it finally "takes". Definitely a very strange operating system!

[StevenK]

SED schreef op 24 november 2003 @ 23:47:
Voor printen onder dos kijk bijv hier:
[...]

Dat gaat nogal lekker met een thin client ?

[StevenK]

Verwijderd schreef op 24 november 2003 @ 21:44:
[...]

http://www.printingsupport.com/tools/hackingcitrix.txt

(voor de verschrikte modjes; het is een doc over wat je dicht moet zetten op citrix, niet over hoe je het open breekt)

Mooi verhaal, maar niet echt relevant: als jij een TS oplossing achter een firewall draait, met 3389 alleen maar open voor de ip-adressen van je clients, *en* je hebt een serieuze security policy voor passwords etc komt er nooit iemand op een illegale manier in, laat staan dat ze in een admin-context binnenkomen.

Wil je het nog veiliger, dan implementeer je een RSA SecurID oplossing op de TS doos en dan zit het volledig dicht.

[Verwijderd]

RedRose schreef op 24 november 2003 @ 17:23:
[...]
Dat is het probleem ook niet. Het DOS-programma staat op de server en die LPTx poort (van de server dus) moet gemapped worden naar de thin-client, zodat daar lokaal geprint kan worden vanuit dat programma. (ala net use LPTx:\\<printer>/<host>/<session>)

Het probleem is dat je vrijwel altijd per sessie dynamisch een nieuwe TSxxx poort krijgt met een daarbijbehorende queue (<printer>/<host>/<session>). De vraag is of dat dan ook weer dynamisch te mappen is naar de eerste vrije LPT-poort op de server. Waarschijnlijk ontkom je niet aan een script of 3d-party software.

Inderdaad je snapt goed wat het probleem is. Alleen nu hoop ik natuurlijk nog dat iemand er een oplossing voor heeft zonder gebruik te maken van 3d-party software.

Wat betreft het beveiligingsverhaal......password policy zit wel snor. (8 willekeurige onlogische tekens, alle karakters die je maar kan bedenken) Server zit achter een firewall en is alleen te bereiken op poort 3389.

[seq_uence]

StevenK schreef op 25 november 2003 @ 08:27:
[...]

Mooi verhaal, maar niet echt relevant: als jij een TS oplossing achter een firewall draait, met 3389 alleen maar open voor de ip-adressen van je clients, *en* je hebt een serieuze security policy voor passwords etc komt er nooit iemand op een illegale manier in, laat staan dat ze in een admin-context binnenkomen.

Wil je het nog veiliger, dan implementeer je een RSA SecurID oplossing op de TS doos en dan zit het volledig dicht.

offtopic:
Ik zou eerder een Secure Gateway neerzetten, en die als SSL gateway (poort 443) tussen de ICA client en de Metaframe server laten functioneren. Als je dan ook nog gebruik maakt van een Nfuse webserver en voor aanmelden gebruikt maakt van een token is het echt goed secure.

[StevenK]

seq_uence schreef op 25 november 2003 @ 14:52:
[...]

offtopic:
Ik zou eerder een Secure Gateway neerzetten, en die als SSL gateway (poort 443) tussen de ICA client en de Metaframe server laten functioneren. Als je dan ook nog gebruik maakt van een Nfuse webserver en voor aanmelden gebruikt maakt van een token is het echt goed secure.

Voor CSG heb je geen NFuse nodig, maar wel een batterij servers (en licenties). Het is daarom een veel duurdere oplossing en niet echt te vergelijken met een enkele TS.

Het is wel een fantastische manier van werken, overigens.

[Verwijderd]

StevenK schreef op 25 november 2003 @ 08:27:
Mooi verhaal, maar niet echt relevant: als jij een TS oplossing achter een firewall draait, met 3389 alleen maar open voor de ip-adressen van je clients.

Blijkbaar heb jij beschikking over een firewall met de capaciteiten op ip security op te zetten. (dat is toch vpn?) Niet iedreen heeft dat, en zet gewoon poort 3389, of 1494 open, en dat heeft consequenties. Niks meer en niks minder.

[seq_uence]

StevenK schreef op 25 november 2003 @ 14:57:
[...]

Voor CSG heb je geen NFuse nodig, maar wel een batterij servers (en licenties). Het is daarom een veel duurdere oplossing en niet echt te vergelijken met een enkele TS.

Het is wel een fantastische manier van werken, overigens.

Volgens mij heb je er maar 1 extra server voor nodig.

En ik heb niet gezegd dat je voor CSG ook Nfuse nodig hebt, het is alleen wel een mooie manier van werken, zeker voor de client.

[Verwijderd]

seq_uence schreef op 25 november 2003 @ 16:13:
Volgens mij heb je er maar 1 extra server voor nodig.

En ik heb niet gezegd dat je voor CSG ook Nfuse nodig hebt, het is alleen wel een mooie manier van werken, zeker voor de client.

Normaal staat NFuse al in de DMZ, dus met CSG erbij, is het nog steeds 1 server. Tenzij het een grote omgeving is, met een flinke load.

De PN client werkt alleen met CSG, indien deze in relay mode draait.
Vanaf versie 2 is realy mode niet meer mogelijk, en zit je vast aan NFuse/WI of the PNagent versie.
Allemaal een beetje gelijk, en geen bloedvergieten

[StevenK]

Verwijderd schreef op 25 november 2003 @ 15:54:
[...]


Blijkbaar heb jij beschikking over een firewall met de capaciteiten op ip security op te zetten. (dat is toch vpn?) Niet iedreen heeft dat, en zet gewoon poort 3389, of 1494 open, en dat heeft consequenties. Niks meer en niks minder.

IP security / ACL doet elke draytek, bijvoorbeeld.

[StevenK]

Verwijderd schreef op 25 november 2003 @ 17:11:
[...]


Normaal staat NFuse al in de DMZ, dus met CSG erbij, is het nog steeds 1 server. Tenzij het een grote omgeving is, met een flinke load.

Eén van de basis-beginselen van CSG is juist dat je 2 servers in je DMZ draait.

[Verwijderd]

StevenK schreef op 25 november 2003 @ 18:26:
Eén van de basis-beginselen van CSG is juist dat je 2 servers in je DMZ draait.

Vanaf versie 2 kan de CSG de wi aanvragen intern doorproxyen. Het combineren van de 2 is dus "by design" bij versie 2. (1 ssl certificaat, en 1 x poort 443 open)
Uiteraard bij gote opzetten, liever gescheiden.

[Rolfie]

StevenK schreef op 25 november 2003 @ 18:25:
[...]

IP security / ACL doet elke draytek, bijvoorbeeld.

Bijna iedere Draytek heeft ook een VPN mogelijkheid

[jwpmzijl]

Wil999 voor het lokaal kunnen printen met DOS-applicaties in een Terminal server omgeving geeft naar mijn mening SED de meest complete oplossing. Kortweg:
- deel in de terminal server sessie de lokale printer met de TSxx poort
- map LPT1 aan de betreffende printer.

Zou moeten werken....

Wat de beveiligingsproblemen betreft van een open TS-poort. Als je zo veilig mogelijk wilt werken dat wil je voorkomen dat onbevoegden de log-in dialog van Windows niet eens kunnen zien. Zonder IP-sec etc kan iedereen met een geldige TS-licentie een poging doen om in te loggen op jouw server (mits men het IP-adres weet). Jouw usernamen en wachtwoorden kunnen dan wel veilig zijn. Toch zullen deze ongenode "gasten" resources van jouw server opslokken. Moet je eens indenken dat er een brute force attack op de server wordt uitgevoerd waarbij ineens 100 cliënts gelijktijdig willen inloggen. Ik vrees dat de performance van de server instort. Daar zullen de reguliere gebruikers niet echt happy mee zijn. Je kunt wellicht vraagtekens stellen bij de waarschijnlijkheid van een dergelijk scenario. De systeembeheerders hebben instelling dat voorkomen beter is dan genezen vandaag de diverse waarschuwingen.

[ Voor 61% gewijzigd door jwpmzijl op 25-11-2003 23:43 ]