Throughout Elusiva website or when communicating with Elusiva employees via email, readers see Elusiva on-demand access suite and Elusiva Terminal Server Enterprise used interchangeably. Some are confused, asking us what is the difference between and two products. Many users have referred to Terminal Server Enterprise asking whether it supports and/or how to enable redirection of local USB devices.

Due to all of the confusion, we decided to write a plan-text explanation covering our suite.

Elusiva Terminal Server Enterprise is an on-demand desktop and application access/delivery suite or platform. This means that our product is made to deliver applications running on remote computers to a variety of access devices. IT personnel can perform desktop management tasks from a single point and click management tool without having to manage individual access devicesThis allows IT departments to provide users with access to business application regardless of users physical location. Therefore, among other things our platform becomes an enabler for telecommuting. Organizations where IT departments decide to go a little further can eliminate computer workstations altogether and provide users with virtual desktops accessed through inexpensive dumb terminals known as thin clients. This can result in dramatic reductions and improvement of the overall business agility.

The name Terminal Server Enterprise is somewhat misleading. In Windows operating system world, Terminal Server is a specific piece of software. Microsoft first released Windows Terminal Server as a part of Windows NT 4.0 Terminal Services edition. This component allows multiple users to access one Windows Server whereas each user will get a dedicated virtual desktop. This functionality is still present in the latest Windows Server release. Recently, Microsoft renamed Windows Terminal Services into Windows Remote Desktop Services, referring to Remote Desktop Protocol utilized by Terminal Server to deliver the desktops and applications.  Elusiva Terminal Server Enterprise is compatible with three different platforms running on the back-end:
 - Windows Terminal Services,
 - Virtual Desktops hosted on hardware virtualization servers (VDI), and
 - Physical Computers such as Blade PCs.
Since Elusiva Terminal Server Enterprise is compatible not only with Terminal Services, we often call the platform for what it is/does - on-demand desktop and application access suite.
Elusiva marketing people are trying to come up with a better product name for 2.0 release.

Our platform can be deployed to deliver only server-based computing (SBC) when installed atop Windows Terminal Server, only VDI when connected to virtual infrastructure platforms from Microsoft or VMWare, and only access to physical computers when desired; or Terminal Server Enterprise can be and often is used to provide access to a hybrid deployment where some users are running their applications off an SBC back-end while others are accessing virtual and physical desktops.

Users access their desktops and applications using either a configurable web access portal with a self-provisioning client, or using an installable stand-alone access client application. Features such as application publishing, single sign-on and plug-n-play device redirection are available off both terminal servers and physical/virtual desktops. Users do not need to know and usually would not know which back-end platform is hosting their session.

There is one difference, however. Elusiva platform includes the ability to redirect user-level USB drivers for both SBC and desktops, but kernel-level USB drivers can be only connected to desktops and will be invisible to shared access servers. The ability to redirect any USB device is often called USB port-level redirection. Unlike user-level driver using operating system interfaces to access the device, kernel-level drivers access hardware direct. Therefore, the only way make to the remote computer think that the device is connected is to, is by redirecting all relevant USB protocol traffic capturing packets at the USB-port level.
Port-level redirection works excellently when the remote computer is talking to only one access device. In shared-access situation, we would have multiple users connected to the same server. All USB peripherals connected to each client devices would all appear to be connected to the server. Users would have no way of knowing which USB device belongs to whom should multiple devices have the same make/model. In addition, there would be no way of ensure confidentiality of access to the device as all users will see all redirected USB peripherals.

Instead of port-level generic USB device redirection, users connected to SBC hosts should take advantage of redirection of specific device classes. Microsoft already includes support for disk, serial and parallel port redirection as well as basic printing. Elusiva platform greatly improves printer redirection and adds support for scanners, microphones, still image cameras and soon camcorders. Devices redirected from within an SBC session are visible only to the session owner. In addition, device class specific redirection consumes a lot less bandwidth and is usually a preferred way to redirect accessories even when accessing desktops. Meanwhile, USB redirection is a fallback mechanism allowing to redirect any unsupported USB device.

