To find out how to use Windows Remote Assistance, see Get help with your computer using Windows Remote Assistance. You can also offer assistance to someone else, and when that person accepts your offer, Windows Remote Assistance creates an encrypted connection between the two computers. . Starting with Windows 10 Fall Creators Update (1709), look for Remote Desktop under System in the Settings app instead of using the Remote Desktop Assistant. Microsoft Remote Desktop assistant allows you to configure your PC for remote access From your Windows PC, access the Microsoft Remote Desktop assistant to configure it for remote. The Microsoft-Windows-RemoteAssistance-Exe component enables a user with a computer problem to receive assistance from another person who is located elsewhere. The helper can be a friend or a support professional. In the corporate environment, the helper is usually an employee receiving help from the corporate IT helpdesk. Remote Assistance quit working for me when trying to help others. Quick Assist easily connects to remote users needing assistance where Remote Assistance used to always fail for me. I suspect that the Teredo IPv6 tunneling used by Remote Assistance is failing for some reason. However, Quick Assist is only on version 1607 of Windows 10.

Home > Sample chapters > Windows

• 10/7/2009

1. Understanding 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.

Microsoft Remote Assistance Windows 7

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

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

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).

Figure 22-1 The User has the option of allowing the Helper to respond to UAC prompts when the Remote Assistance session is in the Control Sharing state.

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%DocumentsRemote 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:

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.

Related resources

• By Mark E. Russinovich, David A. Solomon, Alex Ionescu
• eBook (Watermarked) $39.99

• By Mark E. Russinovich, David A. Solomon, Alex Ionescu
• Book $49.99

• By Mark E. Russinovich, David A. Solomon, Alex Ionescu
• eBook (Watermarked) $35.99

MetaLAN

• Up and running in 5 minutes
• Agent less - No need to install anything on the endpoints
• Free download - No registration required

Prerequisites

You will require the Group Policy Management Tools on Windows 7, Windows 8, Windows10, Windows Server 2008, Windows or Server 2012, Windows Server 2016 or Windows Server 2019. These are part of the Remote Server Administration Tools (RSAT) availabale form the Microsoft web site.

Instructions

To enable Remote Assistance and allow access through the Windows Firewall with Advanced Security using Group Policy (Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2012) please follow these instuctions.

Turning on Remote Access using Group Policy

Is Windows Remote Assistance Safe

1. 1. Edit an existing Group Policy object or create a new one using the Group Policy Management Tool.
   2. Expand the Computer Configuration/Policies/Software Settings/Administrative Templates/System/Remote Assistance node and open the Offer Remote Assistance rule.
   3. Check the Enabled radio button. Under Options: select Allow helpers to remotely control the computer from the drop down list. Click the Show… button.
   4. Enter the users or groups you want to have permissions to offer Remote Assistance, one per line. Then click OK.
      
   5. Click the OK button to exit and save the new setting.
   6. Make sure the Group Policy Object is applied to the relevant computers using the Group Policy Management Tool.

Remote Assistance Support From Microsoft

Allowing access through the Windows Firewall with Advanced Security using Group Policy

1. 1. Edit an existing Group Policy object or create a new one using the Group Policy Management Tool.
   2. Expand the Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Windows Firewall with Advanced Security/Inbound Rules node.
   3. Check the Predefined: radio button and select Remote Assistance from the drop down list. Click Next
   4. Check the Remote Assistance rules for the Domain Profile and click Next.
   5. Check the Allow the Connection radio botton and click Finish to exit and save the new rule.
   6. Make sure the Group Policy Object is applied to the relevant computers using the Group Policy Management Tool.