Using RDP shadowing for convenient user support and remote control

Edited by: Andrew Leniart
This is meant for people who look for a method to support end-users in a windows network using remote control software. Why this article might be relevant: my method is rather unique. No costs involved, secure, easy to set up, no need for internet access

Part 1: Considerations or “why should I use that?”

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...

  • It allows me to display all monitors of the remote machine and scale those if needed.
  • It is quickly initiated and does not even need the user to know how to initiate it – the admin does that.
  • Its performance is good as traffic stays inside the LAN and the trusted RDP is used
  • As it’s RDP, the traffic is encrypted
  • Only those support users who are an admin on the remote system may use it
  • It needs no passwords or access codes
  • It even allows the admin to interact with UAC prompts if need be

Part 2: How does it work in detail?

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:

Please note: for shadowing, there is also an mstsc.exe parameter /noconsentprompt, which will allow the admin to shadow the user session without the user giving his consent. Please be very careful here: if you would like to use that parameter, you definitely have to make sure that your company’s privacy policy is ok with that, as it could be used to spy on users without them knowing it. Microsoft has made sure that by default only admins may use shadowing and that the remote machine will need to be preconfigured to allow a connection without the user’s consent. So be warned again: users need to know how this is configured and used, else you could end up in big trouble.

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:

qwinsta /server:PC1

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 in addition to the smb port (TCP 445). Fortunately, Microsoft has two firewall rules predefined, one for file and printer sharing (tcp 445) and one 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.

Part 3 – My script for your convenience

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, neither you nor person you are trying to give support to know the remote computername (maybe not even the exact username)  – 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:

  1. Create a GPO that allows shadowing and deploy it to the clients
  2. Create two firewall rules that open the shadowing ports at least for the scope of the computer(s) that your supporter(s) uses, and deploy it to the clients and
  3. Depending on whether or not you know the names of the remote computer and user, on your end, use shadow_v1.bat or shadow_v2.bat. As shadow_v2.bat relies on a file created by the users executing helpme.bat, you would need to deploy helpme.bat to their desktops, or, preferably, a shortcut to it, paired with a good-looking icon. [If you know which user uses which computer (you have a list handy) remote users will be free from the duty to co-operate by clicking on a batch]


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:

  • on the remote end, we created one administrator per machine, as in adminpc1, adminpc2,…
  • on the supporting end, we use a batch that enables this dedicated account only for the time while shadowing and sets a random password for it

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 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.


Comments (1)

Brian BEE Topic Advisor, Independent Technology Professional

Very helpful. I've bookmarked this one for future use.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.

Get access with a 7-day free trial.
You Belong in the World's Smartest IT Community