Your comments

I absolutely agree - even if only some code was accessible to some "trusted" partners.   This weekend I started a trial of a new commercial system and found three enhancements I could make to their docs - so I cloned their docs repo, forked, added the enhancements and sent a PR. Four hours after I found the issue it was merged into their main branch and live on their site. That's how collaborative software development works well. If an organisation is daft enough to think all the expert knowledge and ideas about their product come from their staff (who usually don't use it) then 

Given I had to chase on another FR I opened five years ago for CW Automate to properly generate a service file for its agent - I don't think CW know what a service file is... I even supplied the fix in that FR and it's still not been done. 

Why? We have both.  It's only a license key. Our CWA-licensed instance does have an Access license installed. 
I could discuss more details, but CW hid the license details and key after installation as part of an upgrade in the last couple of years. 

Unless you're saying that for partners licensed via CWA, the license check already fails and alerts to screen (and has to be overridden) during an upgrade - then it doesn't make any difference.  

I'm asking for only one change in functionality - for the non-interactive version to do (what is currently documented) and abort if the existing license check fails. The license check itself is already in place and no changes are needed there if it already works properly.

+1 for having an option to make the guest chat window go to top every time it receives a message

Just by renaming the machine from the GUI. I thought this just worked - perhaps I'm wrong. I'd need to test to be sure.

In fairness, SC deals with a machine being renamed OK - and fairly quickly.  Reinstalls of the OS / SC aren't deduplicated though. This should probably be a controllable option, which defaults to deduplicating but can be set to still operate the old way. 

Max, I wish I had a suggestion for HA, but I don't have anything in my toolbox that I'd trust. Don't quote me on this - but I think I've seen it written that it's possible to change SC to another DB engine like PostgreSQL, but it's not supported. As you want HA, I'd assume you'll be wanting to stay within support from CW. 

I also had a database die because I tried to export the auditing reports.  Dead, server gone, toasted.  

Insert Coin To Start Game.   That server was allowing our support desk to service our clients. That was a fun couple of days - NOT!  As I recall, support's response was to tell us to start again with a fresh install and not be stupid enough to try and export the auditing logs again. 

I'm looking forward to hearing from Mike how querying the DB causing complete loss of the DB is not a DB engine issue.  There seems to be a disconnect between how he thinks the DB engine behaves and what you, we, and SC support have seen in real life. 

For the record - I'm not in favour of MS SQL due to license / limitations, and MySQL needs careful backup / restore handling due to lack of VSS support (as we found out on our LabTech DB) though I expect that is true of all / most of the open source options. 

Mike - I have to disagree. Extended auditing was operationally useless for us, and support have told us the reason for this is excessive SQLite DB size. When we restarted the server, it took over an hour for SC to become usable and even then it was slow for three more hours. IMO SQLite is not suited to anything like 200GB.  It's suitable for more like 200MB. Regardless of the maximum size listed on - that doesn't mean it's a good idea to use it at that scale.  The lack of caching being one obvious problem (relying on OS FS cache is not as performant as a DB engine taking nGB of RAM away from the OS and dedicating it to the DB table cache).  Another is the single writer limitation.   

While certainly SQLite makes the system easy to deploy and work with, and while you may say you don't have issues running it at scale it's very clear that many customers do have issues running it at scale (or at least think they do).  If you're SURE all these issues aren't related to the DB engine, perhaps you'd like to explain what is causing them and how to resolve them, because support have told us it's a DB scaling issue?