Last updated: 20 Oct 2020

• Overview
• Remote Desktop Services
  • Guest Remote Desktop Services
  • Virtual Remote Desktop Service
• Remote Desktop Clients
• Troubleshooting

Overview

A "remote desktop" is a means of interacting with an virtual computer's operating system desktop in a similar fashion to interacting with a real computer's operating system via its monitor and keyboard and mouse. The virtual computer's screen is displayed to you as a window of your real computer's screen, and key presses and mouse activity within that window are sent to the virtual computer.

Remote Desktop Services

There are two types of remote desktop services: those that run on the guest operating system as a service (Guest Remote Desktop Services), and those that run on the host operating system as a service (Virtual Remote Desktop Service).

Guest Remote Desktop Services

One of the most popular guest remote desktops is Microsoft's Remote Desktop Service, which uses the Remote Desktop Protocol, or RDP, to show that operating system's display, accept remote keystrokes and mouse activity and pass them into the operating system. Microsoft's Remote Desktop Service runs on a Windows operating system.

Linux systems also have a guest remote desktop service capable of running RDP: xrdp. When xrdp is properly installed, configured and enabled, it works like Microsoft Remote Desktop Service.

Virtual Remote Desktop Service

VirtualBox provides an optional "extension pack" which includes a VRDP service, which runs on the host after the extension pack is installed. SET Lab staff define virtual machines (VMs) and normally enable the "Virtual Remote Desktop Environment" (VRDE) per VM and configure it for use. A TCP port on the host is reserved for that VM and denoted as the VRDE port. It is used with the host IP address to define the remote desktop service to connect to. The host user name and its password are also used to connect.

Other useful VRDE configuration settings include the ability to have more than one user connect simultaneously to the same display, and what authentication mechanism is used to connect. All of these settings would be predefined for your VM(s) by SET Lab Staff.

There are several benefits to using this over guest remote desktop services. You can:

• watch the VM's guest operating system boot up and shut down and note any failures with those processes
• control the booting process
• watch the display/interact with a VM that has no guest networking enabled or perhaps one whose network is incorrectly configured in the guest operating system
• view the non-desktop console of a Linux operating system
• view the desktop when a guest remote desktop service is not available, running or properly configured
• remote desktop clients such as those on a Mac computer are sensitive to the type of guest remote desktop service running and may not connect to it, wherease VRDP seems to be easy to connect to
• connections from multiple clients is allowed via VRDP, whereas that is not the case with most guest remote desktop services

Remote Desktop Clients

When a remote desktop service is running and correctly configured, it can provide access to the desktop from any connected RDP client over the network. Common RDP clients are:

• the mstsc command in Windows,
• the Microsoft Remote Desktop Connection app in MacOS,
• the freerdp package in Linux, and
• various iOS and Android remote desktop clients.

Configured Remote Desktop Services

When SET Lab staff create VMs and install guest operating systems (OSes) for classes, teams, individual students or faculty, they normally enable the virtual remote desktop service and may also enable guest remote desktop services within the guest OS so the users will be to use an RDP client to interact with the remote desktop.

The virtual remote desktop service is by far the easiest way to interact with the guest OS. If guest remote desktop services don't work, see the Troubleshooting section.

Troubleshooting

However, there are some cases where guest remote desktop services are not available:

• The VM is running but the remote desktop service cannot be connected.

  It could be one of the following problems:

  • the guest operating system hasn't yet reached the point of starting its remote desktop service
  • BIOS boot problem
  • a corrupted OS disk
  • someone didn't enable or turned off the remote desktop service

  In these cases, you need to look at the display, and you may be able to use either the virtual remote desktop service to do that, or use the screenshot command. See Using the VCL: Remote Manual Interaction.

• No remote desktop service is installed or available to be installed.

  If you installed the guest operating system yourself from a CD/DVD .iso file or otherwise, you are likely familiar with Using the VCL: Remote Manual Interaction. In that case, you need to install and configure your guest remote desktop service, if one is available.

  If no remote desktop service exists, perhaps you can use an SSH service. Otherwise, your only recourse is to follow Using the VCL: Remote Manual Interaction.

• The virtual or real network is not correctly configured.

  Remote desktop access will only be available from outside the UW campus —unless Husky OnNet VPN is used— if the virtual network interface cards (NICs) can access the internet. Only Network Address Translation (NAT) with port-forwarding enabled or Bridged network methods will work. If all you want to do is remote desktop amongst VMs in a private network such as "host-only" or "internal", then those network methods should work.

  Firewalls on the guest OS must have the RDP port open. Normally, this is port 3389, but can be changed by a privileged user of the guest OS. On Windows, if you can issue a command or send keys, you can change the port as followsi (change "nnnnn" to your desired port number):

  reg add "hklm\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber /t REG_DWORD /d nnnnn /f
  
  netsh advfirewall firewall set rule name="Remote Desktop - User Mode (TCP-In)" new localport="nnnnn" dir=in enable=yes profile=any
  
  sc stop "Remote Desktop Services"
  sc start "Remote Desktop Services"
    

  For NAT, a unique host port must be established that maps to the guest OS port, and the host's IP address must be used. This mapping is usually done by SET lab staff. If you changed the RDP port number, the NAT mapping will need to be changed as well.

  For the bridged networking method, one must use the guest OS's IP address, not the host's. The RDP port number is whatever the default is, or whatever you changed it to be.

Change Log