We have used SEPM for probably over 20 years, but upgrading has always been problematic as in something always goes wrong, and now support sucks - it is out of India with a two hour overlap of our time zones and very unresponsive and unhelpful. Hence the need for change.
ESET Endpoint protection coupled with ESET Dynamic Threat Defense for analysis of suspicious files in the cloud sandbox (results are shared across your organization and you can set up proactive protection to block files unless a verdict is received). Plus you can also buy ESET Enterprise Inspector (EEI) to monitor operations happening in your network and take preventive measures before an attack occurs or to analyze the attack vector in the aftermath.EEI also enables you to immediately block files in your network based on SHA1.
I made the switch about a year ago from Symantec after they were bought out by Broadcom, and the transition for Broadcom was a mess. I narrowed my search to cloud-based offerings for Sophos, Avast Business, and Bitdefender. I ultimately landed on Bitdefender, but honestly, any of those 3 would have made good choices.
Id go with Bitdefender. Solid, low footprint.
Kaspersky is russia. So if allied with motherland. Why go away from in house server? Is a better way to go, low bandwidth. Just 1 out bound to internet.
We moved from Symantec to ESET approx. 4 years ago and have found the experience to be better in almost every way. From the following standpoints we found ESET worked better for us: Management of the solution, actual protection offered, upgrades and updates, pricing, support, and simply working with them as a business.
RE: WatchGuard, do you have the Total Security Suite? If so TDR, Thread Detection and Response is included in the package. You install a TDR host sensor on your endpoints and manage it from the web. We use TDR in combination with LogMeIn AV (powered by Bitdefender). The number of TDR licenses you have is based on the model of firebox. Why pay for something you may already have.
We are on XenDesktop 7.15LTSR CU4 and App Layering v20.3.0.12. The OS Layer is using Server 2016. I'm trying to layer a new version of SEP and running into two issues that I can't find a solution for. Our old app layer of SEP v14.0.3752.1000 works without any issues.
Issue 1: After installing the new version (v14.2.5...) in a brand new app layer we continually get the message "a reboot is pending to update drivers on the boot disk - please check and reboot the Packaging Machine" when trying to finalize the layer. This is after literally rebooting the packaging machine 10 times. I eventually got around this issue by restarting the uniservice Service.
Issue 2: After publishing the new SEP layer as part of a PVS image i notice that the CurrentVersion folder under "C:\ProgramData\Symantec\Symantec Endpoint Protection" is missing the NTFS junction point to the v14.2.5323.2000.105. The junction point is NOT missing when I first install the new version of SEP on the new layer. The junction point only goes missing when the layer is made part of an image template and the image is published. The old app layer with v14.0.3752.1000 does NOT having this problem.
I have followed the same steps I followed when layering the old version of SEP, using the specific Antivirus/SEP instructions provided by Citrix and other sources. Has anyone else run into these issues?
What I have tried is adding a version to the new SEP app layer. In the new version the NTFS junction is still present leading me to believe that the junction is only lost when compositing a new image. I'll create a new ticket with support.
For the first issue of having to reboot this is because Symantec has changed their behavior. They now will update the file SymELAM.sys on every single boot of the machine. This driver is registered in the services with a start value of 0, which means that it will start at boot time. The code that is blocking the shutdown for finalize will check for changes to files that have a start value of 0 and ask for a reboot out of an abundance of caution. It must ensure that if that file got updated, then we must make sure that the machine will boot correctly before you try to deploy the layer. Thus the reason it is asking for the reboot. Now if Symantec updates the file on every single boot, the code has no clue that it is not supposed to ask for a reboot.
So in this case, you the person doing the install, will have to determine that you have completed the install of Symantec, since the software can't detect it. Typically the install of Symantec requires two reboots before it is done doing all of the configuration that it wants to do. So what I recommend is that you do is follow the instructions in Symantec section for anti-virus support ( -us/citrix-app-layering/4/layer/layer-antivirus-apps.html#symantec-endpoint-protection). Do the two reboots after you finish those steps, and then tell the service that you want to bypass the layer check. This is done by a regedit, and navigating to the HKLM\System\CurrentControlSet\Service\Uniservice and adding a DWORD value called BypassLayerCheck and set it to 1. This is documented here: in the final section of the file where it talks about getting the reboot requests. In this case you can do the override because you as the human know that Symantec keeps updating the same file and that the machine is booting correctly with this updated file and thus you can allow the shutdown.
The Symantec Endpoint Security Suite provides attack prevention, detection and response for endpoints in an organization. It provides a broad feature set including traditional and machine-learning based prevention measures, Endpoint Detection and Response (EDR), application control, and deception technology.
Cynet 360 is a security solution that includes a complete Endpoint Protection Platform (EPP), including Next-Generation Antivirus (NGAV), device firewall, advanced EDR security capabilities and automated incident response. The Cynet solution goes beyond endpoint protection, offering network analytics, UEBA and deception technology.
The log message is expected to be in CSV format. Syslog RFC3164 and RCF5424headers are allowed and will be parsed if present. The data is mapped toECS fields where applicable and the remaining fields are written undersymantec_endpoint.log.*.
Below are samples of some different SEP log types. These examples have had theirsyslog header removed, but when sent over syslog these lines typicallybegin with an RFC3164 header likeOct 3 10:38:14 symantec.endpointprotection.test SymantecServer:
Enhancement View pull request
The format_version in the package manifest changed from 2.11.0 to 3.0.0. Removed dotted YAML keys from package manifest. Added 'owner.type: elastic' to package manifest.
Enhancement View pull request
Use the ECS syslog fields. Added log.syslog.appname and log.syslog.procid. Documented log.syslog.process.name,pid as deprecated.
Bug fix View pull request
Change log.syslog.version field type from long to keyword to align with ECS.
Bug fix View pull request
Parse all times relative to the configured timezone offset.
Bug fix View pull request
Rename group_name in policy logs to group for consistency across log types.