Windows Vista Resource Kit Chapter 23: Supporting Users Using Remote Assistance (Part 1)

by [Published on 19 June 2007 / Last Updated on 19 June 2007]

A WindowsNetworking.com exclusive! The three articles in this series represent an entire chapter of the Windows Vista Resource Kit, excerpted with permission from Microsoft Press.

If you would like to read the other parts in this article series please go to:
Windows Vista Resource Kit Chapter 23: Supporting Users Using Remote Assistance (Part 2)
Windows Vista Resource Kit Chapter 23: Supporting Users Using Remote Assistance (Part 3)

Remote Assistance (RA) in Windows Vista includes a number of improvements in connectivity, performance, usability, and security along with feature enhancements that make it even more useful than RA in Windows XP. 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 Vista, how to use it to support end users, and how to manage it using Group Policy and scripts.


Get the Windows Vista Resource Kit today!

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 non-technical, inexact language. As a result, Help Desk personnel are generally reduced to asking a series of simple questions to try and 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 misunderstanding 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 (RA) 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.

Remote Assistance vs. Remote Desktop

Remote Assistance and Remote Desktop are different features of Vista that have entirely different uses. Remote Desktop is based on Microsoft’s Terminal Services and is a tool for remotely logging on to remote computers. When you use Remote Desktop to connect to a remote computer, a new user session is established. Remote Desktop can also establish sessions with computers that have no interactive sessions running (no users logged on locally) such as headless servers. For more information on Remote Desktop, see Chapter 28, “Connecting Remote Users and Networks.”

Remote Assistance, on the other hand, is a tool for interactively helping users troubleshoot problems with their computers. To use Remote Assistance, both the User (also called the Novice) and the Helper must be present on their computers. Unlike Remote Desktop, Remote Assistance  does not  create a new session. Instead, Remote Assistance allows the Helper to work in the existing session of the User. The User’s desktop gets remoted to the Helper, who can then view the User’s desktop and, with the User’s  consent, share control of the desktop.

Here is another way to summarize the difference between these two features: In Remote Assistance, both users involved are looking at the same desktop using the same logon credentials (those of the interactively logged-on User) and can share control of that desktop; in Remote Desktop, when the remote person logs on, the interactively logged-on user (if there is one) is logged out.

Improvements to Remote Assistance in Windows Vista

Windows Vista includes a number of new features and enhancements for Remote Assistance compared to the Remote Assistance available in Windows XP, including:

  • Connectivity improvements with transparent NAT traversal using Teredo and IPv6.
  • An improved user interface that is easier to launch and use.
  • A standalone 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 UAC.
  • New Offer RA via IM scenario and an open API for integration with peer-to-peer applications.
  • Additional Group Policy settings for improved manageability.

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

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

