Your comments
NinjaRMM already has this. Fully interactive CMD, fully interactive PS, can run either as system or as logged on user.
Um...what?
The software already detects and lists active RDP sessions and allows you to select which one you want to connect to, as well as what account is logged on to each. It sounds like maybe you are talking about adding an option to access this feature from the web portal. That's not what this feature request is for, please create your own feature request if needed.
This request is to create a feature that allows you to create a new RDP session (probably on the loopback with your software handling the redirection of input/output) and allow users to connect to that new RDP session that did not exist when you first connected to the machine on the console (which may be in use) or other RDP sessions (also in use by other users).
Yay!
Want to ship the below feature while you're at it? (;
I looked at this, you have to use a GPO/Script/Labtech/Automate anyways to deploy the system variable that plugin needs based on your criteria for which machines need which settings. I got that working and then realized it would be easier to just distribute the app.config files and restart the service so that's what I'm doing now until you guys can get this feature in place.
How do you accomplish this? We are looking for a workaround until this gets implemented, bleeding over this limitation over here
+1
We need to keep using RDP for server access for both the ability to have two simultaneous active/connected tech sessions as well as the ability to leave virtually unlimited number of disconnected tech sessions with processes running.
While we still need to be able to reconnect to our old disconnected RDP/console sessions through Control without getting hit with the consent requirement (which we only need for end-user computers), this gets us part of the way there.
If we could exclude the consent requirement from applying to disconnected RDP sessions as well as console sessions that are at the logon screen, we would be literally jumping up and down with excitement over here
Yes! Let's ditch the slow/sloppy LT shell emulator and the paid LT PowerShell plugins.
Agreed. Huge benefit for us as we are on the LT hosted SC and we do not give our techs login access to SC, only indirect access through LT (between SC, LT, and CW, that's just too many local accounts - SSO or GT*O IMO). And now that making the SC shell interactive and adding PS support is a planned feature, we will be pretending the LT shell emulator does not exist.
+1!
Customer support service by UserEcho
Downvote.
Why don't you have a published pre-configured app in Okta? Or a
guide for IdP's like Okta where you cannot import an XML from an SP? We
are not SSO/SAML experts as SSO/SAML is not our core business. Our
options are to either to invest in becoming experts or assume the risk
of guessing.