From time to time as a systems administrator, you'll need to look at an issue where you really need to see the end users screen. While there are a whole range of third party tools that assist with this, I'm going to look at how we can harness functionality that's already built into Microsoft Windows - Unsolicited remote assistance.

Geoff Kendal

Geoff Kendal is a Windows/Linux systems administrator, scripter and problem solver, with over 12 years experience, based in Leeds, UK.

The 'traditional' way of using remote assistance is initiated by a user requiring help, where they send an assistance request to a 'helper'. In practice, I rarely see this method used - most probably due to the effort required on the user’s part to initiate the session. By enabling unsolicited remote assistance, we can initiate the session from the helper’s side - all the user has to do is accept our help offering - a much more seamless experience for them!

As with most windows configuration, the easiest way to go about enabling it on your domain is via Group Policy. Create a new Group Policy object, named 'Unsolicited Remote Assistance'. Right click the new Group Policy object and proceed to edit it. The settings we need to enable are located in Computer Configuration/Policies/Administrative Templates/System/Remote Assistance.

Configure Offer Remote Assistance

Configure Offer Remote Assistance

Enable Configure Solicited Remote Assistance and set Maximum ticket time (value) to 1hr.

Enable Configure Offer Remote Assistance. Be sure to specify that helpers can control the remote computer, then define which users are permitted to act as helpers. For simplicity, I just add DOMAIN\Domain Admins as helpers. Any users offering help will need to be a local administrator on the system being helped.

Configure Solicited Remote Assistance

Configure Solicited Remote Assistance

By default Windows firewall won't allow these connections, so we'll add some firewall rules to allow this. In the same GPO, navigate to Computer Configuration> Policies> Windows Settings> Security Settings> Windows Firewall with Advanced Security> Inbound Rules.

We will the need to create a few rules:

  • Allow program: %systemroot%\system32\sessmgr.exe
  • Allow program: %systemroot%\PCHEALTH\HELPCTR\Binaries\helpsvc.exe
  • Allow program: %systemroot%\system32\Raserver.exe
  • Allow port: TCP 135

The final part of the GPO is related to how UAC prompts are handled. By default windows shows them on an alternative desktop, we need to disable this so that UAC prompts are visible in the remote assistance session. If we fail to do this, whenever a UAC prompt shows we will just see a black screen with a pause icon/symbol on it. Navigate to Computer Configuration> Policies> Windows Settings> Security Settings> Local Policies> Security Options, then enable the User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop policy.

Allow UIAccess applications

Allow UIAccess applications

Now that we have completed our GPO for offering remote assistance, it will need linking somewhere appropriate, so that the systems you wish to offer help to receive our updated settings. In my test lab I have a single computers OU, so I've linked it there. Once the Group Policy has applied to your systems (reboot or gpupdate /force), you should be good to go ahead and offer assistance.

The command to start offering remote assistance is 'msra.exe /offerra'. You can optionally include a computer name or IP address at the end, so you can tie it into other management systems you may have. Alternatively, you could create shortcuts for those regular customers!

Windows Remote Assistance

Windows Remote Assistance

Win the monthly 4sysops member prize for IT pros

Share
2+

Users who have LIKED this post:

  • avatar

Related Posts

