Your comments

Nice Michael! I won't have a reason to test it, but thanks for sharing it. I'll be discussing this with Partner Care team on Monday. 

WOW. Seriously!?  :-(

There NEEDS to be a centralised way to see machines with saved creds, and preferably clear them. 

OS settings cannot be used to prevent uninstallation by a local administrator or other suitably privileged account.   Removing the entry in add/remove programs does not prevent uninstall - it just obfuscates it so that most numpty users can't manage it. MSIEXEC /X will still work. 

If you're not implementing the password, can I suggest either an option in the installer to NOT add it to Add / Remove programs, or at the very least an official KB on how to remove it - with example commands, which would seem to address >90% of the cases here. 

I think your points about the baked in password have some validity though. 

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.