Considering ConnectWise already allows you to forward your microphone to the remote PC's speakers, why isnt there an option to forward your microphone to the remote PC's microphone so that you can make a VOIP/Teams call on the remote PC.

It would be nice to be able to use the bridge service to access https sites. For example, being able to use it to login to the firewall's internal web interface.

We cannot open settings windows, or open system apps by their deep link URI:

For example, running the command "start ms-settings:about" will open the System > About page in the active user session (not in back stage).

Ideally, I would like to enroll all computers by going Backstage and running the enrollment app via deep link
ms-device-enrollment:?mode=mdm

See: https://learn.microsoft.com/en-us/windows/client-management/mdm-enrollment-of-windows-devices#connect-to-mdm-using-a-deep-link

Instead, I get this error.

Running "start ms-device-enrollment:?mode=mdm" gives an error:

start : This command cannot be run due to the error: The operation attempted is not supported.

At line:1 char:1

+ start ms-device-enrollment:?mode=mdm

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException

+ FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

In our company, we use numbers usually for users' samAccountName. This makes searching harder when you're looking for a real name of the logged in user.

Could this field (shown in pink in the screenshots) be configurable? Perhaps we could have another searchable field that could include the display name or UPN of the user?

As with the relay and the frontend URL, I think it will be useful to have the possibility of defining different domains to separate the support, access and meeting features.

This could provide a way to secure and manage this traffic separately.

For example, allow the frontend for technicians only from office network (or certain IPs) without losing the support public link feature.

Hi there

Command has changed either on this, or previous revision (I skipped over one rev)...

I like the confirmation of processing and the time checkmark, but cannot use the 'arrow up' function to recall the previous commands.

Any chance of getting that back?

Thanks

Have the ability to have 2 seperate toolbox, one for backstage session and another one for the regular session.

The tool we use in standard session VS the backstage session differ greatly, having the possibility to build 2 set of tool for each session would be amazing.

It would be nice to have a quick access feature to create a multisession. To send a request to a colleague within the organization. This would save time when escalating the issue.

Notice: For anyone reading this I'm recommending that you remove the TransferFilesInSession permissions and possibly the RunSharedToolInSession unless the user is an IT Admin and is allowed System Rights on a computer. 

I know, this is hard for me too... 

When we first looked at the RunSharedToolInSession permissions we assumed you had to be connected to the session and logged into the server / workstation which made it more acceptable. The good news is that we at least control the SharedToolBox and can remove harmful scripts. 

What I found, is that by giving a user TransferFilesInSession or RunSharedToolInSession you are essentially giving users rights to run scripts on behalf of other users that maybe logged into the system, even when the screen is locked or run scripts as the SYSTEM account when no-one is logged into the computer. 😬

 Meaning users can possibly -

• Change Local Passwords and or domain passwords depending on who is logged in.
  • It makes you wonder, what's the purpose of locking the machine if someone can just change the password via a batch. 🤷‍♂️
• Install Software
• Run Custom Scripts outside the SharedToolBox
• etc.

The whole purpose of us removing the RunCommandOutsideSessions and SwitchLogonSession was to prevent things from running without someone being logged into the server / workstation. Also hoping this added an extra layer of security incase someone got into someone else's control account meaning users would first have to connect to the server then login again prior to any scripts being executed.  

During my testing I tried disabling RunSharedToolInSession and i found out that you can still add scripts to the personal toolbox and execute them even though the shared toolbox grayed out.

To fully disable the toolbox you need to turn off both RunSharedToolInSession and TransferFilesInSession. 

This is extra depressing because i need my support staff to have the power to transfer files but i don't want them running scripts as SYSTEM... 😞

Thinking about hiding the briefcase to prevent the user from using this function? Well that can easily be bypassed too just by editing an xml file, it's all optional on the users end. 

This means ALL USERS that have TransferFilesInSession have SYSTEM rights and anyone that gets a hold of their account can abuse control.

I would like the option to disable Chat/Messages within Control completely. We have end users who start a chat that we are not monitoring and at the same time have technicians who use the chat and this is a process we don't want for our service desk.