21 Comments
  1. Shqipdo 2 years ago

    Can u explain in detail all the steps please?

    0

  2. John 2 years ago

    How to share the desktop automatically without send a request control?

    0

  3. Todd 2 years ago

    Shqipdo i dont know how more detailed he can be!. he even has screenshots for crying out loud. this could not be easier to setup.

    follow the instructions and you may be surprised.

    Great Article Geoff, I have referred to it at many clients to set them up. (I am old and forget things ...)

    Cheers,
    Todd.

    0

  4. Author
    Geoff 2 years ago

    Cheers Todd! Glad it's helped you!

    0

  5. Tracy 2 years ago

    Seriously great help! You made this incredibly easy . . . thank you!

    0

  6. Jason 2 years ago

    We have this working for some time on our domain. We have a trust in place with another domain also in our environment.
    I have credentials for both.
    When I am logged into domain A, and I try to remote to a PC on Domain A, this works. When I am logged into Domain B, and I try to remote to a PC on Domain A, I cannot connect ("your offer of assistance cannot be sent).
    I have added my Domain B creds to local admin on pc, I have added my Domain B creds to GP group in domain A for remote assistance.

    Any thoughts on what I am missing?

    0

  7. PatrickS 2 years ago

    Perfect! This will save me a lot of time.
    Many thanks

    0

  8. Chuck 2 years ago

    Is it possible to set this up in only a workgroup environment (no domain)?

    0

  9. Schlegel 2 years ago

    Perfect! Thank You very much !

    0

  10. TrevorX 2 years ago

    Offer Remote Assistance works whether you're in a domain or workgroup, but in order to push Group Policy settings out to domain member computers (ie 'auto configuration') you need configure Group Policy for the domain within the Domain Controllers, and then member machines will acquire those settings when they refresh their domain connection (usually when you turn them on and they connect to the network, but you can force Group Policy updates manually too).

    For Workgroup computers you will either need to configure these settings manually or create a script to set them up and run it on each machine, either locally or using Remote Desktop if you already have an administrative account to connect to.

    So, to summarise, there is nothing about Remote Assistance that requires a domain - it works on any Microsoft OS from Windows 7 up (pretty sure it worked on Vista too, but who is still running that?). The only thing domain specific is pushing out Group Policy rules, something you cannot do in a Workgroup (centralised management is kind of the point of having a Domain).

    0

    • Chuck Henry 2 years ago

      @TrevorX: For workgroup computers not on a domain, are you saying there's a place in the local computer's policy to allow Unsolicited Remote Assistance? As an administrator of a small network, this is what I need, but Microsoft appears to make it impossible or very difficult.

      0

      • Will 2 years ago

        I haven't tried local group policy with this setup as I am on a domain, but you can try to set these polices from the artical with Local Group Policy as described here:
        Open the Local Group Policy Editor

        0

  11. Chuck Henry 2 years ago

    Further information: When I run %WinDir%\system32\msra.exe /OfferRA, input the target IP address, the "Offering Remote Assistance" dialog appears, but ultimately times out with the following error: "Your offer to help could not be completed. Either Remote Assistance is unable to find the remote computer or you do not have permission to connect to the remote computer. Verify that the computer name and permissions are correct, and then try again."

    0

  12. Kelvin Johnson 1 year ago

    Hi Chuck

    How is your group policy configured? When you create a group policy and enable "configure offer remote assistance" You have to link that policy to the right group or computers in your domain. If not, the policy will not be applied to any computer.

    Also make sure that "Allow Remote Assistance connections to this computer" is allowed on all computers on your domain environment. You can check if this is allowed on your domain computer by going to Advanced system properties - Remote.

    0

  13. Jim 1 year ago

    Above, TrevorX implies that the domain is irrelevant. He says "The only thing domain specific is pushing out Group Policy". I disagree, but would very much like to be proven wrong as it would solve one of our problems. Here is a scenario: Trusts are not allowed. Unsolicited is mandatory. UserX is helper/expert. He is a Domain Admin on our domain and regularly logs in internally, from other domains (via IPSec), and from laptops not connected to any domain (via OpenVPN). With all the above, he enjoys all his Domain Admin rights and also occasionally uses RDP. Unsolicited Remote Assistance works fine within our domain and is push via GPO. OurDomain\UserX is obviously defined as a helper in the GPO. So, how do you add OtherDomain\UserX (without a trust), or Workgroup\UserX in the GPO?

    On a tangent, Geoff suggests enabling "Configure Offer Remote Assistance". It is not required for Unsolicited and could be considered a security hole since Standard Users can then allow outside users into your network. I set it to disabled.

    0

  14. Jim 1 year ago

    @Geoff/Moderator

    Correction: In the above tangent I typed "Configure Offer Remote Assistance" which should be "Configure Solicited Remote Assistance". Please edit accordingly. You might want to try these firewall settings - allow inbound tcp 135 for msra.exe & raserver.exe - I find that's sufficient.

    0

  15. Eric 9 months ago

    Fantastic write up Geoff. Thank you!

    0

  16. Michael 9 months ago

    Hello, nice, is it possible to script this local Policy in order to deploy easily on each computer?

     

    Regards,

    0

  17. nadim 3 months ago

    Nice article - i recommend people try this out on a small OU that doesn't include other critical machines...such as a Domain Controller for instance... (me? of course I did)...sent me in circles for days -

    The GPO in my understanding allows the ports/programs you set exclusively, so if a machine under that policy had other firewall settings they all go bye-bye...

    spent days trying to figure out why DNS names were not resolving and why domain machines couldn't authenticate properly (yeah the rules seem to set in randomly and slowly so you don't get this abrupt-oh everything is out-all of a sudden that would get you to check your firewall settings-No!), first you get very quaint nonchalant kind of issues like long-login-times and delayed gpupdates...

    1+

  18. William 3 months ago

    Is this the same for Windows 10?

    0

  19. Shaun 4 weeks ago

    Hi and many thanks for this. Very well explained.

    I just have a slight challenge.

    Our Anti-Virus controls the firewall section and disabled the windows firewall..

    What ports would need to be open inbound on client machines in order for this to work.

    Regards,

    Shaun

    0

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account