If you are running an environment with a modern management strategy where your clients are highly mobile and managed by cloud services, your built-in direct connection based tools like RDP or Remote Assistance are limited in usability for supporting your devices. In general with the mobile workforce nowadays we can’t rely on solutions needing a direct connection between two devices.
The lesser known built-in Quick Assist from Windows 10 implements a different way of connecting to the remote client. The supporter connects to a Microsoft cloud service by starting Quick Assist and logging in with a Microsoft Account (MSA and AAD accounts supported). Quick Assist will hold a connection to the Microsoft cloud service and the supporter is given a connection code. The user who needs assistance also starts Quick Assist and connects the the same session by specifying the connection code. This way both clients can use outbound connections to the Microsoft cloud service and the cloud service is acting as a broker between both clients. This allows flexible connectivity to remote clients wherever they are. Even behind some firewalls we normally don’t have any issues to successfully build a connection. In fact this is the same approach all the third party vendors like AnyDesk, TeamViewer, BeyondTrust Remote Support (aka Bomgar), or LogMeIn are using with their remote support software products.
That’s great but why should I care about a remote support solution anyway if I have Teams?
That’s a valid point in times where collaboration tools like Microsoft Teams are available and we have screen sharing capabilities where we can give control to someone else:
The main issue is the elevation of privilege’s. I guess everyone is familiar with the User Account Control (UAC) in Windows. If you try to elevate a process from a standard user context you will be switched to the so called Secure Desktop, the dimmed desktop in the background is the Secure Desktop which can not easily be circumvented:
The Secure Desktop can not be handled by the collaboration tool Microsoft Teams. As soon as the Secure Desktop appears the shared screen looses track of the session and the remote supporter can’t control any UAC dialog:
Actually this is the same for Quick Assist, as soon as you try to elevate a process as supporter you loose the session and you get a black “pause” screen like this:
Do I have to switch to third party software for elevation support?
It depends on what functionality you need for your support processes. Third party normally has a lot of functionality which is needed in enterprise environments like extensive logging/auditing etc. All third party products normally support also the elevation scenario, but there is a way to accomplish remote support even with the Windows 10 built-in Quick Assist solution. The simple solution here is to deactivate the “Secure Desktop” on your clients:
As soon as this is done, the elevation prompt will be visible in the Quick Assist session and can be controlled and the remote supporter can enter credentials for elevation. Instead of the black pause screen you will see the UAC prompt (without secure desktop):
The downside is that the secure desktop is designed that no one can remote control the UAC dialog and inject something as the dialog is not running on the users interactive desktop. Without the secure desktop the UAC dialog is running like every other Windows dialog on the interactive desktop of the user. This makes the device vulnerable to UAC spoofing attacks. If you and your security department are feeling okay with that fact, you can re-configure the devices and get a working Remote Support solution out of the box from Microsoft built directly into Windows 10 called Quick Assist.
Okay wait but what about Microsoft Teams when I disable the secure desktop? Yes, it would be the logical conclusion that we are able to control the UAC dialog via Teams then also, but that’s not the case. You will see the dialog but you are unable to control it. You can’t enter credentials or click on any of the buttons:
How to reconfigure my devices now?
To deactivate the prompt on the secure desktop, you can easily use a simple PowerShell script provided on my GitHub account and deploy it via Intune to your devices. I used an AAD device group for assignment here:
When successfully applied you will see it in the Intune portal:
The script is very simple and checks if the PromptOnSecureDesktop value is not 0 and will set it accordingly to 0. You can find the script here:
You might have configured UAC already with a custom Intune profile or you use the Intune MDM Security Baseline for Windows 10. The baseline will configure the UAC to a more strict default for standard users to deny UAC requests:
So, you might need to adjust these policies. You can also implement the same behavior by configuring the Intune profile without using the PowerShell script. As already mentioned and shown above, the Microsoft security recommendation for UAC is not to disable the secure desktop. As security is always a trade off between usability and security, you have to adjust from time to time some settings for your organizational needs. If your user support needs this and the security department is taking that risk, you can move forward with this solution.
This might help if Quick Assist provides you enough functionality to support your processes, or if you not have the budget for an additional remote support tool. But actually there are some remote support tools which are quite affordable and providing way more functionality and don’t require to turn of Secure Desktop, one of the candidates here is AnyDesk.
A last goodie and small side note, there is a keyboard shortcut to open Quick Assist via:
[Ctrl] + [Win] + [Q]
I hope this helps if you are looking for a cheap built-in solution to get Quick Assist to work even with elevation and UAC prompts.
Happy supporting of your user base.
Many thanks to one of my blog readers (Tomasz) who mentioned this approach in the comments! I will show the approach to disable Secure Desktop during a remote session when you have enabled the local Administrator account or any other additional local admin account on the target device. Meaning you can keep the local admin credential and do not provide them to the user. It gets a little hacky but it can help people in times of WFH to have another way of enabling elevation for remote support, when no management channel else like MDM, GPO, internet-based software management is available.
The solution relies on the fact that the “run as different user” does not show an UAC dialog on secure desktop. I’ll quickly demonstrate the way to disable the UAC with the help of this fact. Hold Shift while right click on PowerShell and choose “Run as different user”:
Now you will get a run as dialog without Secure Desktop:
Here you can type in a local admin account or the built-in Administrator account if your devices have it enabled. You will get a PowerShell running in the context of the .\localadmin in my case:
In that PowerShell I’m still not able to do task which require elevation as you can see with my first command “reg add” to write to HKLM. But interestingly I’m able to open secpol.msc as you can see. In the normal user session secpol.msc can’t be opened, you get this dialog:
With the ability to open secpol without UAC you can modify the Prompt for Secure Desktop policy to disable the Secure Desktop and UAC will be shown on the interactive desktop again:
If you have an enabled the built-in local Administrator account, you can use that one for run as different user:
and you will get a PowerShell which is automatically elevated (as long as you run the Windows default UAC settings):
Elevation can be seen in the title and my reg add to HKLM succeeded this time. That way you can modify the the reg key for Secure Desktop directly, or again use secpol.msc to modify it.
Yeah, this approach needs a local admin account but if you have one and do not have any other management channel this might be your rescue.