Export (0) Print
Expand All
Expand Minimize
4 out of 5 rated this helpful - Rate this topic

Remote Assistance Overview

Applies To: Windows Server 2008

Understanding Remote Assistance

Computer users, particularly users without much technical expertise, often have configuration problems or usage questions that are difficult for a support professional to diagnose and fix over the phone. 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 (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.

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 the following.

  • Connectivity improvements with transparent NAT traversal using Teredo and Internet Protocol version 6 (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 User Account Control (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 Windows Vista deprecates the following features that were available in Windows XP.

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

  • No more support for voice sessions

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 e-mail 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.”

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

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. For more information, see the section titled “Managing Remote Assistance Using Group Policy.”

  • 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” in the Windows Vista Resource Kit.

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 the following table.

 

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

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, Windows 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 Windows 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, The RA in 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 “Enterprise Remote Assistance Scenarios.”

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

  • RA will not work if the NAT-enabled router is configured to block the specific ports used by RA. For more information, see the section titled “Remote Assistance and Windows Firewall.”

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

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

Remote Assistance and IP Ports Used

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

  • Windows Vista to Windows Vista RA Session: Dynamic ports allocated by the system in the range TCP/UDP 49152–65535

  • Windows Vista to Windows 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

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 UPnP technology 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.

The following table 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.

Default State Of Remote Assistance Firewall Inbound Exception For Each Type Of Network Location

 

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

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

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

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 resembles the following.

<?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>

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 RA. This is done via Group Policy. Additionally, the Remote Assistance exception in the Windows Firewall must be enabled.

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 RA functionality.

noteNote
Offer RA needs preconfiguration of the User’s computer via Group Policy. See “Managing Remote Assistance Using Group Policy” for more information.

Interoperability with Remote Assistance in Windows XP

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

  • Offer RA from Windows Vista to Windows XP is supported, but Offer RA from Windows XP to Windows Vista 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 Vista are themselves running Windows Vista (and not Windows XP).

  • NAT traversal using Teredo and IPv6 is supported on Windows Vista to Windows Vista RA only, and not on Windows Vista to Windows XP.

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

  • The MAILTO method of soliciting assistance that is supported by RA in Windows XP is not supported by RA in Windows Vista.

  • Windows Messenger (which shipped with Windows XP) does not ship with Windows Vista. Users of RA with Windows Messenger in Windows XP will need to migrate to an IM vendor that supports Windows Vista and Remote Assistance. Windows Live Messenger currently supports Windows XP, Windows Vista, and Remote Assistance.

  • Offer RA via Messenger is a new feature in Windows Vista and is not available in Windows XP.

Managing Remote Assistance Using Group Policy

In an enterprise environment, Remote Assistance can be managed by using Group Policy. The policy settings for Remote Assistance are all per-computer settings and are found in the following policy location:

Computer Configuration\Administrative Templates\System\Remote Assistance

When these policy settings are written to the registry on targeted computers, they are stored under the following registry key:

HKLM\SOFTWARE\Policies\Microsoft\WindowsNT\Terminal Services

Remote Assistance policy settings are summarized in the following table.

Group Policy Settings for Remote Assistance

 

Policy Description

Solicited Remote Assistance

Enabling this policy allows users of targeted computers to use Solicited RA to request assistance using e-mail, file transfer, or instant messaging. Disabling this policy prevents users from using Solicited RA. The default setting is Not Configured, which allows users to change their Remote Assistance settings using the Remote tab of the System CPL in Control Panel.

If the policy is Enabled, you can further configure whether Helpers can be prevented from sharing control of the User’s computer, the maximum ticket lifetime, and the method used for sending invitations my e-mail. (Windows Vista does not support the MAILTO method—select SMAPI instead if the targeted computers are running Windows Vista.) Ticket lifetime applies only to RA invitations sent by e-mail or file transfer. The default ticket lifetime when Group Policy is not being used is 6 hours.

If this policy is Enabled, you must also enable the Remote Assistance exception in Windows Firewall to allow Solicited RA to work.

In an unmanaged environment, this setting can also be configured using the Remote tab of the System CPL in Control Panel.

This policy is also supported on Windows XP Professional and Windows Server® 2003.

Offer Remote Assistance

Enabling this policy allows designated Helpers to use Offer RA to offer assistance to users of targeted computers. Disabling this policy or leaving it Not Configured prevents Offer RA from being used to offer assistance to users of targeted computers.

If the policy is Enabled, you can further configure whether Helpers can view or control the Users’ computers, and you must specify a list of Helpers who are allowed to Offer RA to the users of the targeted computers. Helpers can be either users or groups and must be specified in the form domain_name\user_name or domain_name\groupname.

If this policy is Enabled, you must also enable the Remote Assistance exception in Windows Firewall to allow Offer RA to work.

This policy is also supported on Windows XP Professional and Windows Server 2003. See the Explain tab of this policy setting for more details.

Allow Only Vista Or Later Connections

The default Windows Vista invitation file includes a Windows XP-specific node for backward compatibility. This node is not encrypted and allows Windows XP computers to connect to the Windows Vista computer that created the ticket. Enabling this policy causes all RA invitations generated by users of targeted computers to not include the Windows XP node, thereby providing an additional level of security and privacy. Disabling this policy or leaving it Not Configured leaves information such as IP address and port number unencrypted in RA invitations This policy setting only applies to RA invitations sent using e-mail or file transfer, and has no effect on using instant messaging to solicit assistance or on using Offer RA to offer assistance.

In an unmanaged environment, this setting can also be configured by clicking Advanced from the Remote tab of the System Properties dialog.

This policy is supported only on Windows Vista and later platforms.

Customize Warning Messages

Enabling this policy causes a specified warning to be displayed on targeted computers when a Helper wants to enter Screen Sharing State or Control Sharing State during an RA session. Disabling this policy or leaving it Not Configured causes the default warning to be displayed in each instance.

If the policy is Enabled, you can further specify the warning message to be displayed in each instance.

This policy is supported only on Windows Vista and later platforms.

Turn On Session Logging

Enabling this policy causes RA session activity to be logged on the targeted computers. For more information, see the section titled “Remote Assistance Logging.” Disabling this policy causes RA auditing to be disabled on the targeted computers. The default setting is Not Configured, in which case RA auditing is automatically turned on.

This policy is supported only on Windows Vista and later platforms.

Turn On Bandwidth Optimization

Enabling this policy causes the specified level of bandwidth optimization to be used to enhance the RA experience over low-bandwidth network connections . Disabling this policy or leaving it Not Configured allows the system defaults to be used.

If the policy is Enabled, you must specify the level of bandwidth optimization you want to use from the following options:

  • No Optimization

  • No Full Window Drag

  • Turn Off Background

  • Full Optimization (Use 8-Bit Color)

If No Optimization is selected, the User’s computer will use the Windows Basic theme with full background, and during a shared control session the Helper will be able to drag full windows across the User’s screen. Additional optimization turns off effects to allow a more responsive experience for the Helper.

This policy is supported only on Windows Vista and later platforms.

noteNote
In Windows XP, members of the Domain Admins group were implicitly granted Helper privileges even if they were not added to the Helpers list of the Offer Remote Assistance policy setting. This is no longer the case in Windows Vista, where the Domain Admins group must now be explicitly added to the Helpers list to grant them Helper privileges for Offer RA.

Configuring Remote Assistance in Unmanaged Environments

Users of unmanaged computers can enable and configure Remote Assistance using the Remote tab of the System CPL in Control Panel. Enabling or disabling Remote Assistance and configuring its settings this way requires local administrator credentials on the computer, so a UAC prompt will appear when the user tries to change this setting.

Note that settings changes made this way will affect all users on the system. The per-computer registry settings for Remote Assistance are found under the following key:

HKLM\SYSTEM\CurrentControlSet\Control\Remote Assistance

In managed environments, when the following Group Policy setting is Enabled, the Control Panel settings for configuring Remote Assistance become unavailable (are grayed out).

Computer Configuration\Administrative Templates\System\Remote Assistance\Solicited Remote Assistance

noteNote
Group Policy settings always prevail over locally configured settings when they overlap.

Additional Registry Settings for Configuring Remote Assistance

Additional behavior for Remote Assistance can be configured by modifying certain registry settings. Specifically, per-user registry settings for Remote Assistance are found under the following key:

HKCU\Software\Microsoft\Remote Assistance

These settings are changeable when in the Waiting To Connect mode or when in the connected mode from the Settings button.

noteNote
If Group Policy is used to manage Remote Assistance settings and any configured policy settings overlap these registry settings, the policy settings prevail.

Summary

Remote Assistance has been enhanced in Windows Vista to provide better performance, improved usability, NAT-traversal flexibility, and increased security. Best practices for implementing Remote Assistance in an enterprise environment include:

  • Use Group Policy to enable users of targeted computers in a domain or OU to receive offers of RA from Help Desk personnel.

  • Use Group Policy to enable the RA exception in the Windows Firewall.

  • Use Group Policy to deploy scripts to enable users to run the msra.exe executable if you want to customize how they launch RA sessions—for example, to upload an invitation to a network share monitored by support personnel.

  • If all of your support computers are running Windows Vista, use Group Policy to encrypt RA tickets to hide sensitive information such as users’ IP addresses and computer names.

  • If corporate policy requires RA records for auditing purposes, use Group Policy to enable RA logging on your company’s desktop computers and run scripts to periodically move both Helper and User RA logs to a safe storage.

  • To meet corporate privacy and security requirements, use Group Policy to customize the text message that users see before they allow the Helper view their screens or share control.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.