Microsoft often provides special interfaces allowing third-party vendors to build extensions enhancing baseline Microsoft products. Such application interfaces exist for 'Remote Desktop Connection'. This allows Elusiva and other vendors extending Remote Desktop to tell the Microsoft-made client and server to load special executables - extensions adding new functionality to basic terminal services.

You can look up the list of Remote Desktop Connection extensions registered on your system using the Windows registry editor. The location of the corresponding value - HKLM\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\RDPDR
String value 'Name' contains the list of plugins.

These application programming interfaces (API) make it possible for third-party software vendors offering extensions for Remote Desktop to develop useful enhancements to the Microsoft protocol without having to implement either the client or the server. Elusiva Remote Scanner, Remote Sound and Universal Printer for Windows work this way. Extension vendors can, therefore,  concentrate on their core expertise - usually improved peripheral devices support, and seamless user experience - without having to develop a complete client capable of speaking RDP protocol.
Meanwhile, Elusiva customers have been asked us to help with audio/video acceleration and printing from Linux thin clients and Mac OS X computers since the day Elusiva audio acceleration for RDP plugin has been released in the summer of 2008.

Our R&D team needed to provide a capability to utilize various Elusiva extensions to Remote Desktop Protocol from client platforms where native Microsoft client is not available. Typically, non-Windows clients use a free open source RDP client - rdesktop available for everyone at rdesktop.org. Elusiva maintains a Java port of this product. This Java rdesktop port is a bugfix release of the rdestkop in Java implementation originally developed by Propero Limited, now a part of VMWare, Inc.

Since Elusiva already maintained a Java port, using the native-code version of rdesktop seemed like a natural choice. While rdesktop only implements RDP 5 - a very old version of Remote Desktop Protocol - RDP backward compatibility allows accessing newer hosts from an older client. Improving an existing project appeared easier that developing a completely new clean implementation. There was a problem, however; rdesktop was covered by a popular open source GPL license. This meant that Elusiva products covered by a proprietary closed source license cannot be used together with rdesktop client.

We considered completely open sourcing all client components of Elusiva platform. There were, however, serious technological and business implications.  Accordingly, we decided to develop a full client in order to offer access from any device. And while Elusiva embraces Open Source for its merits, we feel the rdesktop project is already a viable solution to those interested primarily in openness of the source code.

Another project pursuing exactly the same goal could have split the rdesktop community. Elusiva decided to go with a proprietary license, but open the product architecture. Following Microsoft's example on Windows platform, we set to develop a proprietary solution with open interfaces for extending the base package. This will allow any vendor – open or closed source – to focus on extending the base access platform without having to repeat the process of developing the complete remote access client, as long as licensing covering extensions is compatible with proprietary systems. Much like third-party vendors use Microsoft Remote Desktop Connection and Windows registry to specify which extensions to load in order to extend functionality Remote Desktop Protocol, these vendors can use Elusiva Access Client and simple configuration files on Linux/Unix, Mac OS X, iOS and WebOS and older/unsupported versions of Windows, without having to develop the full client for either of those platforms.

This however was a long endeavor. As of August 2010, Elusiva Access Client still has not been released into production. We are anticipate a release in early Q4 2010.

In 2008, our customers needed something as soon as possible. It seemed that whatever 'quick-and-dirty' solution we can devise, we would have to utilize rdesktop intellectual property.

The issue with GPL covering rdesktop is that GPL is a viral license. This is not bad or good. The viral nature is, in fact, probably the main reason behind the license's popularity, and the success of some of the highest caliber open source projects. The viral license means that when a GPL licensed software "touches" any other software, it too becomes GPLed. Most other licenses are not viral. For example, code covered by BSD -like licenses can be freely converted to commercial code. Even GPL's close relative LGPL while requires that all modifications to the code stay open, is compatible with non-GPL software.

