So sorry, this was completely my mistake. Forgot i had the <allowConfig> set to false.

Hey Sergey
Thanks for your feedback, i'm looking forward to it! Meanwhile we fixed it by writing a little extra script of our own to monitor if the GUI started and close it again :-)

It's really nice to see there is so much commitment to following up on the user issues!

It is actually happening on both (tried both versions of the software)

It's the 'client' that we don't want the UI opening. So the computer that initiates the connection, when closing it, the UI opens. We want to prevent this because we don't want the client's laptop to be able to accept incoming connetions. In a previous post, i've posted the issue that blocking incoming connections (either through the xml file or in the managed remote assistant) doesn't work as expected.

So our current setup: server side with UI allowed and remote access enabled
Client side with CLI access enabled, Config disabled, UI disabled, incoming connections disabled. When client makes a connection to server using a CLI script, all goes fine. When closing the connection, the UI opens op. When viewing the incoming connections tab, it says the connections are disabled. However, when clicking on said icon, the option page still opens op.

We've found a manual fix by writing a script that runs in the background and checks for the MainWindowTitle property of the Remote Assistant process (it differs on the main UI and when connecting to a remote server, thus being able to check when UI opens op and close it again). Still extremely excited about your product, but this does seem like a bug. I realize that what we're trying to do is counterintuitive, but our security policies demand it

While testing your solution, we encountered another problem. If you modify the xml file to prevent incoming connections and disable the option menu, there still is a workaround. If you click on the 'box' in the GUI that says the connection is disabled, it prompts you to the option page to enable it. Thus completely bypassing the limitation in the xml file...

We'll keep looking for a workaround on this, but i assume this behaviour isn't ment to be?

This is exactly what we've been looking for. Thanks for the answer!

Update: If it would be possible to generate an install script that automatically ticks the option 'prevent incoming connections' along with the 'access to configuration' limitation in the Managed Remote Assistant, our needs would be addressed completely

FYI: i tried disabling the GUI and making the connection with CLI using a script, which works like a charm. One remark: when closing the connection, the GUI of the application starts (even tho the install is configured without GUI permissions, using the Managed Remote Control)

Hey David, that would indeed address our need. However, we wouldn't want our employees to be able to uncheck this option themselves. Is it possible to shield this?

Using the Managed Remote Assistant, does disabling the direct connections and installing the modified client (and disabling the configuration options) have the same result?

After searching a bit i found VAC (Virtual Audio Cable) to rout audio output to mic input. It works on the host system (tested it by recording a small sound file and transferring it to client).

I selected the correct input device in the Remote Assistant, but the audio isn't coming through (yes, my mic is unmuted)
My client isn't showing any audio output for Remote Asisstant in sound mixer either. Am i missing something obvious here?

Thanks for the quick reply. A workaround i'm trying (but failing to do so) is loop host audio output to mic input (windows 10) ... I know this is Windows related, but could that be a temporary solution?