For information on interoperability between the XP and Vista 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). RA is launched from the Start Menu by navigating to All Programs, clicking Maintenance, and then selecting Windows Remote Assistance. It can also be launched 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 RA session using e-mail, instant messaging, 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). An example of an e-mail client that supports SMAPI is Windows Mail, which is included with Windows Vista. Other examples of SMAPI-compliant e-mail clients include Microsoft Outlook and other third-party clients. In this approach, the User launches the RA user interface to create an email message that has an RA invitation file (*.MsRcIncident) attached to the message. The User must enter a password for the RA 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 RA invitation, she opens the attached ticket, enters the password that was conveyed by the User, and the RA session starts. The Helper must respond to the invitation from the User within a specified time limit (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 an RA invitation file and saves it in the shared folder. The User must provide a password that must be communicated to the Helper using an out-of-band (OOB) method such as a telephone call. The Helper retrieves the ticket from the shared folder, opens it, enters the password, and the RA 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 using Group Policy).
    • Solicited RA Using Instant Messaging. This method for soliciting assistance requires that the instant messaging (IM) applications being used by both the User and the Helper support Microsoft’s new Rendezvous API. Windows Live Messenger is an example of an IM application that supports Rendezvous. Windows Live Messenger is available as a download. 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 SDK on MSDN at http://windowssdk.msdn.microsoft.com/en-us/library/default.aspx.
  • Unsolicited RA. In Unsolicited RA (also known as Offer RA) the Helper offers help to the User by initiating the RA session.
    • Offer RA using DCOM. This is a typical corporate Help Desk scenario in which all the users are in a domain. The Helper enters either the fully qualified 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 a domain administrator to be able to offer Remote Assistance to the Users. (For information on how to authorize Helpers for offering RA, 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.
    • Offer RA using Instant Messaging. This method for soliciting assistance requires that the instant messaging (IM) applications being used by both the User and the Helper support the Rendezvous API. In this approach, the Helper offers assistance to someone on her buddy list. If the buddy agrees, then he must enter a password to be used by the Helper. The password must be relayed by an OOB mechanism to ensure that the remote person is really the User’s buddy (and not someone masquerading as the buddy). For more information on the Rendezvous API, see the Windows SDK on MSDN at http://windowssdk.msdn.microsoft.com/en-us/library/default.aspx.

How It Works: RA Invitation Files

Remote Assistance invitation files (.MsRcIncident) are XML-formatted file documents that include information used by the Helper’s computer that will attempt to connect. This ticket information is encrypted to prevent unauthorized users from accessing the information should e-mail or file transfer be used to send the invitation over an unsecured network.

If the e-mail method is used to send the invitation file to the Helper, the invitation file is sent as an e-mail attachment with a file name of RATicket.MsRcIncident. If the file transfer method is used instead, the invitation file is created by default on the desktop of the User’s computer and the file name of the invitation is Invitation.MsRcIncident.

Remote Assistance Operational States

Remote Assistance has three operational states:

  • Waiting For Connect. This state occurs when either:
    • The Helper has offered RA 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 an RA connection has been established and both computers have entered the Screen Sharing state. Once the RA 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 RA application opens on the User’s computer and waits for the Helper to accept the invitation. If the User closes RA 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 RA to the User. In the Screen Sharing state, an RA 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 only be able to perform 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

Once an RA 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 23-1.

Description of Task

User?

Helper?

Chat

Yes

Yes

Send files

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

Disconnect using Esc key

Yes

No

Table 23-1: Tasks that can be performed by User and Helper during an RA session

Remote Assistance and NAT Traversal

Remote Assistance works by establishing a peer-to-peer connection between the User’s computer and the Helper’s computer. One challenge this poses is that it can be difficult to establish peer-to-peer connections if one or both of the computers involved are behind a gateway or router that uses Network Address Translation (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, Vista includes 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 Vista allows RA connectivity when one or both of the users involved in an RA session are hidden behind a NAT. The RA experience is transparent from the perspective of the users involved, regardless of whether NAT is being used on either user’s network. For most small business and home user environments, Vista’s RA 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 “Enterprise Remote Assistance Scenarios” later in this chapter.

NOTE: Offering RA using DCOM is not usually a Teredo scenario because enterprise users are behind a corporate firewall and not separated from each other by NATs.

Remote Assistance will not connect in certain configurations. Specifically:

  • Teredo cannot traverse a symmetric NAT. Remote Assistance can only connect across restricted NATs and cone NATs. In most cases, this is not a significant limitation because the large majority of deployed NATs are either the restricted or cone variety. For more information on NAT traversal support in Vista, see Chapter 29, “Deploying IPv6.”
  • RA will not work if the NAT-enabled router is configured to block the specific ports used by RA. 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.

NOTE: To determine the type of NAT a network is using, open an elevated command prompt and type netsh interface teredo show state.

For more information on IPv6 support in Windows Vista, including built-in client support for Teredo and other IPv6 transition technologies, see Chapter 29.

Remote Assistance and IP Ports Used

The ports used by a Remote Assistance session depend on whether the session is between two Vista computers or between a Vista computer and a downlevel Windows XP computer. Specifically:

  • Vista to Vista RA Session: Dynamic ports allocated by the system in the range TCP/UDP 49152–65535
  • Vista to XP RA Session: 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 RA exception. The RA exception properties will change depending on the network location of the computer (private, public, or domain). For example, the default RA 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 RA exception is disabled by default and does not open ports for Universal Plug-and-Play (UPnP) and Simple Service Discovery Protocol (SSDP) traffic. In a private network (a home or work network, for example) the RA exception is enabled by default and uPnP and SSDP traffic is permitted.  

Table 23-2 summarizes the state of the Remote Assistance firewall inbound exception for each type of network location. The RA exception has outbound properties as well; however, the Windows Firewall is not by default configured to enable outbound properties.

Network Location

State of RA Exception

Default Properties of the RA  Exception

Private (Home or Work)

Enabled by default

  • Msra.exe application exception
  • uPnP enabled for communications with uPnP NATs
  • 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

Disabled by default—typically enabled by Group Policy

  • Msra.exe application  exception
  • RAServer.exe (the RA COM server) application exception
  • DCOM Port 135
  • uPnP enabled for communications with uPnP NATs
Table 23-2: Default State Of Remote Assistance Firewall Inbound Exception For Each Type Of Network Location

In other Windows Firewall profiles, the default configuration of the Remote Assistance exception is as follows:

  • Private profile. The RA 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 there is a uPnP NAT in this environment, Remote Assistance will attempt to use the uPnP for NAT traversal. Offer RA via DCOM is not configured in this profile.
  • Public profile. The RA exception is disabled by default and no inbound RA 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 RA 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 RA exception when the computer is in a domain environment is geared towards the Offer RA scenario. This exception is disabled by default and is typically enabled via Group Policy. Teredo is not enabled in this profile because corporate networks typically have a corporate firewall that blocks Teredo UDP traffic. However, uPnP is enabled so that uPnP NATs can be communicated with.

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 23-1). Typically, User Account Control (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 admin on her computer) or by entering local admin credentials (if she is a standard user on her computer).


Figure 23-1: The User has the option of allowing the Helper to respond to UAC prompts when the RA session is in 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 only respond 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 while the Helper is a local administrator on the User’s computer, the Helper can only have 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 Vista desktops. The reason behind this design decision is that if RA was architected to allow the Helper to remotely elevate the User’s privileges, the User would be able to terminate the RA session and thus steal local admin credentials from the Helper.

Remote Assistance Logging

Remote Assistance can generate a session log of RA-associated activity. Session logging is enabled by default and consists of time-stamped records that identify RA-related activities on each computer. Session logs only contain information about activities that specifically relate to RA functionality, such as who initiated the session, whether 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 an RA session, the session logs will not contain a record of this action.

Session logs do include any chat activity performed during an RA 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 also record when the session has been paused.

Purpose of RA Session Logging

Session logs for RA 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 ACLs 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 Helper’s computer so that the Helper can protect and archive them from tampering. The logs created on each side of an RA 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” 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 under each user’s Documents folder within the following path:

Users\user_name\Documents\Remote Assistance Logs

A unique session log file is created for each RA 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, 2006, would be named 20060813154520.xml.

The XML content of a typical session log looks like this:

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

If you would like to read the other parts in this article series please go to:
Windows Vista Resource Kit Chapter 23: Supporting Users Using Remote Assistance (Part 2)
Windows Vista Resource Kit Chapter 23: Supporting Users Using Remote Assistance (Part 3)

Featured Links