The sources that Elusiva needed were covered by GPL. We started doing research into what is actually considered "touching" GPL code. After all, Linux computers running open source Linux kernel and GNU userland covered by GPL are allowed to talk to Windows machines. It turns out that as long as GPL and proprietary applications  are running in as separate processes, they can talk in a way that would not violate GPL.
We immediately relealized that shared libraries - .so files on Linux and .dylib on Mac OS X would not work. We would have to load second process into a separate address space and communicate between rdesktop and the plugin processes using an interprocess communication mechanism.
We understood that such design had the potential to benefit not only Elusiva, but all software vendors working with Microsoft remote access platform. Elusiva R&D searched the Internet for anyone else attacking the same problem. This led us to use one of the better ideas proposed by Simon Guerrero as a foundation for our solution.

Simon's patch adds the following functionality to original rdesktop:
- new command-line options to specify extension parameters (extension path, virtual channel name)
- extension launching using fork and exec system calls
- opening unix pipe between the rdesktop process and the launched extension process
- forwarding of received rdp packets from the network to the appropriate extension (revised and improved by Elusiva)
- forwarding of extension's rdp packets to the network (revised and improved by Elusiva)

The key moment is communication between rdesktop process and extension process via unix pipe. GPL does not prohibit such communication between GPL'ed process and non-GPL'ed process.

Elusiva modified rdesktop is available on our website in the Open Source section in the source form and on our downloads page customers can obtain precompiled Linux and Mac binaries.

To curb fraud and abuse, the FTC already requires medical practices to scan the insurance cards and IDs of all patients. In accordance with the HIPAA act, by 2013 health-care providers in the United States will have to complete the switch to fully electronic medical records systems.

While electronic health care software offers instant access to charts, lab results, billing information, prescriptions and more, running a health care practice requires more than just medical expertise.

With health care facilities moving steadily to institute information technology – in order to provide more accurate patient care, protect patient private documents, as well as maximize billing efficiency – industry experts forecast a greater need for business analysts, program managers, HIM build experts for a variety of applications, and registered nurses with IT experience.

While doctors, hospitals, outpatient providers, FQHCs, clinics, pharmacies, labs and ancillary operations will be moving forward with EMR implementation, the greatest challenge will be in achieving "meaningful use" in order to qualify for state and federal funds. To a significant extent, therefore, the success of health care providers will rely on enterprise architects designing both systems and data-flow to achieve Health Information Exchange.

A “local” EMR implementation that cannot exchange clinical summaries, e-prescribing and receive labs, for example, may not be eligible for funding in 2011.

As health care providers continue to implement the switch to computer based practices, the most important decision they will make is which EHR package to select, and how to ensure it will meet the tomorrow's needs.

EMR and PM platforms can be broadly categorized as either:
    Premium feature-rich products from established industry leaders including PCTI, GE, NextGen, AllScripts and Cerner, or
    Simpler often web-based products that frequently come with less sophisticated user-interface features.

While premium products can be more expensive to acquire, better software generally improves the overall productivity of medical office workers. Properly utilized, an EMR platform will eventually pay for itself.

In addition to the costs of software licenses, heath care providers must also maintain the actual package.  Installing a complicated software product on a single workstation can be extremely involved.  As the operation expands, there might a need to add more stations in the same office, or in different locations.  Practice management and patient medical records data must be synchronized – and accessible to all authorized employees – from all computer stations. 

Installing the EHR package on every station might not even work. Some packages are designed to serve multiple workstations using a data repository on a central server. This architecture – known as “client-server” – works well on a local area network [LAN]. Using client-server software over the Internet, however, usually requires an additional VPN solution, and expensive commercial-grade Internet connections linking each satellite office.

This is extremely important to any health care organization in which not all practitioners always work from the same central office.  In order to achieve all of the IT goals now required for a modern heath care organization, one must start by building a flexible IT infrastructure – one that provides applications and data to users on demand, without sacrificing information integrity.

Increasingly, knowledgeable health care IT administrators are turning to server-based computing [SBC] to provide a secure yet flexible infrastructure.  An SBC setup means all processing is performed on servers maintained in a secure IT hosting facility.  This facility is accessed over an encrypted network connection from end-point devices called clients.  In addition, server-based deployments can perform well over residential-quality Internet connections.

