Supporting Windows 7 Users with Remote Assistance

• Understanding Remote Assistance

• Implementing and Managing Remote Assistance

• Summary

• Additional Resources

Remote Assistance (RA) in Windows Vista included improvements in connectivity, performance, usability, and security along with feature enhancements that make it even more useful than Remote Assistance in Windows XP was. The Windows 7 operating system builds on these earlier improvements with Easy Connect, a new feature of Remote Assistance that makes it easier than ever for novice users to request help from expert users and for experts to offer help to novices. With increased Group Policy support, command-line scripting capabilities, session logging, bandwidth optimization, and more, Remote Assistance is now an essential tool for enabling enterprises to support users in Help Desk scenarios. This chapter examines how Remote Assistance works in Windows 7, how to use it to support end users, and how to manage it using Group Policy and scripts.

Understanding Remote Assistance

Supporting end users is an essential function of IT departments and the corporate Help Desk. Unfortunately, conventional technical support provided over the telephone or using chat tools is generally cumbersome and inefficient. As a result, supporting users is often both time-consuming and costly for large enterprises to implement. For example, end users often have difficulty describing the exact nature of the problem they are having. Because of their general inexperience and lack of technical knowledge, end users may try to describe their problem using nontechnical, inexact language. As a result, Help Desk personnel are generally reduced to asking a series of simple questions to try to isolate the problem the user is having. The methodical nature of these questions sometimes causes users to feel as if Help Desk personnel are being condescending, and such misunderstandings can reduce the effectiveness of the support experience and can make users tend to avoid contacting support personnel when future problems arise.

End users also often have difficulty following instructions given to them by Help Desk personnel who are trying to assist them. Well-trained support personnel will try to avoid using technical jargon when communicating with end users, but although using plain language can improve the support experience, it may also mean that resolution steps become long and tiresome. For example, telling a user how to use Disk Cleanup from System Tools in Accessories can require several sentences or more, and this kind of communication can add time to support incidents, making them more costly to the company.

Remote Assistance solves these problems by enabling support personnel to view the user’s desktop in real time. The user seeking assistance can demonstrate the nature of the problem to the support person. This is a quicker and more efficient way to communicate a problem than using words or e-mail. If necessary, the user can also give the support person permission to assume shared interactive control of the user’s computer to show the user how to resolve the problem. The result of using Remote Assistance is faster problem resolution, an improved support experience, and a lower Total Cost of Ownership (TCO) for supporting end users in large, corporate environments.

Improvements to Remote Assistance in Windows 7

As mentioned previously, Remote Assistance in Windows 7 builds on the many enhancements introduced earlier for this feature in Windows Vista. These earlier enhancements improved upon the earlier Windows XP implementation of Remote Assistance and included the following:

• Connectivity improvements with transparent Network Address Translation (NAT) traversal using Teredo and IPv6

• An improved user interface (UI) that is easier to start and use

• A stand-alone executable (Msra.exe) that accepts command-line arguments and can easily be scripted

• Improved overall performance with a smaller footprint, quicker startup and connect times, and optimized bandwidth usage for screen updates

• Enhanced security with mandatory password and integration with User Account Control (UAC)

• New Offer RA via IM scenario and an open application programming interface (API) for integration with peer-to-peer (P2P) applications

• Additional Group Policy settings for improved manageability

In addition to these Windows Vista enhancements for Remote Assistance, Windows 7 adds the following new enhancements to Remote Assistance:

• Easy Connect, a method for soliciting Remote Assistance that uses the P2P collaboration infrastructure to simplify Remote Assistance user interactions

• An improved Windows Remote Assistance Wizard that makes it easier than ever for users to solicit or offer help

• New command-line arguments for the Remote Assistance executable (Msra.exe)

Remote Assistance in Windows 7 and Windows Vista deprecates the following features that were available on Windows XP:

• No more support for the MAILTO method of solicited Remote Assistance

• No more support for voice sessions

