Sign macOS app
In order to deploy macOS privacy preferences policy via MDM/DEP, the macOS app in Mojave that needs exceptions must be signed. Otherwise, a user has to create exceptions to allow remote control via ConnectWise Control, which isn't ideal. I don't want to have to sign your app to get the payload pushed out to create the exceptions from our management software. If you signed your apps like other developers, this would be much easier for all users, like those of the Addigy and JAMF communities.
Without signing, supporting this en masse is costing a lot of support hours.
Apple’s recent release of the Mojave operating system introduces new features and security measures, offering end users more peace of mind but also introducing new challenges to partners supporting Apple machines. The team at ConnectWise Control is working to ensure that these changes have the least amount of impact possible for partners.
These new security and privacy settings were enacted by Apple and change how all vendors of remote control products are able to deploy to endpoints. One of these new challenges is a change in the way hosts gain control of Mojave devices. When first connecting to a macOS Mojave session, end users must physically allow access to the ConnectWise Control app from the machine itself. The steps to control a macOS Mojave session have been outlined in documentation. After extensive research, the team has determined that this requirement is mandatory on the first connection; signing the application or access agent will not solve this issue.
ConnectWise Control is actively researching the best way to manage the Gatekeeper feature and improve the experience when updating or reinstalling an access agent on macOS Mojave. The team has also planned performance enhancements and improvements to the Mac client, and will communicate more Mojave updates as they become available.
@Caitlin signing the product will fix the problem. Then it can get access to accessibility through an MDM like other applications
To add some background to this, we're increasingly seeing our customers moving towards mixed / MacOS workstations, and supporting MacOS for BYOD. We LOVE ScreenConnect and don't want to replace it - but we need something that will work reliably and easily on MacOS including ad-hoc sessions. The current situation with signing etc is not good, but if it is going to get worse then we might have to look for another solution even though we REALLY don't want to. I don't know enough to contribute anything technical on this, but I want to plead with you to really exhaust EVERY option - imagine if you're the only remote control solution to crack this one... that's a unique selling point right there!
@Alex Heylin they won’t be the first. This can already be done for Team Viewer, bomgar and I believe Logmein
Thanks @A Simm, in which case it clearly CAN be done, and we need it to be done. The company (we already use) that we consider a direct competitor to LT uses LMI, and while we don't want to use them instead of LT - this is another nail in the coffin for LT / SC having a place in our business.
It's been standard practice to sign MacOS packages for years now. So, why not just do it? Please don't let this turn into a dev versus product fight. Side with the customers and do the right thing. Just take the devs out for beers.
I tried posting this as a reply above, but it has been stuck in moderation for 2 days now. I'll try here instead.
Hi Caitlin (and team),
I'd like to encourage your team to not give up. I respectfully reject your assertions that this isn't possible. I know this is in fact possible, as I've seen it working (with other applications and with your application when signed). Your team unfortunately did not research extensively enough. While I agree signing the application in and of itself not enough, if you have an Apple MDM setup and deploy your own privacy policy that whitelists the application (a signed application is required), then you can remotely approve the use of CW Control *without* any user intervention on the first connection. Let me try to help by providing some reading material:
https://derflounder.wordpress.com/2018/08/31/creating-privacy-preferences-policy-control-profiles-for-macos/
https://www.jamf.com/jamf-nation/articles/553/preparing-your-organization-for-user-data-protections-on-macos-10-14
https://macadmins.herokuapp.com/ (see mdm channel)
https://github.com/carlashley/tccprofile
I'd love to work with you and your team more directly to make sure this comes to light. If that is at all helpful, please don't hesitate to contact me. Here are the signing requests:
https://control.product.connectwise.com/communities/6/topics/2014-mac-signed-application
Please note, this is the .app that needs to be signed, not the installer.
Thank you for considering my feedback on this.
I almost lost a client because of this. They sent me an email about how it costs $100 to become a developer, how can we use this software, etc etc. It made me reconsider using CW Control.
Also, another user was able to get this working (only if they have a developer cert from Apple and sign the app themselves, which shouldn't be a requirement, hence this topic):
I wanted to give an update on our ongoing work with Mojave. Thanks for your continued suggestions and attention. ConnectWise Control is multi-instance, not multi-tenant like other remote control solutions, which means that changes to compensate for Mojave permission updates are a higher architectural discussion, and something we’re diligently researching. Being a multi-instance product provides additional levels of security for our partners, but also presents new challenges.
I enjoy all the feedback we have gotten on this issue. As we continue development on this issue, I wanted to provide some clarification.
We have started development on signing the macOS installer bundle. When the macOS installer bundle is downloaded, it undergoes dynamic changes related to our customization features. The same is true for all of the installers. However, only for macOS do these changes break the signature of the bundle. Therefore, not signing the application was a tradeoff to allow for the .pkg to have customized branding, naming, etc. However, the release of Mojave changes that calculation for the following reason: permissions granted to unsigned applications to not persist upon reinstall.This is the main reason why we have decided to investigate signing the installer. Doing so requires some significant changes to what/how we customize our application, but we are working hard to maintain all functionality at this point. This is the main sticking point with signing the application.
As Caitlin said, this does not solve this issue because end users will still be required to be admin users and supply permissions to our application. Although signing the application allows it to be distributed with an MDM product, we do not consider that a solution because we can't require our partners to purchase a 3rd-party tool to support ours. Currently, there is no way to get around these permission challenges for any software vendor. That said, we are glad that signing our application has the ancillary benefit of making it compatible with 3rd-party tools in use by our partners.
Hope that helps. We will keep this thread updated as work progresses.
Is there an ETA of when this will be working for macOS 10.14? Currently unable to push it out to labs until I can give accessibility access using an MDM.
You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January
Please post here when that version is available. While I can also dig up the Team ID after it is installed, can you also provide us the Team ID of your signed installer when the new version is available? This will make it possible to whitelist in Jamf/PPPC before I test the new version.
Thanks!
We need more than just team IDs. Here's a sample of code requirement needed to create a configuration profile to whitelist an app. Note that the team ID is at the end, and there is information related to the certificate that is attached to the Jamf agent. Since Screen Connect has no certificate there's not enough information to put into the code requirement field.
identifier "com.jamfsoftware.jamfAgent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"
The next Stable release of 6.9 after you made this post came and went without any change to the situation, I suspect the code for that release was locked already.
Do you have an eta for the NEXT 6.9 stable that will have this in, or pre-release of 7 ?
This is critical for us and we are getting a lot of backlash denying upgrade to Mojave while we wait for this, i'd love to get this tested ASAP.
Thanks
Brandon
The latest stable version of 6.9 came out a few days after you made this post and the change was not there, I assume the code was already "Locked" by that time.
When will the next stable version of 6.9 with this fix in it be available ? Or a Pre-Release of 7 ?
We are getting masses of flack from our user base because we wont allow them to have Mojave until this is fixed and we can control their machines properly.
I would love to know exactly why ConnectWise was not signing the app in the first place. I have WASTED hours of precious time working on a profile that would allow Screen Connect to run, and then I find out that because it's not signed, this is not possible. Application signing became a requirement on the Mac with the release of OS X Lion nearly 8 years ago. Why did ConnectWise wait so long? When I have a choice, I won't work with developers who don't sign their work.
Only the macOS access client is not signed. This is due to incompatibilities with Apple's signatures and Control's customization features. The unsigned access client has not caused any problems on macOS until Mojave.
OK. So it's Apple's fault for improving the security of their operating system. Let me go on record as saying that I do not blame Apple for this. I am 100% in support of their security and privacy measures on macOS even though they are sometimes a pain to have to deal with. As I stated before in this thread, macOS Mojave was released to developers in June of last year. The full release of the OS was released in late September.
The macOS access client currently works as expected when permissions are granted. The main issue is that the applications permissions are not persisted upon reinstall, and must be re-granted. We are working to remedy this and are testing OS releases more thoroughly in the future to find issues like this sooner.
Right. It will work once permissions are granted, but that requires admin access. If a user is not an admin, they can't grant permission. Also, a lot of the affected systems are out of my reach. I cannot grant access. The only solution to this is that we need the app to be signed. Period. I don't care about the installer. When Jamf Pro runs the installer for Screen Connect, it does so with root privileges, so there is no Gatekeeper warning. The app itself needs a developer certificate. I'm not going to debate this. We know what the solution needs to be, so it needs to be implemented.
Brandon, can you please clarify what it is that ConnectWise is working on (referenced above in https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app#comment-7007 "You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January")? I really hope that the app itself is going to be signed as part of that work, which is what this ticket is for, and not something else. I would expect that the customizations are either held outside the application (in Library or something like most other apps). I could see you signing before download (after customizations are injected server-side), but it seems easier to just move those outside the .app that you sign. Ideally, you aren't signing with any client preference changes on the server side (that requires re-install of client. Bottomline, this request and the outcome of any related work should be a signed app.
The changes include signing the macos access client. Please refer to my comment above for a description of what's involved with that.
Our customization features include rebranding of the application that is a part of the app itself and cannot be extracted to an external library (e.g. bundle name, icon, etc)
Don't forget that the privacy permissions manually granted are reset anytime you update the client, which you guys also do very frequently, for better or worse.
Good point, because an update to the client requires a reinstall, the clients permissions will not persist.
If it will help, I would be happy to test the new version by distributing it using one of our Jamf Pro servers. We need to be able to deploy Screen Connect without users being nagged about approving the app. A lot of the Macs that we manage never get touched by us. Some of them are as far as 1000 miles away, and the users are not admin users. The key for us being able to whitelist the app is that it must be signed. There is no other way for us to do this.
There really shouldn't be much to test. They just codesign the app and we put the Code Requirement string in our PPPC profiles.
No. I test. When I took my Jamf certification courses, I was taught to test, test, test, and do more testing before deploying something to hundreds or thousands of systems.
@Headbolt: There is a new version of 6.9 available in the Canary channel in Control Cloud (6.9.21870.6964). This includes several fixes for macOS Mojave (including the signing of the access client) and is currently in testing.
!!!!NOTE: Versions in the Canary channel have not completed internal testing and are not appropriate for production environments!!!!
A new version of 6.9 will be available in the Preview channel once testing is complete. I will keep this thread updated with details.
This version (6.9.21870.6964) is now available in the Control Cloud Preview channel. Barring setbacks, this version should be able to be made stable next week.
Does this version include the signing fix? Do we have an idea what day it will be made stable ?
Have a Free Cloud account that is seemingly on that version now, have tested with that and created a Config Profile to deal with the TCC issue.
Seems to work.
Will re-test when This release goes stable and we have updated our live install
FYI for those that need it, here are the settings i use to allow the TCC/PPPC to work.
The Client ID does not seem to be an issue, so this should work for anyone on the new version.
I do mine in JAMF
APP
Identifier
com.screenconnect.client.access
Bundle ID
Code Requirement
identifier "com.screenconnect.client.access" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = K8M3XDZV9Y
APP or Service
Accessibility
AppleEvents
Reciever Identifier
com.apple.systemevents
Bundle ID
Reciever Code Requirements
identifier "com.apple.systemevents" and anchor apple
UPDATE: There have been no major error reports received from Cloud Preview partners about 6.9.21870.6964. This pre-release is available to on-prem partners through the ConnectWise Control downloads page (https://www.connectwise.com/software/control/download). It will hopefully be upgraded to stable next week.
Sorry, that page is still updating. Try this one in the meantime: https://www.screenconnect.com/Download?result=5sdfss156d156sfsd156fsd156f
Any word on when this will got to stable and be available to cloud customers? I can sign my customized app and set the appropriate PPPC settings via my MDM which allows the app to launch but every time an update (and subsequent reinstall) of the app comes out this breaks the code signing and is very annoying.
Should be in the next few days. We are soliciting more feedback on the build from Cloud preview partners before we declare it stable. The more partners that participate in the preview channel, the faster we can graduate builds to stable.
v6.9.21870.6964 has been promoted to stable and is available for on-prem and cloud partners. This thread should remain open while documentation is being completed.
Make sure to update the uninstall script available at
@Brandon, what's the status on this?The linked script still references old deploy https://docs.connectwise.com/@api/deki/files/21478/controlclientcleanup.sh?revision=1 connectwisecontrol-...app vs screenconnect-...app, for example.
We have sent this to the documentation team for an update. Sorry, no ETA on a resolution
I just built a custom branded pkg installer (10:25 am EST 2/14/2019) from our Cloud Portal and it installed 6.9.21691.6956
Is the cloud installer only available for direct download as of now rather than through our portal?
Also will the pkg installer also be code signed now as it is not currently?
Also it is currently only listed for download at https://www.screenconnect.com/Download?result=5sdfss156d156sfsd156fsd156f
and not
https://www.connectwise.com/software/control/download
Can we have some continuity?
- Verify that your cloud instance has been upgraded to 6.9.21870.6964. Every client installer is downloaded from a particular instance
- The pkg access client is signed
- You are able to download 6.9.21870.6964 stable from https://www.connectwise.com/software/control/download
To clarify, the pkg itself is not signed, but the app it installs is. I don't believe we have any imminent plans to sign the pkg itself
Thank you. There is am issue with our license that is preventing your cloud instance from upgrading. I will get that resolved internally. The link you provided now shows 6.9.21870.6964. in pre release NOT stable. It showed neither this morning.
Well that's still a huge mis step on Connectwise's part. It's one additional certificate to sign the package.
Why would you go through the trouble of signing the app and not the package? What would like me to tell our customers/employees when they receive Gatekeeper warnings which can be very forbidding. And no telling them "its ok to install' is not a valid answer.
Signing the pkg without removing support for customization would be a significant undertaking (though of course you're welcome to create a separate feature request for that if it doesn't already exist).
You could also connect with a support session to begin with and then install the access agent from there; the support bundle is signed, so Gatekeeper shouldn't complain about that.
ConnectWiseControl PPPC.mobileconfig
In case anyone needs it, I've attached a .mobileconfig that you can deploy with your approved MDM/DEP solution.
Here is the outcome of deploying that:
As a heads up if you've signed screen connect with your own developer cert and deployed a PPPC profile this update is probably gonna break that since the app is now signed with Connectwise's cert.
I assume that's self-explanatory and I'm guessing that you may have been impacted unexpectedly. perhaps that is because you have automatic client updates on? If you turn off automatic client updates, then you won't have to worry about this. Simply change out your profile before updating clients. Not only is the cert going to be different, but also the identifiers. The application and changed in this update as well.
Oh yeah I get it and was expecting it (well not today because Connectwise said our instance would be upgraded next week even though it was today sigh...) but I wanted to make sure other people knew as I don't think Connectwise made that overly clear and it might catch people by surprise.
Does having the signed installer help at all when reinstalling on mac Access clients, or do we still need physical access to each machine to re-grant permissions to control again? I'm hoping this means physical permissions only need to be granted on initial install and updates/reinstalls are possible without further physical visits. If not, man... this is becoming a deal breaker.
Hi Brent,
You should only need to physically grant access to the machine on install (or the first reinstall after moving to the release that has the Mojave changes). Any other reinstalls should be possible without additional physical intervention.
Caitlin
I have tested that with success... I pushed this update to a mojave machine, had to re-enable permissions, and then could control. I then reinstalled and it worked without intervention. However, when a new version comes out, will I then have to have physical contact again or will it work as well?
The Mojave improvements we made will persist in all new releases. We'll continue to double check that these improvements remain in good order during our QA process, so there shouldn't be any further problems or the need for you to physically access the machines.
Bad news people, this is now Broken again in Catalina, so upgrade with Caution.
There is a new "Screen Recording" Section in PPPC now that ScreenConnect needs to also be added to, but there is no tool or guidance on how to create a Profile to do it at present.
The addition of this Section also breaks 3rd Party Docks by the way, so if you have one, manually add your Dock software to the new section, or hold off the upgrade until any tools are updated to suit.
I'm going to push to remove this crapware from every Mac that we manage. ConnectWise does not care about the user experience on Macs. If they did they would stay on top of this. They would also create an agent that doesn't activate the discrete GPU on MacBook Pros. That issue has been going on for over 2 years. It's very clear that Apple users are not the priority at ConnectWise.
I posted this as an FYI and warning, it's not connectwise's fault.
Be fair Howie, this security change was unannounced and only appeared in Catalina Beta 6 and that was only released 10 days ago, there is no remote control software on the market that is ready for this yet and I'd imagine 3rd party dock vendors are going nuts to get this fixed for release as well.
Naturally Apple docks and Apples own ARD are exempt from this, for all the good ARD does when devices are out of the office.
these unannounced features trip up everyone on every release, I'm sure Apple do it to nudge people into sticking to all Apple peripherals etc
This update will break many things, and while there is a manual fix, Apple has provided no documentation on how to automate this for enterprises.
BTW if the manual route is ok for you, simply go to the PPPC system preference and tick screen connect or your dock app in the Screen Recording section.
I am being fair. ConnectWise is marginalizing Mac users. Any GOOD developer would download and install macOS Catalina developer beta and begin working on making needed changes their software. It took ConnectWise MONTHS to give us a signed agent that could be whitelisted using a configuration profile. They have not bothered to do anything about how this software activates the discrete GPU which causes excessive battery drain. I can go a whole 8-10 hour day without plugging in my MacBook Pro to power but I couldn't do that if I had Screen Connect installed. I will not tell Apple to change their security settings because I support them 100%. Sure, it's annoying to have to whitelist some apps and processes, but that's my job. It's ConnectWise's job to produce a quality product. They. Have. Failed.
We are currently working on the necessary notaries and signing for Catalina's public release in mid-September.
That's great. I'm not holding my breath waiting for it though. And what are you doing about the issue with Screen Connect activating the discrete GPU? That's not necessary. The Apple Remote Desktop agent doesn't do that and neither do other remote support agents. There is no need to do this. That issue has been open for over 2 years. This is Mac marginalization.
Any chance of getting ahead of this game in future so support is ready before the OS is released?
We don't control when our customers update - and Mac users seem to LOVE updating on release day.
Thanks
Alex
Again, i posted this as a warning for Enterprise/Business people to NOT upgrade to Catalina yet, this is not something within ConnectWise's control and there is nothing for them to fix.
There is a simple Tickbox within Catalina to fix this issue, so Connectwise's software works just fine and as intended, this is a simple addition/extension to the "sandboxing" of any non Apple application that was introduced in Mojave, and like that introduction in Mojave, this one in Catalina was also not announced or documented, it simply appeared without warning in one of the last Beta's before final release, giving Administrators no time to react and no tools or information to react with.
The issue here is that the only Administrative or Enterprise mechanism available to push this setting out to MAC's en-masse has not been documented yet BY APPLE so we are unlikely to have the information on how to create config profiles to do this until after launch.
Bear in mind that the documentation for the Mojave changes came very late, and the only Apple Supplied tool to create proper config files these days (Apple Configurator) still hasnt been updated to deal with the Mojave additions.
A lot of my users WILL upgrade to Catalina because they need to. They're developers. Also, what are we supposed to do with Macs that come preinstalled? Imaging on Mac is dead and a new Mac model will not boot up properly on an older macOS. ConnectWise had the opportunity to upgrade their software but it's obviously not important. I'm going to build the case to abandon Screen Connect for Macs. I have never liked this software anyway. It's poorly designed and it activated the discrete GPU in MacBook Pros which causes excessive battery drain. That alone makes this software bad for Mac users.
OK, even worse news.
Finally got my hands on some apple documentation.
https://developer.apple.com/documentation/devicemanagement/privacypreferencespolicycontrol/services
Sadly it seems the "Feature" actually dubbed "Screen Capture" at the backend, cannot be allowed by policy, you can only deny apps, even though everything is seemingly denied by default. So unless a U Turn is in the works, we can basically upgrade no further than Mojave.
Way to go Apple, will hopefully be the final nail we need to abandon MAC's entirely as the overpriced, overrated, and despite Apple's continued assurances and continued broken promises most definitely NOT Enterprise class products.
Fellow posters,
Not trying to hijack this post, but not sure where else to talk to you guys that have this working...
Do you guys only use ConnectWiseControl via https:<domain>.screenconnect.com or do you all use ConnectWiseAutomate, which has two components, the Remote Agent for monitoring, and the second ConnectWiseControl piece that is basically the same piece that is a part of the screenconnect product?
We have been trying to migrate from the former to the latter. We use Jamf for pushing out things. After ConnectWise started signing the screenconnect.com installer for Mac, things were gravy. However in the ConnectWiseAutomate side of things, I have issues. The mpkg installer from the Automate console supposedly fails to install and gives the following error:
"Script result: installer: Package name is <br/>installer: Installing at base path /<br/>installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)<br/>"
However, the mac shows up in the Automate console and the LTTray icon appears in the tray. In order to install the ConnectWiseControl software, I have to double click control and it asks me to install the control piece of the software. Doing that pops up a PPPC-related request (see below) with ltechagent, even though I've separately put in a PPPC config profile for the path "/usr/local/ltechagent/ltechagent" (see below). It must somehow be running from another path, but I can't find a trace of another ltechagent on the test Mac I'm using.
I have all of the suggested PPPC profile items in place for Bash and the signed screenconnect stuff (all courtesy of mobileconfigs from here.) The additional PPPC I tried to use to get rid of the PPPC prompt:
Prompt I'm getting when I believe ltechagent tries to install ConnectWiseControl:
' "ltechagent" wants to access to control "Finder". Allowing control will provide access to dcouments and data in "Finder", and to perform actions within that app.'
PPPC for LTechAgent:
identifier: /usr/local/ltechagent/ltechagent
identifier type: Path
code requirement: identifier "com.labtechsoftware.ltechagent"
Accessibility- ALLOW
AppleEvents- ALLOW
com.apple.systemevents
BundleID / identifier "com.apple.systemevents" and anchor apple
AppleEvents- ALLOW
com.apple.systemuiserver
BundleID / identifier "com.apple.systemuiserver" and anchor apple
AppleEvents- ALLOW
com.apple.finder
BundleID / identifier "com.apple.finder" and anchor apple
Some questions:
1. Is the Remote Agent installer from ConnectWiseAutomate supposed to install both the LTray/ltechagent and the ConnectWiseControl software?
2. How do I troubleshoot the installer error I see?
3. Is the installer error related to the installer trying to install the ConnectWiseControl software too?
4. If the answer to 1 is no, is there another way to install the ConnectWiseControl automagically without needing to double-click connect in the ConnectWise Automate console?
Hello @Catalina, there is not way to automate the approval of the PPPC Screen Recording option on macs with macOS 10.15 installed. ConnectWise ScreenConnect prompts for this to be approved after installation. On managed devices with macOS 10.15 installed it doesn't look like this installation can be completed without manual intervention, which isn't realistic when managing devices at multiple locations.
Hi ASimm,
Unfortunately, we're at the mercy of Apple and their security decisions. We've done what we can do smooth the process of remotely connecting to Macs, and will continue to look for ways to improve this process as later Catalina versions come out. However, as with Mojave, it is required that some manual intervention take place on the end users machine. However, some users have reported that with Apple MDM you can setup/deploy your own privacy policy that whitelists the application, which allows you to remotely approve the use of CW Control without any enduser intervention on the first connection. There is some discussion of that in the thread above.
Best,
Caitlin
I'm going to push to remove Screen Connect from all of our managed Macs. This is not the first time the ConnectWise has failed to deliver a quality product on the Mac. I asked over 2 years ago when or if you would create a native client for ConnectWise on the Mac so I could stop using the web client. I was told that one was coming. Obviously that wasn't true because I'm still waiting. We need a quality remote support agent, and Screen Connect isn't it. You can tell us not to upgrade to Catalina, but that's a very ignorant suggestion. New Macs will come preinstalled with it, and they will not boot properly from an older version of macOS, if at all. Using the excuse that you're at the mercy of Apple is lame. You have had macOS Catalina since it was released to developers in June. Your top priority should have been to make Screen Connect work. And one more thing... I don't appreciate that I have to reissue my configuration profile whitelisting Screen Connect every time there's an update for it. Why?
We are trying to deploy the ScreenConnect Access agent to our Macs through our MDM but are unable to do so as the pkg is not signed or notarized. Are there any plans to solve this?
I'm not aware of any plans to sign/notarize the pkg at the moment, but a workaround would be to first deploy the support guest client, and then from the Support tab select all sessions and Install Access (though this is assuming that your license allows support sessions)
The current version should be signed. At least it is for us. Also if you deploy through MDM siding should not be a factor (depending on the MDM) as most install software as root which is not affected by Gatekeeper requirements.
Might you be getting hit by PPPC settings that need to be whitelisted? Accessibility or Screen Recording?
The access agent installer is not signed, the agent itself is. Our MDM documentation states that apps must be signed. I just ended up signing and notarizing it from my personal developer account.
Oh sorry the pkg. Correct. Still though most MDMs should handle that. I know JAMF does.
Can someone from ConnectWsie please give us an update on this feature request? It has been 3 years since requested.
Hi John,
The above thread still applies to the situation with Mac. We've signed and notarized as much as possible, but the installer and pkg won't be signed because of the dynamic nature of agents and the customizations possible.
It can be deployed through an MDM. I use Jamf Pro to allow users to install the app on demand from Self Service. I do not push the app out automatically since it would cause the users to see a pop up window requesting permission for screen recording and accessibility. Despite the lack of a certificate this does work. It's when a user has to download the package themselves that this becomes an issue. They see the warning and the installer won't launch unless they right click and use the option to open.
We have been deploying the PKG file with our MDM (Filewave) for a couple of years now. It's just gotten increasingly frustrating to login as an admin so we can see their screen. Many of these systems are remote and thus, not an option. How did you get Jamf Pro to get around the Accessibility and Screen Recording prompts?
The security prompts are part of macOS. Currently, it is not possible to allow the app to have access on behalf of the user. This is the same with any screen sharing app, except Apple Remote Desktop. ARD continues to work perfectly with no prompts. It does tell the user their screen is being observed but it does not prompt.
John,
I deploy through our MDM and I also deploy a custom policy to enable the acessibility permission and to allow the standard user to allow screen record permission for ScreenConnect. Here is the .mobileconfig file so you can do the same: ScreenConnect Client.mobileconfig
This profile allows Accessibility permissions but not the screen record permission. Is it possible to automate this?
Hey Igor, does that profile automagically check off Screen Recording and Accessibility? We use Kandji as our MDM and I can deploy Screen Connect with no problems, but as far as having to check those off its a pain. I got an article form Kanji on creating a PPPC, but it seems SC app identifier is different on every machine. Thoughts?
It only does accessibility, not screen recording so users will see that annoying popup when installed which they will think it's malware :(
Customer support service by UserEcho
