Windows 10: Unable to use Single Session Per User on tablet

[fajarnugraha]

I've been using rdpwrap on Windows 7 starter with Single Session Per User option activated, which works great. A user will have the same view of desktop/running apps whether its login directly from the console, or (later) logging in thru remote desktop. Obviously only one session for that user can be connected at the same time.

I'm trying to replicate the setup on Windows 10 home, but it doesn't work. I've replaced the ini file with the one from latest git (https://github.com/binarymaster/rdpwrap/blob/master/res/rdpwrap.ini). However, when an rdp client is connected, all connected sessions are logged out (including the console), and then closed. Even the new connected client is disconnected. If I try to connect again at this point, it works, but all running application on that user desktop is gone (obviously due to being force logged out).

Disabling Single Session Per User option allows multiple sessions from the same user (e.g. from console, and from several remote desktop connections), but each one has different sessions (e.g. different running app), which is not what I want. Trying to connect to existing session as suggested on #28 (task manager -> users -> select session -> connect) logs out the session instead (it shows "Signing Out", and then the rdp session is disconnected)

Is there a workaround or fix to achieve Single Session Per User the way it works in windows 7?

I saw #34 , but I already use latest git tip (and the symptom is different).

Any ideas?

[dragon2611]

I can confirm I'm seeing the same thing.

It also happens if you start an RDP session close Remote desktop and later re-login instead of re-joining your previous session everything is closed and a new session is started.

Edit:

This also causes a session drop (I.e due to Wi-Fi issues) to close anything that you were working on and log you out, - I actually saw a screen stating "Signing out" and then RDP closed upon reconnection

[binarymaster]

I can't test it right now, but it seems like this problem is beginning with Windows 8.

[jfolt]

Yes, I have the same problem. And multiple sessions cause other problems for me.

When I run RdpCheck, it shows "Access is denied" error.

I am running Windows 10 Home.

[jfolt]

Single session option also doesn't work on Windows 7 Home Premium.

The same error: "Access is denied"

[ultraboost]

I got single session option working by the following

1. Uncheck single session per user in rdpconf
2. Start regedit
3. Go to
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer
4. Open the fSingleSessionPerUser value.
5. Change value 0 to 1 to force each user to a single session
6. Reboot

[fajarnugraha]

@binarymaster : you might be right.

I tried windows 10 enterprise with it's built in "Remote Desktop -> Allow Connnections", it behaves the same: all running programs are terminated and user gets a clean desktop.

I'm thinking the "best" solution right now is to update README.md, stating that from windows 8 (?) onwards, rdpwrap can be used to connect to a computer, but can NOT be used to run programs in background.

[ultraboost]

fajarnugraha, have you tried what I suggested? I can access the remote PC from multiple other PCs and get the same session with the same running progams and desktop

[fajarnugraha]

@ultraboost : I did. It didn't work. At least not on windows 10 home that I currently have running rdpwrap

[fajarnugraha]

I just tested Windows Server (2016) Technical Preview 2. To compare it with windows 10:

On windows 10 (both home and enterprise), rdpwrap with updated rdpwrap.ini:

• with "single session per user" disabled, works (as in the same user can connect multiple times). HOWEVER when shadowing/connecting to/taking over an existing session (task manager -> users -> right click on a session -> connect) the OLD session (e.g. console, or another rdp session) will be logged out, and the NEW rdp session will be disconnected
• with "single session per user" enabled, it will behave like when you takeover an existing session: OLD session logged out, NEW session disconnected. When there are no existing session (e.g. all logged out), you'll get a new session when connecting again.

On windows 2016, rdpwrap with updated rdpwrap.ini:

• with "single session per user" disabled, works, and you can take over existsing session
• with "single session per user" enabled, works, and you automatically take over existsing session

So I'm guessing the issue is in taking over existing sessions, and MS deliberately disable that functionality on windows 10 (probably since windows 8). Any ideas where that functionality lie? registry settings? binary dll?

Until that functionality can be replicated, again, IMHO the "best" solution right now is to update README.md

[binarymaster]

Added this issue to README.md

[konistehrad]

I managed to get Single Session in Windows 10 Home working, though somewhat by accident. Here's my best account of what happened:

1. Physically logged in to Server, starting "session 0"
2. Installed RDPWrap in admin console via install.bat.
3. Opened RDPConf.exe. Saw "not listening [not supported]" as expected.
4. Unchecked "Single Session Per User", hit "Apply", closed RDPConf.exe.
5. Reopen RDPConf.exe. Saw "Listening [not supported]"
6. Attached to server via RDP, new session started ("session 1")
7. Closed RDP client. Attached again to RDP, another session started ("session 2").
8. Ran RDPConf.exe from "session 2", in RDP. Saw "Listening [Fully Supported]".
9. Huh, that's unexpected. Checked "Single Session Per User", hit "Apply".
10. Closed RDP client. Reattached to machine. Saw a reattach prompt with sessions 1, 2 listed.
11. Walk through old RDP-initiated sessions (1,2), logging out of each and closing client.
12. Attach to server via RDP, presented with "session 0".