In order for an on-demand computing platform to succeed in health care, it must support industry specific business processes, including:

    Support for microphones used by doctors for transcription.
    Support for easy scanning to acquire medical and practice images, as dictated by FTC Red Flag and HIPAA.
    Integration with local printers and other hardware peripherals.

Another major requirement in making any business process computerization successful – with calculable benefits – is a simple intuitive interface, so that non-technical end-users can utilize the system without special training.

Prior to designing our platform, we at Elusiva conducted hundreds of customer interviews, and organized a number of focus groups, to better understand the needs of our potential customers.  These initial brainstorming sessions provided considerable direction in designing our products to meet specific end-user needs.  It is no surprise, therefore, that our products – including local scanning for Remote Desktop, and the complete application access suite – power thousands of health care IT solutions around the world.  Customers of all sizes – from the smallest medical offices to extensive hospital systems and EMR software vendors – trust Elusiva to solve their essential business infrastructure needs. Among the health care leaders who exclusively use Elusiva products as part of their offering include: British health care software leader PCTI – the maker of Docman, QuickEMR, MedWorxs, as well as many others.

Some customers are unclear what is the major idea behind Elusiva Virtual IP and when would they need to deploy IP address virtualization for terminal services.

Let's image the following scenario: a 100 physical desktops office decided to switch to server-based computing in order to improve security and save on desktop maintenance. The office IT administrator wants to complete this transition with as little changes to their infrastructure as possible.

Given enough RAM, a single Windows Server with Terminal Services can easily handle load sufficient to accommodate 100 users. Let's assume that office employees are all using only terminal server -friendly applications. Therefore, no special extensions such as Remote Scanner or Remote Sound are needed.

An administrator still could have the following problem:
The office uses a simple firewall appliance to protect the company LAN against malware and to limit or monitor the employee access to the Internet. A typical SMB firewall appliance is priced under $1,000. It does a good job performing URL filtering, utilizing IP addresses of desktop and laptop computers as the primary means of identifying local communication endpoints. This works well in an environment where each desktop is a dedicated computer so it already has a unique IP address. In a server-based computing setup, when all processing is performed on terminal servers, user-sessions share server resources and therefore all share the host server IP address. This IP sharing completely defeats SMB security appliances.
In addition to firewall appliances, some client-server business applications were programmed to use IP addresses as client identifiers. While it is theoretically possible to rewrite these legacy applications implementing algorithms compatible with server-based computing, reprogramming an existing application is exceptionally expensive. Even when source code and engineering talent is easily available, it requires labor investment to change the code and additional time for testing. Depending on the amount of work and the size the organization, rewriting legacy code may completely defeat any cost savings realized by deploying centralized on-demand virtual desktops.

Elusiva Virtual IP is an inexpensive off-the-shelf software allowing sessions running on terminal servers to maintain a unique IP address for each session. Virtual IP supports several IP address allocation strategies including direct mapping to sessions, allocation from predefined address ranges and substitution the application visible IP address with the client address.

Note that client IP addresses are visible only to applications running on the terminal server. Meanwhile, Virtual IP addresses allocated from a range are assigned to the actual network interface of the terminal server and are fully visible on the network. It is important to remember that networks with a DHCP server already have a reserved a range of IP addresses for DHCP clients. This range should not overlap with any of the Elusiva Virtual IP diapasons.

Customer feedback is the most valuable source of information any manufacturer can have. Thanks to conversations with Elusiva customers, we knew for for several years that scanner redirection for terminal services was a highly sought piece. The actual product - Elusiva Remote Scanner was released less than one year ago. It has by now become one of the most requested items. Our scanner for Remote Desktop Protocol plugin has been deployed to power all sorts of real world IT solutions including electronic medical records (EMR/EHR), document management systems, legal and health-care practice management and more. In addition to hundreds of value added resellers, computer software industry leaders, including British HNS leader PCTI Solutions Ltd - the maker of Docman the most recognised 'practice specific' Document Management System in Primary Care, SoftDocs - leader in electronic document management and paperless office solutions, and many others partnered with Elusiva in to provide seamless scanning for on-demand computing environments.

