Windows Remote Desktop

Windows has had a built-in capability to allow the system desktop to be viewed and controlled remotely since Windows XP. This functionality is called Remote Desktop, also referred to as RDP (the acronym standing for Remote Desktop Protocol). It has the advantage that it comes as standard (both client and server), and is tuned to work with the Windows graphic display model. Official clients also exist for MacOS, Android and iOS. There is no official client for Linux, but Remmina and Vinagre (amongst others) speak RDP.

Notes on specific clients §

Windows (client and server)
MacOS (client)

Connecting from off-campus §

It can be used for connections between system on campus, or to control on-campus system from off campus. There are two main choices here - VPN or RDP Gateway.

Via VPN

You can use RDP using the VPN (both Campus_use and Off_Campus_use profiles should work), and this is an obvious way to do things, especially if you are using the VPN for other purposes anyway. If the VPN is being unreliable, is blocked or is otherwise not available then there is an alternative route as of April 2020 - the RDP Gateway.

Via RDP gateway

The RDP gateway is a specialised system that allows you to Remote Desktop to internal Windows systems via an externally accessible gateway. One potential advantage of this system is that the connection from your client to the gateway uses https (TCP port 443), which should be allowed from almost anywhere (the ports used for the Cisco VPN are sometimes blocked on restricted networks). The other advantage is that it reduces load on the VPN system.

Interaction of VPN and RDP Gateway

What happens if you fire up a connection that uses the RDP Gateway and are are connected to the VPN as well? The answer is that the connection should work, but it will go through both systems (first the VPN, then the Gateway). This is non-optimal. Note that if you are on campus the connection may still go through the gateway if configured (technically, if you are on a different subnet from the target system). We recommend that you set up two connection profiles to your target system, one with and one without the gateway configured. The one without the gateway system is optimised for use on campus or through the VPN.

There is also a third route that can be used - SSH tunneling. This is not recommended unless you have very unusual constraints.

General notes §

Remember to log out of the Windows session when you are finished, unless you want to leave the user logged on to the system (e.g. for acquiring data). When choosing log off there is an option to disconnect. Closing the connection window or losing the network connection disconnects you, leaving the user account logged on to the remote system.

When you connect to the remote system any screen connected to the remote system will display the lock screen. If you disconnect the system will remain locked, until:

the user goes to the system and unlocks it with their credentials.
the user connects remotely and then logs off, leaving the system free to use.
the system is forcibly reset or power-cycled

If a user is logged on to the system (remotely or locally) and another RDP client tries to connect the behaviour depends on who is trying to connect:

same user - they take over the connection automatically
different non-administrative user - they cannot connect
administrative user - they are warned that a different user is logged on to the system and connecting will kick them off (with no chance to save documents etc.)

To get the Windows Security screen in a remote session use Ctrl-Alt-End (Ctrl-Alt-Del always goes to the security screen on the local system with Windows). When running the client on a MacBook try Fn-Ctrl-Alt-Delete or Fn-Ctrl-Alt-right arrow.

Unlike applications such as VNC, TeamViewer etc. you are connecting to a "virtual" screen on the remote system. This is independent of the physical displays on the remote system - you can in principle choose any size you like. However, if you are connecting to an existing session with windows carefully positioned it is advisable to try and match the size of the previous session.

One reason for choosing a small RDP screen is to reduce the bandwidth required for the connection - on a slow network connection this can make a noticeable difference.

User accounts §

When logging in to a Windows system locally you often do not have to worry about where the account database actually lives - for a laptop it is often a local account, and for desktops in the School the user account lives in the same security domain as the system (GUPHYSICS). When using Remote Desktop this is often not the case. For Windows systems in the School (desktops and servers) there can be several different accounts in use. These are:

Local accounts: These are accounts that are local to the individual machine. When connecting remotely these need to be specified in the form MACHINENAME\username (when logging on locally, you can use the form .\username as a shortcut).
GUPHYSICS accounts: This is the security domain that most School desktops, servers and user accounts live in (and also provides authentication for the GUPHYSICS wireless network). These can be specified in the form GUPHYSICS\username when connecting remotely.
Campus accounts: This is the central University security domain. User accounts are specified as CAMPUS\username, where username is the 'short form' of your GUID. (Alternatively, you can use your email address, but this can cause confusion in some cases). These credentials are required for use of the 'RDP Gateway' system.

Note that in Windows usernames and domains are not case sensitive - we write domains in upper case purely as a convention to try and make documentation clearer. Passwords are obviously case sensitive.

Also note that it is possible to log on to GUPHYSICS desktops with your CAMPUS username, and some people do do this. In the long term this will become the standard, but presently GUPHYSICS accounts are still required for the wireless network.

You can omit the domain name if you are connecting to another system on the same domain.

Version incompatibilities §

There are some incompatibilities between versions of the clients and servers, involving the authentication protocols in use. For example, a fresh install of Windows 7 SP1 without updates may not be able to communicate with Windows 10, without additional configuration.