Your comments

There is no reason a software as good as Connect Wise cannot support both interfaces. :)

I think there is a pretty good reason for not creating a separate, native, desktop app *and* a Web UI. It's duplicating functionality and would be a nightmare to maintain.

What this 'standalone client' should be, I think, is a specialised web browser, perhaps using a Blink/Chromium backend. But, it can then contain important "glue" between the web app and the host client. For instance:

- double clicking a session in the web UI could immediately launch a session. 

- desktop notifications could be sent

- saved login credentials

Think that's what you're thinking off @Matthew Pendleton? If so, I agree wholeheartedly. 

This can already be achieved by creating and uploading a .bat script to the toolbox.

Just create a .bat file with the following content:

To open control panel

start control.exe

To open services

start mmc.exe services.msc

Upload it to the toolbox and it can be run either from the host client or the web UI.

Alternatively, you can achieve this functionality with the command toolbox extension, built for this use case:

I'm afraid I can't see the reason for adding this feature as a standalone tool. It's too specific, can be implemented via the above methods (which can be adapted to practically any system utility such as taskmgr, regedit etc), and doesn't serve any purpose if you're primarily supporting other operating systems. 

I have this in my Shared Toolbox, and it works well.

You could run it at command line and see results without logging in. 

This is absolutely needed. Sign in should be handled and remembered by the app and not passed through to the web browser. 

Please allow us to add multiple instances too. 

I have always thought the thing that set CW control apart was a web based interface. I don't like installed representative portal software, like what BOMGAR offers because cross platform desktop apps are almost always hideous and clunky unless they use Electron or similar technologies (e.g. VSCode or Spotify) or are massive enough to develop and maintain native cross platform apps (e.g. Photoshop). 

I do support significant improvements to the client apps - both the support and access clients as well as the host clients (I think they should be native apps, not reliant on Java). But I can't support developing yet another desktop based portal for CW to maintain unless it is an Electron-like app that uses HTML and the same web backend - this could mean it could additionally offer things like quick session launching, persistent sign in, tooltips, tray icons and desktop notifications (good suggestion above by Brandon Stone). This I would absolutely support. 

The browser interface should be improved, particularly for mobile. But don't throw the baby out with the bathwater. Creating another representative portal aside from the browser one will, I suggest, lead to fragmentation and fewer updates as it creates added complexity of managing 2 sets of code - the web frontend AND a full, separate desktop client. Be careful what you wish for. 

@Koncept Technologies "Maybe it can be an extension with a one-time fee."

No way! The whole point of Let's Encrypt is that it is free. Charging to implement ACME is unethical. The point of Let's Encrypt is to make HTTPS usable by everyone. 

Charging, even small amounts, is against the point - you can already get cheap certs for a few dollars. The point is certificate authorities can no longer justify charging for DV when it can be automated for free.

I'd only support it if 100% of the proceeds were a donation to Let's Encrypt.

+1 this is a great idea, I'm surprised so many others have thought about this too!