Use Remote Desktop for remote hosted server management

The most common way to access any Windows-based remote hosted server is through a native technology available in every edition of Windows 2000 and 2003: Remote Desktop. However, when using Remote Desktop to deal with a server that's not on your premises, you need to be careful: If something goes wrong, you can't just walk into the next room and take control from the console.

Here are six tips about using Remote Desktop on a remote server.

1. Secure the remote hosted server connection. If the only way to connect to the remote hosted server is through a local computer, don't shoot yourself in the foot by making the local computer an open door.

Sure, it's possible to create a Remote Desktop connection that has the username and password already filled out to save time. Don't do this.

People should not be able to arbitrarily connect to the server without supplying credentials of some kind. By default, connections must supply their own connection credentials anyway; this is governed for each Terminal Services connection in the Terminal Services Configuration snap-in. If you right-click on the connection and select Properties | Logon Settings, the default setting is "Use client-provided logon information", which is exactly as it should be. (If it isn't, set it to that right now!)

In particular, do not cache passwords if there's a chance that the console you'll be connecting from can be physically compromised (i.e., if it's not behind a locked door). If someone can get to that console, they can walk right into your server.

2. Limit the needed connection bandwidth to the remote hosted server. Even if you're on a high-speed network, the less bandwidth you use for the Remote Desktop connection, the better. Connections to a remotely hosted computer are going to be at the mercy of Internet traffic as a whole, so you're best off sending as little as possible across the wire to begin with. This also affects the latency of actions taken in the Remote Desktop window: You're not only sending less, you're waiting for less to come back.

You can do this by editing the properties of the Remote Desktop connection you're using, and changing a few settings. Under Display, pick "256 Colors" (unless you have a real need for high-color support); under Local Resources, set "Remote computer sound" to "Do not play" (unless, again, you need sound from the remote server, which isn't likely); under Experience, turn off everything except for bitmap caching. The latter option stores copies of bitmaps sent across the wire on your local machine, and makes subsequent screen refreshes faster.

3. Plan remote hosted server connections, and restrict accordingly. Most of the time you will never need to allow more than one person at a time to connect via Remote Desktop. If that's the case, you'll want to enforce that on the server side. Go into the Terminal Services Configuration snap-in, right-click on the current connection and select Properties. Under Network Adapter, you can control how many connections can be established to the computer via Remote Desktop; I typically set up a maximum of two (one for normal use and one in case the other connection gets hung up). Two is the maximum allowed for systems that use Remote Desktop for administration, anyway.

Under Sessions, you can control how long sessions can idle before being automatically disconnected. My typical behavior is to disconnect after five minutes of idling, but to disconnect rather than log off and to allow reconnection from any client. As long as the passwords/user credentials are not publicly available, this should be okay, and it's faster to reconnect with an existing user session instead of logging off and then on again every time you reconnect.

Note: If you get disconnected from the remote hosted server because of a network condition, and you have "End a disconnected session" set to "Never" in Sessions, the system may try to log you in under a separate connection if you try to reconnect too quickly. Either wait a few minutes before trying to reconnect under such circumstances, or set "End a disconnected session" to "1 minute" to prevent it from happening in the future. (This is not the same as logging off; this simply closes the hanging connection.)

4. Keep the remote hosts in the loop. The people you're paying to host your hardware should always be kept up-to-date about which passwords, logons and other critical information have been set up. (If you're uneasy about giving such information to these people, you shouldn't be hosting your hardware remotely in the first place. If you can't trust paid professionals with your hardware, who can you trust?)

5. Consider using an alternate remote-connection protocol. In most cases, Remote Desktop should more than do the job. But if you're connecting to the server from non-Windows clients or if you have someone else who will do so regularly, consider setting up another remote-connection technology. My favorite is some variant of VNC, a widely used and widely supported remote control system that works across OS platforms.

Just keep in mind that VNC has its own set of security protocols and network ports that typically have nothing to do with Windows, so you'll need to set it up carefully.

6. Consider setting up a remotely manageable reboot utility. If you're paying for hosting, odds are you get certain types of incidents as part of the remote hosted server plan, such as an emergency reboot. But that still takes time, since it's usually done by hand. A technician has to go into the network center and do the reboot himself. (By the way, some network centers may even charge you per reboot incident.)