I just installed the 25.4.16 screenconnect for On-Premise. I was previously on 25.2... I just noticed that the connecting user gets a download of a ZIP file instead of an EXE file when Joining with a code. Is that a new intended change? I can't find it in the release notes. Can we change it?
Clearly nobody at screenconnect has actually provided remote support to end users.
Our clients phone us requesting remote assistance.
We create a public session with their name and direct them to our login page, on prem screen connect system. They ‘join session’. Sc client exe downloads, the execute it. All done and almost anyone can do that including elderly, and low tech folks.
NOBODY is going to handle downloading a zip, finding the zip wherever it downloaded, open the zip, and then depending on whatever zip handler is installed, extract the zip to a temp folder somewhere, browse to that folder they probably don’t remember, find the executable and launch it. Not to mention the probability they will extract only some of the files, or overwrite files somewhere creating an even bigger mess. We will spend 30 minutes on the phone just trying to walk them through the process. Currently we can connect in under a minute.
Consider you have to help you elderly relative. Prior to 25.4 no sweat. Do you really think you could walk that person over establishing a session with this new zip method?
This new zip concept is entirely unworkable in the real world of providing remote support.
We are moving on to a different product unless this insane change is reverted either immediately or in very short order, or an alternative is provided. Given the June 13 update requirement we are already looking into a better solution. Sorry to say that as a sc user for many many years.
sc - are you listening?
We 2nd your comment. Currently our team has resorted to using window's builtin Quick Assist to help our users. We will give SC sometime to fix this or we too will need to find a better solution.
Same here. This need to be changed quickly. Otherwise its not useable anymore.
But i really dont understand the reason for this. What is the problem with the old way?
Only idea I had was when someone uses only http for the sc website. But we use an nginx reverseproxy to setup https and had never problems with that.
Same here. This need to be changed quickly. Otherwise its not useable anymore.
But i really dont understand the reason for this. What is the problem with the old way?
Only idea I had was when someone uses only http for the sc website. But we use an nginx reverseproxy to setup https and had never problems with that.
I also do not understand the reason. It is nearly impossible getting any non tech person connected for support via the ZIP delivery. Maybe SC devs could explain what the issue is with respect to certificates / code signing etc and simply delivering the exe directly. They have posted some info on getting this solved "soon". For now most of our team have switched to an alternative provider.
Yeah I'm having similar issues and need it changed back. Walking some people through unzipping a file adds so much time to some calls. Today I saw one with a file handling software that was unique and trying to use my default UI as reference was useless because theirs was so weird.
Any further updates from support on this issue please. Now a week since the last comment, and still a nightmare getting non tech savvy clients connected. Currently not fit for purpose until a workable alternative to zip file provided...
You could modify Scripts/sc.launch.ts and change and make the MSI 'WindowsInstallerDownload' the first option. That has its own set of drawbacks due to the MSI not being signed - you'll have to walk clients through one or more warning prompts.
We ended up rolling back to the previous version and re-signing all the binaries with our own code signing certificate - but that's not an option for most people.
You could modify Scripts/sc.launch.ts and change and make the MSI 'WindowsInstallerDownload' the first option. That has its own set of drawbacks due to the MSI not being signed - you'll have to walk clients through one or more warning prompts.
We ended up rolling back to the previous version and re-signing all the binaries with our own code signing certificate - but that's not an option for most people.
Yes, screenconnect did too until this latest release. I feel this was a pants on fire release. Hopefully they reinstate the exe file soon.
Installed v25.4.25.9314 on prem which reports incorrectly as 25.4.25.9313
Main issue is no reinstall\upgrades as Webroot has flagged it as infected
Infection List:
SCREENCONNECT.CLIENT.EXE, W32.Malware.Gen, %programfiles(x86)%\screenconnect\bin\
SCREENCONNECT.CLIENTSETUP.EXE, W32.Malware.Gen, %programfiles(x86)%\screenconnect\bin\
I am glad to report that Version 25.4.25.9314 is now rolling out in the cloud, so the zip file is gone. I can speak for the entire ScreenConnect team when I say that we appreciate your patience; this was always intended as a stop gap fix while we could work on a more permanent solution.
The auto upgrades will take several days to hit each instance, so if you want to manually upgrade your cloud instance you can follow these instructions
Upgrade a cloud instance - ConnectWise