Answered by:
Remote Assistance & UAC

Question
-
Hi All,
I would like to use remote assistance to help my staff - after all that's what it's designed for
The problem I am having is that general users are not machine / domain admins.
When they send a remote assistance request to me, for me to do anything more than open notepad or the like the user is prompted to enter admin account creditials - which they don't have - so I have to go find them and type it in directly, hence making remote assistance nothing more than a convoluted support request email system
Is there a way a user can send a request, and the remote helper (that's me) enter the UAC admin credentials instead of the local user? Group policy or something...???
Thanks guys!
Russell.- Moved by Carey FrischMVP, Moderator Thursday, September 8, 2011 3:51 PM Moved to more appropriate forum category (From:Windows Vista Setup)
Sunday, June 3, 2007 3:17 PM
Answers
-
Hi ppl,Note: This is based around the Expert being on a 2003 Server and the Novice being Vista and the vista client generating a RA (remote assistance) request file.I simplified the RA request file creation by creating a small HTA that generates the request file and saves it on the 2003 management server in a hidden share.Workaround for the UAC problem is to set the following policy either locally or via a Domain GPO.Computer Configuration > Windows Settings > Local Policies > Security Options > User Account Control : Switch to the secure desktop when prompting for elevation. Check Define this policy setting and select Disabled.Now when you check the elevated access check box the UAC prompt will appear on the experts session and you will not get the irritating Pause signAs always do your own testing first!Cheers,Barry
- Proposed as answer by Russ-ASID Friday, April 22, 2011 6:49 PM
- Marked as answer by Carey FrischMVP, Moderator Tuesday, September 20, 2011 12:31 PM
Tuesday, February 5, 2008 6:05 PM
All replies
-
UAC is designed to highly secure your Windows and your data! It's a hard closed system that prompts for operations with tasks would require administrator privilages and tasks which would affect system or files directly (delete, move or execution of data). It's useful to prevent trojans and worms to execute behind being watched by you "as administrator". Remote assistance must be of those applications with Run as Admin or high elevation privilages. You may disable the UAC if your work concentrated specially on Remote Assistance Application.
Good luck
- Proposed as answer by CProfile Wednesday, January 28, 2015 5:40 PM
Sunday, June 3, 2007 7:53 PM -
I understand why UAC is there, I do not want my users running as admins, nor disable UAC, hence the problem.
How I can provide remote assistance (which fundamently requires admin access to be of any significant use) to a user without giving them an admin login - to enable me to be a remote admin?
It seems that I have the key to the lock, but I must give to the user in order to use it, and hence remove the reason for the remote assistance?
Or have I missed the point here...
I want to be a remote admin, helping my users, but in order to do so, I must give them admin access?
ThanksSunday, June 3, 2007 11:06 PM -
Did you find a solution? I have the same problem.
I want to help my users but I don't want them to have local admin passwords.
Andrew
Friday, November 9, 2007 3:50 PM -
Hi Andrew,
No, I never did find a solution
Sorry!Friday, November 9, 2007 8:47 PM -
I am also having this issue. I will look around a bit more before opening a ticket with Microsoft utilizing my Partner support for business critical down situations. I will come back and post the resolution if there is one.Thursday, January 10, 2008 11:14 PM
-
I've found the answer. If UAC is enabled, the user MUST respond to a UAC prompt when allowing remote assistance. This is a design "feature" that essentially makes it impossible for a company to help their users unless the users are granted local admin rights on the PC, unless a third party product is used or UAC is disabled. Thanks Microsoft for making our jobs that much more difficult and costly.
Below is an excerpt from the Vista Resource Kit book (from http://www.windowsnetworking.com/articles_tutorials/Windows-Vista-Resource-Kit-Chapter-23-Supporting-Users-Using-Remote-Assistance-Part1.html)
Pay attention to the last paragraph... basically, the user must allow the helper to have admin access by providing their own admin credentials in order to prevent them from stealing local admin priviledges from the helper, which is moot because they already must have local admin priviledges! At least MS should have provided a Group Policy setting that turns off UAC for RA in a Domain or something similar.
--------------------
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 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.
Friday, January 25, 2008 7:04 PM -
Hi ppl,Note: This is based around the Expert being on a 2003 Server and the Novice being Vista and the vista client generating a RA (remote assistance) request file.I simplified the RA request file creation by creating a small HTA that generates the request file and saves it on the 2003 management server in a hidden share.Workaround for the UAC problem is to set the following policy either locally or via a Domain GPO.Computer Configuration > Windows Settings > Local Policies > Security Options > User Account Control : Switch to the secure desktop when prompting for elevation. Check Define this policy setting and select Disabled.Now when you check the elevated access check box the UAC prompt will appear on the experts session and you will not get the irritating Pause signAs always do your own testing first!Cheers,Barry
- Proposed as answer by Russ-ASID Friday, April 22, 2011 6:49 PM
- Marked as answer by Carey FrischMVP, Moderator Tuesday, September 20, 2011 12:31 PM
Tuesday, February 5, 2008 6:05 PM -
This is seriously doing my head in. I set up a computer for an overseas colleague, without giving him administrative access. I figured that if he needed to install something, I could provide remote assistance and enter the administrator password for him. Obviously this isn't possible due to this "feature"
Unfortunately I did not discover this problem until after the computer was sent. While there are a few ways round this, (like turning off UAC, using Barry's security policy change) they all require the admin access that I can not provide so I am stuck in a real catch-22 situation. I really don't want to give him the password as foolishly I used a password in use in other places and it would be a hassle to change it in multiple locations
Can anyone think of any way of modifying the registry or local policy that does not invoke UAC?Tuesday, April 15, 2008 3:23 PM -
Disabling UAC or the Secure Desktop is a terrible solution. Microsoft, GET IT TOGETHER.Vista Remote Assistance is totally useless in the enterprise. Their I no reason the USER needs administrative privileges to receive Remote Assistance. This isn't even a technical question, it's just plain stupid. Their is no technical reason that Remote Assistance can't be given my network credentials to initiate UAC access. I have to authenticate to initiate Remote Assistance anyway, just like Remote Desktop.Also, showing the checkbox to allow UAC prompts to non admins is just plain stupid. Every user in my company has tried to check that box, and then get stuck because they don't have permission and don't know what to do.This is one more feature from Windows XP that has been ruined in Vista.Tuesday, April 15, 2008 5:42 PM
-
MS has fixed this problem in Vista SP1. Find this local security policy: User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop - and set it to Enabled. Problem solved.Friday, September 12, 2008 7:19 AM
-
Pirks wrote: MS has fixed this problem in Vista SP1. Find this local security policy: User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop - and set it to Enabled. Problem solved. That is incorrect. User's will still get a UAC prompt for admin creds, even with the policy enabled, and the Helper(Admin) on the other end will still get the black screen. it's only after that initial promp that the rest of the RA session will have secure desktop disabled.
bump this thread for a better solution from the MSFT, pros.
currently, it seems the workaround is to disable secure desktop.
Wednesday, December 3, 2008 10:54 PM -
Anyone can comment if this problem is fixed in Windows7?
Remote assistance (RA) is really needed in the enterprise and 95% is the following scenario - Help Desk employee with admin rights must help local person who does not have admin rigts and in 90% of cases Help Desk employee need to open computer management tools or other things that require admin credentials (for example, to install additional program, etc.)
Current problems:
1. Help desk initiated RA requires to open dangerous ports common with other windows features in firewall. Instead, it should work over separate port only for RA.
2. UAC prompt on local user side makes this feature totally useless. And this does not improve the security at all - third party programs are installed that share desktop including all the UAC prompts. Every second counts for expensive Help Desk employee, nobody has the time to talk to non-advanced local user that he must press one or another button.
3. No questions must be asked on the user side (exept first Yes/No to allow connection) for connection of authorized Help desk technicians (if such domain policy is in place).
"Enterprise" version must not behave like version designed for the home user. Company owns a PC and if the decision is that Help Desk employee or company administrator can connect to any PC to fix the problem, must be group policy enabling that.- Proposed as answer by harrymrh Friday, March 6, 2009 5:21 PM
Sunday, February 15, 2009 5:13 PM -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop.
DWORD Value - EnableUIADesktopToggle
To Enable - 1
To Disable - 0
It worked for me on home premium sp1, and basic sp1.
Note registry edit because the basic and home systems don't have the local security policy editor. The tick box on the take control screen in remote assistance vanishes, remote user can see the uac prompts remotely. It only effects remote control. Secure desktop is still active locally.
Harry- Proposed as answer by harrymrh Friday, March 6, 2009 5:28 PM
Friday, March 6, 2009 5:28 PM -
Hi Guys, I am sorry, I am not seeing the problem here.
1 - If you are concerned that these ports are being exploited, limit the Scope to the IT department subnet or better still select the "Allow the connection if it is secure" and require Computer and User authentication. No need for a seperate port. Search for IPSec in technet.
2 - Removing the requirement for the Secure Desktop is not "Disabling the UAC" as described by James. The secure desktop is meant to avoid spoofing of the UAC, which in the enterprise is unlikely to be a problem. (Users know they don't have credentials anyway, and when they see it they always called you anyway.)
3 - There are only two questions the user needs to answer - Allow the Helper to connect, and Allow the helper to control the desktop. You then have control.
Even people working for a company have some rights to privacy. I would personally consider it of extreme rudeness for me as a Support Person to try and take control of or try to view a users desktop without first asking them. I have accordingly edited the Group Policy to change the message so that it identifies the department as the connecting to the desktop. As I am on the phone and have spoken to them, the message make perfect sense and does not take them by surprise.
If you worry that the person will steal your credentials, you only need to use a local admin password. You can then easily reset this using group policy and change after use or every day/week/month/whatever. There are also many scripts that can do this for you. In one of my previous jobs we used a password setting tool that gave you an admin password for a PC, set this on the PC for use, then scrambled it afterward. So much for that concern.
Under these conditions RA works fine under Vista and works fine under Windows 7 in an enterprise environment.
Anthony Sheehy - .netWednesday, October 21, 2009 3:33 PM -
For those who do need a workaround, the following will work. I don't think there's a way to request elevation from the command prompt, but if there is, it would make this easier.
If the issue you face is that UAC requesting your admin credentials brings up the secure desktop on the remote machine and shows you a big pause button. do this instead:
When you are given shared control by the user you're assisting, open a command prompt, and start another command prompt with RUNAS. In other words type runas /USER:domain\adminusername cmd. You will be prompted for credentials in the command line box, and a new command prompt will open that is running under your admin credential. So far so good.
Now however you need to run a program that requests elevation. We have a custom admin tool that sits on every machine that does this, but for example you can create a .NET program that does nothing but launch an elevated command prompt. When this program runs, the secure desktop will still come up and you'll still get a pause on your end, but the difference is that you don't have to enter any credentials because you've already done that. The user will just be prompted to Cancel or Allow the elevation. Tell them to click Allow, and you have your elevated admin prompt on the remote machine.
The following articles discuss ways of elevating via scripting and/or PowerToys. Again, the main point is entering credentials on the remote machine without getting the UAC at that point. With a bit of work you can support your enterprise users remotely even under a fully secure scenario. Hope that helps!
http://blogs.msdn.com/b/aaron_margosis/archive/2007/07/01/scripting-elevation-on-vista.aspx
http://technet.microsoft.com/en-us/magazine/2008.06.elevation.aspx
Thursday, July 29, 2010 8:17 PM -
Hi Guys, I am sorry, I am not seeing the problem here.
2 - Removing the requirement for the Secure Desktop is not "Disabling the UAC" as described by James. The secure desktop is meant to avoid spoofing of the UAC, which in the enterprise is unlikely to be a problem. (Users know they don't have credentials anyway, and when they see it they always called you anyway.)
3 - There are only two questions the user needs to answer - Allow the Helper to connect, and Allow the helper to control the desktop. You then have control.
Even people working for a company have some rights to privacy. I would personally consider it of extreme rudeness for me as a Support Person to try and take control of or try to view a users desktop without first asking them. I have accordingly edited the Group Policy to change the message so that it identifies the department as the connecting to the desktop. As I am on the phone and have spoken to them, the message make perfect sense and does not take them by surprise.
If you worry that the person will steal your credentials, you only need to use a local admin password. You can then easily reset this using group policy and change after use or every day/week/month/whatever. There are also many scripts that can do this for you. In one of my previous jobs we used a password setting tool that gave you an admin password for a PC, set this on the PC for use, then scrambled it afterward. So much for that concern.
Under these conditions RA works fine under Vista and works fine under Windows 7 in an enterprise environment.
Anthony Sheehy - .net
Well Anthony if you aren't seeing the problem here, you may need to get back into the trenches more often. This attitude is unfortunately why we arent getting a fix. I lead a team of Level 1 and Level 2 guys and I must say that the decision to force prompt is extremely short-sighted given today's ENTERPRISE needs from MS products.
a) Rights to privacy. Anthony how about logging into a newly imaged machine in a remote branch office with no IT staff? We have a global vendor who ships hardware to us, plugs it in for us (or we talk someone through it if that service is not provided in the respective country) then we build new machines for people in offices all around the world using PXE boot deployment silently and unattended right to the point that someone has to press CTRL-ALT-DEL (sometimes imaging script stops because of bad logic in a new software package etc and we need to restart). However since Windows 7, we have to annoy someone to read prompts on a screen where we never had before. Terrible.
What about the situation where the user has allowed you to remote control via email chain (so there's your authorisation paper trail) and you are playing phone tag with them? I don't like hearing from my guys "i was delayed in solving because I needed the user at the computer". Terrible!
b) So what was previously a 60second helpdesk task turns into 3-4 minutes as my guys have to wait for someone to sit down (always get written confirmation that we are allowed to remote control) then once done we have to reset passwords. Even if we had your wonderful password reset tool, or used local password change via GPP, it is still time consuming. We have on average 200 jobs/calls a day. 90% of them are remote control. That's 200 password changes x at least 2-3 mins. You do the math and see if that is ENTERPRISE FRIENDLY.
Also, I would probably fire one of my guys if they handed out the local admin password and the user had access to that for anything more than 5 minutes. I completely disagree with your assertion that the user knows local admin credentials for a day/week/month.
Seriously, get with the times and hear what the greater community are saying MS. We want no prompt.
Sunday, January 23, 2011 10:52 PM -
Remote Assistance was a very great tool in Windows XP, and now it is completely useless!!!
Does Microsoft really think that end-users should have Admin rights on their PCs to be able to ask for help??? Come-on, they are calling the person asking for help a novice in the documentation, do they really imagine that I will give the admin password to a novice!!!!!
We are a 4000+ employ Airline, and this "feature" will delay our migration to windows 7 until we find, pay for and get a 3rd party Remote Assistance tool that works. That an extra time and money wasted, because somebody is not thinking logically in Redmond.
Again, really??? They expect us to give the Admin password to the end-user!!!!
I can not believe what I am reading... somebody wake me up please !!!
Maybe all users in Redmond are Admins on their PCs, and the average novice in Microsoft is at least an MCSE... but out of our 4000+ users only about 100 are Admins on their PCs, and I am sure it is the same in all normal enterprises.
Sunday, March 6, 2011 8:00 AM -
I think Remote Assistance is designed for home/small business. It's just not useful in an enterprise environment, as you can see. If it were for enterprise, the user wouldn't even need to initiate a session, because there would be an admin tool to simply logon to any desktop to share the user session. And that isn't going to happen, because Microsoft wants to sell terminal server licenses.
You'll just have to go with 3rd party solutions, like GoToAssist, which does not have all these limitations.
Thursday, March 17, 2011 7:15 PM -
MS has fixed this problem in Vista SP1. Find this local security policy: User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop - and set it to Enabled. Problem solved.
Pirks' solution is correct.Here is a specific reference to the setting:
http://technet.microsoft.com/en-us/library/dd851479.aspx
This one has the Group Policy location for that setting, as well as some other UAC setting details:
http://technet.microsoft.com/en-us/library/dd835564(WS.10).aspx
It works as advertised, which greatly improves the usefulness of Remote Assistance. The user does not need initiate the session as long as you know the name of their system.
Thursday, March 17, 2011 11:03 PM -
I'm not sure if this is a Windows 7 or SBS 2011 feature or both, but Windows Remote Assistance now has a checkbox to allow the remote user to respond to UAC prompts.
No policy changes needed, as long as someone's there at the PC.
Saturday, April 2, 2011 7:32 PM -
Yes there is a checkbox there in Windows 7 to respond to UAC prompts however when using the Secure Desktop for UAC the screen will go blank and it is not possible to elevate.
Lowering our UAC settings is not an option!
Lee Bowman MCITP MCTSTuesday, April 12, 2011 10:40 AM -
Computer Configuration > Windows Settings > Local Policies > Security Options > User Account Control : Switch to the secure desktop when prompting for elevation. Check Define this policy setting and select Disabled.
Now when you check the elevated access check box the UAC prompt will appear on the experts session and you will not get the irritating Pause sign
As always do your own testing first!
Cheers,BarryYes, Barry is right. It worked for me. HOWEVER... there is a second Policy that MAY need to be set as well.
Set both of these:
- User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop (Set to Enabled)
- User Account Control: Switch to the secure desktop when prompting for elevation (Set to Disabled)
All the UAC settings are here:
- Security Settings\Local Policies\Security Options
All the UAC setting descriptions are in the GPMC or here:
Friday, April 22, 2011 6:48 PM -
We had same problem with Windows 7.
Additional to both Policies (see answer of 'Russ-A SID') we did have to set
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
"User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" to "Prompt for credentials" and
"User Account Control: Behavior of the elevation prompt for standard users" to "Prompt for credentials".
Now there is no pause by RA when UAC is on!HLM\Software\Microsoft\Windows\CurrentVersion\Policies\System looks like this:
ConsentPrompBehaviorAdmin: 3
ConsentPromptBehaviorUser: 3
EnableUIADDesktopToggle: 1
Thanks for this question and answers!
Soheil- Proposed as answer by Theo v Z Tuesday, July 26, 2011 2:13 PM
Wednesday, July 6, 2011 2:00 PM -
Saw this feature in windows7 and thought it was great. Tried to fix an issue for a user (install some software) when I did the run as admin I got the pause screen. Then I noticed the check box for let the helper see UAC. I thought oh right, got the user to tick that box ... pause screen again. Now I think the feature is a waste of space. I would be much happier if I could configure users who can take control and use UAC in group policy.
I'm just going to deploy VNC again. Phone call to user
Me: "Hi, is it ok for me to connect to your PC to help with the issue you've been having"
User: "Ok"
I VNC their machine and can work, how easy was that.
Thursday, September 8, 2011 3:35 PM -
One other issue :
In Active Directory add the user member of "admin of domains" during the remote assistance, they uses their credentials.
But it's not a good solution ...
Tuesday, September 20, 2011 12:05 PM -
One other issue :
In Active Directory add the user member of "admin of domains" during the remote assistance, they uses their credentials.
But it's not a good solution ...
Tuesday, September 20, 2011 3:01 PM -
Making a user a domain admin? That's a terrible idea! But it highlights the point that Microsoft has purposely made it impossible to share screen sessions with remote desktop. Obviously, they want people to buy Windows Server with terminal server. If a desktop client allowed multiple simultaneous user logins, Microsoft fears it would cut into the terminal server licenses (which are very expensive).
Exactly, my position was to emphasize this point. You are right it is a story to protect the business of licensing TSE.Wednesday, October 12, 2011 12:57 PM -
So after doing the steps above (as we have done already), we are unable to type into the credential fields. Are you saying you can enter your admin credentials here?Thursday, March 22, 2012 5:01 PM
-
After doing this, are you able to enter your admin credentials? All our users are standard users.Thursday, March 22, 2012 5:05 PM
-
This continues to be a problem for us on ALL Windows 7 computers we deploy even though we have...
disabled the following local security policy: User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
...and enabled the following; User Account Control: Detect application installations and prompt for elevation
...secure desktop and enabled the prompt in local security policy. We have thousands of users, many of which are remote with user accounts that are not part of any group other than standard user. We use various remote support tools and we have the same issue across the board; because UIAccess is disabled we can at least see the prompt remotely but that is useless because we cannot enter admin credentials and even when a the user enters the local admin credentials provided to them the remote admin is unable to interact with or click through application installers. MS needs to fix this fast, I am sure an additional policy to allow remote access to the UAC and installers.
What is the need of security if it gets in the way? Now we are having to issue remote users local admin credentials just so we can support them, something that we should not have to do. Why isn't there a policy that also lets remote admins able to enter credentials and click through application installers?
Monday, May 28, 2012 12:56 PM -
I tested this on Windows 8 Release Preview and it worked flawlessly. All I needed to do was enable the the UIAccess and siable secure desktop in local policies as everyone has done in Windows 7 without success. This goes to show that the implementation in Windows 7 is broken and needs to be fixed.Saturday, June 2, 2012 7:13 PM
-
Does ANYONE have this working on WIN 7 Enterprise?
I want to use Remote Assistance with UAC on. Do the Group Policy mentioned above work?
Thanks
Dave- Proposed as answer by Antiskeptic Friday, June 15, 2012 6:47 AM
- Unproposed as answer by Antiskeptic Friday, June 15, 2012 6:47 AM
Friday, June 8, 2012 6:05 AM -
Hi Dave,
Our Enterprise environment has it working. We may now remote into Win 7/Win XP boxes using group policy and a couple firewall exceptions.
Firewall ports: 3389 & 135
Windows 7
GPO: Remote_Assistance_Win7_Vista (Or your on GPName)
Computer Configuration\Administrative Templates\System\Remote Assistance:
Offer Remote Assistance: Enabled
Allow helpers to remotely control the computer
Helpers: (Domain Admin Accounts/Group)Security Settings\Local Policies\Security Options:
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure deskFirewall:
When using the Windows 7 default domain profile, the default firewall configuration is already set correctly and the remote maintenance option active.
Windows XP
GPO: Remote_Assistance_XP
Computer Configuration\Administrative Templates\System\Remote Assistance:
Offer Remote Assistance: Enabled
Allow helpers to remotely control the computer
Helpers: (Domain Admins/Group)Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile:
Windows Firewall: Define program exceptions: Enabled
Exceptions:- %WINDIR%\SYSTEM32\Sessmgr.exe:*:Enabled:Remote Assistance
- %WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe:*:Enabled:Offer Remote Assistance
- %WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe:*:Enabled:Remote Assistance - Windows Messenger and Voice
Windows Firewall: Define port exceptions: Enabled
Exception: 135:TCP:*:Enabled:Offer Remote AssistanceComputer Configuration\Administrative Templates\Windows Components\Terminal Services:
Allow users to connect remotely using Terminal Services: EnabledOnce these GPs are applied, you can use the following command line to open a Remote Assistance prompt that allows you to input IP Address or DNS Name:
msra.exe /offerRA
Here's some links we used to get this up and running:
http://www.cloudtec.ch/blog/tech/remote-assistance-windows-7-free-built-in-remote-control.html
http://support.microsoft.com/kb/301527
http://technet.microsoft.com/en-us/library/dd835564(v=ws.10).aspx
http://technet.microsoft.com/en-us/magazine/ff356868.aspx
- Proposed as answer by BlurryEyed Friday, June 8, 2012 6:27 PM
- Edited by BlurryEyed Friday, June 8, 2012 6:30 PM
Friday, June 8, 2012 6:26 PM -
For information, this solution also works on Windows 8 (the home edition)
We have a number of employees who have Windows 8 (not Pro) and this solution worked perfectly for me.
Thanks!
Tuesday, May 21, 2013 9:51 AM -
This solution works fine like a charm!!!
Thank You! :-)
Cheers,
Helton.
Friday, January 31, 2014 5:09 PM -
Thank mate, it works for me,Thursday, June 12, 2014 5:03 AM
-
Thanks mate it works for me but just need to add few more setting.Thursday, June 12, 2014 5:04 AM
-
I found a solution & want to share with you. Please follow the below steps to configure UAC by using group policy so that it can apply to all machine.
Steps 1:Create an OU (Organizational Unit) on your AD (active directory) & move the machine which you want to apply the GP (Group Policy) for UAC access on remote assistance.
Steps 2:Open Group Policy Management Console on your AD machine and create a GP & link it to OU which you have created. Give a name to that GP & select edit.
Steps3: Now go to this location
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
And make the changes as mentioned below
Group Policy setting
Registry key
Default
Changes Required
User Account Control: Admin Approval Mode for the built-in Administrator account
FilterAdministratorToken
Disabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop
EnableUIADesktopToggle
Disabled
Enabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
ConsentPromptBehaviorAdmin
Prompt for consent for non-Windows binaries
Prompt for credentials
User Account Control: Behavior of the elevation prompt for standard users
ConsentPromptBehaviorUser
Prompt for credentials on the secure desktop
Prompt for credentials
User Account Control: Detect application installations and prompt for elevation
EnableInstallerDetection
Disabled (default for enterprise)
User Account Control: Only elevate executables that are signed and validated
ValidateAdminCodeSignatures
Disabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations
EnableSecureUIAPaths
Enabled
User Account Control: Run all administrators in Admin Approval Mode
EnableLUA
Enabled
User Account Control: Switch to the secure desktop when prompting for elevation
PromptOnSecureDesktop
Enabled
Disabled
User Account Control: Virtualize file and registry write failures to per-user locations
EnableVirtualization
Enabled
Now run ‘’gpupdate’’ on server & client side to verify. Enjoy J
Thursday, June 12, 2014 12:24 PM -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop.
DWORD Value - EnableUIADesktopToggle
To Enable - 1
To Disable - 0
It worked for me on home premium sp1, and basic sp1.
Note registry edit because the basic and home systems don't have the local security policy editor. The tick box on the take control screen in remote assistance vanishes, remote user can see the uac prompts remotely. It only effects remote control. Secure desktop is still active locally.
Harry
You're still helping people 6 years into the future ;)Best Regards Wojciech Wróblewski Visit my blog (in polish): http://wojciechwroblewski.wordpress.com/
Friday, April 3, 2015 10:11 PM