Network Computingwww.networkcomputing.com

Remote-control applications may fulfill this wish for traveling users, network administrators and support staff, letting them access their desktops from across the building or around the world.

However, if many people need access to a few desktops via remote control, or if you're using remote control for desktop support, you still have to pay the licensing fees for all of those clients. You also have to support the application on the desktops or laptops, and worry that someone might open a hole in your network security by setting up a remote-control host attached to a modem. These issues can easily offset the benefits of remote control.

Enter browser-based remote control. With the proliferation of Web browsers on every desktop (primarily Netscape Communications Corp.'s Navigator and Communicator, and Microsoft Corp.'s Internet Explorer), combined with the development of interactive content for the browsers (Java, ActiveX and assorted plug-ins), remote control is possible from any desktop equipped with a Web browser--regardless of operating system.

Traditional remote control lets you effectively manage a Windows NT Server, or the applications on it, transfer files between PCs, and set up your own remote-control host--all without you sitting at the console. However, you must pay for every application that you own, and the cost of distributing remote control to network administrators and support staff can quickly add up.

Browser-based remote control is ideal for users who need flexibility but don't want to install a full client or don't need the functionality of one. It's perfect for tech-support personnel who need to connect to user desktops. Thin clients take up minimal memory because much of their functionality relies on br owsers that are already running.

Browser-based remote control also offers users a way to get temporary remote-control connectivity over slow, dial-up links quickly. Unlike their larger cousins, thin clients take up less than 500 KB, and they transfer over modems in under two minutes.

But browser-based remote control has its limitations. You relinquish data security, such as strong data encryption, cannot perform file transfer from host-to-host or of network volumes, and do not have hosting capabilities.

How'd They Do That? Implementing browser-based remote access on the desktop isn't dictated by technology. Instead, vendors make design choices about implementation, and those choices have an impact on how you distribute, connect and manage browser-based remote control. Vendors are hedging their bets on the browser wars and are offering browser-based remote control for both Netscape Navigator and Microsoft Internet Explorer.

One strategy involves putting the browser-based clients on a Web page and letting users download them when needed. Symantec Corp. with its pcANYWHERE products uses this method with its Java applets and ActiveX controls, offering three advantages: enhanced security by restricting who can access the page containing the applet with SSL (Secure Sockets Layer); the ability to define which remote-control hosts users can connect to; and greater control over the initial session parameters for users. Within the Web page holding the Java applet or the ActiveX control, you use a scripting language to launch the application and set up any special parameters for the remote-control session.