ScreenConnect, a remote access tool, allows you to host a server that enables remote support of client computers. Many of the best features of this software relate to giving you control over deployment and hosting. This would seem like the perfect fit for Amazon’s cloud server infrastructure. Generally, the server is geared to Windows, but maybe you don’t want to run this on the more expensive Windows or Linux Servers? If what you wanted to do is run it on a lower-cost AMI (Amazon Machine Image) free-tier micro instance, here’s how to do that.

Briefly: I’ll walk you through the process of installing ScreenConnect (version 4.4, current as of publishing) on a cloud-based, free-tier eligible, Amazon AMI Linux micro-instance.

Create the Instance

Log into your Amazon Console. You’ll need to create and start an AMI instance. I’ll leave you to the details on how to do that. I’d suggest the free tier to get a feel for things. In fact, if you have one or two licenses for ScreenConnect, the free AMI tier seems like the perfect fit for support. If you have a running instance, you might try copying what you have and testing on that first. In this article, I’ll work with a server I’ve copied.

Connect to the server

You’ll want to set your instance’s security group to allow access by way of SSH, or port 22. Once available, use our server key and connect to the server by way of a terminal. Several tutorials exist out there that explain this process, so I won’t go over that. If you need any specific help on that process, by all means, contact me.

Download and install ScreenConnect

I used the simple process explained in “Option 3” on the ScreenConnect Linux installation help. The third option is preferred because it allows you to see each command one by one, and catch any problems [1] .

Here’s how it looked on my AMI instance:

# wget -O sc.tar.gz "http://www.screenconnect.com/Download?Action=DownloadLatest&Platform=Linux&PreRelease=false"

Saving to: ‘sc.tar.gz’
100%[======================================>] 33,854,877 1.70MB/s in 20s

# tar xzf sc.tar.gz

# $(find . -name install.sh)

I followed the rest of this install process and generally used the defaults to install things. There wasn’t any issue with the process while using the defaults. At the end you’ll get a url to access the installation:

To access your new ScreenConnect installation, open a browser and navigate to:
http://localhost:8040/Host

Open external ports

On the Amazon Console, find and edit your instance’s Security Groups. you will need to open two more TCP ports for access. ScreenConnect needs the above mentioned port 8040 and 8041 (which is used by all clients as a relay).

Connect and configure the server

Going back to your console, find the running ScreenConnect instance and it’s public IP address [2]. Use that IP to connect to your installation. It might look like this:

http://00.00.00.00:8040/Host

Performance Considerations

So far, I haven’t had any performance problems with one concurrent connection. As you add concurrent connections, more attention will need to be paid to how the instance handles the increased usage. It’s hard to say what the upper limit is here, but Amazon allows a fairly rich set of options for expanding instances if you need it.

You’re going to need to go through a considerable amount of effort to performance tune your micro instance. By default it won’t come with swapping enabled, so expect the server to crash if you don’t at least set that up. You may need to tune the instance in other ways, so be ready for this and follow the issues (as they occur). I can’t recall all the things I’ve done to tune my instance, but I can say that it’s been working well so far.

Other Things To Know

1.  On one of my testing servers, I had MySQL and Apache installed (using port 80). The ScreenConnect installation didn’t cause any problems with this. The two web servers ran side by side fine in my testing. Naturally, on a micro instance, this is probably not an ideal configuration with the limited memory you have.

2. Be aware that if you stop or terminate your AMI instance, the public IP will be released and a new one assigned on startup. Before you run this in a production environment, be sure to set up a hostname that points to the instance so clients don’t always require re-installation on IP changes. Naturally, Amazon offers ways to protect IP addresses from this change (if you want). You should never really have to terminate an instance though.

Take Away: This is a wonderful mix of two solutions that can provide you with a powerful, branded remote access option similar to Logmein and Teamviewer (firewall traversal). If you look what you see here and the process above seems daunting, get in touch and I can build it in no time.

1. They offer an all-in-one command that I didn’t try. Go ahead, be brave.
2. Once you’ve finished with testing this, you’ll want to attach that IP address to a hostname for ease of access and consistency (and it will help if you move servers).