Component Tales: A Window to a Remote Embedded Device –Terminal Services
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
In its disguise as “Remote Desktop” most computer users probably already have been in contact with Terminal Services. The name “Remote Desktop” describes the technology quite well, namely a desktop experience to a remote device.
When thinking of embedded usage scenarios for Terminal Services, device management and maintenance come to mind, of course, especially l if the device is headless and therefore hard to handle without a user interface. In addition, Terminal Services can save the development effort to provide , for example, a web-based configuration user interface. The user rights on the device can easily be managed locally or in an Active Directory domain in the same granular fashion one is used from a normal desktop system.
A bit of a difference - Terminal Services and Terminal Server
Despite the similar sounding name there is a big difference between Terminal Services and Terminal Server. Terminal Services are limited to a maximum of two connections and is intended for remote desktop scenarios, while Terminal Server, e.g. in its newest release coming with Windows Server 2008, is a highly scalable backend infrastructure, capable of providing desktop sessions to thousands of users. Needless to say that Terminal Server is not included in Windows Embedded Standard. For embedded scenarios Terminal Services are sufficient for most project requirements and it is good to know that the included RDP 6.1 Terminal Server client is able to connect to a Terminal Server farm as well. In addition, the hardware requirements for Terminal Server would be way out of scope for any reasonable embedded device.
If one is building just a thin client without the need to have remote desktop capabilities, including only the Terminal Server Client component from the catalogue is enough. In this case the device will be able to access a TS farm, but will itself not be remotely manageable via RDP.
Including Terminal Services functionality
The Terminal Services macro component is located below the Software\System\Management node.
It has dependencies on TCP/IP networking, the core TS components and Windows Logon (Standard). The services need Windows Logon because it works with user accounts and credentials. Images which use MinLogon to save footprint, therefore cannot leverage Terminal Services. The smallest images that can be created with the Terminal Services macro component included are about 200MB, if tailored well.
If you are creating a headless device, it is a good idea to have a look at the “Adding Support for a Headless System to your Configuration”, and “Message Box and Balloon Pop-Up Interception” topics in the Windows Embedded Standard platform help to get more information.
Configuring Terminal Services
From a configuration perspective not everything related to Terminal Services can be set up in Target Designer. User rights for remote users need to be configured after the system has completed the FBA phase, either locally or on an AD domain controller.
Best practices
With security in mind, adding Terminal Services opens an additional door to the system, which needs to be protected. Therefore, be aware that you need to set up suitable user rights management as well as a proper credential handling. All RDP users should have strong passwords. Security can be enhanced by blocking the RDP port 3389 on routers and firewalls at the edge to unsecure networks.
For maintenance use, it is convenient not only to use the classical RDP client, but to install the Terminal Services Web Control Extension component, as well. This component enables a remote desktop session from any computer running IE to the embedded device.
If programmatic configuration of the services is desired, be sure to have the Terminal Services Windows Management Instrumentation (WMI) Provider component included in the image. It offers native and managed ways to access the Terminal Services settings via WMI on the device. The VBScript code snippet below shows how to configure Terminal Services properties for the user account Alex in the Wechslernet domain.
Const Enabled = 1Const Disabled = 0Set objUser = GetObject _("LDAP://cn=Alex,ou=Development,dc=NA,dc=Wechslernet,dc=com")objUser.TerminalServicesProfilePath = 2"objUser.TerminalServicesHomeDirectory = ""objUser.TerminalServicesHomeDrive = ""objUser.AllowLogon = EnabledobjUser.SetInfo
From WMI, basically all settings and functionalities for Terminal Services, which are available in the related MMC console, are accessible.
Thin clients
One might wonder why there have not been many words about thin clients in a post that deals with Terminal Services. Although the technology used for thin clients is nearly the same, the approach and the architecture for this scenario are completely different and will be a topic in one of my upcoming posts.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009,Terminal Services
Comments
- Anonymous
July 22, 2009
The comment has been removed - Anonymous
July 23, 2009
Hi Peter, You are correct that Remote Desktop logs off the local user. This certainly is not desired in some use cases as You described. However, there is another approach that could be helpful in Your scenario depending on the task required. If the embedded device can be accessed via DCOM. One could use the Microsft Management Console (MMC - e.g. CompMgmt.msc) to connect remotely to the device, without any interference of the running application. This might not work for all existing maintenance tasks, but if you complement this with remote scripts for PowerShell (needs to be included in the image), then possibilities get quite interesting.