Elusiva Remote Scanner software includes a special process displaying the list of redirected scanners and any warning or messages that Remote Scanner software wants to communicate to end-users. This functionality is implemented using an icon in Windows system tray. Several administrators contacted Elusiva customer service asking how they can remove or hide the Remote Scanner notification icon. We were told that in some instances this icon confuses end-users. For example, when scanning extension is not installed on the end-device, Remote Scanner notification icon will warn that scanning is not possible displaying an appropriate message balloon. This notification icon will also advise end-users when the number of licensed connections has been exceeded and show other relevant information. At the same time, a warning message like 'Remote Scanner client is not accessible' does not mean that there is something wrong with the access device. Devices that do not have scanners attached should not load the Elusiva scanner over remote desktop software plugin as to not to use a license which then can be utilized by a connection from a device with local scanners. Some end-users see a warning and assume that something is wrong with their system contacting administrators. Hence, we were asked whether this notification can be disabled.

I knew that the notification service is implemented by the RemoteScannerTray.exe userland process. This is a regular process and closing it does not interfere with the actual scanner redirection functionality. Usually, when a process is being started either at the start of the session of by a terminal server, it is listed somewhere in the Windows registry database. A quick registry search reveals the location where the tray icon executable is listed, among others, under HKLM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\StartupPrograms. We remove the tray notifier process name from the list and after we close the old the session. Now, we start a new remote desktop session and see that the Remote Scanner icon is gone from our system tray.

This however may not be the best way to solve the problem. Now, customers who are want to, yet unable to scan would have to manually start the tray process to see what is causing their problems.
If we wanted some users to see the tray and other not see it, we could script the notification service into Windows profiles. Organizational units [OUs] seem like a good place to do this.
In reality however, most administrators probably want to redirect scanners from those devices that have scanners attached, regardless of the username. I decided to try to solve this need with a logon script. Let's assume that we already have or can easily make a database of all client devices that have scanners attached. Windows environmental variable %CLIENTNAME% within remote desktop session, including a logon script, will return the name of the client device. We add a line to the the startup script to check whether the client device name matches one from our database then start the tray notifier for client devices with scanners. This is already a much better solution. The remaining shortcoming is that we scripted the Remote Scanner tray from our logon script. This means that our script won't catch reconnects and disconnects. In a situation when a session was started from one device, then disconnected and later resumed from a different access device, the tray notification message might again spook end-user. One possible solution to the this issue issue is to kill the tray notification process upon every disconnect and run the same check during a reconnect.

In order to request an evaluation of any Elusiva products, or to receive pricing information in the Elusiva online store, visitors have to register with Elusiva.com and verify their email address ownership. Some consider this to be a serious annoyance and complain to Elusiva customer service. We want to explain our position and the reasoning behind asking for an email address.

We ask visitors to sign up not for spam purposes or to bombard registered users with countless emails. In fact, we give those who sign-up on our website the option to refuse such communications from Elusiva and/or our affiliates. And our pricing is not a secret reserved for our special online members only, and we will gladly provide the pricing for our products to anyone calling our offices.

There are multiple reason that made Elusiva require registration, in order to view specific portions of our website and to place orders for software. As a practical matter, we send all trial and purchased keys for Elusiva products via email. We validate the emails so that before we send the keys we can be certain that users will receive them. Additionally, by validating email address ownership we eliminate the possibility of Elusiva web server being used to relay spam.

All Elusiva products are free to try before buying. We allow users to return to the Elusiva website to request as many trial keys as they want. We ask for registration information to both personalize user-experience and to market related products to users opting to receive this information. This allows Elusiva to keep marketing expenses to a minimum, and supply all interested customers with evaluation software free-of-charge.

