Recently, I received some e-mail sent to one of our internal DLs describing an issue a customer is facing when using Remote Assistance:
My customers engineer requests to connect to a user’s machine via remote assistance. The user accepts and the engineer requests to take control. The user ticks the box to allow the engineer to respond to UAC prompts – then selects Yes. However – this change requires admin rights and the user is prompted for admin credentials (which they obviously don’t have) Is there a way to work around this?
My customers engineer requests to connect to a user’s machine via remote assistance.
The user accepts and the engineer requests to take control.
The user ticks the box to allow the engineer to respond to UAC prompts – then selects Yes.
However – this change requires admin rights and the user is prompted for admin credentials (which they obviously don’t have)
Is there a way to work around this?
Why, yes! Enter UIAccess.
The way Remote Assistance “remote control” feature works is through an OS feature called UIAccess, which allows the app the ability to control the desktop programmatically. By combining this with RDP/TS, Remote Assistance is able to provide the “remote control” feature.
However, in order for this to work properly in scenarios that prompt for elevation (i.e. UAC prompt), you have to enable a certain group policy:
What this will do is it will enable Remote Assistance to show the UAC prompt on the user’s desktop, as opposed to the secure desktop. If you don’t enable this, the user being helped (call him novice) will get the prompt on his local machine – so the expert cannot interact with it since RA will only remote out the user’s desktop. At that point, the novice may not know what to do with it, and/or he may not have the administrator password. So it is important that you enable this group policy in order to have the UAC prompt show up in the user’s desktop and have RA remote out this dialog to the expert’s machine.
However, there was a bug with RA and how it determined where to show the UAC prompt. However I’m happy to say that my team fixed this bug recently, and you can now download a hotfix that should fix this issue.
You can download this hotfix here: http://support.microsoft.com/kb/2614066 (“Black screen during a Remote Assistance session in Windows Vista, in Windows Server 2008, in Windows 7, or in Windows Server 2008 R2”)
I downloaded and installed the hotfix on my Server 2008 R2 box, but it did not solve the problem. When I click on an invitation file sent from an XP SP3 box, the connection goes through but screen in the RA session remains black.
Hi SKahn, thanks for reading and posting!
If you're seeing a black screen in the RA session regardless of UAC prompt interactions, it sounds like the issue you're facing is different, as the scenario described in this post is black screens resulting from the UAC prompt showing up on the secure desktop instead of showing up in the remoted desktop [when the appropriate group policies are applied].
Hello Alexander Sklar!
Thanks for the great hotfix, this has resolved our issue when the user is member of the "local adminstrator" group as RA paused the session on UAC prompts.
Hence, I have one comment, which I feel would improve this HotFix, a lot:)
The prompt "Allow <User Name> to respond to the User Account Control prompts" checkbox that appear if the user is not an standard user, is that really necesarry?
We often see, that the user "don't check" this box, casuing an frustration fo servicedesk
if the user has "Local administrator" rights. This checkbox is not apperaing if the user is an standard user (domain user).
If Microsoft feel that this should be by design, wouldn't it then be wise to add an registry key / GPO so that org can controll this themself?
PS! We have enabled "User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop" which is working perfectly.
This needs to be added to the Microsoft Update Catalog for ease of deployment.