Many IT infrastructure architects and system administrators have battled with the problem of printing from applications deployed through Windows Terminal Services or Citrix in heterogeneous networks. ThinPrint .print is a product suite that can help you out with most scenarios, albeit with a few limitations.
One of the main drawbacks to .print is that it's difficult to understand at first, because there are so many different product options and ways of configuring it. Also, the documentation provided is not that good. I've spoken to many people and done a lot of research, but no-one's been able to explain to me satisfactorily how the product works. So I decided to get to grips with it myself and share the benefit of this effort by posting a series of articles on the subject.
To begin with, it's worth highlighting the main benefits it brings:
- Print job compression - extremely useful for low-bandwidth and/or high-latency network connections
- Driverless printing - good for reducing the number of print drivers on a Citrix farm or Terminal Services server.
The best way to explain how it operates is to work through a series of example deployments and detail the processes that take place. In this, the first of a number of posts on the subject, we'll be looking at the most basic printing scenario: printing in a Windows Terminal Services environment.
This operates in a pretty similar fashion to Client Printer Mapping when making an RDP connection to a server running Windows Terminal Services. As long as you have a printer configured on the client device, you get a printer appearing in your Terminal Services Session. So what components do you need to make this happen, and what is the process exactly? And also, why bother when you can get your client printer mapped using Terminal Services anyway?
To do this, you need to buy a licence for .print RDP Engine for each Terminal Server. That's all - the only other software component is free. That other component is the .print client (configured for RDP), which resides on the client device.
When your RDP client connects to Windows Terminal Services, part of the logon process is to run a ThinPrint-supplied utility called TPAutoconnect.exe, which examines the printing virtual channel within the RDP protocol stream for the existence of the .print client at the other end. If it finds the client, it autocreates one or more printers within the Terminal Services session corresponding to the printers found on the client (using as a template a special printer object on the Terminal Services server). Any jobs printed from applications running on Terminal Services are rendered and compressed on that server, transmitted down the RDP session to the .print client, decompressed and printed on the corresponding printer on the client. It doesn't matter whether that printer is connected locally or via a network; once the job is passed to the .print client, it is considered by the client machine to have been generated locally and is handled correspondingly.
So why spend all that money on the .print RDP Engine? One reason is for the compression. If your users are coming in to your server(s) across low-bandwidth (128Kbps or less) and/or high-latency links, any documents they print are likely to swallow all the availble bandwidth can, and significantly degrade the performance of the session. That alone is likely to save you a packet of headache pills.
But if you have a lot of different printer drivers on the connecting client machines, then without .print, the Terminal Server will attempt to use those drivers to render the jobs. At best, this clutters up the terminal servers with a load of unnecessary printer drivers, which is an administrative burden. At worst, this could blue-screen the terminal server - need I say more?
If you use the .print RDP Engine, it will always use the TP Output Gateway driver for any RDP session printer created by TPAutoconnect. This means that you need only have one driver on the Terminal Servers for remote printing, which is more stable and eases the administrative effort involved. It's also quite functional, letting you change things like resolution (up to 600dpi), duplex, different paper trays etc. and the ability to apply client printer settings to the auto-created printers. In addition, you can adjust the amount of compression delivered, the trade-off being document quality.
And what are the limitations? Well, for one, your client device has to be running 32-bit or 64-bit Windows (95, 98, NT, Me or XP). This is because the format of the print job sent down the virtual channel within RDP is only comprehensible to Windows clients. If you need to enable this for other client device operating systems (Linux or WinCE), you'll need to use the next product up in the range: the .print Application Server Engine, together with the appropriate .print clients. But more on this in the next article....
For those of you who have more than one mobile phone for whatever reason, and are looking for options (other than keeping one SIM card in your wallet and swapping it with the other one all the time!), this article is for you.
As with anything in this technology space, there is a plethora of options. I've distilled these down a bit to make it easier to make your choice.
Solution Category A: Get a second line on one of your phones
This is only feasible if both your handset and your mobile provider support this. Orange UK offers this feature on a reasonable number of handsets (www2.orange.co.uk/servlet/Satellite?pagename=OUKPersonal/Service&cid=1096023563451), but the bill is sent to only one party. Hence it's really only useful for people who work for themselves and want to separate business from personal calls easily, or for small businesses who want to make it easy for their employees to separate (and pay for) personal calls.
Solution Category B: Get a multi-SIM device
Generally speaking, these are little SIM card holders that accept two or more SIM cards, but still fit into your handset. You can then switch between mobile SIM cards without having to remove one SIM and replace it with the other. Be aware, though, that you may well need to have your handset unlocked to do this. In order of ascending cost and convenience, here are the options:
Option 1: Multi-SIM handset back
Pros: Cheap
Cons: Requires phone to be switched off and on again + Handset-specific in nearly all cases
Examples:
http://www.phatphones.com/accessories_for_nokia_phones.htm (dual- and triple-SIM battery covers for Nokia 8210/8250)
Option 2: Multi-SIM Ghost holder
Pros: Doesn't require new battery cover for your phone.
Cons: Handset-specific in many cases.
Option 3:
Pros: Provides the ability to use two mobile networks from one phone.
Cons: Requires phone to be switched off and on again + requires SIM cards to be cut (eek!) and stuck on to the holder.
Examples:
Stancom Black I (www.stancom.ch/black1.html)
2-phones-in-1 Universal Dual Simcard Holder Adapter (www.2-phones-in-1.com/english/products/universal_dual_sim_us.htm)
2-phones-in-1 also offer a service to cut the SIM card for you, if you are (understandably) too nervous to do it yourself. Unfortunately, they accept no liability for anything going wrong - so why do they even offer it, I wonder? It would be better if they cloned your SIM card, cut the clone and sent both of them back to you....
Option 4: Multi-SIM holder with software support
Pros: Doesn't require the phone to be switched off and on again to activate a different SIM - can be done in the phone menu.
Cons: Still requires your SIM cards to be cut.
Examples:
Stancom Black II (www.stancom.ch/black2.html)
Option 5:
The ultimate solution: SIM-card consolidator
USB SIM card holder, with software to extract the contents of up to 16 (yes, sixteen!) cards and download them to a blank, consolidated SIM. This is definitely the Rolls Royce answer: the new SIM card has the characteristics of all the other SIMs that have been consolidated to it. Here's what it looks like:
http://duosim.com/supersim.html