2

If I connect to an office PC with Remote Desktop (Terminal Services) I can see in Powershell that I have an RDP session:

PS E:\> QWINSTA
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 services                                    0  Disc
>rdp-tcp#13        berndw                    2  Active
 console                                     4  Conn
 rdp-tcp                                 65537  Listen

But I can see the console session is available. I know it is because I can log in to the same PC using VNC and see that I'm logged into a console session:

PS E:\> QWINSTA
 SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
 services                                    0  Disc
>console           berndw                    2  Active
 rdp-tcp                                 65537  Listen

Nothing has changed, all my windows are still open, even the powershell window I ran QWINSTA in, and I can move to RDP again and the windows are still there and I can move back to VNC and they are still there, that is, user context survives this switch from a terminal services session to a console session back and forth.

Fantastic. And?

Well, I would like, while logged in with RDP to run a windows application in the console session! I'd be happy to respond to a login prompt to do the session switch, if needed. Is that even possible? And if so how could it be done? Is there some way in Powershell to make this request, to use Start-Process say to start a process that starts in the Console terminal (happy to switch back once it's started).

There is a way indeed to do this. It runs like this:

  1. Close my RDP client
  2. Connect with VNC client
  3. Login
  4. Connect with VNC client again
  5. Start-Process myapp
  6. Close VNC
  7. Connect with RDP client

Why is this not good enough? Because its extremely slow to do, and frustrating as all heck.

Step 4 is interesting and I should explain, but am keen to learn too. What apparently happens is that in step 3, when I log in, Windows (Windows 10 in my case) notices a terminal Services session (RDP) closes that and opens a Console session, and in this switcheroo the Ultra VNC server on the host disconnects. So I have to reconnect and when I do, I see my windows as they were (all happily moved from the RDP session to the Console sessions). Then when I close the VNC client and connect with RDP again all my windows again survive just fine.

So why do all this? I'll admit that is not relevant to the question of how, but to satisfy your curiosity, the reason is simple enough and relates some software I need to use which only starts properly in a console session, but VNC is patently unusable (it's far too slow, and I believe throttled on top of that by a firewall the host is behind in an effort to discourage use, and encourage RDP use - I have no control over this, it is simply the case that RDP is like I was there at my PC and VNC takes seconds to echo keystrokes and 10s of seconds to render the desktop - as I said, no control over this, not within my sphere of influence).

So at present I am stuck with a frustrating time consuming process to start this app. If I could somehow run it from the RDP session but in the console session that would make all this go away. Even if that logs me out of RDP and I have to log back in again, it is less time consuming and less frustrating than the current VNC solution. And no, nor can I use Teamviewer, LogMeIn or Nomachine or anything else that connects to a console session - again not in my control (only RDP and VNC are supported/permitted)

Improve this question

1 Answer 1

Reset to default
0

It is not officially possible with standard Administrator privileges, but tools such as psexec can elevate themselves to have SeTcbPrivilege and create processes belonging to any desktop on any session. (If there is no session attached to the console and it is currently showing Winlogon, then you probably need the -x option as well.)

psexec -d -e -i -x notepad

It should also be possible to forcibly move your session from RDP to console using tscon:

psexec -e -s tscon 2 /dest:console
Improve this answer
7
  • 1
    I look forward to trying this out when next able. Will report back soon.
    – Bernd Wechner
    Commented Nov 26, 2020 at 11:02
  • OK tested it. Was hopeful but not much luck. The first command is good, it seems to run a notepad, and I can't see it on my RDB session so I trust it's on the Console (though can't know that of course as it is remote and I'm not there, I can just see it is running as a process). The second command is interesting as the -s option is poorly documented on the psexec page but it may be in the right direction, alas the experience of running it inn administrator powershell is that the RDP session closes. Reconnecting I am back in an RDP session not the Console session (as QWINSTA reveals).
    – Bernd Wechner
    Commented Nov 30, 2020 at 0:43
  • The problem is that your expectations on how sessions work are different from how they work in Windows RDP. There is no such thing as "the Console session" – the names are not permanent identifiers, rather, 'console' is the label for whatever session is currently attached to the console. And because a session cannot usually be attached to more than one place, connecting to it via RDP will always detach it from the console! (This is very different from VNC which doesn't touch Terminal Services at all, it just captures the image of whatever session it's running inside.)
    – grawity_u1686
    Commented Nov 30, 2020 at 6:38
  • Thanks for the clarification of terms there. To aid my understanding perhaps can you share some more insight into why, in the OP, running QWINSTA through and RDP link (active), I see both the rdp-rcp session and the console session (Conn). It seems only one session is active. My goal would be: from an RDP session, in one atomic move, switch to a console session and start a program and the switch back to the RDP session. In a powershell script perhaps? Is that a vaguely possible direction to think or also just the product of a confused understanding of how sessions work (which I admit I have).
    – Bernd Wechner
    Commented Apr 18, 2023 at 23:54
  • In your 1st output, 'console' is still listed because the "seat" continues to exist physically (i.e. monitor/keyboard still present), hence Conn (connected), with Windows automatically showing the logon screen in place of a session. Basically the same as what you have on a freshly booted Windows when nobody's logged in yet.
    – grawity_u1686
    Commented Apr 19, 2023 at 5:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .