This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Connectwise Automate Feedback & Questions.

Please use this space to create a new post for issues you are having if you do not see a post already created for your issue.  We will also welcome feature functionality feedback, enhancement requests, and general questions.



This thread was automatically locked due to age.
  • OK. Some new notes, which are all good -

    1 - when using the Plug-in to make a delete request of a server, it was successful (at the plug-in level) AND I actually saw it report the deletion at the Sophos Central portal about 3 secs later. Very cool!

    2 - I also performed a delete in the other direction (the asynchronous route), which again was successful.

    If I were guessing, the removal showed in the Plug-in anywhere from 20-30 mins later.

    Things I was able to accomplish (and what makes the plug-in great):

    - go through the list of servers and workstations that had Tamper Protection disabled (techs turned off and forgot to turn back on) and put them back to enabled. I had one site that a tech had adjusted the policy to disable tamper protection at the entire site, but the plug-in helped me figure that out

    - find servers and workstations that had been removed from Automate, but not removed from the Sophos Central portal and removed as needed

    - find offline workstations and verify whether they are retired, have damaged installs, and really get the sites cleaned up

  • Hey Christian, thanks for posting back with this.  We're happy to see this is really addressing your needs.  As for the endpoint update times back to the plugin, those times sounds correct.  The plugin has a scheduler that queries and updates the endpoints every hour from application open time.  It sounds as if you made the change about half way through that scheduler time.

    In addition to the scheduler, you have the option to 'Force Update' every 15 minutes if you are waiting on an update before moving downstream to your next items within your process.

  • New issue as of today. We had a client's server getting disconnected from the SQL backend - application support believed it to be Sophos. I took a look at the machine in Automate, and as of 12/1, machines with Sophos on them are having a script run multiple times per day. "Sophos Central Install and Register".  This has come out of the blue - I've not done anything with the plugin at all in the past two weeks since I originally installed and set it up.

    The only thing I can see that calls this script is the "Sophos - Install Agent' Alert template which is being called by the 'Sophos Auto-Register' Monitor set which is picking up pretty much every single machine we have Sophos installed on. 

    Any idea what's going on? Anyone else seeing this? It looks like the monitor set is looking for a service called 'Sophos MCS Agent', but even though it appears in the monitor set as being an issue and not having the service, it absolutely does have it and it shows in the view table correctly.

  • Hi Candace, sorry to hear you are experiencing this issue.  It sounds as though the global auto deploy settings are set from the Clients window.  Could you please private message me your email address, I'd like to set up a troubleshooting call with you, myself, and our SE tech lead for this integration.

    Also, could you please confirm what version of the plugin you have installed and if it's not the latest .133 version, could you download that version from the wiki page and get it deployed prior to our meeting as we've made some changes to the deployment workflow and I'd like to have the latest version running to troubleshoot from.

  • Running the latest 1.0.0.134.

    The log still shows near constant 403 errors with no reasons. 

    The computer pane is currently empty; if I try to force a sync it fails with "Object reference not set to an instance of an object"

    Overall seems like a step backwards in usability from .132

  • Hello Matt, First, let me say Happy New Year!  Thank your for reaching out and I'm sorry you have been experiencing some issues with the latest version.  Could you just confirm for me that .132 was indeed working and now .134 is throwing the 403 errors?

    If this assumption is the case, we have seen this behavior on occasion with a subset of upgrades.  The fix so far, has been to apply the below SQL statement to drop the Sophos tables from the Connectwise database, from within your Connector admin console, and then reboot the machine the Connecttwise instance runs from.  Upon reboot the tables will be re-created and should populate with data once confirmation of the API key is present.

    SQL Command: “drop tables plugin_sophos_central_cls_basic, plugin_sophos_central_cs_basic, plugin_sophos_central_ls_basic;”

    Please do let me know if this corrects your issue or if we'll need to schedule a remote session to further troubleshoot.

  • Thanks for the response. .132 also threw 403 errors, however it appeared to be otherwise functional, computers/locations appeared and could run commands against them. I will give that table drop a try and see what happens.

  • Quick followup, after running the SQL query, I can now see computers/locations again. Still getting a lot of 403 errors though

  • We've made some good progress at least!  403 errors are also typical when you have trial accounts as it attempts to pull the endpoints for those tenants, but then doesn't have the permissions as we have barred trial accounts from API access.  Would you be able to confirm if this is the case?  If so, I have an enhancement on the backlog to better handle this situation.

  • I have 403 errors as well.  From what I've seen it's for accounts that we don't have partner access to.  In a future release I'd like to see it smart enough to recognize this and not try to sync these accounts.  I'd settle for a manual process of de-selecting accounts we don't want to attempt to sync.