If you’ve read the first article in our series about branch networking, you hopefully understand the basics of a networked bank branch a little better. Here, we’ll talk about using peripheral devices, such as scanners and printers, in a virtual desktop network environment. Some important topics we’ll cover include:
- Why external devices are notoriously difficult to run in virtual desktop infrastructure (VDI) environments;
- Ways to work around these compatibility issues, and how Digital Check products address them; and
- Additional benefits – what a (properly) networked scanner or printer can do that an ordinary one can’t.
Why is it difficult to get external devices, such as scanners and printers, to work correctly in a networked branch?
As noted in Part 1 of this series, the major difference between a traditional teller station and one running a virtual desktop is where the “brain” of the computer is located. An ordinary workstation would have a standalone PC running the bank’s teller software; accessories would be plugged in via USB cable and run using drivers and/or API software installed on that PC.
In a branch using a virtual environment, the workstations are calling programs from a central server that runs all the software. The workstations themselves are designed as a pass-through, with no full operating system – and little additional software – s installed locally. When it comes to peripherals that must be physically plugged into the workstations, though, it can get a bit tricky. Most VDIs have evolved to the point where they can handle “standard” devices, like mice and keyboards, with relatively few issues. More complex devices, like printers and scanners (including check scanners), may or may not play nice.
Check scanners, in particular, face three common hang-ups when running on a virtual desktop workstation. The first is that the scanner “expects” the drivers and API software to be installed locally on the machine to which it’s connected – but the barebones workstations won’t have them. In this case, the scanner won’t work at all.
Generally, it IS possible for a check scanner to be driven remotely with the drivers installed on the central server . However, the second problem that arises in this case is one of network latency – how long it takes for commands to travel back and forth between the server and the scanner. If that adds, say, a quarter of a second to each item scanned, then it would result in a minimum 30% performance loss for a device operating at 150 documents per minute.
A third, much more serious issue is transferring the raw images that the scanner is producing as it works. The “finished” black-and-white bi-tonal check images used in the United States’ clearing system are very small – usually 10 KB to 20 KB each – but they don’t start out that way. Check scanners begin by taking a raw 300 dpi grayscale image of the check, which typically yields a file with a size of 2 MB or 3 MB. That raw image file travels down the USB cable to the computer at the teller’s workstation where it’s processed into one or more standard file formats, such as .JPG, .BMP, .TIF, and so on, which are in turn used to create the finished bi-tonal image with that much smaller file size.
In a virtual environment, though, the teller workstation doesn’t do the conversion because it doesn’t have any software installed – or for that matter, any local processing capability . Instead, the raw image of 2-3 MB must travel all the way to the central server in uncompressed form, creating a serious bottleneck along the way. A teller scanner operating at full speed might be outputting close to half a gigabyte of raw image data per minute! Needless to say, the strain this puts on a branch’s external connection is unsustainable, resulting in the scanner throttling itself to lower speeds (sometimes as low as a few documents per minute) until the network catches up.
Occasionally, we hear anecdotes about other device conflicts, such as scanners and printers that won’t work at the same time, or which require a reboot to switch between devices, when non-network hardware is used in thin-client virtual environments. While less prevalent than the other three main hang-ups, it does share the same solution:
How do newer scanners and receipt printers solve network compatibility problems?
Since the fundamental issue for check scanners in a virtual environment is that the raw images are too large to efficiently transmit to a remote server in real time – and the teller VDI workstations can’t process the images locally – the best solution is to do the processing and compression before the image leaves the scanner.
Technology has come a long way toward solving this problem in the 10 or more years since the first “network-ready” scanners were introduced. Simple computer processors and memory – think of the kind that are inside a smartphone or on a Raspberry Pi board – have become so cheap that you can put them in almost any device, turning it into its own self-sufficient mini-computer. That’s the gist of what we do with networked scanners – we give the scanner some basic computing power, load the drivers and API onto that chip, and make the device capable of doing its own image processing .
Digital Check deployed its first VDI-ready scanners, the SmartSource Expert series, as far back as 2007, when the first iPhones were hitting the market. In the ensuing decade-plus, the types of system-on-a-chip processors used for this purpose have only become cheaper and more powerful, to the point where it’s practical to put a miniature computer in just about anything. (If you remember the previous article where we used the idea of playing a movie on a streaming device as an analogy for virtual branch environments – you are literally running the scanner with the same type of technology as a Roku, Chromecast, or Apple TV.)
There’s more than one way to do this, as it turns out, with each method having benefits and drawbacks of its own. The most straightforward approach is to simply build the processor and memory into the scanner, which is what we do with the SmartSource Expert and Expert Elite series. However, we also built an external mini-computer to connect to the scanner with a USB cable, which is how our SecureLink device works.
The advantage of a built-in processor, obviously, is that there’s one less piece of equipment involved, so it’s closer to “plug-and-play” (although, that’s a bit of an oversimplification). On the other hand, being “built-in” means that if your existing scanner doesn’t have networking capability, you would typically have to buy a new one if and when you switched to a virtual environment. With an external device, such as SecureLink, the processing power is separate from the scanner, so you can connect it to any existing CheXpress CX30, TellerScan TS240, or TS500 device (with more Digital Check scanners being certified in the future) – essentially turning a non-network scanner into a network-capable one.
There’s also the matter of how the device is addressed: Truly “network-enabled” scanners will connect with an Ethernet cable (or occasionally WiFi), receiving commands through a browser-based interface. There are other scanner models that perform onboard processing (such as the SmartSource Serial Embedded, or SE models) but connect to a standard PC using a non-browser interface. These are not network-enabled scanners in the sense we are talking about here, but they can help, for instance, to solve compatibility and local bandwidth issues.
It’s worth mentioning that if you want to use devices such as tablets – which can only connect via a network – then the check scanner must be network-addressable with a browser to be controlled by that device. This opens a whole new world of possibilities, as we’ll discuss in the third and final article in this series.
One final point regarding network-enabled scanners and related devices: If a scanner or printer is unavailable for some reason, it is possible to switch to another device on the network to complete a task. While it’s not usually practical to “share” devices between workstations for regular operations, this provides a nice fallback capability in case of emergency.
What else can a networked scanner do that a non-networked one can’t?
Since they receive commands through any standard web browser, networked scanners and printers can be operated by almost any device that can connect to that same network, including PCs, laptops, tablets, and smartphones. They are also free of operating-system constraints; so, in addition to the standard Windows and OS X compatibility , they’ll also work with Android, iOS, Linux, and virtual environments, such as Citrix and VMWare. This has opened the doors to all sorts of new customer-facing and self-service applications that were not feasible before (see the next article in this series for more).
As you may have surmised, giving the scanner an onboard processor with its own computing power also opens the door to a huge array of other possibilities, some of which can allow the peripherals to do things that used to be the job of the PC. We’ll talk more about this in Part 3 of this series.
