Printing in a VDI Environment

[redsox04]

How are people accomplishing printing in a VDI environment, specifically, remote printing.

2 scenerios I am thinking about;

1. User at a remote office using a PC that prints to a network printer. When they connect via RDP to their XP hosted desktop, how will they print to this remote network printer.

2. User at a remote office using a PC that prints to a local printer (lpt or usb). When they connect via RDP to their XP hosted desktop, how will they print to this remote local printer?

I don't believe RDP & XP will handle this smoothly and I am thinking 3rd party printing products may need to be used such as ThinPrint.

Citrix has finally come along way with printer 'auto-creation' but RDP doesn't handle this very cleanly.

Any thoughts on this or real world feedback? Thanks!

[TomHowarth]

I only thought they came in Orange or Green, Did'nt realise that there were colour ones

[davlloyd]

Max's out the rs232 connection I bet

[sgrinker]

Is it just me, or doesn't it look like the color pie graph is just overlayed into the photograph itself?

[davlloyd]

...and the guy is wearing a wig!

Phonies!!!!

[conyards]

To get this kinda back on topic.

How would you guys look at a UniPrint deployment? obviously in the Citrix world, I can swallow $1000 for a UniPrint server licence, this kind of cost isn't going to fly if it has to be installed to each VDI?

So how do we plan a deployment of UniPrint in the VDI world?

Simon

[TomHowarth]

This is a question I will be raising with UniPrint over the next week or so, as yet I do not think they are exactly aware of the paradigm.

I am involved with them direct to their Developers in Canada with a Citrix Implementation that requires a custom Uniprint client to be developed.

[Sean_Cottrell]

For RDP Connections and even Citrix ICA connections I map printers from the User's Network Logon Script.

Here's how:

In Active Driectory, create two groups, call them P1 and P2. In the Description field of each group enter something like
PrintServer\P1. Next, locate the Computer Object for your VDI XP VM, make it a member of the P1 Group.

During the execution of the Network Logon Script, grab the hostname of the computer that is running the script. With this information query Active Directory to what group(s) this hostname (computername) is a member of. It's a memember of the P1 group, how cool. Query AD for the description field of the P1 group object, grab it, in this case
PrintServer\P1, call the mapnetworkprinter command. Ta-Dah. Nice part you are using native drivers for the printer instead of a universal driver, which in my case is great because we have many printers with dual trays, duplexers, and even envelope feeders.

For my normal Users they each have 3 printers, 2 B/W, 1 color all are network printers, and some cases they are local printer or Multi-Function units, all work well.

My entire Network Logon Script, including mapping network drives (using the same AD Group look-up) and performing a complete basic invemtory of the host, takes 1-7 seconds to run. Even have IE launch to take them to the default Citrix Web Interface page.

I have created this as a VBScript, also have the code to set default printer and even inventory the printer(s) to an SQL Database table.

Thoughts?

Message was edited by:

Sean Cottrell

[TomHowarth]

This is all well and good in a high bandwidth, low latency enviroment, where toe opposite is true, you need a more robust solution

[Sean_Cottrell]

In a dial-up connection (as low as 19k) the script takes 20-45 seconds to run.

[TomHowarth]

the script may only take 20-45 seconds to run, but how long does it take a 100 page multi images document with differnent fonts and tray mappings to print on that site. using native print drivers

That is what we are on about not how long it takes to map a printer.

[Sean_Cottrell]

Then obviously you would not be using mapped network printers over a dial-up connection if your User output was a "100 page multi images document with differnent fonts and tray mappings". You would be giving that user a locally attached printer or giving the User a solution, such as Citrix, VDI XP PC or Terminal Services.

But even in a Citrix or Terminal services environment and you allow the User to map to thier local printers, say thier Multi-Function Printer, and you try to have them print that same "100 page multi images document with differnent fonts and tray mappings" you are still in the same boat. Large document, slow connection.

I was mearly trying to point out that I have an easy to setup and free scripting solution for printing, that uses native drivers (if your environment would need that) that works both in and out of a Citrix or Terminal Services or even an VDI XP VM.

Message was edited by:

Sean Cottrell

[Sean_Cottrell]

Another area that we have applied a solution too is one of our remote offices. They have half of a T1 connection to the main office for 39 Users. Thier traffic over the wire consists of Outlook to Exchange, World/Excel to File Server, 3270 to mainframe, full-bloawn Imaging software and a few others. And of course the badnwidth killer, Internet traffice over the wire!

