[#rdcrdp]: Remote Desktop Connection (“RDC”) (over Remote Desktop Protocol (”RDP”)), a.k.a. “Terminal Services”
This may be called RDC, RDC/RDP (meaning RDC over RDP). Often references to RDP are really referring to using RDC over RDP, and so it might not be entirely incorrect to say that a screen session is being shared with RDP (because RDP is, in fact, involved), although referencing RDC would be more technically clear. (RDP is a foundation that may be used by RDC or other software, such as when MMC restarts remote services using RDP.) The newer terminology preferred by Microsoft for these RDC and/or RDP services are “Remote Desktop Services”; the older terminology was “Terminal Services”, sometimes abbreviated TS, and sometimes called “Terminal Server” (or “TServer”).
- Protocol details
- [#rdcsecur]: RDC Security considerations
Unknown, it is possible that there are issues similar to VNC sessions being unencrypted and perhaps concerns about encrypting the authentication mechanism may also be an issue. If so, these may be resolved by:
- port forwarding with an SSH tunnel
- Routing through an RDC proxy which may be communicated to using encrypted methods. This approach may be taken by Microsoft's “Remote Web Workplace”.
With some versions of the software, such as the server software built into Windows Server 2003, the server may broadcast the possible domains that may be logged into. Therefore, the name of any domains being broadcasted are not an unshared secret which may be an effective portion of the unshared secret credentials used to authenticate.
Some client software may broadcast the name of the domain which was last logged into. (In particular, this was noticed by an environment where the clients kept connecting to the same server address, which was a loopback address (IPv4 127.0.0.1) that was combined with some sort of tunneling). This ended up meaning that the various servers connected to could get the domain names of other domains that the clients had previously connected to. (This concern remained unresolved; apparently the decision was to simply allow such information to be shared.)
RDC is often implemented over another protocol, such as RDP, which may offer access to more things (such as MMC snap-ins, some of which are seen in Computer Management, and also such as some tools that Sysinternals has released) than just remote desktop support. This might often not be much of an issue, since the remote desktop may often post a larger security risk than these other alternatives. However, the other items may not have the same authentication requirements that are posed when creating a remote desktop session, and if RDP is left on even when RDC is disabled then those other avenues might still be options.
- RDC server software
- Provides an X Desktop. (Runs on Unix)
- xrdp is based on FreeRDP (and rdesktop). However, a potential advantage of FreeRDP is that there is wfreerdp, for Microsoft Windows. GitHub article on FreeRDP for Windows, built with Visual C++ 2010 provides a binary for Windows Vista, and references /VMLiteRemote.zip from http://www.vmlite.com.
- [#remdsksv]: Microsoft Windows Remote Desktop Services
- [#termsvcs]: Names/Terms related to Remote Desktop Services
This was formerly known
as “Microsoft Windows Terminal Services”. A server running such
Terminal Services was often referred to as a “Terminal Server”, and
so the term “Terminal Server” often refers to technology involving
a server running Terminal Services. The term
refers to the client software.
- [#remdkmsv]: Main/common server software distributed by Microsoft
- Terminal Services
- How to specify the TCP port used by RDC
Petri.com IT Knowledgebase: add a new RDP listening port to Windows 2000/2003 Terminal Server says HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp PortNumber (hexadecimal format)
"HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"/v PortNumber
"HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"/v PortNumber
PortNumber REG_DWORD ” ”0x
0xd3d = 3389
“RemoteApp” refers to the idea of sharing a single program, rather than an entire desktop. See: RemoteApp.
- Remote Assistance
Available in XP Home Edition (and other operating systems). Windows Vista has a reference to this in the Tools tab of
. It may run
(although the location of that file is probably, in same way, based on where Windows was installed to.)
This may not be a very good long term solution, but will be covered here anyway. On the Remote tab of the System Properties screen, check the box that says “Allow Remote Assistance connections to this computer”. Choose the “Advanced...” button if desired.
Once that is enabled, an invitation needs to be made. In Windows Vista, this is done from
which may be found from the Start Menu in the “Programs”/“All Programs” section under a folder called “Maintenance” and using an icon called “Windows Remote Assistance”. With Windows XP, this was more clumbsy as it was done from the operating system's Help section. A page on TechNet about Remote Assistance may help. Perhaps see also: Article/Tutorial in Remote Assistance in Vista
- [#remdsktp]: Remote Desktop
Petri's guide says “in Windows 2000 Advanced Server, this feature was called Terminal Services in Remote Administration Mode”. This cited/quoted material may benefit futher from some verification, by checking W2KAdvSvr...
Remote Desktop may come built into the operating system on some more systems than some of the other alternatives listed. However, it must be enabled.
- How to enable the Microsoft's Remote Desktop server
There are multiple steps to getting this functionality to be available. The steps are described in a specific sub-section: Remote Desktop Enabling.
- Verifying the security
If the client is getting warnings, see certificate warning window presented by
- Allowing more than one session
When a new user logs into Terminal Services, the newly created session may take over an already-existing session. If anybody was using that already-existing session, they lose access to it. If the already-existing session was a remote Terminal Services session, the already-existing session may simply close. If the already-existing session was on the local console (that is seen on a physical monitor), then the local console may look (to anybody who is watching) like it is being logged out.
The following solutions may help to allow more than one user. Simply choose one as desired.
- One solution: TS Cfg / Registry
- Registry Values
Using the Registry can be preferable over using graphical interface methods. (Using the registry is likely easier to automate.) Unfortunately, there may be multiple locations in the Registry that may end up affecting this setting. Therefore, using one of the other methods may be preferable in some cases. (Or, perhaps a single location per operating system can be readily identified. Those wishing to automate things should not be afraid to investigate this method.)
It seems likely that this is controlled by a Registry setting. Specifically, this is handled by a REG_DWORD called fSingleSessionPerUser which may be set to 0 or 1. Specifically, in HKLM\SYSTEM, there should be a CurrentControlSet (and perhaps others, like ControlSet001 and ControlSet002). Within the relevant Control Set key should be a Control\Terminal Server key. There are indications the setting may also be elsewhere. TechNet Core Services: fSingleSessionPerUser indicates the fSingleSessionPerUser may be in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\. Post about this setting suggests this “second key should not exist” or it should “exist with a value of” zero. MSDN page about Terminal Services Machine Policy indicates this is viewed as a TRUE or FALSE value. (Setting to zero would be FALSE and would allow multiple users.)
- Using Terminal Services Configuration
A graphical interface is provided. Chances seem high that this approach will be provided in future versions of Microsoft Windows, and will change whatever Registry entry is needed for such a version of Windows.
One way to do that may be to use
(note: in Win Svr 2008,
Terminal Services Configuration.lnk
C:\Users\All Users\Start Menu\Programs\Administrative Tools\Terminal Services\
C:\Users\All Users\Start Menumay now be a Junction to
C:\ProgramData\Microsoft\Windows\Start Menu\) which points to the
(assuming that the operating system will be set up to run
when it encounters the
(This was written for Win Svr 2008.) Once in the “Terminal Services Configuration” object, find the “Edit settings” section. Access the Shortcut/Context Menu of any setting (by right-clicking on the setting), and choose Properties. On the “General” tab is a checkbox for a setting called “Restrict each user to a single session”. It defaults to checked, which makes it show up as “Yes” on the main “Terminal Services Configuration” screen.
- Local Computer Policy
Edit the local computer policy. There may be multiple methods to do this, including:
One way is(/may be...
it is in Win Svr 2008) to run
and “Add/Remove Snap-in...” (Ctrl-M), then find “Group Policy Object Editor. After selecting that MMC object, be sure to choose to “Add >” the object (don't just say “OK” which shows all previously-added objects). Remaining steps should be self-evident: choose the default “Group Policy Object” which is the one known as “Local Computer”. Then after accepting the added objects, look under the “Console Root” folder, and review the “Local Computer Policy” object.
Within the “Local Computer Policy” object, drill down into “Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections”. There should be an object called “Restrict Terminal Services users to a single remote session”. The default of “Not configured” is to use a setting from the Terminal Services Configuration tool: specifically the “Restrict each user to one session” setting.
- Terminal Services and/or RWW
- For terminal services, setting this up is not detailed in this section, as the setup may be more elaborate. For RWW, if an RWW server is already set up then go to the server (e.g. https://servername.example/remote/ ) and login with that. Note that the end user will need to be allowed. Also, it may be helpful/required for the end user to have Administrator privileges on the RWW client.
- Command line applications
Here are some command line applications. (This may be particularly useful for Windows Server 2012, since the GUI
from Windows Server 2008 seems to have gone away.)
To list connections, you'll need to know the name of the server, and use:
This will show session IDs. To close/terminate/kill/end a session:
- Integration with a web server
- [#rdwc]: Remote Desktop Web Connection (“RDWC”)
- Remote Desktop Connection Web Connection Overview (archived by the Wayback Machine @ Archive.org) notes that the “The Remote Desktop Web Connection is a Win32-based ActiveX control (COM object) that can be used to run Remote Desktop sessions from within” “Internet Explorer 5 and later versions?on any Windows 32-bit operating system.”
- Remote Desktop Connection Web Connection Software Download has a “software update” (as described by the page) which provides the functionality for Windows NT Server 4.0 with IIS 4.0, Win 2K w/ IIS 4.0, or Windows XP Pro with IIS. However, this is an update for XP: MS Q284931: Installing Remote Desktop Web Connection in Windows XP Pro shows installation instructions for XP Pro which does not mention any download requirements. However, XP Pro's IIS needs to be installed (which is a process described by that article).
- The Internet Explorer web browser visits /tsweb on the web server to make this happen.
- Setting this up requires IIS to be enabled. Also, the Remote Desktop must be enabled from the Remote tab in the System Properties. To do that, either see MS Q284931: Installing Remote Desktop Web Connection in Windows XP Pro or the guide (which also has info about IIS) at Using Remote Desktop in Windows XP Professional (archived by the Wayback Machine @ Archive.org) (which has info about opening up an exception for the Windows Firewall).
- Perhaps see also: Petri guide to Download Remote Desktop Web Connection for Wimndows Server 2003 and Petri guide to Install remote Desktop Web Connection on Windows Server 2003.
- Terminal Services Web Access (“TS Web Access”)
- [#remwbwkp]: Remote Web Workplace (“RWW”)
Wikipedia's article on Microsoft Remote Web Workplace: section on “Offsite Access”, as well as text near the top of the article, identifies the operating systems that support Remote Web Workplace. Those operating systems are “Microsoft's Windows Small Business Server and the midsize business-focused product, Windows Essential Business Server”.
To access this, a web client must visit the login page which is located at /remote from the web server.
Then, once logged in, the user may be able to choose from various systems to be able to have access. Wikipedia's article on Remote Web Workplace: section called “Means of Access” describes a rather secure setup: Only when a user requests a session via the web GUI, the web server will create a proxy that listens on port 4125 and only for connections that come from the address that requested the remote access session. The proxy created by the web server will then connect to the client's port 3389.
Troubleshooting: To successfully run the ActiveX control that is needed to make a remote connection, the web client may require elevated permissions. (In Windows XP, make sure that the user is part of the “Administrators” group of the machine which is running the web browser/client.) If a user gets to the login screen but then cannot log in, see the troubleshooting for Remote Desktop.
Note that for checking E-Mail, web servers that support RWW may also support OWA. (If E-Mail is the primary thing to be checked, users might to able to get to their mail more quickly using OWA, and also may be able to do this even in cases where they are using browsers that don't have full administrative privileges. For browsers that don't support RWW, OWA Light may work.)
What may be shared:
- Sharing printers with Microsoft Windows Terminal Services Client
The ease of sharing printers can
depend on factors including what version of terminal services is being used
(on the server).
- Terminal Services EasyPrint (and other info for Vista and Server 2008)
- Microsoft KB 951616: “Description of the Remote Desktop Connection 6.1 client update for Terminal Services” Microsoft KB 952155: Description of the Remote Desktop Connection 6.1 client update for Terminal Services in Windows XP Service Pack 2 references this for servers using Windows Vista and newer operating systems (including Windows Server 2008), and clients which are using both Terminal Services client 6.1 and .NET Framework 3.0 SP1. A TechNet article titled “Terminal Services Printing” notes that “Although the Specify terminal server fallback printer driver behavior Group Policy setting still exists, it can only be used for computers running Windows Server 2003 with SP1 or Windows Server 2003 with Service Pack 2 (SP2).” So it seems this setting exists but has no impact. The reason this is not impactful is given by that same web page: “The terminal server fallback printer driver is not included with Windows Server 2008.”
- Windows Server 2003 SP1 and SP2, RDP 5.2 client
See also the section about Windows Server 2003.
Terminal Services in Windows Server 2003 Service Pack 1 describes the “Terminal Server fallback printer driver”. (More info about this not being supported/usable in Vista/2008, even though the group policy setting does seem to still exist, is noted in the section about remote access servers running Vista or Server 2008.) If the printer drivers do not seem compatible, success might be achievable if the client's local printer's driver supports the HP PCL standard or the Adobe PS standard. The way to support these standards is to use the “Terminal Server Fallback Printer Driver”, although using this driver requires some non-defualt settings as noted below.
To use the TS Fallback Printer Driver, modify the group policy which is in “Administrative Templates\Windows Components\Terminal Services\Client/Server data redirection” and which is called “Terminal Server fallback printer driver behavior”. First, make sure the setting is enabled. Second, specify what happens if a printer driver is not found. Flip this setting from the default “Do nothing if one is not found” setting to another setting, such as “Show both PCL and PS if one is not found”.
The client will need to be a supported operating system: Terminal Services in Windows Server 2003 Service Pack 1 says “Client must run Windows 2000 or Windows XP”. (It is possible that is an old document, and so perhaps newer opprating systems would work. However, it is odd that Windows Server 2003 isn't mentioned as a possible client.) Also, the clients need to use RDP 5.2, which can be done by using the installer found on the terminal server at: %systemdrive\system32\clients\tsclient\win32\msrdpcli.msi
The Terminal Services in Windows Server 2003 Service Pack 1 also describes a need for clients to trust the server's certificate.
- Windows Server 2003
Printers that use a port with a name that does not start with COM, LPT, or USB won't be redirected by default: MS Q302361: Printers that use a port with a name that does not start with COM, LPT, or USB aren't redirected in remote sessions (by default) describes a registry entry to enable other ports. (This seems consistent with Win2K documentation: “Printing from Terminal Services” which indicates that LTP, COM, and USB ports are supported.)
- RDP 5
- Word document: “Terminal Services and the Printing Redirection Process (easily viewable with web software using Google Cache/conversion of tsprint.doc) notes that RDP5 came with Win2K. Win2K documentation: “Printing from Terminal Services” states, “Automatic Printer redirection is supported on all Win32 client platforms, including Windows 95, Windows 98, and Windows NT. When a client logs on to Terminal Services, local printers attached to LPT, COM, and USB ports are automatically detected and corresponding queues created in the user's session.”
- Win2K (client) info
- MS Q306566: How To Connect Clients to Terminal Services By Using a Terminal Services Client in Windows 2000 has a bit of info on this, including noting that “manual redirection of printers that are connected to USB ports is not supproted.” (Automatic redirection may work, however.)
- NT 4.0 info
- Microsoft says about ICA (and Windows Terminal Server), in KB MS Q239088 “Printer redirection is not possible with the RDP 4 client in Windows NT Server 4.0, Terminal Server Edition. In a Windows NT 4.0 Terminal Server environment, you must use Citrix MetaFrame and the Independent Computing Architecture (ICA) client to redirect client printers.” The page referenced Terminal Server Printer Driver Redirection Wizard and provided information about .inf files.
Trying to use different drivers may help make things work better. MS Q239088 specifically says, “if you are using third-party drivers or some Microsoft Windows 95/Microsoft Windows 98 drivers on the client, printer redirection does not work.” Using different types of printer drivers may help: often there are one or more of these basic types: PCL, PS, standard (“host-based”) hardware-specific, and universal.
If the above doesn't work, one may be able to get an existing driver to work by modifying a *.INF file as noted by MS Q239088. MS Q214593 describes a similar technique, modifying a text file, when using Terminal Server with a (Citrix) Metaframe ICA Client. The text file to create ends with .inf and the content of the file uses the syntax shown by the %systemroot%\system32\Wtsuprn.txt file.
If this isn't working, other solutions may be available. A page called Differences Between Several Universal Printer Solutions provides some options (which might all be proprietary and at a cost). Another option to consider, though, may be to use a different printer.
A server for Win9x has not been found. Using RFB/VNC may be the best option to perform much of the similar functionality. (However, some features, such as audio transmission, may not be implemented using this approach.) However, there are some RDP servers that use open source code: FreeRDP (and specifically the wfreerdp code/port/build) might be the most promising base to use to start creating such a thing.
There are also a number of WMI providers that are built into modern operating systems, which which seem to be focused on just this protocol. These are RDAccount, RDNIC, RDPermissions, and RDToggle.
- [#rdcclisw]: RDC client software
Note: Before using any of these options, review RDC/RDP protocol considerations.
- [#remmina]: Remmina
Remmina's home page lists RDP as says “Currently RDP, VNC, NX, XDMCP and SSH are supported.” Reminna's home page listing its Features lists plugins including those just mentioned, and also Telepathy. See: Praise of Remmina.
This software uses, GTK+. Developed under Debian and available for Ubuntu (as noted by Remmina's download page, the page notes, “You should be able to find Remmina package in most popular distributions.” There is a FreeBSDPorts.info page on Remmina plugins. At the time of this writing, OpenPorts.se search for Remmina shows no port for OpenBSD.
- Software for use with Microsoft Windows
- Microsoft Windows Remote Desktop Connection
This software has been quite popular because various versions of this software, as well as the matching server software, have been bundled with some versions of Microsoft Windows.
This may have previously been known as “Terminal Services Client”, and may be run from the command line using
. The program does some interesting keyboard remapping, such as using Ctrl-Alt-End to mimic Ctrl-Alt-Del and Ctrl-Alt-“Numeric-pad-minus” mimicing Alt-PrntScrn. Alt-tab might switch applications on the remote system if the client's window is maximized, or switch applications on the local system if the client's window is not maximized.
- Obtaining the software
- Remote Desktop Connection (Terminal Services Client 6.0)
- For Windows XP SP3, this may be built in. For Windows XP SP2, update to SP3 or, less ideally, see Multilinugal User Interface (“MUI”) pack for the Remote Desktop Connection 6.1 client update for Windows XP SP2 (described by MS KB 952230) and/or the Remote Desktop Connection 6.1 client update for Terminal Services, described by MS KB 952155: RDC 6.1. For Windows Server 2003, see: KB 925876: Remote Desktop Connection (Terminal Services Client 6.0) client for both 32-bit and 64-bit versions of both Windows XP SP2 or Windows Server 2003 SP1/SP2. Some related documentation is in Microsoft's article: “Mobile Computing with Windows XP”.
MS Q306566: How To Connect Clients to Terminal Services By Using a Terminal Services Client in Windows 2000 has a bit of info on this, including info on what keyboard mappings are supported.
Petri's guide to specifying which TCP port is used involves exporting a connection from the Client Connection Manager to a *.cns file (named name.cns file, possibly just as an example) and editing the
Server Port=line before re-importing the *.cns file.
MS RDP Client software is referenced by MDGX's page on RDC and might be a 6.0 client for 9x/NT4/2K/ME (and XP/2003) which is older than the update from KB 925876 (and the newer XP update from KB 952155).
The Win98SE installation CD had \ADD-ONS\TSCLIENT\MSTSC\WIN16\ as well as \ADD-ONS\TSCLIENT\MSTSC\WIN32\ directories.
- Using the software
When using the software in Vista Home Premium, believed to be the first time the software was used, the “Computer:” drop down box showed a value of “Example: computer.fabrikam.com” (as grey text) until text was typed into the field (after those words still showed when the keyboard cursor was initially placed in the text field).
- Special keys
Some keys, such as Alt-Tab, might be sent to the server when this software is maximized, or may be sent to the client desktop when this software is in a non-maximized window. Perhaps most famously, the the 3 finger salute will get processed by the machine running the client software. Using Alt-Ctrl-End will mimic the 3 finger salute on the remote machine. (Unfortunately, there doesn't seem to be a real method to apply this recursively. So, if RDC'ed into one computer, one cannot then use that remote computer to RDC to another computer and then send a three finger salute to the second layer of remote connections. The only real solutions are to use different remote access software, or adjust traffic routing in a way to be able to connect more directly to the desired remote computer.)
MS Q306566: How To Connect Clients to Terminal Services By Using a Terminal Services Client in Windows 2000 has a bit of info on this, including info on what keyboard mappings are supported.
[#mstscert]: Seeing a certificate warning in
This may be more likely to be seen on newer versions of Microsoft Windows?
You may find a certificate warning similar to the following:
In this case, the certificate name is named after the computer.
Consider whether this warning makes sense. For a newly installed server that is using a self-signed certificate, the message of “The certificate is not from a trusted certifying authority.” does generally make sense.
If you have access to the server, then you can check this properly, in which2 case the recommended method to handle this is generally NOT to just ignore the security implications and blindly say Yes (and certainly does NOT involve checking the “Don't ask me again for connections to this computer” checkbox). Instead, properly check the details of the certificate and, after confirming its validity, let the computer know that the situation is okay. Following that process will achieve the generally desired goal of making the computer stop showing an extra and scary-looking window, while retaining security.
(This text might still be fairly preliminary.)
To do this, start by locating some details on the server. Run the following command on the server:
Then, on the client, use the “View certificate...” button.
The “certificates” hyperlink (at the bottom, where the General tab says “Learn more about certificates”) runs a Help program. The window is titled “Certificates”, and the page is called “Certificates Overview.)
Then on the client side, go to the [“Details” tab of the “Certificate” viewing window] to compare values.
(The “certificate details” hyperlink, at the bottom where a message says “Learn more about certificate details”, presumably causes some help to appear. Details have not yet been documented here.)
Start off by comparing the the “
” type (in parenthesis) on the server to the “Thumbprint algorithm”. Perhaps more telltale, compare the rest of the line in the “
” on the server to the Thumbprint on the client. While you're at it, also compare the “Serial Number” on the server to the “Serial Number” on the client.
[Viewing a Serial number of a self-signed certificate], [Viewing the thumbprint of a self-signed certificate] (Notice that when viewing the thumbprint, the above line shows the “Thumbprint algorithm”.)
If everything looks perfect, then on the client, go to the General tab and click “Install Certificate...” button. That will pop up a wizard.
Now, the tricky part is, upon reaching the [“Certificate Import Wizard”: screen to select which certificate store to use], do NOT just press the “Next >” button.
It *IS* desirable to place the cert into a specific store (and not the one that gets Automatically selected). As indicated by [“General” tab of a “Certificate” window] we want this to go into the store named “Trusted Root Certification Authorities”.
[“Certificate Import Wizard”: screen to select which certificate store to use, “Place all certificates in the following store” selected], and then choose “Browse”. A small [“Select Certificate Store” window] pops up, with the first option (“Personal”) selected.
Select [“Trusted Root Certification Authorities” on the “Select Certificate Store” window]. This will then lead to the [“Certificate Import Wizard” screen showing which Certificate store has been selected]. When that is properly showing the desired value of “Trusted Root Certification Authorities”, then proceed on to the “Next >” screen.
At this point, a [”Certificate Import Wizard” window, Review screen] will be visible. Most of the time, reaching such a window is a great time to proceed to complete the “wizard” window being used. However, this time, before pressing Finish button, read on just a bit to consider a warning...
- Instability warning
Now, one last warning before pressing the “Finish”. This has been known to not work well. (If the remote connection just really needs to be made, and if problems are highly undesirable at this time, just abort installing the certificate and go ahead and say “Yes” to connect this one time.) The problem is that the “Certificate Import Wizard” would freeze up. Also, sometimes, when the mouse moved, there would be beeps coming out of the speakers, and mouse clicks did not really seem to register at all. Weird, but true. (This was with Windows 7 Home Premium.) Using the keyboard to force the window closed seemed like progress was made:
Showed up. However, what was found is that if the “Certificate Import Wizard” window was forcibly closed, then accepting the thumb print did not achieve the desired results. The certificate warnings continued to occur.
When trying to install to different certificate stores (simply as an experiment), the error did not occur, but neither did this resolve the issue of certificate-related warnings appearing.
The ultimate solution was to press the 3 finger salute. For some reason, this surprisingly caused the [“Security Warning” prior to accepting a certificate (showing certificate name, origin, thumbprint algorithm, and thumbprint)] window to become visible. The 3 finger salute screen was exited cleanly using the Esc button, and things proceeded fine with the certificate going into the correct store.
If this story of system instability isn't too scary, then go ahead and press the button to proceed.
- [#rdctmnls]: Terminals
Open source (source code page for Terminals), the System Requirements for Terminals shows that it requires .NET and the page says, “First and foremost you will need a Windows machine. I have heard of people testing Terminals with Wine on non-Windows machines but most of what has been done locks us to good old Microsoft.” Note that this quoted text does not say that the testing (with Wine) resulted in people successfully using the software. What this ends up meaning is that this software requires a closed source operating system that already has, probably/certainly pre-installed, some software that accomplishes this task.
- Royal TS
- For Windows, alternativeto.net: Royal TS, About calls this Open Source although the web page suggests it is Shareware (limiting how many simultaneous connections it supports).
- Using a web browser
- Microsoft has released some ActiveX controls which are provided by the Remote Desktop Web Connection and Remote Web Workplace solutions for supported copies of Microsoft Internet Explorer.
- Solutions for Mac OS X
- Apple.com info on Remote Desktop Connection Client
- Software for DOS
- Old FreeDOS news article notes a non-free solution may be at Terminal-Services.Net / http://126.96.36.199/tsnet/dos.htm (although the URL provided did not seem to resolve when checked Nov 20, 2011: also Terminal-Services.Net did seem to work by redirecting to 2X.com which did have RDP-related offerings, but there might not have been DOS software being visibly offered at the site. Forum post about TS DOS Client indicates 2x merged with Terminal-Services.net.)
(For a related topic, see: ICA, for more technology based on Citrix's code.