Most Windows administrators are familiar with remote support tools such as Virtual Network Computing (VNC), Remote Desktop and Remote Assistance. These tools have one thing in common: They are designed to be used peer-to-peer. In other words, a direct connection is established between the administrator’s computer and the computer of the user who needs support.
Inside a corporate network, for the most part, such peer-to-peer support tools work well. The problems start when you need to support a user who’s unable to connect to the corporate network. A typical scenario might be a remote user working in an Internet cafe who can’t connect to the corporate network using a Virtual Private Network client. The user needs help with an application. With firewalls, Network Address Translation (NAT) routers and other defenses between the administrator and the remote user, the chances of being able to connect successfully are reduced significantly.
In this article, we’ll look at some possible solutions for connection difficulties with traditional peer-to-peer remote support tools.
If you’ve ever tried to offer or solicit Remote Assistance in Windows XP over the Internet, you know what a hit-or-miss affair it can be. That is not because Remote Assistance doesn’t work, but because the requirements for making a connection are complicated. Remote Assistance is based on Terminal Services technology and therefore requires port 3389 to be open on firewalls.
Remote Assistance supports NAT traversal provided by Universal Plug and Play (UPnP) technology. UPnP NAT traversal works by learning public IP addresses, enumerating port mappings and then adding/removing port mappings as required with a given lease time to NAT tables. Remote Assistance doesn’t work if both the person requesting help and the helper are behind non-UPnP NAT routers. Not all routers support UPnP technology (or have it enabled).
The connection method also depends on how an invitation is sent. If Remote Assistance is requested using Windows Messenger, a non-UPnP NAT router will work when only one of the Remote Assistance clients is behind a NAT router.
Confused yet? These requirements mean that support over the Internet using Remote Assistance is ruled out in many situations. Remote Desktop and VNC also require that a firewall port other than HTTP be open in order to work.
In Windows Vista, Remote Assistance still uses Remote Desktop Protocol on port 3389 but removes the reliance on UPnP for NAT traversal by using IPv6 and Teredo. Teredo allows IPv4 NAT to be traversed by sending IPv6 packets as IPv4 User Datagram Protocol messages, enabling Remote Assistance to work across most NAT-enabled routers.
The Teredo service in Windows Vista contacts a Microsoft Teredo server, which in turn sends back an IPv6 address for Remote Assistance to use. When Remote Assistance communicates with another client using the IPv6 address issued by the Teredo service, packets are sent either directly to the destination address or to a Teredo relay service that is responsible for routing packets to the destination.
Still in beta at press time, SharedView can be thought of as a cut-down version of Microsoft Live Meeting 2005 (although you should note that the technology SharedView is based on is different from that of Live Meeting). SharedView allows you to share a desktop (or any application) with up to 15 users simultaneously. So what’s the advantage of SharedView over peer-to-peer support tools such as Remote Assistance?
SharedView works via a hosted Web service, which allows it to operate over HTTP- and NAT-enabled routers. The service also provides optimized distribution of traffic to users in a session, so that those with fast connections receive quick screen updates, and updates for those with slower connections are buffered. Because SharedView is a free application but requires a hosted Web service, the beta includes advertisements.
Some of the other features of SharedView include the following:
Microsoft SharedView beta can be downloaded from http://www.connect.microsoft.com/content/content.aspx?ContentID=1301&SiteID=94 
Installing SharedView is simple and involves just a few steps:
Users who want to start a SharedView session will need a Windows Live ID before using SharedView.
Before entering the session, you have the opportunity to invite other participants by email or instant message. If you select the phone option you’ll be presented with the session name (which is the same as your Windows Live ID) and password. Click Phone (Instructions) and the session details will be displayed. You can also skip the invitation process and enter the session immediately.
Any participant of a SharedView session can initiate the sharing of an application or desktop running on his or her own computer.
The application or desktop is now shared. Figure 3 shows an example of a shared application in SharedView.
You can grant control of shared application if you initiated the sharing.
You can take back control anytime by simply clicking on the shared application.
If you didn’t start the sharing of an application or desktop, you can request control.
SharedView provides simple collaboration features that can be used by normal users and support technicians anywhere an Internet connection is available, without the technical restrictions that are imposed by peer-to-peer tools. One disadvantage of SharedView and other similar tools is that software must be installed on a participant’s computer. If you need to provide ad hoc support to a user who doesn’t have privileges to install software, you’re going to be stymied if you can’t establish a connection using Remote Assistance.
Traditional support tools such as Remote Desktop and VNC can be problematic when making connections outside the corporate network. Support and collaboration tools such as Microsoft SharedView (Beta), Live Meeting 2005 and GoToMyPC use hosted Web services to enable connections from any location without the need to reconfigure firewalls and routers. Consider the following points when evaluating SharedView: