Sean, thanks for the update, although it's certainly disappointing to have to keep hacking around this with Nginx/Stunnel.  A cleaner option I've considered is putting a WAF in front of ScreenConnect, but I don't know how to get around the fact that to my knowledge, the hostname of the web interface has to be the same as the relay (which of course can't be proxied through a WAF).  Does anyone know if ScreenConnect can be reconfigured to use different URLs for relay and web interface?

Any progress on this?

Also, find a way to sign packages so we don't have to walk users through finding the security applet and explicitly allowing this "untrusted" app.

Even just periodic screenshots for review would be a great help.

Vote here instead: http://product.screenconnect.com/topics/1224-ability-to-connect-to-guest-when-their-dns-is-not-working/

+1.  I really like the idea of automatically caching the last resolved IP address.  No setup, just increased reliability and usability on day 1.

Peter, I'd love the WMIC pack - jnelson@pintechfw.com

Also related to http://product.screenconnect.com/topics/172-nginx-reverse-proxy-by-default/

I remember this as being one of my first annoyances when I initially trialed ScreenConnect. I did this from day 1, because I wanted control over the SSL settings. Once I got it worked through, I've never had to mess with it, but it would have probably made my trial smoother to have had this.

(Also related to the Let's Encrypt request - http://product.screenconnect.com/topics/473-add-lets-encrypt-support-to-base-screenconnect-functonality/ )

We make a "group" that shows all "old" clients, and periodically go through and just select them all and do a "reinstall", which upgrades them. Having the clients auto-upgrade themselves would be nice, though. Then I could leave a 5.2 version msi in the group policy, knowing that the software will upgrade itself to the latest version the first time it connects to the server.