So far everything I've talked about when it comes to remote hosted server management has been about the server itself: the operating system, the physical hardware and so on. Now it's time to address everything else you have on the box—namely, the applications you run with it.
Applications can be managed remotely in a few basic ways. Not every option will be available for every application, but the vast majority of programs that allow remote administration (and many that don't) can probably be coaxed to work in one of three ways.
- Direct management on the remote hosted server via Remote Desktop.
- Remote management via a client application.
- Web-based management interfaces.
Direct management on the remote hosted server via Remote Desktop is the easiest and least complicated way to manage an application remotely: Fire up a Remote Desktop session and work with it as if you were administering it locally.
Whether or not you can use this method will depend on three things:
- Is more than one person administrating the application in question? Only one person at a time can log in via Remote Desktop, unless you have client access licenses that allow otherwise, so if more than one person tries to work with the program at a time it may
- create a conflict.
- Is the application in question run from the desktop or as a service? If it can only be run from the desktop, only one interactive user will generally be able to administer it at a time. If another user wanted to administer the application, they would either have to log in on the same account as the first user (in essence, picking up where they left off), or the first user would need to close the program and let the other user re-launch it—which semi-defeats the purpose of it being hosted on a server!
- If multiple users are going to access the remote hosted server at once via Windows Terminal Services, does the server have the resources to handle that (memory, connectivity, etc.)?
So the most likely scenario for managing an application via Remote Desktop is when there's only one user that administers the program and the remote hosted server—or when administering that one program requires access to others through Remote Desktop that aren't available otherwise.
One example of this from my own experience is when I work on a remote hosted server that has SQL Server and uses ASP.NET. Typically, I open a secure Remote Desktop connection to the server, and from there open up Query Analyzer, the IDE I use to edit the ASP.NET pages, and any of the other applications I might need to write and debug the Web server code. I don't have FrontPage extensions or remote access to SQL Server enabled for security reasons, and since I'm the only administrator it's just easier for me to log in via Remote Desktop and do everything there.
The scenario involving remote management via a client application varies enormously depending on what you're using, but it usually involves applications which support being remotely administered through a client. An example of this would be Microsoft SQL Server, which could be remotely administered from another computer through the SQL Server Enterprise Manager.
This approach has its downsides. One is that the remote hosted server needs to have certain ports open in order for the client application to access it (in the case of SQL Server, port 1433 for data and 1434 for interprocess communications.) Doing this will often expose your application to the world at large (not a good thing). Therefore if you choose to do this, it's best to do it through a Virtual Private Network (VPN) or other filtering/access control mechanism. On the plus side, this makes administering the application as easy as running the administration tool on the server; in fact, it's almost entirely transparent.
The Web-based management interface method -- using a Web-based interface to manage a given application remotely – has become increasingly popular. More and more programs come with their own built-in Web-based management system. For instance, the Mercury/32 mail system has a module that allows an administrator to manage the whole program from the Web. Microsoft has extensions to allow Internet Information Services (IIS) and other applications to be managed through Web interfaces, too, so odds are the vast majority of the server applications used today can be controlled in this fashion.
The advantages to using a Web interface should be obvious: It's easy to connect to, easy to secure and easy to work with. The downside is that nearly every application needs a Web interface built specifically for it. There's no standard that yet exists to allow a program to have a generic Web-based control system.
In theory it would be possible to write something that allows a program that uses the standard
Microsoft Management Console interface to also work with a Web client—the standardization of the
interface is the big thing—but for the time being, each application needs to be dealt with on its
Remote Hosted Server Management Fast Guide
Use Remote Desktop for remote hosted server management
Remote Desktop alternatives
Managing applications on a remote hosted server
Remote hosted server management: Disaster recovery and prevention
This was first published in June 2006