Let me start by listing what other methods there are and why I would not recommend using them.
There is numerous 3rd party software for this intent, but most of it costs money that you may save using what’s built-in. Even free remote control software like UltraVNC has some challenges: how do we deploy it, maintain it, ensure that it’s secure? What do we do if the project is suddenly discontinued?
Now let’s look at what’s built-in. For ages, Microsoft has offered a tool called msra.exe ("Microsoft Remote Assistance”), which will let you invite a helper and authenticate his session with a code. For a long time, I had used that tool and found a way to automate it, so that users would not have to deal with codes but simply click on a shortcut “ask for help” and then I would click on “start helping” and there we would go.
For two reasons, I have recently abandoned msra.exe: 1st, it does not support multiple monitors very well, which is bad, given the fact that in our network nowadays almost anyone uses two. Secondly, msra.exe, in current Windows 10 builds, has started to show some funny behavior: on machines without internet access, it would “wait” for 45 seconds before it starts. Whatever the reason for that is, I felt I finally needed to get rid of msra.exe
So I looked at the more modern “quick assist” that is also built-in. Quick assist, unfortunately, requires internet access, so that we, in our secured network, cannot use it on any machine. Furthermore, and this is important for most readers, it will only work if you start it using a Microsoft account. No Microsoft account, no quick assist, sorry.
That left me with shadowing as a remaining option. Shadowing, like msra.exe, is relying on the remote desktop service of the client. But while using the remote desktop client in the standard way will create your own session on the remote client, shadowing will offer to use and display an existing session, which is what I want. Furthermore...
Shadowing is carried out by simply calling the mstsc.exe (“Microsoft Terminal Services Client”) with the parameter /shadow, followed by a session number. Of course, that command will need to be directed to a target machine (parameter /v) and name a target user session to be shadowed. See this example:
mstsc.exe /v:PC1 /shadow:1 /control
Simple, isn’t it? This command targets PC1 and will shadow session 1. The parameter “/control” will ask the target user if we may control his session as in share the mouse cursor and be able to type.
The user we are helping will see a remote control request popup, which he will need to consent to before the session starts.
Will this work right away? No, we have to configure the use of shadowing on the target machines, first, using this GPO setting: on your test machine, go into gpedit.msc -> Computer Configuration / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Session Host / Connections and enable the policy "Set rules for remote control of Remote Desktop Services user sessions". I set it according to the picture:
Now about the session number (which was 1 in my example) – how do we find it out, or is it always 1?
No, it can be different. Session numbers can be listed by anyone on the command line using the command qwinsta. Let’s see a standard output of qwinsta:
Here, user “loser” has session ID 2.
Can we query that session ID from remote? YES! If your support user has access to SMB port TCP 445 on the remote machine, we can query that session ID from remote. The command (to query "PC1") would simply be:
and the output would look the same as before.
What if the support user has no access to that port? That would mean, the user himself will need to query that number. Fortunately, no admin rights are needed to do so. The command that returns the number is simply:
for /f "tokens=3" %a in ('qwinsta /server:%username% ^| findstr /i console') do echo %a
Please note: you won’t have to memorize any command in order to use this. Part 3 has is all wrapped up in batch files.
So with that number accessible to and fro, that leaves us with a final question: how do we connect, what port does shadowing use, is it the RDP port? NO! Astoundingly, Port 3389 does not even need to be open on the target for this to work. The remote desktop service needs to be running, yes, but the port is not 3389. Instead, it’s a random high port. Fortunately, Microsoft has a firewall rule predefined for shadowing, that we need to deploy using GPOs:
And that’s all the theory. Now let me show you, how to make this conveniently usable.
If I could take it for granted that your support user account is admin on the remote machines and has access to port TCP 445 (SMB – file sharing port. In many networks this port will be accessible for support personnel) at all the remote targets, this would be pretty easy to script within just 2 lines of batch code (let me call it shadow_v1.bat):
set /p target=Name of target?: %=% for /f "tokens=3" %%a in ('qwinsta /server:%target% ^| findstr /i console') do mstsc /v:%target% /shadow:%%a /control
Start this batch and it will ask you for the name of the target machine and then immediately initiate a shadowing of the console session.
The user at the remote machine will have to give his consent
and that’s it, after he accepts, you are able to help him.
That's it! Or...?
Let’s say, you don’t have access to port 445 and neither you know the remote computername, nor does the person you are trying to give support to – what do you do then?
In my opinion, this should be solved by having the remote user click on a batch that reads out the computer name and his session number and writes it to a file help.txt (let me call this batch helpme.bat):
for /f "tokens=3" %%a in ('qwinsta ^| findstr %username%') do echo %%a %computername%>\\server\share\help.txt
Now the supporter would make use of this file like this (I will call it shadow_v2.bat):
for /f "tokens=1,2" %%a in (\\server\share\help.txt) do mstsc /v:%%b /shadow:%%a /control
And that’s all, as easy as it gets.
So, wrapped up, this is what you need to do:
Now for those of you who really care about security, you might have realized that this construction needs our support user to be an admin on ALL remote machines that he will possibly need to support. If that is what you want and already have in front of you, you can stop reading here.
If you don’t like the idea of supporters needing administrative permissions just for remote control, you will want to look into msra.exe and what it offers (it can do without administrative permissions). Remember, the creation of MSRAincident files (“supporter invitations”) and passwords can be scripted, too.
Or, you take this one step further and do like I do in our network:
What’s that good for? you might ask. It allows supporters to use their weak everyday account for initiating the shadowing, making that support account less desirable as a target for attackers.
Sound good? Details to follow:
Let me call the following batch shadow_v3.bat
for /f "tokens=1,2" %%a in (\\server\share\help.txt) do set target=%%b for /f %%a in ('***command inside here creates a random password ***') do net user admin%target% %%a /domain /active /workstations:%computername%,%target% & cmdkey /add:%target% /user:yourdomain\admin%target% /pass:%%a for /f "tokens=1,2" %%a in (\\server\share\help.txt) do mstsc /v:%%b /shadow:%%a /control net user admin%target% /domain /active:no cmdkey /delete:%target%
Details about this concept for safe user support can be found in my article over at https://www.experts-exchange.com/articles/18180/A-concept-for-safe-user-support.html where you will also find a script “generaterandompassword.ps1” to insert between the *** in the second line of this latest shadow_v3.bat
That’s all. If you have questions, please ask a related question.