The problem with the toolbox approach is it doesn't harvest the results from the scripts, and it would be clunky to execute programatically (adding a tool to the box, waiting for all machines to finish executing before removing it, etc) You'd end up with a bunch of old scripts cluttering your toolbox.

This doesn't solve the problem. Backstage mode has a lot of problems, specifically it is very difficult to paste long scripts into the terminal that is opened. Because it is in session 0, many UIs don't build correctly, specifically PowerShell ISE. I think what users really wanted (which you'll see in other feature requests) is to have a larger terminal window that works conceptually similar to the terminal window on the web UI, but built into the client itself that we can paste large PowerShell scripts into and have them run consistently without user interruption.

The issue we are specifically asking for here it for you guys to not jam up communication to the agent service on the target machine when executing commands.

Please do this and also tag commands with a unique id so we can tie requests/responses together. 

Is this working for the local IP? I have the extension installed but I don't see the local IP...

Just because my client is an admin of their own Azure AD doesn't mean I want them to be able to be an admin of my Control instance. 

Please explain to me the purpose of allowing multiple authentication sources if you aren't going to centrally limit the levels of access for each.

Allowing my clients to remote control their own computers is a supported solution. You guys helped me set this up.

Please move this back to being a bug. This is serious. 

Azure AD

We allow some of our clients with internal IT to use our ScreenConnect instance. If I link their Azure AD and put the Display Name as them, then it leaks who my clients are to the public. The only alternative is to give them generic names, but then I have to tell my various clients to use the second button, or the third one.

I would really like it if the logon page could match the domain of the user with a given external provider instead of listing the various external providers to the public.

We could simple add a field to the SAML configuration that is the domain name and then it can auto switch.