So we implemented an Citrix Only environment (except for Internet surfing). What was the new badnwidth killer (excluding the Citrix ICA and Internet srufing traffic)....network printing.

I found an article that described network printing: client to printer server to printer. So what we did was create a VM printer server with network printer definitions defined for the network printers in the remote office.

So while the user was ICA or RDP'ed over the wire and they printed, the raw printer data was handled inside of the corporate office using the speed of the internal LAN. Once through the printer server, the smaller, cleaner, formatted print data stream was set over the wire to the Network printer in the remote office. (And mapping of these Network Printers is handled by the scripted I mentioned earlier.)

We estimated the savings on badnwidth anywhere from 20% to almost 50%.

Anyway, just another approach to printing. And yes we have Users printing " 100 pages...." with this solution.

[Elie-prof]

Although printer auto-creation in RDP is feasible as Param had previously outlined, it just isn't always reliable. This is why a true universal printing solution is recommended in most situations.

For the low bandwidth / large document scenarios mentioned here (we have that too) we've had great success with the built-in universal printer in the Provision Networks VAS - it supports page streaming and bandwidth control - the full list from their their website:

-Support for EMF and PDF modes of printing

-Does not require the Adobe Acrobat Reader on the client

-Does not require any server-side fonts to be pre-installed on the client

-Size-optimized print streams

-Adaptive compression technology (multiple compression algorithms for color and black-and-white images)

-Bandwidth usage control (i.e., bandwidth throttling)

-Intelligent font embedding (only fonts that do not exist on the client are embedded inside the print stream)

-Partial font embedding (only the used portions of fonts are embedded inside the print stream)

-Excellent print quality

-Incredible print performance and reliability compared to other third-party universal print driver solutions

-Page-level streaming for instant printing of large-size documents over low-speed connections

-Support for native printer features (i.e., bins, paper sizes, margins, print quality, and much more)

-Support for private printer features (i.e., manufacturer-specific features such as stapling, watermarks, etc)

-Support for the RAW data type (i.e., accommodates many legacy applications that perform their own rendering)

-Multiple printer naming options

-Synchronous/asynchronous printer auto-creation (ensures the auto-creation of at least one printer before the server-side application is started)

-Clientless support for LAN-connected print servers (transforms Windows print servers into universal print servers)

-Clientless support for remote sites and distributed environments (i.e., branch offices, business partners, ASP customers)

-Support for virtually any printer make and model

-Stress-tested using QualityLogic tools

[TomHowarth]

Sean

I am not having a go. and if it appeared so I am sorry for offending you.

However the initial poster did start remote sites not local when starting the thread and had specifically requested information regarding thrid party printing product that add value and conserve bandwidth.

[benhin]

Great discussion, but after reading everything, Interpetation.

First off the XP system doesn't appear to actually create local printers.

So third party product only to approach Citrix autocreate solution?

Message was edited by:

benhin

[TomHowarth]

Benhin

The local printers we are talking about are Client side, not on the VDI guest,

RDP will pick up locally attached printers and present them to the users as if they are installed with in the guest XP desktop.

This discussion is focusing on the reliability and stability of native print drivers over a third party printing solution

[conyards]

Hi, Tom any comeback from UniPrint on a VDI implementation?

Simon

[Elie-prof]

bonne chance!?

[TomHowarth]

Sorry, everybody, been on vacation, just got back today. I will be pinging them a nudge in the moring.

[Anil_Agrawal]

Hi Sean:

On January 15, you wrote:

"... I found an [u]article[/u][/b] that described network printing: client to printer server to printer. So what we did was create a VM printer server with network printer definitions defined for the network printers in the remote office.

So while the user was ICA or RDP'ed over the wire and they printed, the raw printer data was handled inside of the corporate office using the speed of the internal LAN. Once through the printer server, the smaller, cleaner, formatted print data stream was set over the wire to the Network printer in the remote office. (And mapping of these Network Printers is handled by the scripted I mentioned earlier.)

We estimated the savings on badnwidth anywhere from 20% to almost 50%.

Anyway, just another approach to printing. And yes we have Users printing " 100 pages...." with this solution. "[/i]

Bandwidth savings of 20%-50% are astounding!

1. Can you please give me the reference to that article you have cited above?

2. Also, you have mentioned a 'script' for printing. Where is that script available?

I am testing remote access from thin-clients to XP Virtual Desktops on VMware ESX Server using RDP and ICA protocols. One of our bottlenecks is printing to remote locations.

Thanks.

Anil