We are trying to adopt Remote Assistance as our primary means of operating our helpdesk but we have hit a stumbling block. When the IT Pro asks for control of the remote PC, the user is asked to grant that permission. There is a check box which is related to UAC prompts and if the user selects it, they then get prompted for administration credentials - which they don't have. If they don't select the check box, the IT Pro gains control of the computer but any action that results in a UAC prompt again locks the IT Pro out as only the user can see the prompt and they don't have the credentials. I have deployed a Group Policy that enables "Allow UIAccess applications to prompt for elevation without using the secure desktop". It was my understanding that this should correct the issue I'm seeing because Remote Assistance is defined as an UIAccess application. However, all UAC prompts are still happening in the secure desktop and the IT Pro cannot process any of them. Is this a bug or is there another setting I need to change? Philip

Hi, Thanks for posting in Microsoft TechNet Forum. After checking this issue, please also try to configure the following policy to check how it works: • "User Account Control: Switch to the secure desktop when prompting for elevation" - Disabled Meanwhile, please kindly refer to the following article: User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop Hope it helps.Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I am not happy with disabling "Switch to the secure desktop when prompting for elevation" as this would seem to disable the secure desktop for ALL UAC prompts, thus going a long way to defeat the effectiveness of UAC. I have reviewed the article referenced but it does not help. As I stated, my understanding is that the Remote Assistance executable should be correctly identified as a UIAccess application and therefore allow the UAC prompt to be visible over the Remote Assistance connection. Philip

I wanted to share the news that installing Service Pack 1 fixes the problem. The GPO setting works as expected without reducing overall security and Remote Assistance now works properly.

I wanted to share the news that installing Service Pack 1 fixes the problem. The GPO setting works as expected without reducing overall security and Remote Assistance now works properly. I have unmarked this as the answer. Further testing now leaves us with some computers with SP1 still displaying the UAC prompt on the secure desktop. So now we have inconsistency, which is worse than ever because I have no idea what has got this working on some systems but not others. Any thoughts, anyone? Philip

We have experienced this also and is frustrating since any Admin Tasks require logging onto the Admin Account and then RA is no longer used and RDP is used. Will be following this post for hopeful answers. As above we do not want to reduce the UAC effectivnessLee Bowman MCITP MCTS

When you enable "Allow UIAccess applications to prompt for elevation without using the secure desktop" it allows the remote helper to respond to elevation prompts. The remote helper is expected to be an Admin and hence can respond to elevation unlike earlier where the helper would only see a black screen and the non-admin user will be prompted with a UAC prompt which he cannot respond to. In machines where you are seeing pre-Sp1 behavior, do you have some other UAC related policies configured? Is the UAC setting in its default? Sumesh P - Microsoft Online Community Support

Sumesh Thank you for your reply. Your explanation of "Allow UIAccess applications to prompt for elevation without using the secure desktop" is in agreement with my understanding and, certainly on some SP1 computers, the experience matches that. However, on some SP1 computers, the remote helper continues to see a black screen and therefore cannot respond to the elevation prompts. I have no explanation as to why some computers are working "properly" and others aren't. I'm not aware of any other UAC policies configured in Group Policies. UAC should definitely be at the default setting. It isn't something we mess with. Regards Philip

Do you see the elevation prompt on the secure desktop at the target machine when not under remote assistance? Sumesh P - Microsoft Online Community Support

I am experiencing the exact same issue as Philip. We enabled "allow UIAccess applications to prompt for elevation without using the secure desktop" expecting all UAC prompts to be visible by the IT Pro offering assistance. Instead, the user is prompted with UAC on the secure desktop and the IT Pro's session is paused. Sumesh - yes, when remote assistance is not in use, UAC prompts use secure desktop. Thank you, Stephen

This appears to me as a policy issue rather than RDS/RA… I would start with GPRESULT /v on working and non-working machines; for comparison Sumesh P - Microsoft Online Community Support

If this cannot be attributed to GPO, then you will have to open a paid support case to troubleshoot this further as we'll require to get traces of the failure for indepth analysis. Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone Sumesh P - Microsoft Online Community Support

Sumesh, did you try this in a testing environment? I have tested the scenario, and it is definitely NOT a policy issue. I see that even though the policy is applied, Remote Assistance still pauses when the helper initiates the consent UI. I checked the Group Policy status with GPResult and I am sure that the policy "Allow UIAccess applications to prompt for elevation without using the secure desktop" is applied. According to the documentation this should be sufficient to allow MSRA to request elevation without the secure desktop. This is not happening. Is there any other way to troubleshoot the existing situation?Ray - Author of Windows 7 for XP Professionals

I am unable to repro this in a lab, it works for me as expected. Are you seeing this in an environment where no other policy is applied? Is this in an SP1-SP1 scenario? that is what i tested with. Sumesh P - Microsoft Online Community Support

I am also testing in a SP1-SP1 environment with Windows 7 32-bit SP1 systems without any extra policies. Philip Colmer already mentioned that this behavior is unpredictable with SP1. I have not yet seen it working as it should.Ray - Author of Windows 7 for XP Professionals

I did some more testing and I think I found the catch. When the assisted account (the user accepting assistance) is a member of the local Administrators group, Remote Assistance will always pause when elevation is triggered. If the assisted account is a standard user, then RA shows the consent UI without the secure desktop. This enables the helper to enter administrative credentials in the remote session. Now the option "Allow UIAccess applications to prompt for elevation without using the secure desktop" works as expected.Ray - Author of Windows 7 for XP Professionals

