Supporting Users Outside of the Corporate Network

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.

Remote Assistance in Windows XP

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.

Improvements to Remote Assistance in Windows Vista

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.

Microsoft SharedView

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:

• Integration with Microsoft Word — documents can be updated with session participants in real time and the Track Changes feature of Word will mark each modification with the participant’s name and a time stamp;
• Ability to distribute files to other participants using the Handout feature;
• A personalized mouse pointer for each session participant;
• Authentication via Windows Live ID.

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:

1. Double-click the SharedView.msi executable.
2. Accept the license agreement and click Next.
3. Choose various options, such as whether SharedView should run when Windows starts and the creation of shortcuts and click Install.
4. Check the Run SharedView (Beta) when setup is finished box and click Finish.

Starting a SharedView Session

Users who want to start a SharedView session will need a Windows Live ID before using SharedView.

1. Click Start Session on SharedView’s main screen.
2. On the sign in screen, enter your Windows Live ID and password and click Sign In.
3. 
   Figure 1

   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.

4. Click the arrow at the bottom of the screen to start the session.

Join a Session

1. Click Join Session on SharedView’s main screen.
2. On the Join a Session screen, enter the ID of the session you want to join (the Windows Live ID of the presenter), the session password (provided by the presenter) and your name. Click the arrow at the bottom of the screen to join the session, as shown in Figure 1.
3. The presenter who started the session will be prompted to accept or reject the request in a small pop-up at the bottom of the desktop.

Figure 2

Share an Application or Desktop

Any participant of a SharedView session can initiate the sharing of an application or desktop running on his or her own computer.

1. Click Share on the SharedView toolbar at the top of the screen.
2. Select an application (or the entire desktop) to share and then click Start, as shown in Figure 2.
3. You’ll be presented with a warning dialog stating that other users will be able to see your application or desktop. Click OK to continue.

The application or desktop is now shared. Figure 3 shows an example of a shared application in SharedView.

Figure 3

Grant Control of an Application or Desktop

Figure 4

You can grant control of shared application if you initiated the sharing.

1. Click the dropdown menu of users next to Control in the SharedView toolbar at the top of the screen, as shown in Figure 4.
2. Click OK on the warning dialog.

You can take back control anytime by simply clicking on the shared application.

Request Control of an Application or Desktop

If you didn’t start the sharing of an application or desktop, you can request control.

1. Click Request Control at the top of the sharing window.
2. The participant who started sharing the application must confirm the request by clicking Grant in the pop-up window on their desktop.

Conclusion

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.