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.
Just delete the entry in add / remove programs. That'll deal with 99% of users who uninstall things.
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.
shutdown /r /f /t <n seconds>
+1 for having an option to make the guest chat window go to top every time it receives a message
Customer support service by UserEcho
The SC bundled with Automate is the exact same build as the standard self-hosted build. The license comes via the LabTech (Automate) license. Nothing special here except some common config options which are used to tie SC to LT.
However, the hosted product while the same software build has some different server config (which CW are annoyingly refusing to support self-hosted using) which allows both web and relay to use the same port (443 I think). It's the same code, but with some non-standard config hacked into it which makes it different enough to be worth noting.
Adhoc is just a license. The software is the same.