In addition, Remote Assistance in Windows 7 has deprecated the file transfer feature that was available in Windows XP and Windows Vista. Compatibility with earlier versions is still supported, however—for example, if a file transfer is initiated from a Windows XP or Windows Vista computer, Windows 7 will accept the transfer.

For information on interoperability between the Windows XP, Windows Vista, and Windows 7 versions of Remote Assistance, see the section titled "Interoperability with Remote Assistance in Windows XP" later in this chapter.

How Remote Assistance Works

In Remote Assistance, the person needing help is referred to as the User (or Novice), and the support person providing assistance is called the Helper (or Expert). You start Remote Assistance from the Start menu by navigating to All Programs, selecting Maintenance, and then selecting Windows Remote Assistance. You can also start Remote Assistance from a command prompt by typing msra.exe.

Remote Assistance has two basic modes of operation:

• Solicited RA In Solicited RA (also known as Escalated RA), the User requests assistance from the Helper by initiating the Remote Assistance session using e-mail, instant messaging (IM), Easy Connect, or by providing the Helper with a saved copy of an invitation file (*.MsRcIncident). Each of these methods uses a different underlying mechanism:

  • Solicited RA using e-mail This method requires that the e-mail clients being used by the User support Simple Mail Application Programming Interface (SMAPI). Examples of SMAPI-compliant e-mail clients include Windows Mail, which is included in Windows Vista, and Microsoft Office Outlook 2007. Windows 7 does not have a built-in e-mail SMAPI-compliant client, but you can install Windows Live Mail, which is available for download as part of the Windows Live Essentials suite of applications (at http://get.live.com). Web-based e-mail services, such as Windows Live Hotmail, are not SMAPI-compliant and cannot be used for soliciting or offering Remote Assistance using e-mail. In this approach, the User starts the Remote Assistance UI to create an e-mail message that has a Remote Assistance invitation file (*.MsRcIncident) attached to the message. The User must specify a password for the Remote Assistance session, which must be communicated to the Helper using an out-of-band (OOB) method such as calling the Helper on the telephone. When the Helper receives the User’s Remote Assistance invitation, she opens the attached ticket, enters the password that was conveyed by the User, and the Remote Assistance session starts. The Helper must respond to the invitation from the User within a specified time limit (the default is 6 hours), or the invitation will expire and a new one will need to be sent. In a domain environment, this ticket lifetime can also be configured using Group Policy. See the section titled "Managing Remote Assistance Using Group Policy" later in this chapter.

  • Solicited RA using file transfer This method requires that both the User and Helper have access to a common folder (such as a network share on a file server), or that they use some other method for transferring the file (for example, by using a USB key to manually transfer the file or by uploading the file to an FTP site). The user creates a Remote Assistance invitation file and saves it in the shared folder. The User must provide a password that must be communicated to the Helper using an OOB method such as a telephone call. The Helper retrieves the ticket from the shared folder, opens it, enters the password, and the Remote Assistance session starts. Again, the Helper must respond to the invitation within a specified time, or the invitation will expire and a new one will be needed. (The expiration time is configurable through Group Policy.)

  • Solicited RA using instant messaging This method for soliciting assistance requires that the IM applications being used by both the User and the Helper support the Microsoft Rendezvous API. An example of an IM application that supports the Rendezvous API is Windows Live Messenger, which is available for download as part of the Windows Live Essentials suite of applications (at http://get.live.com). In this approach, the User requests assistance from someone on his buddy list. To ensure that the remote person is really the User’s buddy (and not someone masquerading as the buddy), Remote Assistance requires that a password be relayed from the User to the Helper by other means (such as a phone call) before the Helper can connect. For more information on the Rendezvous API, see the Windows Software Development Kit (SDK) on MSDN at http://msdn.microsoft.com/en-us/library/aa359213.aspx.

  • Solicited RA using Easy Connect This method for soliciting assistance is new in Windows 7 and uses Peer Name Resolution Protocol (PNRP) to enable direct P2P transfer of the Remote Assistance invitation using the cloud. To establish the initial Remote Assistance session, the User only needs to communicate a password to the Helper using an OOB method such as by telephone. The Helper uses this password to obtain the Remote Assistance invitation from the cloud and initiate the session. When the initial Remote Assistance connection has been made, a trust relationship is established between the Helper and the User. This trust relationship is established through the exchange of contact and certificate information. Subsequent interactions are simplified because the contact information can be used to pick a Helper who is currently available. For more information on this method for soliciting assistance, see the section titled "Scenario 1: Soliciting Remote Assistance Using Easy Connect" later in this chapter. For information on how Easy Connect works, see the sidebar titled “Direct from the Source: How Easy Connect Works” later in this chapter. For information on how PNRP works, see the sidebar titled “How It Works: PNRP and Microsoft P2P Collaboration Services” later in this chapter.

• Unsolicited RA In Unsolicited RA (also known as Offer RA), the Helper offers help to the User by initiating the Remote Assistance session using Distributed Component Object Model (DCOM). Unsolicited RA is a typical corporate Help Desk scenario in which all the users are in a domain. The Helper enters either the fully qualified domain name (FQDN) or IP address of the User’s computer to connect to the User’s computer. This method requires that the Helper has been previously authorized as a domain administrator to be able to offer Remote Assistance to the Users. (For information on how to authorize Helpers for offering Remote Assistance, see the section titled "Managing Remote Assistance Using Group Policy" later in this chapter.) This method also requires that the Helper either knows the name (the host name on a local subnet; the fully qualified name otherwise) or address (IPv4 or IPv6) of the User’s computer.

Remote Assistance Operational States

Remote Assistance has three operational states:

• Waiting For Connect This state occurs when either:

  • The Helper has offered Remote Assistance to the User, but the User has not yet agreed to allow the Helper to connect to his computer.

  • The User has sent the Helper an invitation but the Helper has not yet responded by opening the invitation, or the Helper has opened the invitation and the User has not yet agreed to allow the Helper to connect to his computer.

  In the Waiting For Connect state, the Helper cannot view or control the screen of the User’s computer until a Remote Assistance connection has been established and both computers have entered the Screen Sharing state. After the Remote Assistance application has been started and is running in the Waiting For Connect state, the application should not be closed until the other party responds and establishes the connection. For example, if the User uses the Solicit RA Using E-mail method and sends an invitation file to a Helper, the Remote Assistance application opens on the User’s computer and waits for the Helper to accept the invitation. If the User closes Remote Assistance on her computer before the Helper accepts the invitation, the Helper will not be able to connect to the User’s computer and the User will need to send a new invitation.

• Screen Sharing This state occurs when the User has consented to allow the Helper to connect to his computer—either after the User has sent the Helper an invitation or the Helper has offered Remote Assistance to the User. In the Screen Sharing state, a Remote Assistance session has been established and the Helper can view—but not control—the screen of the User’s computer.

  When the User is prompted for consent to allow the Helper to connect to his computer, a warning message appears on the User’s computer saying that the Helper wants to connect to his computer. This warning message is customizable using Group Policy. See the section titled "Managing Remote Assistance Using Group Policy" later in this chapter for more information.

• Control Sharing This state occurs after the Screen Sharing state when the Helper has requested control of the User’s computer and the User has consented to allow the Helper to have shared control of his computer. In the Control Sharing state, the Helper has the same level of access to the User’s computer that the User has, and the Helper can use his own mouse and keyboard to remotely perform actions on the User’s computer. Specifically:

  • If the User is a standard user on his computer, the Helper will be able to perform only those actions on the User’s computer that can be performed by a standard user on that computer.

  • If the User is a local administrator on his computer, the Helper will be able to perform any actions on the User’s computer that can be performed by a local administrator on that computer.

  For more information on the level of control that a Helper has on a User’s computer, see the section titled "Remote Assistance and the Secure Desktop" later in this chapter.

User vs. Helper Functionality

After a Remote Assistance connection has been established and both computers have entered the Screen Sharing state, the User and Helper are able to perform the tasks listed in Table 22-1.

Table 22-1. Tasks That Can Be Performed by User and Helper During a Remote Assistance Session

DESCRIPTION OF TASK	USER?	HELPER?
Chat	Yes	Yes
Save a log of session activity	Yes (default)	Yes (default)
Configure bandwidth usage	Yes	No
Pause (temporarily hide screen)	Yes	No
Request shared control	No	Yes
Give up shared control	Yes	Yes
Disconnect	Yes	Yes

Remote Assistance and NAT Traversal

Remote Assistance works by establishing a P2P connection between the User’s computer and the Helper’s computer. One challenge this poses is that it can be difficult to establish P2P connections if one or both of the computers involved are behind a gateway or router that uses NAT. NAT is an IP routing technology described by RFC 1631 that is used to translate IP addresses and TCP/UDP port numbers of packets being forwarded. NAT is typically used to map a set of private IP addresses to a single public IP address (or to multiple public addresses). Home networks using a wireless or wired router also use NAT technology.

To overcome this difficulty, Windows 7 and Windows Vista include built-in support for Teredo, an IPv6 transition technology described in RFC 4380 that provides address assignment and automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet. The NAT traversal capability provided by Teredo in Windows 7 and Windows Vista allows Remote Assistance connectivity when one or both of the users involved in a Remote Assistance session are hidden behind a NAT. The Remote Assistance experience is transparent from the perspective of the users involved, regardless of whether or not NAT is being used on either user’s network. For most small business and home user environments, Remote Assistance in Windows 7 and Windows Vista will seamlessly traverse a NAT-enabled router with no additional router configuration required. For information on enterprises that need to remotely support users who work from home, see the section titled "Other Possible Remote Assistance Usage Scenarios" later in this chapter.

Remote Assistance can connect across restricted NATs and cone NATs, which generally comprise the large majority of deployed NATs. Beginning with Windows 7, Remote Assistance can also connect across certain types of symmetric NATs, but only if the other computer is not behind a symmetric NAT as well. For more information on NAT traversal support in Windows 7, see Chapter 28. "Deploying IPv6".

Remote Assistance will not connect in certain configurations. Specifically:

• Remote Assistance will not work if the NAT-enabled router is configured to block the specific ports used by Remote Assistance. See the section titled "Remote Assistance and Windows Firewall" later in this chapter for more information.

• Remote Assistance will not work if the User’s NAT-enabled router is configured to block all UDP traffic.

For more information on IPv6 support in Windows 7, including built-in client support for Teredo and other IPv6 transition technologies, see Chapter 28. "Deploying IPv6".

To verify whether your NAT supports Remote Assistance, you can use the Internet Connectivity Evaluation Tool at http://www.microsoft.com/windows/using/tools/igd/default.mspx. If your NAT supports Universal Plug and Play (UPnP), then Remote Assistance should be able to get a global IPv4 address that allows anyone to connect to you. If your NAT supports Teredo/IPv6 and you are running Windows 7 or Windows Vista, then an RA Helper that is running Windows 7 or Windows Vista and is Teredo-enabled should be able to connect to you.

Remote Assistance and IP Ports Used

The ports used by a Remote Assistance session depend on which version of Windows is running on the two computers involved in the session. Specifically:

• Windows 7 to Windows 7, Windows 7 to Windows Vista, or Windows Vista to Windows Vista Dynamic ports allocated by the system in the range TCP/UDP 49152–65535

• Windows 7 to Windows XP or Windows Vista to Windows XP Port 3389 TCP (local/remote)

In addition, the Offer RA via DCOM scenario uses port 135 (TCP).

Remote Assistance and Windows Firewall

The Windows Firewall is configured with a group exception for Remote Assistance. This group exception has multiple properties that are grouped together as part of the Remote Assistance exception. The Remote Assistance exception properties will change depending on the network location of the computer (private, public, or domain). For example, the default Remote Assistance exception when the computer is in a public location is stricter than when the computer is in a private location. In a public location (such as an airport), the Remote Assistance exception is disabled by default and does not open ports for UPnP and Simple Service Discovery Protocol (SSDP) traffic. In a private network (a home or work network, for example) the Remote Assistance exception is enabled by default and UPnP and SSDP traffic is permitted. In a domain-based enterprise environment, the Remote Assistance exception is typically managed using Group Policy and is enabled by default in Windows 7; it was disabled by default in Windows Vista.

The default configuration of the Remote Assistance exception in Windows Firewall varies depending on the firewall profile. Specifically, note the following:

• Private profile The Remote Assistance exception in the Windows Firewall is enabled by default when the computer location is set to Private. It is configured for NAT traversal using Teredo by default so that users in a private networking environment (for example, the home environment) can solicit help from other users who may also be behind NATs. The private profile includes the appropriate exceptions needed to allow communication with UPnP NAT devices. If a UPnP NAT is in this environment, Remote Assistance will attempt to use the UPnP for NAT traversal. This profile also includes exceptions needed for PNRP. Offer RA via DCOM is not configured in this profile.

• Public profile The Remote Assistance exception is disabled by default and no inbound Remote Assistance traffic is permitted. Windows Firewall is configured this way by default to better protect users in a public networking environment (such as a coffee shop or airport terminal). When the Remote Assistance exception is enabled, NAT traversal using Teredo is enabled. However, traffic to UPnP devices is not enabled, and Offer RA via DCOM is not enabled.

• Domain profile The Remote Assistance exception when the computer is in a domain environment is geared toward the Offer RA scenario. This exception is enabled by default in Windows 7 and is typically managed via Group Policy.

Table 22-2 summarizes the state of the Remote Assistance firewall inbound exception for each type of network location. The Remote Assistance exception has outbound properties as well; however, outbound exceptions are not enabled in Windows Firewall by default.

Table 22-2. Default State of Remote Assistance Firewall Inbound Exception for Each Type of Network Location

NETWORK LOCATION	STATE OF REMOTE ASSISTANCE EXCEPTION	DEFAULT PROPERTIES OF THE REMOTE ASSISTANCE EXCEPTION
Private (Home or Work)	Enabled by default	Msra.exe application exception UPnP enabled for communications with UPnP NATs PNRP enabled Edge traversal enabled to support Teredo
Public	Disabled by default; must be enabled by user with Admin credentials	Msra.exe application exception Edge traversal enabled to support Teredo
Domain	Enabled by default in Windows 7; disabled by default in Windows Vista	Msra.exe application exception RAServer.exe (the RA COM server) application exception PNRP enabled DCOM port 135 UPnP enabled for communications with UPnP NATs

Remote Assistance and the Secure Desktop

When a User consents to having a Helper share control of her computer during a Remote Assistance session, the User has the option of allowing the Helper to respond to UAC prompts (Figure 22-1). Typically, UAC prompts appear on the Secure Desktop (which is not remoted), and consequently the Helper cannot see or respond to Secure Desktop prompts. The Secure Desktop mode is the same mode that a user sees when she logs on to her computer or presses the Secure Attention Sequence (SAS) keystroke (Ctrl+Alt+Delete). UAC elevation prompts are displayed on the Secure Desktop instead of the user’s normal desktop to protect the user from unknowingly allowing malware to run with elevated privileges on her computer. The User must provide consent to a UAC prompt to return to her normal desktop and continue working. This consent requires either clicking Continue (if the user is a local administrator on her computer) or by entering local administrative credentials (if she is a standard user on her computer).

It is important to understand that the Secure Desktop on the User’s computer is not remoted to the Helper’s computer. In other words, the Helper can respond only to UAC prompts on the User’s computer using the User’s own credentials. This means that if the User is a standard user on her computer and the Helper is a local administrator on the User’s computer, the Helper can have only administrative privileges on the User’s computer if the User can first supply those credentials.

Enforcing this limitation is essential to ensure the security of Windows 7 desktops. The reason behind this design decision is that, if Remote Assistance was architected to allow the Helper to remotely elevate the User’s privileges, the User would be able to terminate the Remote Assistance session and thus steal local administrative credentials from the Helper.

Remote Assistance Logging

Remote Assistance can generate a session log of Remote Assistance-associated activity. Session logging is enabled by default and consists of timestamped records that identify Remote Assistance-related activities on each computer. Session logs only contain information about activities that specifically relate to Remote Assistance functionality, such as who initiated the session, if consent was given to a request for shared control, and so on.

Session logs do not contain information on actual tasks that the User or Helper performed during a session. For example, if the Helper is given Shared Control privileges, starts an Admin command prompt, and performs steps to reconfigure the TCP/IP configuration on the User’s computer during a Remote Assistance session, the session logs will not contain a record of this action.

Session logs do include any chat activity performed during a Remote Assistance session. The log generated during a session is also displayed within the chat window so that both the User and the Helper can see what is being logged during the session. Session logs also include any file transfer activity that occurs during the session, and they also record when the session has been paused.

PURPOSE OF REMOTE ASSISTANCE SESSION LOGGING

Session logs for Remote Assistance are mainly intended for enterprises that are required to maintain records of system and user activity for record-keeping purposes. They are not intended as a way to record every action performed by Help Desk personnel when troubleshooting problems with users’ computers. A typical environment in which session logging might be required would be in a banking environment, where a financial institution is required by law to maintain records of who accessed a computer and at what time.

Because the permissions on these session logs grant the User full control over logs stored on her own computer, by default, session logs are generated on both the User’s computer and the Helper’s computer so that the Helper can archive them and protect them from tampering. The logs created on each side of a Remote Assistance session are similar but not identical. This is because session logs are generated from the perspective of the computer involved—whether the User’s computer or the Helper’s computer—and therefore complement each other instead of being identical.

In an enterprise environment, Group Policy can be used to enable or disable session logging. If session logging is not configured using Group Policy, both the User and Helper are free to disable session logging on their own computers. For more information, see the section titled "Managing Remote Assistance Using Group Policy" later in this chapter.

SESSION LOG PATH AND NAMING CONVENTION

Session logs are XML-formatted documents so that they can be easily integrated into other data sets—for example, by importing them into a database managed by Microsoft SQL Server 2005. All session logs are stored in the following subfolder of the user’s profile:

%UserProfile%\Documents\Remote Assistance Logs

A unique session log file is created for each Remote Assistance session on the computer. Log files stored within this folder are formatted using XML and are named using the convention YYYYMMDDHHMMSS.xml, where the time format is 24-hour. For example, a session log created at 3:45:20 P.M. on August 13, 2008, would be named 20080813154520.xml.

The XML content of a typical session log looks like the following:

<?xml version="1.0" ?>
<SESSION>
  <INVITATION_OPENED TIME="3:24 PM" DATE="Wednesday, May 07, 2008" EVENT="A Remote
Assistance invitation has been opened." />
  <INCOMING_IP_ADDRESS TIME="3:26 PM" DATE="Wednesday, May 07, 2008">fe80::2856:e5b0:
fc18:143b%10</INCOMING_IP_ADDRESS>
  <CONNECTION_ESTABLISHED TIME="3:26 PM" DATE="Wednesday, May 07, 2008" EVENT="A Remote
Assistance connection has been established.">jdow</CONNECTION_ESTABLISHED>
  <EXPERT_REQUEST_CONTROL TIME="3:27 PM" DATE="Wednesday, May 07, 2008" EVENT="jdow has
requested to share control of the computer." />
  <EXPERT_GRANTED_CONTROL TIME="3:27 PM" DATE="Wednesday, May 07, 2008" EVENT="jdow has
been granted permission to share control of the computer." />
  <EXPERT_CONTROL_STARTED TIME="3:27 PM" DATE="Wednesday, May 07, 2008" EVENT="jdow is
sharing control of the computer." />
  <EXPERT_CONTROL_ENDED TIME="3:27 PM" DATE="Wednesday, May 07, 2008" EVENT="jdow is not
sharing control of the computer." />
  <CHAT_MESSAGE TIME="3:30 PM" DATE="Wednesday, May 07, 2008">jdow: test</CHAT_MESSAGE>
  <CHAT_MESSAGE TIME="3:30 PM" DATE="Wednesday, May 07, 2008">jchen: ok</CHAT_MESSAGE>
  <CONNECTION_ENDED TIME="3:30 PM" DATE="Wednesday, May 07, 2008" EVENT="The Remote
Assistance connection has ended." />
  <INVITATION_CLOSED TIME="3:30 PM" DATE="Wednesday, May 07, 2008" EVENT="A Remote
Assistance invitation has been closed." />
</SESSION>

Using Remote Assistance in the Enterprise

The main Remote Assistance scenario within a corporate networking environment is supporting desktop computers that are on the corporate network and joined to a domain. Users’ computers must be configured appropriately before they can be offered Remote Assistance. This is done via Group Policy, as explained in the section titled "Managing Remote Assistance Using Group Policy" later in this chapter. Additionally, the Remote Assistance exception in the Windows Firewall must be enabled. For more information, see the section titled "Remote Assistance and Windows Firewall" earlier in this chapter.

Because most corporate networks have a perimeter firewall blocking access from outside the internal network, supporting remote users who are connecting from outside the corporate network can be more difficult. However, most enterprises now use virtual private network (VPN) technologies to allow remote users to connect to their corporate networks over the Internet, and this kind of scenario generally poses no problem to Remote Assistance functionality.

Using Remote Assistance in the Corporate Help Desk Environment

The standard approach to using Remote Assistance in an enterprise environment is for Help Desk personnel to offer Remote Assistance to users who telephone to request assistance. A typical scenario might be as follows:

1. User Jane Dow (the User) is having problems configuring an application on her computer. She phones Help Desk, explains her problem briefly, and asks for help.

2. A Help Desk person named Jacky Chen (the Helper) asks Jane for the FQDN or IP address of her computer. She responds with the information, which she can get from computer properties or by running ipconfig.

3. Jacky starts Remote Assistance on his computer and uses the Offer RA feature to offer help to Jane. This causes a dialog box to appear on Jane’s computer, asking her if she would like to allow Jacky to connect to her computer.

4. Jane accepts the offer, and at this point Jane’s desktop may temporarily change to conserve network bandwidth used by the Remote Assistance session. The Remote Assistance window that opens on Jane’s screen tells her that she is being helped by Jacky.

5. At this point, Jacky can see Jane’s screen, but he can’t control it. Jane then explains the problem she is having, either by using the Chat feature of Remote Assistance, or more likely over the telephone. Jacky asks Jane to perform a series of steps to correct the problem and watches her screen in his own Remote Assistance window as she does this.

6. If the instructions Jacky provides are too complex or if time is limited, Jacky can ask Jane if he can share control of her computer. If Jane agrees, Jacky clicks the Request Control button at the top of his Remote Assistance window. A dialog box appears on Jane’s desktop asking her if she wants to allow Jacky to share control of her desktop. Jane accepts the prompt and also selects the option to allow Jacky to respond to UAC prompts on Jane’s computer.

7. Jacky is now connected to Jane’s computer using Jane’s credentials, and he can both view her screen and interact with it using his own mouse and keyboard. Jacky then proceeds to perform the steps needed to resolve the problem, either correcting the issue or demonstrating to Jane how to fix the problem if it occurs again in the future. If at any time Jane wants to force Jacky to relinquish control of her computer, she can click the Stop Sharing button or the Disconnect button, or she can press the Panic key (Esc).

Other Possible Remote Assistance Usage Scenarios

Other types of Remote Assistance scenarios are also possible for businesses ranging from large enterprises to Small Office/Home Office (SOHO) environments. Examples of possible usage scenarios include:

• A user who is having a problem configuring an application on her computer can phone the Help Desk for assistance. A support person can then use Offer RA to connect to the user’s computer, ask for control of her screen, and show the user how to configure her application. This scenario is the standard one for enterprise Help Desk environments and is described in more detail in the section titled "Using Remote Assistance in the Corporate Help Desk Environment" earlier in this chapter.

• A user who is having trouble installing a printer sends a Remote Assistance invitation to Help Desk using Windows Mail. A support person who is monitoring the Help Desk e-mail alias reads the message, opens the attached invitation file, and connects to the user’s computer. The support person asks for control of the user’s computer and walks him through the steps of installing the printer.

• A user is on the road and is connected to the internal corporate network using a VPN connection over the Internet. The user is having problems configuring Windows Mail on her computer, so she opens Windows Live Messenger and notices that someone she knows in Corporate Support is currently online. She sends a Remote Assistance invitation to the support person using Windows Live Messenger, and that person responds to the invitation, asks for control, and shows the user how to configure Windows Mail.

• A user who is having problems installing an application uses Easy Connect to request help from a support technician. Because this is the first time he has requested help from this particular support technician, the user must communicate the password for the session to the support technician using an OOB method such as making a telephone call. The next time the user needs help, however, he will not need to provide a password because of the trust relationship that was established during the first Remote Assistance session between them.

The preceding list is not intended to be complete—other corporate support scenarios using Remote Assistance are possible. Generally speaking, however, corporate environments will use Offer RA to provide assistance to users who phone Help Desk when they have problems. Some enterprises may also allow users to submit Remote Assistance invitations either via e-mail or by saving invitation files to network shares that are monitored by support personnel. Others might use IM applications that support Remote Assistance within the corpnet.

Interoperability with Remote Assistance in Windows Vista

Remote Assistance in Windows 7 is fully backward-compatible with Remote Assistance in Windows Vista, except that Windows Vista does not support the new Easy Connect method for soliciting Remote Assistance found in Windows 7. This means that a User on a Windows Vista computer cannot use Easy Connect to solicit Remote Assistance from a Helper on a Windows 7 computer, and a User on a Windows 7 computer cannot use Easy Connect to solicit Remote Assistance from a Helper on a Windows Vista computer. In addition, a Windows 7 user cannot transfer a file with a Windows Vista user during a Remote Assistance session.

Interoperability with Remote Assistance in Windows XP

Remote Assistance in Windows 7 is backward-compatible with Remote Assistance in Windows XP, with the following limitations:

• Offer RA from Windows 7 to Windows XP is supported, but Offer RA from Windows XP to Windows 7 is not supported. This means that enterprises who want to implement Offer RA as a support solution for their Help Desk departments should ensure that computers used by support personnel who will help users running Windows 7 are themselves running Windows 7 (and not Windows XP).

• NAT traversal using Teredo and IPv6 is supported on Windows 7 to Windows 7 Remote Assistance only, and not on Windows 7 to Windows XP.

• Voice support for Remote Assistance in Windows XP is not supported by Remote Assistance in Windows 7, and any attempt by a User on a Windows XP computer to use this feature during a Remote Assistance session with a Helper on a Windows 7 computer will cause a notification message regarding this limitation to appear.

• The MAILTO method of soliciting assistance that is supported by Remote Assistance in Windows XP is not supported by Remote Assistance in Windows 7.

• Windows Messenger (which shipped with Windows XP) does not ship with Windows 7. Users of Remote Assistance with Windows Messenger in Windows XP will need to migrate to an IM application such as Windows Live Messenger that supports Windows 7 Remote Assistance.

• Offer RA via Windows Live Messenger is supported in Windows 7 but not in Windows XP.

• Windows XP does not support the new Easy Connect method for soliciting Remote Assistance found in Windows 7. This means that a User on a Windows XP computer cannot use Easy Connect to solicit Remote Assistance from a Helper on a Windows 7 computer, and a User on a Windows 7 computer cannot use Easy Connect to solicit Remote Assistance from a Helper on a Windows XP computer. A Windows 7 user cannot transfer a file with a Windows Vista user during a Remote Assistance session.