If you have never used concurrent remote desktop to support your Windows clients, this post is about to make your day! Concurrent remote desktop can allow you, as an admin, to interactively use a client OS while the main user is still actively logged in.
I’ve written about concurrent remote desktop before. The method that I used five years ago is
Where the old version was a cumbersome and very OS version specific, this newer method is simple and scalable. With more than two million downloads, it also has a wide user base to provide some support. Today, we are going to deploy RDPWrapper in about ten minutes.
Start by downloading these two files:
Place the MSI on a network share and deploy it with Group Policy / SCCM / etc. As a general rule, do not deploy it to any computer where the primary user remotes in as it can lead to some strange session issues. For example, I deploy this MSI to my student and teacher machines, but I do not deploy it to IT computers. If you have used an alternative CRDP method in the past, you will want to ensure that the original termsrv.dll file is restored to the computer.
Once the MSI is installed, you’ll see just two new files in \Program Files\RDP Wrapper\. RDPWrap.dll sits between terminal services and provides concurrent use abilities. RDPWrap.ini contains the instructions and support for each client OS.
If you scroll to the bottom of RDPwrap.ini, you will see that it does not have information for the latest Windows 10 versions. That information is stored in the
Set the preference action to replace and use Item Level Targetting to ensure that the newer file replaces the default file. While you are in the common options tab, set the preference to just apply once.
When future Windows 10 client versions are released, just grab the updated INI file and deploy it. It really is that easy! To test RDPWrapper, reboot the client machine and log on to that computer as a standard user. From your admin machine, launch a remote desktop session to that computer and you should be able to log on as well. If you open
In the game Civilization, there is a quote that says, “Don’t reinvent the wheel. Just realign it.” At times, it might seem silly to go back and find another solution to the same problem. Those realigned solutions, such as using RDPWrapper, are simply so much better!
These instructions are not working for me but thank you for taking the time to write to this up! Have a wonderful day!
Thanks for the info. I’d like to give it a try for home use but the github repository has been taken offline due to violation of T&Cs there. Any idea where I can get it from now?
This RDPWrapper has stopped working for me .. It seems Windows Updates kills it. Does anyone know of a method to get around this? Is anyone else still able to use this??
NO=o luck searching in thr repository
Not in the entire github either tbh.
Can you please show me the steps to: “…and use Item Level Targetting to ensure that the newer file replaces the default file…”
I’m using a PowerShell script to make sure that the newer file replaces the older file in another scenario.
I’ve tried to check the Level Targetting (in a Windows Server 2008 R2 machine), but all it has is to check if the file exists or check the file version…
I just ran windows updates and when we test concurrent sessions it says “”Another user is signed in. IF you continue, they’ll be disconnected. Do you want to sign in anyway?”.
What does this mean: When future Windows 10 client versions are released, just grab the updated INI file and deploy it.
Correct – just grab the latest INI and deploy it. Most of the time, you can also just edit the INI yourself and include the new version information (copy the previous version’s settings).
Where do you find the latest ini file?
I typically check this page first if the update/version was just released: https://github.com/stascorp/rdpwrap/issues
You should see a issue for the latest version of Windows and it should contain either the INI edits and a fix.
For an update/version that has been out for a while, I just download the RDPWrapper installer again and push out the INI that it contains.
Any clarification on
‘As a general rule, do not deploy it to any computer where the primary user remotes in as it can lead to some strange session issues’
I have several clients who remote into a workstation regularly. What issues might occur? Would they be more of an annoyance or a serious problem? Thanks for any insights anyone might have on this scenario!
In the past, I’ve seen multiple user sessions being created. It is more of an annoyance because the user thinks that their computer restarted or logged them out.
I’ve been using this method for quite a while now. The latest versions have improved a lot over the original.
I can’t count the many times I have remoted into a user’s computer, solved and issue or installed a program without interrupting the user’s work.
MS should have long ago give admins concurrent login into desktop OS, for precisely these scenarios.
Glad to here you like it too!
PS: Some antivirus [I use Bit Defender] flag the files as RAT and block/delete the install files.
Just my 2 cents…
Thank you for that tip! And I completely agree that this feature should have been built into the client OS for years now.
Fantastic, thanks very much, works like a charm.
Not a problem at all!