Currently in Sophos Central we can add servers to a Test Group and prevent all other servers from having their agent update.
This is completely inadequate. Need to be able to create more Server Groups and be able to update to the new version by server group.

Should be able to download a manual install for the new version and apply it to the servers while Controlled Updates is turned on.

This would allow us to update critical servers at a time of our choosing.

Right now, the option is Update All Servers - This is equivalent to pushing the Nuclear Button, especially if the update requires a reboot.

I tried to rerun the SophosSetup and the SophosInstall with a new update available on my Portal. No luck. Server stayed stuck at the previous version!

Hi,

Somethimes, managing 1000+ or even 5000+ machine its difficult, even more if we don't have built-in features in the console to remediate/uninstall corrupt/broken installations.

But, the main problem is not that. The problem is that we CANNOT disable Tamper Protection remotely to reinstall/remove Sophos AV, in the following cases:

1) Console was erased/failed and there's no cert/db/registry backup (all Endpoint with Tamper enabled)
2) Broken installations dont apply Tamper Policies (to disable it)
3) Migrated console (don't have the old one).

All this would be solved by having the chance to disable Tamper through Command Line. Example

Case A: Failure in console and no backup.

Solution: Create GPO Policy that disables Tamper with script:

@echo off
c:\program files\Sophos\Sophos Antivirus\DisableTamper.exe /password:TamperPassword
c:\installer\SophosReInit.vbs (to use with migration utility)

Case B: Broken instalation:

Solution: Create SCCM colection that does the following

@echo off
c:\program files\Sophos\Sophos Antivirus\DisableTamper.exe /password:TamperPassword

:: uninstall sophos
MSIEXEC /X{blablabla} /NORESTART
MSIEXEC /X{blablabla} /NORESTART
MSIEXEC /X{blablabla} /NORESTART
....

c:\instaler\SophosEndpoint_Newinstaller.exe

I mean, you get the idea. If I get the chance to disable Tamper through command line, it helps me to do more thing remotely without bothering the final user and the admin people.

Not asking to disable all without any proof that I manage the system, but if I do know the password, I should be able to put it, either GUI or CLI, specially the CLI, to help automatize.

Thanks,

Antonio.

While working with Support we provided the SDU logs for investigation. Sophos Support came back and requested some additional files not captured as part of the SDU tool. Please add an option in the SDU to include these sources.

To obtain these files we needed to disable Tamper Protection, and copy the files ourselves.

From Sophos Support:
To further progress, we will also require you to copy, zip, and upload the following directories to our FTP. The reason we require these folders is because they contain the snapshots of the event in a .tgz format which our SDU tool does not gather by default

Folder required:
C:\ProgramData\Sophos\Sophos System Protection\
C:\ProgramData\Sophos\Endpoint Defense\
C:\ProgramData\Sophos\Sophos Data Recorder\ [If this folder does not exist do not worry about this]

After upgrading to Intercept X with EDR there are situations where a Threat Case is not created. Sophos Support mentioned a Threat Case was not forwarded to Central because a root cause could not be found. Even when a Root Cause cannot be identified consider creating a Threat Case so customers have access to the additional context information. Perhaps set the beacon as the root cause.

"Note: Threat cases are only created for malicious detections; this does not include detections for PUAs, Application Control, Device Control, Web Control. Additionally if Sophos isn't able to automatically confirm a root cause, a Threat Case may not be generated."
https://community.sophos.com/kb/en-us/125120

After upgrading to Intercept X with EDR in situations where are Threat Case is not created revert to the pre-Intercept X behavior of publishing the Detection Event as an Alert.

"Note: Threat cases are only created for malicious detections; this does not include detections for PUAs, Application Control, Device Control, Web Control. Additionally if Sophos isn't able to automatically confirm a root cause, a Threat Case may not be generated."
https://community.sophos.com/kb/en-us/125120

We've gotten a number of malicious Events which haven't created corresponding Threat Cases for hosts assigned to the Intercept X with EDR policy. Sophos Support mentioned a Threat Case was not forwarded to Central was because a root cause could not be found. When this occurs the Event is not displayed on our Central Dashboard nor in the Alerts tab. This reduces the value compared to Sophos Endpoint Protection since Intercept X with EDR should provide additional context, and we now must query via the Event Viewer under Logs and Reports periodically.

Hi guys, when Invincea was bought by Sophos I was excited about Invincea's sandboxing feature to be included to Sophos Endpoint Protection.
This however doesn't appear to have been planned.
Useful scenarios include:
- Running unknown/suspicious applications in a sandboxed environment.
- Opening email attachments
- Opening downloaded files
- Manual use by security admins (Specify programs to run in sandbox, or temporarily whitelist a blocked program/file forcing it to run in sandbox for investigations.)

That last one is particularly useful, as we've recently had a case where some emails were flagged by Sophos and quarantined. Sophos would block us from opening the emails, which meant we were unable to investigate the emails in order to create a rule to filter them out.
We had to disable Sophos to complete our investigation, which is very non-user friendly.
Having a simple option of allowing to run a quarantined/blocked program or file from sandbox would solve this issue while keeping the system secure.

Again and again, I find that it is very time-consuming and almost impossible for the end user to fail when installing the Sophos Security VM, especially if the error is due to a failed during SSVM installer. Since the introduction of the Sophos for virtual Environment in Q1 / 2018, we have repeatedly had to spend a lot of time resp. Time lost, because we did not comming forward as fast as we planned! It would be desirable to have errors made clearer and more transparent, at the beginning and not at the end of an installation. Why a test of the TARGET situation is not made right at the beginning of the installation is already somewhat questionable for me. Maybe that would be a point that could be taken into consideration during the next installer development.