369 votesStarted · 68 comments · Sophos Central » Endpoint Protection · Flag idea as inappropriate… · Admin →
Work is progressing well on the back end changes. The first access will be via APIs. See https://developer.sophos.com/ for documentation on what the APIs will offer. I believe the APIs will be released and usable by any Sophos Central customer in the next couple of months.
Once the backend and APIs are completed we will start to work on the admin interface improvements (which will use the same API and backend). There is still a lot of work to go, but the current estimate is that the UI changes will start to be released by the end of this year, with us gradually adding capabilities over time. I'll keep this feature request page updated as we go along. Thanks for your patience.
It is difficult to show the policy in effect on a user without being misleading. A user can have more than one device, and those can have different policies.
We plan to improve the device list details page so that, amongst other things, you can see which policies are applied.
We will consider the same changes for the user list view afterwards, though it will need to take account of the device policy complexity outlined above.
For now, I'm going to merge this request into the device details request as it is the primary way we're focussing on this type of request.
Non urgent reboots are not detrimental to protection, so do not create an alert. At the moment they can only be seen in the admin console by looking for the event type on the user, device or event report.
We plan to add more detail to the list views, including whether a reboot is urgently/non-urgently or not needed. I'll merge this request into that request accordingly.
Agreed, this would be very useful. We're working on significant improvements behind the scenes to the "device list views", so that you can for instance add a column about tamper protection to see which devices have it enabled/disabled, and optionally filter for those in one state, e.g. disabled.
We expect this to take several months owing to the nature of the backend changes, but please bear with us!AdminJon (Admin, Sophos Features & Ideas Laboratory) shared this idea ·
238 votesStarted · 69 comments · Sophos Central » Endpoint Protection · Flag idea as inappropriate… · Admin →
I just revised the title to clarify it won't be an "offline" installer- a small amount Internet access/data will still be required. It will mean that the vast majority of data for an install comes from a local source (e.g. USB stick, network share). The Internet connection will be required for the endpoint to register with Central and get policies etc.
We have a team working on this now and the initial estimate is that it will be available in October, though we will of course release earlier if it is ready sooner.
The implementation will be:
1. The installer will have an additional new command line option to point it at a specific "cache" location (local or network path).
2. The installer will retrieve a list from the Internet of the current files it needs. It will first try the local cache for the files it needs.
3. If any files are not present in the local cache it will still transfer them from the Internet. This is to avoid installs breaking if even a minor update has been released since the cache was populated (for most customers, this means within a few hours). In the extreme, it does mean an install would succeed even if the entire cache was obsolete. It also accommodates installing different versions/software components across different Windows versions, where there may not be a 100% overlap in the file set required by previous installs.
4. If the installer has to download files as they weren't in the cache, it will try to put them in the cache so that it is up to date for subsequent installs. If it can't (e.g. read only cache location) then it will just continue installing.
5. The installer will not remove files in the cache; it does not have a way to determine what is not useful to other installs (different OSes, components installed, controlled updates etc).
6. Creating the cache will involve running the installer with the same cache switch on a machine with suitably quick/available Internet (or update cache) access. It will not find any of the files and so download them all and put them in the cache folder- effectively point 4 for all files.
We will also try to find a way to get files to create the cache from an already installed endpoint (i.e. without installing), but have not yet verified if this is possible. We will clarify when the capability is released.
Merging with a thread about a "full" installer.
An uninstall capability (called via command line for when you are replacing a broken install) will be added to the installer.
We are working on an update to the install so that it can use a local copy of the install files rather than pulling them from Sophos. This should be out in the next few months.
To clarify; it isn't strictly an "offline" installer as it needs to connect to Sophos Central for registration, policies etc, but the bulk of the data transfer is usually the install files and it will be possible to provide these locally (e.g. USB stick, local network share etc).
In the meantime please do be aware that there are potential workarounds:
1. Use an update cache on a local server; clients will retrieve the initial install files from it.
2. Use a caching proxy (e.g. if you have 3rd party web filtering you may well be able to use that to cache the files downloaded from Sophos, so that only the first install truly uses the Internet connection).
3. Restrict the bandwidth usage for updates (including installs). It can go as low as 64kbps which should be a negligible impact on even relatively slow connections (like the 2mbps link mentioned below). Although installs will take a long time, they will complete in due course.
We are reviewing this request. Please see the feature request Stefan linked to for updates when we have them
Thanks for raising this. We can see it has a high number of votes and will review the request.
In the meantime, the update cache capability can provide a way to install from a local network source (i.e. avoiding the internet connection/WAN link) in cases where there is a local server. I appreciate that isn't always relevant, but bringing it up for visibility where it does help. If an update cache is present locally, new installs will find and use it automatically.
We already have the concept of sub estates, please see:
Did you mean something different?
I merged a number of similar requests.
We understand that alerting remains a problem area. There isn't a single issue to resolve, but we are gradually implementing the main feature requests and addressing the underlying causes.
The main outstanding requests are:
Reduce volume- stop unnecessary alerts. If the volume was more manageable, then many of the feature requests would be unnecessary or less important. We plan to re implement how alerts are generated as part of an overhaul of status reporting and how it is displayed. this should allow us to be more accurate in generating alerts. Where alerts are genuine (but still too common) we are addressing the underlying issues as we identify them.
Admin responsibility specific alerting, for example an admin only responsible for servers should only get alerts for servers, not for computers. We are looking at implementing roles along these lines, and can add suitable alerting as we do that.
Please note there are some recently completed items that may help:
Group alerts by type (and be able to delete all alerts in a category/ies)
Disable alerts for a certain user (e.g. helpdesk user or person who only needs Central access for generatign reports)
Send alerts to addresses that aren't a Central admin
This is not planned in the next 12 months, but is an important candidate for after that.
Please note that in the meantime we do offer federated auth with AD and second factor support.
We will have a new release of the ADSync tool before the end of June that will allow syncing of devices and device groups, protected computers will not be removed from Central but unmanaged/unprotected devices will if regular syncing is setup.
We're planning to make device deletion reversible (i.e. mistakes can be undone) in future. Until that point we do not want to automatically delete devices, as mistakes require a reinstall of the machine(s).
Admins can manually delete machines, and we have a backlog item (note: currently not planned) to offer some canned filters of the devices list view to allow easy selection of devices on/offline for different periods of time. For example: filter for machines offline >30 days, then select all and delete.
For those (such as MSPs) with access to the Partner Dashboard, please note that as of last Saturday (8th Dec 2018), it now has the ability to set up policy templates to use across multiple Central accounts (customers). So for example you can have 2 Threat Protection policy templates, one for "regular" servers and one for AD servers with AD related exclusions.
We plan to bring this to to the Enterprise Dashboard in 2019.
The customer admin console has had a "clone policy" capability for some time so it should be easy to copy an existing policy within an account.
We don't currently have plans to add a bulk import feature to the customer console (or either Dashboard) but we can review this.
I appreciate there are numerous reasons to need to add exclusions but please do be aware that we have automatic exclusions to cover some common apps, such a some MS Exchange and SQL versions:
So, you may find you do not need to add all exclusions, particularly ones you had in SEC (the on-premises Sophos management console), which did not have these automatic exclusions.
It may also be the case that a given exclusion isn't needed, for instance it was needed for another security vendor, or was needed to address a bug now resolved. I appreciate it is hard to know what exclusions aren't needed, but something to bear in mind as a potential typing reducer!
Darryl Richardson (UK TSAM) also asked for this: "I have an existing EPA customer who’s interested in migrating to Cloud Endpoint at some point in the near future (350 users). They have several offices across the globe and would like to assign an IT admin at each site to be able to amend policies for their region only, as well as having a master admin who has visibility of the entire estate.
I understand this isn’t currently possible with CEA, if a customer buys 100 x CEA for example, they get one management console. The only way I can think of them doing this would be to split the licences across their estate (10 for office A, 20 for office B etc…) which would be less cost effective due to the price breaks.
Is there anything on the roadmap which will facilitate multiple instances of the management console?"
Lee Carass (UK SE) also raised this request: "the customer has multiple regions and wants each region to be able to manage a specific group of machines, with deployment, remediation and policy assignment"