+2
Considering for Future Release

Ability to filter machines based on users connected to RDP sessions

Jesse Cross 7 years ago updated by Brian OLeary 2 years ago 7

It would be quite helpful if we could filter and search in ScreenConnect based on usernames also connected to RDP sessions.  For example on a Terminal server if user1 is connected and I search for user1 the search would populate the terminal server user1 is currently connected to.  The only way to see that user1 is connected now is to start a remote support session on each server and check the view menu to see all sessions connected.

Considering for Future Release
+1

Looking for similar functionality as we are running a floating virtual environment that has some users connecting to sessions via RDP. This makes it impossible for operational management to know who is in what session without knowing the name of the VM their user is connected to. 

It would be really helpful to have this functionality.  Our Azure vendor uses software that initiates RDP sessions to connect to the device.  As it stands, we can't see any of the useful information like who is connecting, the session times, or the screenshots.  It would be nice if Connectwise supported this and I'm surprised it hasn't become more prevalent given the growing use of Azure/AWS computing.

You can right click on the session and choose "Join With Options" and you will see a list of sessions, including backstage.

That is how I determine who is logged into the server.

That is true and is important, because without that we wouldn't be able to join a remote session on these computers at all.  However, it doesn't provide all of the detail that you would get in the "General" pane particularly for the Session information, most importantly if anyone is actually connected to the instance.  It won't show the screenshot.  It also won't be searchable anywhere, so we have to use another source like SCCM or AD to pull the user associated with the specific Azure instance.

I should clarify that these Azure instances are being deployed to our users and they aren't servers, for our use case.  If they were servers, I definitely wouldn't care as much about some of the items mentioned in my previous reply.