The Elusiva online registration process takes only a minute or two. We simply ask for some information, beginning with an email address. Once the email address has been verified, the newly registered user is free to enjoy all the benefits of an Elusiva online account, including access to trial downloads, free product extensions, and special areas, such as the Support Forum. Elusiva online membership also allows users to view and manage their activity on the Elusiva online store, including access to order history and more.

We already downloaded and installed Universal Printer on our client. The client part of Elusiva Universal Printer is implemented by UPrinterClient.dll from Windows System32 directory - %WINDIR%\System32. We will also install the Remote Sound client. The server pieces have to be installed on SBS host. We already did this for Universal Printer, earlier.

Let's make a backup of the tsweb.aspx file in case, in case we will accidentally break something. We now find the line with «Device redirection options» in tsweb.aspx file and add new line under it with the text «MsRdpClient.AdvancedSettings.PluginDlls = "UPrinterClient.dll, RdpSndClient.dll"». That was it. We are done, as soon as we restart Small Business Server host Operating System.

We now once again connect to RWW and open a new session. This time printing over terminal services finally works. All printers are being auto-created just like with a regular client. If we remembered to install Remote Sound server on the SBS computer, when we open Windows Sound Recorder the record button will be enabled and other programs will have access to a local microphone even from within Remote Desktop sessions.

The technique demonstrated to configure Remote Web Workspace for Elusiva plugins, is applicable to other products developed by other software companies and individuals.

Remote Desktop Protocol, originally developed for Windows NT 4.0 Terminal Server Edition, has its roots in even older protocol - ITU-T T.128 (aka T.SHARE) application sharing protocol.  Originally, RDP had many shortcomings, making it ill-suited for high-latency networks and/or users who needed to use 'multimedia' software. Overtime, Microsoft has greatly improved the Remote Desktop Protocol, covering more deployment scenarios with each operating system release. These enhancements included compression for better performance over public networks, support for higher color-depths, better client-to-server peripherals redirection, improved caching, and more recently various improvements for making RDP friendlier to multimedia-enabled applications.
One highly anticipated feature was application publishing - the ability to stream individual application windows instead of a full desktop. Publishing allows seamless blending of local and remote applications in a way transparent to the end-users. This feature was long available using a pricey terminal server extension - Presentation Server from Citrix Systems. Adding Citrix into the mix however, greatly increased the price of the overall solution making the start-up costs prohibitive for many customers.
Windows Server 2008 finally came out with application publishing in the base operating system. This feature was significantly further improved in the next release - Windows Server 2008 R2.

A customer running Elusiva Terminal Server Enterprise on Windows Server 2008 R2 reported that the platform does not allow properly publishing Windows Explorer directories. The customer was pretty sure that he correctly configured everything using 'Publishing Wizard'. Below is the excerpt from the email:

I want to publish the My Computer shortcut. The properties of the published app look like this

Target: C:\Windows\explorer.exe

Start in: C:\Windows

Parameters: /E,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

When trying to open the published app, it opens windows explorer but defaults to the my documents folder.

We easily reproduced this problem in-house and asked QA department to investigate. First, our testers tried publishing a directory using Remote Desktop Services RemoteApp and Server 2008 RDP files. This immediately revealed that the limitation is not connected to Terminal Server Enterprise, but rather is related to the behavior of Windows Explorer. Our customer still had a problem, however. We wanted to help. One of the programmers quickly came with a work-around:

create a batch file to invoke explorer with the necessary arguments,  put it in windows directory (c:\windows for e.g.) and add it into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key.
Batch file may look like this: myexp.bat

c:\windows\explorer.exe  /E,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

This is a very cumbersome way to go around publishing a directory, however. We decided to look whether a more straightforward solution was possible. After further investigating, our QA lead discovered this Windows Explorer 'limitation' is in-fact a policy option. Setting TS RemoteApp Manager ->Terminal Server Settings-> Users can start listed and Unlisted programs in initial connection, immediately resolves the problem with published applications for both Server 2008 R2 and Terminal Server Enterprise. Changing security policy to permit unlisted programs, allows for publishing of specific directories, in addition to desktops, applications and documents.

