bbahes

Yes, you can create installer that has policy included. But did you upgrade v5 server to v7 leaving policies intact?

Have you used policy from v5 during upgrade or did you create new policy?

Ah, after searching your main site I found this https://www.eset.com/int/about/newsroom/corporate-blog/corporate-blog/esets-response-to-nss-labs-advanced-endpoint-protection-test-results-3/

Can someone from ESET comment on this: On September 18, 2018, NSS Labs filed an antitrust suit against CrowdStrike, Symantec, ESET and the Anti-Malware Testing Standards Organization (AMTSO) https://www.nsslabs.com/blog/company/advancing-transparency-and-accountability-in-the-cybersecurity-industry/

Hi! Regarding "upcoming service release" do you have public information (web site, release note notification subscription) on these intervals that you share for customers? For example: 1. By the end of each month service release for endpoint products 2. By the end of each quarter (Q1/2018, Q2/2018, Q3/2018, Q4/2018) service release for management products (I'm thinking maybe endpoint products need to be prepared for changes for service update of management products) 3. Every six months feature update for management products etc... I know you have monthly Customer Advisories that you send by e-mail, but It seems to me that this is only informative. Correct me if I'm wrong, you send this newsletter month after changes have been already pushed to users? For example, https://support.eset.com/ca7027 Modules Review for August 2018. was released on September 18.

No new issues. v7 is better than v6. That is why we are planning upgrade from v5 finally.

You are biased. ? I would say 5. Testing and looking for user topics on forum that have problems.

Had that been case, would it make any difference? I ask because we use v5 and plan do upgrade to v7, with users having large inboxes.

Description: Policy revision Detail: It would be very welcome feature if policy had revision tab, so we can see what has changed over time. This revision tab would, if implemented, allow us to see all settings in tree view. At the moment we have to go to policy and drill down entire policy to get a look what settings we had in previous policy. Maybe this has already been requested in different form, like I had previously in this topic

I've noticed they have this task out of the box:

@MichalJ could you provide more information via PM, since this information could be turning point for my managers in decision to move entire security suite of products to third party. Thanks!

Can you tell me which option you changed? I use several Synology NAS models.

Just for info. I have reverted VM to working state and completed wizard.

Hi! I'm testing deployment of ESMC v7 on Hyper-V. After initial login i had problem with timeout: After I closed startup wizard I logged off and issued shut down from appliance console. I added more virtual CPU (from 1 to 4). After I powered on VM and I try to login I get this message:

I would prefer if in future releases they automate this internally. I know about this problem in old releases but we have policy about who does what and when so we did not have this problems with v5.

This is big flaw in design and you should revert back to old one. If some organizations have problems with endpoint control, internal organization it should not have been reason to fix these problems with product philosophy. If for some reason endpoint is gone from ERA, than this is mayor security incident inside organization, that should be addressed in other way with internal policies or procedures. This design leads to many potential confusions in reports and management if situation would arise that endpoint was renamed and rename task fails.

Basically, managing endpoint encryption from ESMC would be desired result. A single familiar administrative interface with familiar philosophy, not separate product. Yes FDE is main feature we desire from DESLock+. Preboot login mask is also something that would go handy with FDE.

Description: Consistent licensing/display with regards to renaming endpoint Detail: I'm testing ESMC v7 and Endpoint v7 and I see different results when: 1. Rename client (hostname) on client itself We use All-in-one installer for clients. They are installed when computer has generic name (in case of Windows 10 that is something like DESKTOP-0LALO37). The Endpoint and agent install and report back to ESMC successfully. If we then rename client (technical staff, by either on site or via remote support VNC) to something else we only see change in FQDN property. However in list it lists old "Computer name". 2. Active Directory Sync task. Which brings me to Active Directory sync task. Since we are transitioning from workgroup to active directory we would like to sync list of computers and servers from different OU in Active Directory do different static groups and maintain that list. We have in place task that syncs Lost and Found static group with test Active Directory OU for Computers. But when task runs it "syncs" list in a way that in only adds "new objects" to ESMC list of computers. So now we have PC's with old "computer name" and PC's with new "computer name" in list. Would it be possible to have Active Directory maintain authoritative list of computer object? If this is possible in current product I have not found way to do it. Please advise. Also, if for some reason we rename endpoint it would be very nice for that name to be truly synced in ESMC list with Active Directory for security team to have complete list of workstations. 3. Rename client (Description Name?) on ESMC Which brings me to client rename task. I don't see purpose of adding task that, as far as I am aware of only purpose is to rename object inside ESMC database. I consider it handy in case you have true sync between domain and ESMC. Also, naming convention should be consistent with selected object. In Lost & found you list COMPUTER NAME, yet in Actions (when "object" is selected) you display "Rename multiple items". If "Computer name" is select it would be sensible to write "Rename computer name list" or something more meaningful. Correct me if I'm wrong I see that you use ESMC "Computer name" throughout ESMC (tasks, etc..)? For us, desirable result would be to have single name for object inside ESMC which is FQDN that is synced either with client (workgroup) or Active Directory. If for some reason you find this is not feature request or rather candidate for support, feel free to move post to correct forum. Kind regards!

Hi! We are evaluating DESLock+ for endpoint encryption. One thing that we want to know is do you have plans to integrate DESlock+ features in ESMC interface/product line? In the end, we seek integrated solution, like some third party vendors offer, so that we can control endpoint encryption from familiar environment like ESMC. Thanks for reply! Regards!

Description: Update First steps and best practices Detail: May I suggest that you update your help documentation or somehow automate this step, that when ESMC server is first launched, Update Operating System Task is one of first things to do? This is mainly because Alerts are shown "Operating system is not up to date". Also, I'm guessing, it's best security practice, since it's security product. Would you agree? Also while on this subject: Description: Task executions - more details would be welcome Detail: I have started Update Operating System task via context menu. However, I don't see any detailed status as to what is being updated or possibly status of any error. It would be nice to have console log (virtual appliance) presented while this task is executing. After long wait and many errors, ESMC says "Everything is OK".

This is something we cannot afford and loose control over clients because of update. We will however test clean install, since we really want to move to v7.

I would wait in your place if everything works within your environment. Read posts here about problems with upgrades before you do. My company is still on v5. We hoped to move to v7 but as we see problems with deployments and upgrades we postponed upgrade.

Description: Linux version Detail: We use a Linux-based server to minimize costs and I think ESET should make a version of ESET Enterprise Inspector for Linux. Detail 2: Also, we don't want to pay Windows Server licenses for security products. Description: Cloud version Detail: Managing on premise equipment, patching and monitoring on premise software is costly and time consuming. At minimum you should have Linux version, at best Cloud version.

Shouldn't this be run in upgrade procedure and not by user/admin alone?

We are still on v5 and waiting for v7. The problems I see users have with v6 are not worth upgrade. As for v7, it has cloud version that we are testing and given results will still wait for few minor releases to be sure it's production ready. Kudos to people who developed ESET v5 Business series!