That is a very interesting observation. I have never seen that checkbox. Did you check if this behavior is specific for the user or the computer on the client/server side? Did you run gpresult /h on the clients that behave differently? Ray - Author of Windows 7 for XP Professionals

I have just run another test with a user. They do not have local admin rights. When I ask to take control of the computer, there is a tickbox that says to allow me to respond to UAC prompts. If the user TICKS that box, the OK box changes to have the shield, indicating that the user will then get a UAC prompt. If the user does NOT tick the box, they can click on OK but anything that causes a UAC prompt to appear then locks me out. On a computer that works as it should do, when I ask to take control of the computer, there is NO SUCH CHECKBOX! The user just clicks on Yes and when I do anything that results in a UAC prompt, I can see that prompt and fill out the username and password. I have compared the GPO modelling of a working computer against a non-working computer and there are no differences.

I encountered the same problem as Philip,the GPO are the same,till now still have no any idea for this problem.

if user member of these group will trigger the secure desktop prompt: Administrators Backup Operators Cryptographic Operators Distributed COM Users Event Log Readers Network Configuration Operators Offer Remote Assistance Helpers (not 100% sure about this one) Performance Log Users Performance Monitor Users Power Users So need to move out then the remote assistance will working fine.

if user member of these group will trigger the secure desktop prompt: •Administrators •Backup Operators •Cryptographic Operators •Distributed COM Users •Event Log Readers •Network Configuration Operators •Offer Remote Assistance Helpers (not 100% sure about this one) •Performance Log Users •Performance Monitor Users •Power Users So need to move out then the remote assistance will working fine. And we have a winner!!! The users were in the Network Configuration Operators group. OK - now the problem is that they need to be in that group in order to be able to change their network settings without IT involvement. Any thoughts on a potential workaround?

Did some more testing on this issue. In my testing environment I concluded the following: Administrators, Backup Operators, Network Configuration Operators and Power Users are considered administrative groups in Windows 7. These groups are subject to UAC and will always cause a paused session in Remote Assistance when the Consent UI appears in a session as the assisted party. The other groups mentioned by PingHui have no effect on the behavior of Remote Assistance. @PhilipColmer. I don't think you have any other options while your users are a member of an administrative group. It is a security feature of Windows 7 not to allow RA to block the remote desktop on administrative user accounts.Ray - Author of Windows 7 for XP Professionals

We also ran into this issue a few months ago and submitted a bug report to Microsoft. In my opinion, the Remote Assistance program needs to have better intelligence on whether or not to present the user with the Consent UI. Remote Assistance is capable of running in UIAccess mode, it just choses not to when it sees the user is part of one of aforementioned groups. Supposedly Microsoft is working on a hotfix, but it sounded like it might be some time before all the regression testing is done.

Remote Assistance used to be a great tool for our Help Desk to support users. I have tried to implement a workaround but am running into one final issue. I have applied the two following GPO settings to our Windows 7 computers: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options/User Account: Switch to the secure desktop with prompting for elevation (Disabled) User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop (Enabled) My help desk users offer a remote session through either Lync or through MSRA. They then are able to control the desktop. Any UAC prompt is displayed to them but they are unable to type into the Username and Password fields. They can still move other windows and type in different fields on open windows while the UAC window is open. They just cannot type into the UAC prompt to enter their credentials. Please let me know if there is a workaround for this issue or if there is another GPO I can apply. Thanks, Ryan

I encountered the same problem as Philip,the GPO are the same,till now still have no any idea for this problem. _________________ du hoc|du hoc singapore|tu van du hoc| noi that fami noi that 190

@rjblack and @mrphantuan At TechEd this week, Chris Jackson referred to this issue with the manifest in the Lync client. The current manifest wrongly configured which causes that the application is not known as a UIAccess application on the client. He solved the issue by defining an external manifest. The current Lync client is not able to access the credentials prompt for UAC as the prompt is running at a higer integrity level. This is solved by defining the Lync client as a UIAccess appliction. I am not running Lync myself and cannot post the manifest to use. I'll check if I can extract the issue from the session at TechEd.Ray - Author of Windows 7 for XP Professionals

@VistaGuyRay Thanks for the response. This is unfortunate siloing of the teams at Microsoft. Thank you for addressing the Lync issue, any ideas when this will be resolved?

Here is Chris Jackson his article with the fixed manifest for Lync and Remote Assistance http://blogs.msdn.com/b/cjacks/archive/2009/10/15/using-the-uiaccess-attribute-of-requestedexecutionlevel-to-improve-applications-providing-remote-control-of-the-desktop.aspx To solve the issue the manifest must with the same name as the Lync client executable with the extension .manifest Ray - Author of Windows 7 for XP Professionals

Note that only msra.exe has code reading the group policy specifying to not to show elevation prompts on the secure desktop for uiaccess applications, so the title and description are completely misleading. To implement this, the msra team had to write code to read the policy, and use internal, undocumented APIs to implement it. So, for helpdesk elevation, you have to disable the secure desktop for elevation prompts altogether. But uiaccess will allow them to control elevated windows remotely, once they have been elevated. I've noted this as a shortcoming of significant import to the product team. We at least need to be a lot more clear on the wording of the policy.