Printen over VPN, netwerk overbelast.

[tel2]

Hallo,

Wij hebben gebruikers op een Windows 2012 terminal server die verbinding met deze server maken over een VPN verbinding. We loggen met de 4 gebruikers in over een 1Mbit internet verbinding op het hoofdkantoor die alleen hiervoor gebruikt wordt. Een glasvezel verbinding is aangevraagd maar dit gaat nog enkele maanden duren.

Nu is het werken zeer acceptabel tot het moment dat er geprint wordt door iemand. Als er wordt geprint dan worden de RDP sessies bij alle gebruikers traag. De printer op de nevenvestiging is rechtstreeks op de terminal server geïnstalleerd die op het hoofdkantoor staat. Het gaat om een Kyocera printer.

Ik ben al op zoek gegaan op het internet maar kan geen oplossing vinden voor dit probleem. Ik heb al andere drivers geïnstalleerd maar dit lost het probleem niet op. Is er iets anders wat ik kan doen? Kan ik op de één of andere manier het print verkeer een lagere prioriteit geven?

Ik hoop dat iemand mij kan helpen.

[Question Mark]

Test eens met clientside-rendering enabled op de printers. Een printjob bestaat uit twee fases, waarvan de laatste de meeste netwerkbelasting geeft. Met deze optie enabled gebeurd die stap op je clients, en wordt de WAN verbinding minder belast.

Je clients moeten dit wel ondersteunen overigens...

http://blogs.technet.com/...lient-side-rendering.aspx

Een andere optie zou het inzetten van een oplossing als thinprint kunnen zijn, of het inregelen van QOS op je VPN/netwerkingverbindingen.

[ Voor 6% gewijzigd door Question Mark op 21-10-2014 16:34 ]

[tel2]

De optie clientside-rendering staat standaard aan in Windows 2012 server en dus ook bij mijn printers. De gebruikers die op de remote locatie werken loggen in d.m.v. een thin client op de terminal server op de hoofdvestiging. De printer op de remote locatie is rechtstreeks op de terminal server geïnstalleerd en dus niet gedeeld. Als een printer niet gedeeld is staat het vinkje bij clientside-rendering aan maar kun je niet wijzigen, dit doet dan denk ik ook niets? Klopt ook wel want de terminal server is hier dus client en server voor de print opdracht als ik het goed begrijp.

Voordat ik eventueel naar een oplossing als thin print kijk wil ik eerst kijken of het met de momenteel aanwezige hard en software te verbeteren is.

QoS is misschien een optie maar ben ik niet echt in thuis. Normaal gebruik je dit om verkeer voorrang te verlenen maar ik wil juist het print verkeer een lagere prioriteit geven. Ik zal dus al het andere verkeer voorrang moeten geven. Ik kan nergens vinden hoe ik dit precies configureer.

[Question Mark]

tel2 schreef op woensdag 22 oktober 2014 @ 13:03:
De optie clientside-rendering staat standaard aan in Windows 2012 server en dus ook bij mijn printers. De gebruikers die op de remote locatie werken loggen in d.m.v. een thin client op de terminal server op de hoofdvestiging. De printer op de remote locatie is rechtstreeks op de terminal server geïnstalleerd en dus niet gedeeld. Als een printer niet gedeeld is staat het vinkje bij clientside-rendering aan maar kun je niet wijzigen, dit doet dan denk ik ook niets? Klopt ook wel want de terminal server is hier dus client en server voor de print opdracht als ik het goed begrijp.

Controller gewoon even of de optie al dan niet gebruikt wordt.

One way to check to see if CSR is being used is to check the Datatype for the print job. You can do this by printing a test page or by viewing the properties of the spooled document (on the General tab). For Client-Side Rendering, the Datatype will be RAW. For Server-Side Rendering, the Datatype will be NT EMF x.xxx.

Wordt CSR niet gebruikt, deel dan de printer alsnog en laat een gebruiker eens testen met de gedeelde printer.

tel2 schreef op woensdag 22 oktober 2014 @ 13:03:
Voordat ik eventueel naar een oplossing als thin print kijk wil ik eerst kijken of het met de momenteel aanwezige hard en software te verbeteren is.

QoS is misschien een optie maar ben ik niet echt in thuis. Normaal gebruik je dit om verkeer voorrang te verlenen maar ik wil juist het print verkeer een lagere prioriteit geven. Ik zal dus al het andere verkeer voorrang moeten geven. Ik kan nergens vinden hoe ik dit precies configureer.