Obviously strange. Please let me know if there's any other information I can provide. [UPDATE: this survives reboots]

[agiz]

HI. Just want to chime in that this may be a non-issue (at least to some degree).

You can achieve similar behavior (session shadowing, taking control…) by adding /shadow and/or /control flag to mstsc client.

One issue is that this only works if you are connecting from windows machine. I think it's currently impossible to add aforementioned flags to OS X's Microsoft Remote Desktop client. If someone knows how to (if possible) somehow embed these flags in .rdp file directly, please let me know.

[LittleVulpix]

I tried various flags and other things but it simply won't let me stay logged in. No matter what I have opened etc, it's just a force-logoff every time I try to log back in. This is pretty much making rdp itself pointless for me. Might need to invest in pro :/

[LittleVulpix]

Actually I don't believe this anymore! I'm able to use RDP with rdpwrap on my w10 home just fine, with single sign-on. No problem whatsoever.

It doesn't work on my tablet though, even though it is set exactly the same. Every time I log in the other profile gets DCd. And if I set it up to allow multiple well then I can log in multiple times but I cannot "take over" any of the other already-connected sessions. I'm starting to think it's some kinda special behavior reserved for tablets only, because I tried this on W10 home / w10pro and both behave exactly the same way on the tablet - single session does not work. Whereas on a virtual machine with w10 home and on a real machine with w10 pro, it works no problem. M$ tech was completely unhelpful and told me to talk to surface techs even though the tablet was not surface.

[katlogic]

Can confirm same issue with Win Server 2016:

Initializing RDP Wrapper...
Base addr:  0x00007FFC445E0000
SvcMain:    termsrv.dll+0x000000000000D010
SvcGlobals: termsrv.dll+0x00000000000346C0
Version:    10.0.10586.0
Freezing threads...
Patch CEnforcementCore::GetInstanceOfTSLicense
Patch CSessionArbitrationHelper::IsSingleSessionPerUserEnabled
Patch CDefPolicy::Query
Hook CSLQuery::Initialize
Resumimg threads...
<<< SvchostPushServiceGlobals
>>> ServiceMain
<<< ServiceMain
>>> CSLQuery::Initialize
SLInit [0x00007FFC446D23B8] bServerSku = 1
SLInit [0x00007FFC446D3470] bRemoteConnAllowed = 1
SLInit [0x00007FFC446D3460] bFUSEnabled = 1
SLInit [0x00007FFC446D23B4] bAppServerAllowed = 1
SLInit [0x00007FFC446D3468] bMultimonAllowed = 1
SLInit [0x00007FFC446D23B0] lMaxUserSessions = 0
SLInit [0x00007FFC446D346C] ulMaxDebugSessions = 0
SLInit [0x00007FFC446D3464] bInitialized = 1
<<< CSLQuery::Initialize

Either the DLL takes entirely different route on server editions compared to home, or these .ini patch points are completely wrong.

Does anybody happen to have a DLL version 10.0.11082.1000?

EDIT Never mind, the ini looks alright. Here's the dll - https://a.pomf.cat/iunear.dll

[victorhooi]

I saw the caveat on README, and just wanted to clarify the limitation.

Say I have a Windows 10 machine, with RDP Wrapper.

If I connect to a RDP session, and then terminate the session, rather than logging out - will Windows 10 simply log me out anyway?

And if I try to RDP to the machine again, I will hence get a new session?

What about if I use RDP RemoteApp - e.g. via RemoteApp Tool (http://www.kimknight.net/remoteapptool)?

Does it mean if I start a single application via RemoteApp, but then close it - I won't be able to resume using that app where I was?

Do we think there's any way around these limitations, or would they be difficult to overcome?

Does directly editing the termsvrl.dll file still have this limitation?

[LittleVulpix]

@victorhooi , I actually found out that the rdpwrapper works nice on a w10 machine home. Session resuming etc works like a charm... EXCEPT if your machine is a tablet. For some unknown reason, if it is a tablet, the machine will log you out - forcibly - even if you for example leave unsaved documents running and such (things that normally stop a logout). I have made a technet post about it but no real help: https://social.technet.microsoft.com/Forums/en-US/6465436b-cbf8-42f4-8606-a19563189392/cannot-switch-account-without-being-logged-out?forum=win10itprogeneral

I tried EVERYTHING . I thought it was because of RAM but nope, it works fine on a virtual machine with 900MB ram.

It's not RDPWrapper's fault though. It's something in windows. The behavior is the same on Windows 8 / 10 Pro if you use a tablet.