Jump to content

bbahes

Members
 View Profile  See their activity

  • Posts

    521

  • Joined

  • Last visited

  • Days Won

    5

 Content Type 

Posts posted by bbahes

    [SOLVED] ESMC logs

    in ESET PROTECT On-prem (Remote Management)

    Posted

    On 9/21/2018 at 9:58 AM, MichalJ said:

    Hello @Pinni3

    First of all, let me apologize for the issues you are having. I will try to comment to individual points, that you have mentioned:

    1. We are not aware DGs are not working. Can you please report specific examples of the conditions that are not working the way you expect? Many dynamic group conditions / expressions are non-trivial and there might be quite basic syntax error. We are eager to understand the problem, and provide either change of the behavior of guidance / explanation.
    2. This is an issue that you have identified, we have fixed it and it will be addressed in the next service release which we are preparing as of now.
    3. This is a known issue, we will address it in the upcoming service release
    4. I do not have enough information about this. Have you reported it here on forum, or created a customer care ticket? Do you mean, that old registry entries are removed, however new are not correctly added, therefore agent things there is no agent (as the information about installed software is extracted via WMI).
    5. With regards to the "appliance being distributed with components we do not support" I assume you are referring to the ODBC driver, as mentioned above, correct? However, without initial update, the appliance should contain the correct driver (at least to my knowledge).
    6. This is correct. Old wake-up-call functionality was replaced by the EPNS. EPNS was created due to our "journey to the cloud" and upcoming release of ECA, where we need to have mechanism that will work also in cases when ESMC / ECA is located completely off premises of the customers. We will examine options whether it would be possible to have both functionalities.
    7. This issue is under investigation. The best would be to report it via official customer care request to your local distributor, as we are still lacking proper data / dumps that would allows us to determine the root cause of the hanged connections. Console do not hang, issue is caused by the new replication protocol, which uses GRPC and permanent connections, which do hang under specific conditions (might be related to the fact that you are using a VMware Appliance, but as mentioned above, we are still investigating this issue, and we will do our best to address this in the upcoming service release). 
    You have mentioned that there is no complete KB? Can you please be more specific? Information about HTTP proxy not supporting authentication for agent-server communication forwarding is listed in the documentation (we will also remove the redundant fields, which were kept there by re-using configuration components).  https://help.eset.com/esmc_install/70/en-US/upgrade_infrastructure_proxy.html
     
    We do have many customers, that have upgraded to V7 without issues. ESET internally runs the V7 for months, far before the beta (that you was part of) started. We are monitoring the forums / support and are working hard, to resolve any real-life issues, that are reported by customers.
    In case you have already upgraded to V7, downgrade is possible, but will be painful, as V7 agent is not able to talk to V6.5 server. You will have to remove older agents, and basically redeploy the 6.5 agents, as 7.0=>6.5 "downgrade" is not supported (MSI will recognize there is a newer version and would quit itself).
     
    Last but not least, the absence of the response here is, that @MartinK is currently out of the office. I would encourage you to contact your local support, as that´s the proper way of addressing problems you might have with the software.
     
    Regardless the issues, I do look forward talking to you later today.
    Michal
     

     

    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.

     

    Outlook not synchronising after deploying EES

    in ESET PROTECT On-prem (Remote Management)

    Posted

    41 minutes ago, Marcos said:

    After installing ESET, the plug-in adds a special flag to all messages in the inbox folder (not subfolders) which may take some time if there are thousands of messages. Had the user been using an older version of Endpoint with integration to Outlook enabled prior to installing Endpoint v7?

    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.

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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

     

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    9 minutes ago, karlisi said:

    I object. In our environment, where endpoint renaming was very frequent, new design never caused any problems for us, rename task never failed. Old design was painful, even when endpoints were identified by network card's id. 

    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.

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    22 hours ago, MichalJ said:

    @bbahes

    Concerning the first point, with regards the OS update. I will let our documentation team know, that we should recommend running OS update after an appliance deployment. Concerning the various errors - those are most probably related to the fact, that underlying components of the ESMC were updated, meaning either DB / or some component needed for server to run was not running (those types of errors are happening when the DB does not respond) - so for example the ODBC driver, or MySQL could have been patched on the backend during the OS run. If you want to know / see what is being updated, In case of appliance I would recommend to enable the webmin interface, and then execute updates of a sensitive system via webmin, there details concerning the installed packages are available.

    Concerning the next points:

    1. Computer name entry in ESMC database is created based on the computer name during the first connection. If the value changes on the client, it´s not updated. This is by design, as the previous behavior that you know from ERA  was criticized by some admins, that they were loosing traces of some machines, after a rename (machine simple "disappeared" as it was renamed, so it was a bit "messy" after some time). What you can easily do, if you want to, is to create a regular "rename computers" task, point it towards a specific group (for example "newly deployed computers" (where the AIO will point towards). So they will then get the correct name, based on the locally reported FQDN.
    2. This is possible. You can have multiple OUs synced into multiple groups. What should be done, is to first rename the computers to correct FQDN (step ) and then configure AD sync task computer collision handling to "move" instead of "skip" or "duplicate". That would resolve your problem.
    3. Consistency issue will be reported to the development team, for adjustment towards the future version of the product.

    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.

    DESLock+ status update

    in Encryption

    Posted · Edited by bbahes

    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.

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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!

    DESLock+ status update

    in Encryption

    Posted

    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!

    Future changes to ESET PROTECT (formerly ESET Security Management Center / ESET Remote Administrator)

    in ESET PROTECT On-prem (Remote Management)

    Posted

    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.

    ESMC_Update_Operating_System_Task_1.thumb.PNG.be8f3ac367fe9cc561768615aa668493.PNG

    ESMC_Update_Operating_System_Task_2.PNG.207672a91eef47ffc16bf864a6dc27f2.PNG

    ESMC_Update_Operating_System_Task_3.thumb.PNG.c5a42bf679c95131af259ae5179e877e.PNG

    After long wait and many errors, ESMC says "Everything is OK".

     

    Begin Upgrading Endpoints to V7 while still using OVA ERA6.5?

    in ESET PROTECT On-prem (Remote Management)

    Posted

    17 hours ago, whitelistCMD said:

    I'm actually having issues with Web Control ever since some endpoints decided to stop reading user data once they received a module update. I can only control and modify about half of our users, even though all the endpoints have no issues receiving the updated policy. When I upgrade them to Endpoint Security v7, everything works again. This is why I'm asking if this is ok. I'm only targeting specific users right now, but I would like to speed up the process since we will be upgrading ERAv6.5 to ESMC v7 at some point.

    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.

    Future changes to ESET INSPECT

    in ESET Inspect On-prem (Detection and Response)

    Posted

    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.

    after upgrade Agent to v7 old Agent is also visible

    in ESET PROTECT On-prem (Remote Management)

    Posted

    10 hours ago, MartinK said:

    Or maybe even better, could you verify this registry keys actually points to ERA Agent: 

    
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\07F21F149AF55F34494F355BE44BEE4C"
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{41F12F70-5FA9-43F5-94F4-53B54EB4EEC4}"

    If so, running "Run command" ESMC task with command line: 

    
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\07F21F149AF55F34494F355BE44BEE4C" /f & reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{41F12F70-5FA9-43F5-94F4-53B54EB4EEC4}" /f

    directly from console on affected clients should clean old registries:

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

×
×
  • Create New...