Now that hundreds of users are working from home, need a way to reinstall and/or fix failed Sophos installs

I doubt there is a way to get endpoints to reinstall from Sophos Central as Sophos Central doesn't have the domain level access that SEC has. Without any Sophos software on the machine I can't see a way that they would be able to push an install that doesn't require domain access that they don't have.

There shouldn't be a need to boot to safe mode to disable tamper protection every time something goes wrong.  The tamper protection password should still work in most cases and can be disabled either through Sophos Central, Sophos User Interface, or command prompt/PowerShell.  If you have a tool similar to LiveResposne that grants you command line access to your machines you should be able to do all this remotely without interrupting the user.

The client already can download its full setup and install updates, policy, and then report its status to Central, so why not take it a step further and let it completely reset itself on a bad status? Why should I have to manually go looking for it, disable tamper protection in some way, then do some sort of maintenance? I have thousands of computers. Fixing issues like this is a pain. In SEC you just dragged the problem computers into another policy folder that re-ran setup until it was installed. Central was such a huge step backwards in this regard, IMO. Love the protection it gives, though. No complaints there.

I didn't mean to make it sound like tamper protection was broken system-wide. Most work as expected, but if there's one with a bad status, it could be some version of: setting the slider to "off" in Central works, off slider doesn't work but admin code can be input on endpoint and tamper protection can then be disabled, or neither work and the computer has to be booted into safe mode to disable tamper protection. I've tried resetting the tamper code, using any previous code, etc. Nothing works except for the safe mode option when the first two don't.

We've dealt with the hassles for the last few years after moving to Central because we love the protection and the level of control it gives us for our users, but the exploding number of remote workers we now have has really drove home, at least to me, what a pain Central is on the administration side. Especially when things go wrong. 

Hi Robert Russom 

I definitely understand your concerns, but there are several reasons when the endpoint reports bad health status. The Sophos Health Service is responsible for creating the registry keys under HKLM\Software\Wow6432node\sophos\Health\Status. The MCS Agent Service reads these keys to report the Health status. Please check this article to check and resolve the issues related to "One or more services not running" issue. Many of the times it does require in-depth troubleshooting to resolve these issues( might be the permission issue in writing the values or reboot required after the version update)

• Sophos Endpoint: "One or more Sophos services are missing or not running."

For tamper protection password recovery, you can also check under the recover tamper passwords tab if the devices are deleted. Also, now we have SophosZap tool which is a last resort command line clean up tool focused on uninstalling Sophos Endpoint products to revert a machine to a clean state. Kindly find more details here. 

I would suggest you post your valuable suggestions at feedback forum so that our product management team can have a look into it and consider its feasibility in future version releases. 

Hello Robert Russom,

remote workers we now have [...] what a pain Central is on the administration side
central management wherever the endpoint is was initially the big selling point for, then, Sophos Cloud. (Enhanced) TP became "best practice" in the industry. And Central got a lot of added features.

We use the on-premise SESC, several thousand endpoints (Enhanced TP not in use). About 20% are administered (on the OS level)  by IT, the rest by the respective departments. We have practically no issues on the 20%.  On the others we observe that the ratio of problem-endpoints is department-specific. We provide a basic OS-install that departments can use and in "problem departments" even these installs tend to exhibit issues, in some cases almost immediately. This suggests certain software, software installs, or improper handling as the main culprit.

Just to make sure, I'm not Sophos and don't have any inside knowledge, only conjecturing.
Normally an initial install should succeed, if it doesn't the preventing cause should be identified and removed. Workarounds to make it install aren't a good start. Afterwards a healthy install should update and upgrade without any problems (there might be occasional glitches, i.e. transient problems). If it doesn't (even after a reboot) then it's either some rather minor thing that has to be resolved before an install can succeed (e.g. a Windows Installer process that's hanging, incorrect permissions) or an infrastructure (Sophos or Windows) problem.
In the former case repeated (re-)install attempts seemingly solve the problem, but might hide an underlying systematic problem. In the latter case reinstall attempts wouldn't work at all and reliably fail and consequently result in a reset/reinstall loop that, apart from the performance impact, would not only leave the endpoint unprotected but might render it unusable. One can't simply reset or remove applications that have privileged (SYSTEM) components - other than by reinstalling the OS.
In short - if a client isn't healthy it's an exceptional situation that doesn't lend itself to automatic correction.

At least in theory MCS could schedule an install. This hasn't been implemented with RMS for various reasons (not the least because it will lead to the request scheduling should be reattempted when the first attempt fails ...) and as said situations where a reinstall is required should be rare, let alone one without prerequisite actions.
BTW: With SEC you have nevertheless to initiate a reprotect manually.

Just my two cents,
Christian

Hello Robert Russom,

remote workers we now have [...] what a pain Central is on the administration side
central management wherever the endpoint is was initially the big selling point for, then, Sophos Cloud. (Enhanced) TP became "best practice" in the industry. And Central got a lot of added features.

We use the on-premise SESC, several thousand endpoints (Enhanced TP not in use). About 20% are administered (on the OS level)  by IT, the rest by the respective departments. We have practically no issues on the 20%.  On the others we observe that the ratio of problem-endpoints is department-specific. We provide a basic OS-install that departments can use and in "problem departments" even these installs tend to exhibit issues, in some cases almost immediately. This suggests certain software, software installs, or improper handling as the main culprit.

Just to make sure, I'm not Sophos and don't have any inside knowledge, only conjecturing.
Normally an initial install should succeed, if it doesn't the preventing cause should be identified and removed. Workarounds to make it install aren't a good start. Afterwards a healthy install should update and upgrade without any problems (there might be occasional glitches, i.e. transient problems). If it doesn't (even after a reboot) then it's either some rather minor thing that has to be resolved before an install can succeed (e.g. a Windows Installer process that's hanging, incorrect permissions) or an infrastructure (Sophos or Windows) problem.
In the former case repeated (re-)install attempts seemingly solve the problem, but might hide an underlying systematic problem. In the latter case reinstall attempts wouldn't work at all and reliably fail and consequently result in a reset/reinstall loop that, apart from the performance impact, would not only leave the endpoint unprotected but might render it unusable. One can't simply reset or remove applications that have privileged (SYSTEM) components - other than by reinstalling the OS.
In short - if a client isn't healthy it's an exceptional situation that doesn't lend itself to automatic correction.

At least in theory MCS could schedule an install. This hasn't been implemented with RMS for various reasons (not the least because it will lead to the request scheduling should be reattempted when the first attempt fails ...) and as said situations where a reinstall is required should be rare, let alone one without prerequisite actions.
BTW: With SEC you have nevertheless to initiate a reprotect manually.

Just my two cents,
Christian