To take care of downside #2 the script itself can be stamped with a version, check at a specific URL that you control which is the latest version that should be used and warn that it needs to be updated, eventually with a grace period, after which it simply refuses to work. Of course, this would only work after deploying everywhere a script version which includes such version check, so you'd want to add it ASAP.
It might be possible to also offer a trigger for automatic downloading and deploying of script updates on the customer sites from the script itself. Customers would have to be willing to use such trigger, but that can be difficult in terms of support as different customers may have different deployment requirements, processes, strategies. Might be worthy for select (well paying or "friendlier") customers.
To address downside #1 the script can similarly check at a specific URL that you control their service level config (based on some sort of client or licence ID) and act accordingly. On your server side you can use the accesses to that URL to monitor usage and provide customized configurations.
You can even merge the #1 and #2 checks to one well-crafted URL and obtain both version and client ID check in a single request/reply exchange (with a side effect that you can even allow different per-client script versions out there if needed, which may come handy occasionally - no need to churn new versions to all clients for updates relevant to only a few clients).
I'm assuming here no malicious intent (i.e. customers hacking the script to mislead/avoid these checks), otherwise a more solid/secure enforcing approach would be needed.