While remote control can be an extremely effective help desk tool, this effectiveness comes at a price. Remote control sessions tend to require a lot of bandwidth and therefore may be painfully slow in environments with limited bandwidth. In this article, I’ll discuss these bandwidth concerns and explain what you can do about them.

Lots of screen shots
Remote control sessions require a large amount of bandwidth because the contents of the client’s screen must be transmitted to your computer several times each second. Depending on the client’s screen resolution and color pallet, this simple transmission could significantly increase network traffic.

There is some good news though. First, the problem isn’t as big as it used to be. In the early days of remote control sessions, it was common to transmit the entire screen several times each second. While this technique is still used for pure text environments, things have changed for GUI environments. Now, only the portion of the screen that changes from one frame to the next is transmitted.

Slow but steady at 56K
Suppose that your help desk staff was remotely supporting a client over a slow modem link. During the initial connection process, you would probably be able to watch Windows “draw” the remote screen on your PC. Once the screen has been initially displayed, however, you can move the mouse without the system having to completely redraw the screen after each mouse movement. If you were to open a window though, the new window would have to be drawn onto your machine.

Remotely supporting a system over a slow modem link can be time-consuming and frustrating but is still a good technique to use in emergency situations, especially when long distances geographically separate the help desk and the client. However, in a network environment, remotely controlling a PC is nearly as smooth as working on the remote machine locally.

Perfect for the network, but don’t forget the bandwidth
If you are remotely controlling a machine over a network, you’ve got to remember that you can be placing a considerable amount of traffic onto the network. This is especially true if several members of the help desk staff are conducting simultaneous remote sessions. While the traffic from three or four simultaneous remote sessions should fall well within the limits of a 10-Mbps Ethernet, it’s still a good idea to perform some benchmark tests before implementing remote access capabilities. Remember that although most networks should be able to handle remote control traffic, an already congested network may not be able to handle the traffic increase.

If your network is too congested to use remote sessions, or if you find yourself having to rely on slow modem links to the client, does that mean you should just give up on the idea of using remote control as a help desk tool? Not necessarily.

Using remote control on a congested network
There are a few things that you can do to ease the amount of traffic that’s required by a remote control session. For starters, you can tell the client to temporarily remove any desktop wallpaper and to reduce their desktop color scheme to 16 colors. If this sounds like a lot of work, don’t worry. Some remote access products actually contain features that prevent the background from being transmitted. This means that the product must only transmit the icons, any open windows, and the mouse pointer location.

If you’re low on bandwidth and you’re using NetMeeting, then I strongly recommend disabling the audio and videoconferencing features. These features place more traffic on the network than any of the other NetMeeting features do, and they don’t work very well in low-bandwidth environments anyway. Besides, you can always use the telephone to communicate with the client while conducting a remote session.

As you can see, there are some significant issues that must be considered when implementing remote control capabilities, but with proper planning, you can avoid causing any major network bottlenecks.

Can you share the remote?

Does your help desk use remote control software? If so, what product does it use? How do your end users feel about someone else controlling their computer? Post a comment to this article or send us a note.