Je zult inderdaad je RDP verkeer voorrang moeten geven op al het andere verkeer. Hoe je dat doet is afhankelijk van je gebruikte apparatuur.

Ik zou overigens voor beide opties gaan. Én CSR aan de praat krijgen, en daar bovenop RDP verkeer voorrang geven op je overige wan-verkeer. Die combinatie levert de beste gebruikerservaring op. Overigens, ook als de nieuwe en snellere WAN verbinding opgeleverd is, is dit iets wat je zou willen. Je laat hier momenteel nog een aardig stuk optimalisatie ligggen.

[tel2]

Ik denk dat het begrip CSR voor onze situatie helemaal niet op gaat omdat de printer rechtstreeks op de terminal server is geïnstalleerd.

Ik krijg steeds meer het idee dat we toch een third party tool moeten gebruiken.

[Wim-Bart]

tel2 schreef op woensdag 22 oktober 2014 @ 16:36:
Ik denk dat het begrip CSR voor onze situatie helemaal niet op gaat omdat de printer rechtstreeks op de terminal server is geïnstalleerd.

Ik krijg steeds meer het idee dat we toch een third party tool moeten gebruiken.

Sterker nog, Client Side Rendering moet je uitzetten!!!!!

De reden is heel erg simpel. Wanneer je print maakt stuurt de spooler native printer commando's naar de printer in de taal zoals de printer het snapt. Bijvoorbeel PCL, HPGL, PostScript, Dit is zeer efficicient, het kan bijvoorbeeld gewoon zijn:

[Ec (s1S]Dit is een Italic text[Ec (s0S] = totaal 5+23+5 bytes = 33 bytes.

Met Client Side rendering wordt het allemaal anders. Ten eerste wordt als eerste de bovenstaande tekst als bitmap image gerenderd in het DPI formaat van de pagina. Daarna gecomprimeerd. Bovenstaande test zal ongeveer naar de 30KByte renderen wat over je lijn heen gaat.

Client Side Rendering dus nooit aanzetten in een Terminal Server/Citrix omgeving.

Daarnaast vreet Client Side Rendering resources als een gek. Moet je voorstellen op een server met 80 mensen en allemaal printen, de spooler zal gek worden.

Client Side Rendering dus uitzetten op: 1 Terminal Server, 2: Op de printserver.

Daarnaast, gebruik ook nooit inktjet printers of goedkope laser printers zonder buffer, is killing voor je omgeving.

[PeterEs]

Hoe snel is de verbinding op het hoofdkantoor en hoe snel op de nevenvestiging?

Ik heb een vergelijkbare omgeving gehad, 4/4 op het hoofdkantoor en 4/1 op de nevenvestiging. Ging prima met 15 man incl. printen.

Wij hadden alleen HP P4015 zwart/wit printers, misschien dat daar het verschil in zit?

Wellicht een workaround zolang je de glasvezel nog niet hebt: Printer op Pause zetten en 1x per uur de printjes uit de printer laten rollen. Is het 1x per uur even wat traag, maar kan iedereen wel normaal werken. Gaat natuurlijk niet op als je die printjes direct nodig hebt.

[tel2]

PeterEs schreef op donderdag 23 oktober 2014 @ 19:47:
Hoe snel is de verbinding op het hoofdkantoor en hoe snel op de nevenvestiging?

Ik heb een vergelijkbare omgeving gehad, 4/4 op het hoofdkantoor en 4/1 op de nevenvestiging. Ging prima met 15 man incl. printen.

Wij hadden alleen HP P4015 zwart/wit printers, misschien dat daar het verschil in zit?

Wellicht een workaround zolang je de glasvezel nog niet hebt: Printer op Pause zetten en 1x per uur de printjes uit de printer laten rollen. Is het 1x per uur even wat traag, maar kan iedereen wel normaal werken. Gaat natuurlijk niet op als je die printjes direct nodig hebt.

De verbinding op het hoofdkantoor is 1/1 (SDSL), de verbinding op de nevenvestiging is 8/1. Waarschijnlijk is de SDSL op het hoofdkantoor de bottleneck. Het pauzeren van de printer is voor ons heel onhandig dus niet echt een optie.

Bedankt in ieder geval voor het meedenken. (Ook Wim-Bart)

[PeterEs]

Wij hebben ook een tijdje 2/2 op het HQ en 8/1 neven gedraait, ging toen alleen niet over een VPN maar gewoon over internet. Users namen hun lokale printer "mee" naar de TS.

Kan me bijna niet voorstellen dat het in die ene mbit zit die jij minder hebt. Wat zijn het voor afdruktaken (brieven/foto's) en zijn die in kleur of zwart wit? Is de printer een kleur of zwart/wit?

Wellicht is er op het hoofdkantoor een mogelijkheid om op korte termijn tijdelijk een tweede internetaansluiting te realiseren? Dan kun je een tweede VPN bouwen en daar je print verkeer over routeren.

[tel2]

PeterEs schreef op vrijdag 24 oktober 2014 @ 14:04:
Wij hebben ook een tijdje 2/2 op het HQ en 8/1 neven gedraait, ging toen alleen niet over een VPN maar gewoon over internet. Users namen hun lokale printer "mee" naar de TS.

Kan me bijna niet voorstellen dat het in die ene mbit zit die jij minder hebt. Wat zijn het voor afdruktaken (brieven/foto's) en zijn die in kleur of zwart wit? Is de printer een kleur of zwart/wit?

Wellicht is er op het hoofdkantoor een mogelijkheid om op korte termijn tijdelijk een tweede internetaansluiting te realiseren? Dan kun je een tweede VPN bouwen en daar je print verkeer over routeren.

We hebben een z/w en een kleuren printer. De kleurenprinter wordt minder gebruikt maar bij beide hebben we de vertraging. Er wordt hoofdzakelijk vanuit Word, Excel en Adobe Reader geprint, voornamelijk tekst.

Er is wel een tweede internet verbinding op het hoofdkantoor waarop al een aantal andere gebruikers inloggen vanaf de nevenvestiging (gewoon over internet). Ik kan een tweede VPN verbinding opzetten en kijken of ik het printverkeer hier over kan laten gaan. Moet ik het verkeer naar het IP adres van de printers dan via een static route over de tweede VPN laten gaan?

[begintmeta]

De verbinding tussen terminalserver en printer is dus als ik het goed begrijp dezelfde als die tussen terminals en terminalserver (allen de richting is verschillend?)

Dan ben ik op zich wel beniwued naar de vorm waarin de terminalserver de afdruk naar de printer stuurt, heb je daarover meer informatie? Dus welke printer, welke driver gebruik je, welk protocol wordt voor de verbinding gebruikt, welke vorm heeft de opdracht, ....

[ Voor 16% gewijzigd door begintmeta op 24-10-2014 15:59 ]

[tel2]

begintmeta schreef op vrijdag 24 oktober 2014 @ 15:49:
De verbinding tussen terminalserver en printer is dus als ik het goed begrijp dezelfde als die tussen terminals en terminalserver (allen de richting is verschillend?)

Dat klopt.

Dan ben ik op zich wel beniwued naar de vorm waarin de terminalserver de afdruk naar de printer stuurt, heb je daarover meer informatie? Dus welke driver gebruik je, welk protocol wordt voor de verbinding gebruikt, welke vorm heeft de opdracht, ....

Hoofdlocatie:
Terminal Server

Nevenlocatie:
ThinClient
Printers

ThinClient logt in via RDP op terminal server en print op de printer die geïnstalleerd is op terminal server maar fysiek op de nevenlocatie staat. Het gaat om een Kyocera FS3540MFP en ik heb beide drivers voor Windows Server 2012; geinstalleerd http://www.kyoceradocumen...lse._.FS3540MFP._.NL.html

Het is een IPSEC VPN verbinding.

[begintmeta]

Hoe stuurt die driver de opdracht naar de printer&kan je meten hoe groot de opdrachten zijn?

[kraats]

Welke driver gebruik je nu? Volgens mij is de KX driver op basis van Postscript. Dat zou vooral met het printen van PDF-bestanden flink minder data naar de printer moeten sturen dan een PCL-driver.
Maar ik denk dat het vooral van belang is te weten wat er precies geprint wordt. Een dagje logging verzamelen en aan de hand daarvan gaan testen welke driver of opstelling verbetering biedt.

[PeterEs]

tel2 schreef op vrijdag 24 oktober 2014 @ 15:41:
[...]
Er is wel een tweede internet verbinding op het hoofdkantoor waarop al een aantal andere gebruikers inloggen vanaf de nevenvestiging (gewoon over internet). Ik kan een tweede VPN verbinding opzetten en kijken of ik het printverkeer hier over kan laten gaan. Moet ik het verkeer naar het IP adres van de printers dan via een static route over de tweede VPN laten gaan?

Als je alle gebruikers nou gewoon over internet laat inloggen en de VPN enkel voor print verkeer gebruikt, dan is het probleem toch opgelost? (Los van dat de printjes er mogelijk wat vertraagd uitkomen...)