The quick version:

This brief video introduces using remote desktop client from a Windows 10 PC (also appropriate for Windows 8.1, 8.0, and 7)

This brief video introduces using remote desktop client from a Mac

Also, take note of some Remote Desktop Ninja Tricks below.

Longer version

Remote desktop connections allow a device -- typically a computer but most other 'smart' devices like tablets and phones -- to login another computer on a network or across the internet. To connect remotely your device will need remote desktop client software -- built in or easily found and installed at no cost -- plus the host domain name system (DNS) name (or IP address) of the computer being remoted to. The DNS name or IP address may be appended with a colon and a port number. You will also need a login ID established for you on the remote computer and a password. These pieces of information are available through your TechCats subscription or may have been provided to you by the remote host administrator or your instructor. This information would be something like

DNS Name: or

Login ID: imauser or vm\visitor

If you have questions about your DNS name and login credentials for a TechCats subscription, please contact TechCats Solutions. Feel free to contact us even without a TechCats subscription since we may be able from Linux

Linux users are expected to write their own Remote Desktop Client in one line of Byzantine grep-ing and awk-ing. Kidding aside, if you are on a Linux box you might try rdesktop or please contact TechCats Solutions for guidance.

Remoting from Android or iOS Devices

Microsoft developed a remote desktop application for those wishing to connect to their VM via Android or iOS devices. The application is named Microsoft Remote Desktop and can be found on each platform's respective marketplace: Microsoft Remote Desktop for Android and Microsoft Remote Desktop for iOS. Fortunately, since these applications are developed by Microsoft, they have provided fairly straightforward documentation for getting connected to your VM. For guidance on configuring the Microsoft Remote Desktop applications, Android device users can go here and iOS device users can go here.

Remote Desktop Ninja Tricks

OK, not really Ninja tricks but some things to remember to make the remote desktop (RD) experience work for you in your courses.

  • TechCats remote desktops use port 3389, the default for RDP. Some routers (e.g., the guest WIFI at Augusta University, some workplace wifi) block port 3389 traffic so remote desktop will not work. If you are having trouble connecting to a remote desktop try visiting to see if you can connect at all through this port. If not, a different internet connection or router adjustment will be needed (e.g., use GR-Secure wifi or a wired lab computer at Augusta University).
  • Your RD has a private Documents folder for your stuff which will remain for the duration of the subscription. This folder is a great place to leave your work in progress and finished results. Your instructor will likely have permission to look at these files to help trouble-shoot and grade your work. Toward the end of your subscription you might want to make a zip file copy of your Documents and save it on your local machine as an archive.
  • Your RD has an internet connection, and one that's probably faster than your own. If you need to upload something to a course management system for a course, you can login to the CMS from the RD and upload from, for instance, your Documents folder in the RD. Similarly, you can download an internet resource if needed.
  • Your RD connection can be configured to allow copying files to the RD from your local machine and vice versa; this configuration is typically a default. Instead of drag & drop (which might work but is a little difficult between windows), just right-click a file, choose copy, get to the destination folder (on the other machine), and use right-click | paste.  Slightly more advanced: you can configure your RD connection so your local machine drives are available in the RD; handy for syncing up file folders.
  • Your RD connection and credentials can be saved in a file so that you don't need to enter the RD's DNS name, login ID, and password whenever you connect; take some care with this file anyone who has it can connect to your RD without needing your credentials.
  • Sound and video playback on a RD aren't so good; best to do those tasks on your local machine.
  • If you disconnect from a RD session without signing off, the session will remain for an hour before signing you off. So be sure to save work-in-progress before leaving an RD session but you will find yourself back in context if you remote back in within two hours.
  • Instructors:  Keep in mind that many RD subscribers will use the same remote virtual machine, potentially some users outside of your courses or even your university. Students work is private to them, though instructors will likely have privilege to look at folders and other assets of students in their courses. If you have your entire class do the same exercise (e.g., from a textbook or class) give a little thought to providing naming or location guidance for, e.g., databases and file folders. For instance, if a textbook says 'create a database named Schedules using SQL Server', you will have to provide a scheme where each student's database gets a different name (e.g., have them prefix the database name with their login so login tuser would create tuserSchedules and login jsmith would create jsmithSchedules). Similarly for folders (e.g., an assignment that says 'create a folder C:\TransFiles and ...' would need to be modified to 'create a folder named TransFiles in your Documents folder and ...' for two reasons: avoiding name collision and users can only create folders and files in their user folder / sub-folders. As long as assets reside within individual C:\Users\{LoginID} folders and sub-folders, all is fine.
  • Instructors: If you plan on using RD for class labs, exams, or work-with-the-instructor demos beware of having too many users depending on weak or shaky WIFI. Labs with wired connections aren't a problem but 30-50+ consumers of the same WIFI router in one room occasionally leads to connections problems on the client side; when a connection is re-established users will find they are where they left off (unless more than an hour has passed in which case the remote session will have been ended).