Redirecting TWAIN scanners under 64-bit Windows client OS or detangling 32-bit and 64-bit RDP plugins mess.

Customers using Elusiva Remote Scanner sometimes report that server does not see correctly installed Remote Scanner client. Remote Scanner icon in system taskbar warns that Remote Scanner client is not accessible. After customer support investigated this problem, we discovered that this issue only happens on 64-bit Windows clients and never on 32-bit Windows. We reached for answers to our Research and Development and received the following explanation.

Starting with Windows XP, Windows client OS became available in two flavors 32-bit also known as x86 and 64-bit known as x64. The main benefit of x64 architecture compared to 32-bit Intel - much larger amount of RAM that x64 systems can address. When 64-bit Windows client was initially released, most users were still running the 32-bit version. In fact, often times x64 compatible desktop/laptop motherboards had 64-bit mode disabled in BIOS so that the processor worked only as x86 CPU. This was fine for most users since x64 drivers for Windows XP were difficult to find.
Newer client OS releases: Windows Vista and finally Windows 7 took 64-bit mainstream. Today, many workstations and notebook computers come with x64 Windows preinstalled. However, there are still sometimes issues including various aspects of functionality...
x64 Windows client OS comes with two executable versions of Microsoft Remote Desktop Connection program. [Original Windows XP x64 came standard with RDP 5.x client which was 64-bit only. A free upgrade to Microsoft Remote Desktop Connection 6.0 is required for the following to work.]
First is 64-bit executable is located is %WINDIR%\System32\ and second is 32-bit binary located in %WINDIR%\SysWOW64\ directory. The file-name of both binaries is mstsc.exe.

x64 Windows OS has two subsystems for executing programs - one for 32-bit processes and one for 64-bit processes. The two subsystems can communicate. At the same time, a process running within x86 system will see only 32-bit programming interfaces while 64-bit processes will see x64 API.
Microsoft Windows comes with TWAIN32 layer - 32-bit layer implementing TWAIN scanning interface - standard maintained by the TWAIN consortium. TWAIN32 comes with 32-bit Windows client and is available within 32-bit subsystem of 64-bit Windows. At this time, Windows does not have TWAIN64 layer and processes running outside x86 subsystem do not have access to TWAIN API.

Going back to our original problem, in order to use Remote Scanner from 64-bit Windows, we must use Remote Desktop Connection mstsc.exe process from SysWOW64. However, when we start mstsc.exe from %WINDIR%\SysWOW64 there is still the same error - client is not accessible. It is because, Windows sees that we have a 64-bit client and starts x64 process even when we were explicitly trying to execute the x86 counterpart. Renaming mstsc.exe from %WINDIR%\System32\ helps and now we finally see all our scanners.

This is however, not the end of the story. We covered the above issue on our support forum at http://www.elusiva.com/forum/Default.aspx?g=posts&t=261
A customer who followed detailed instructions from the above URL, complained:

... Client is using UniPrint and RemoteScanner. As per Igor's instructions below, I was able to get RemoteScanner to work in the 64 bit environment by using mstsc.exe from the Windows/SysWOW64 folder specified below.

When I do this, however, UniPrint will no longer function. If I run mstsc.exe from the windows\system32 folder, UniPrint works just fine, but RemoteScanner will not function.

I need to get both of these programs working at the same time.

The problem seems to be that UniPrint [competitor to Elusiva Universal Printer product] installer registers the x64 extension, but does not copy and/or register the x86 plugin within the 32-bit subsystem, on 64-bit Windows OS. The solution would be to copy x86 DLL and manually create whatever registry entries necessary. Perhaps, UniPrint will consider changing their installer script so that both 32 and 64 -bit subsystems see UniPrint plugins. Elusiva RDP extensions register both 32 and 64 -bit plugins so that whether x86 or x64 Remote Desktop client is used, it will see all installed plugins.

The bottom line - while 64-bit Windows client OS is finally mainstream, some applications still work only in 32-bit subsystem. Even when 64-bit programs are not available, it might be possible to utilize 32-bit software on x64 clients.