Add an option to specify a specific logon session when opening a session to servers/computers with multiple users

Avatar
  • updated
  • Started

Example: Say you have a server that multiple users remote into. Currently you can assist them by opening an access session to the server, and then changing the logon session from the [serveradmin account] RDP session to the [user that needs help] rdp session. What I'm suggesting (especially as I can see direct benefit at least in my own environment) is to have an option for access sessions to open directly to a specific logon session. IE, rather than having one of my techs open an access session, then select a logon session, instead have them see multiple access sessions for each user, which automatically opens into that user's logon session.

This would be helpful for a variety of connectwise environments:

-It would be useful for those who charge clients a monthly fee based on how many users they support. It's easy to track supporting X number of users when you have X number of computers with access agents installed, but can be difficult if you have an unknown number of users that remote into a central server. If you were able to create access session groups based on user logon sessions, it would be easier to track active users. Because it's one thing to see that logon sessions on the server exist for whatever number of users, but it's another to be able to see things like 'this access session for User7's server session hasn't been logged into by a tech in months'

-It would be useful for those who assign specific users to specific Technicians (EG, companies that have tech1 assist users1-30, tech2 assist users 30-60, etc), as you could just give each tech permissions to the sessions for each user's logon session, instead of the entire server.

-It would be useful in helping stay organized with companies/clients that have large RDS environments, where you may have 30-40 users remoted into a given server. Instead of needing to go through a massive dropdown from the screenconnect client, you could leverage filters and groups through the web portal.

Those are just the examples that spring to mind right away, in addition to my own admittedly niche needs, just to demonstrate that a lot of people could benefit from this feature. 

Duplicates 3
Terminal Server connect only to console session

We would like the ability either select the session to connect to or to restrict our connections to the console session on a Terminal Server. From what I understand ScreenConnect will automatically connect to the session that it was connected to last. The problem is that we're using LabTech and since LabTech uses a single user account when a tech connects to a Terminal Server they will connect to a seemingly random session.

Specify a logon session before joining session

The partner would like to specify the logon session before joining a session. Currently the partner has to join the session and switch the logon session

Set permissions on what which session logon you can see

"Ok, we have a user that we want to have console access to a terminal server using screenconnect. It seems they have the ability to view and control all sessions using this feature, that is why we are trying to disable it"

Avatar
0
anonymous
  • Under Review
Avatar
0
Mike Bannerman Team Member
  • Pending Review
Avatar
0
Ed Davison

Would definitely like to be able to choose a user session rather than the console session that we seem to be only able to do now (connect to console session only).

Avatar
0
anonymous
  • Pending Review
Avatar
0
anonymous
  • Pending Review
Avatar
0
Seth Whaley

That would be a great feature. Not sure if possible, but if so - I could definitely see the use cases!

Avatar
0
Jason Spreen

I definitely agree. Without this option, accessing Citrix servers connects to a random user's session. We need the option of choosing which session to join.

Avatar
0
Mike Bannerman Team Member
  • Under Review
Avatar
0
MAD

any update on this?

Avatar
0
anonymous
Quote from MAD

any update on this?

Hello,

We are currently reviewing this issue and have it scheduled for Q2.



Top contributors

Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar
Avatar