Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by terrum

  1. Looks like the new version was released on 22/03/2016, why no update here? Is it not official version? Thanks, Terrum
  2. Thank you, that's the answer to my question! You don't see anything in return to "wmic qfe get hotfixid | find "KB2664888"", because the hotfix is actually not installed! According to the KB, two service branches exist - GDR and LDR, perhaps for some reason, your first computer got the LDR version of the netio.sys and the second computer got GDR, though I have no idea why would that happen. What you can try now is uninstall 2957189 from the second computer and re-install it again. Or, if that makes no difference, after you uninstalled 2957189, get the 2664888 hotfix installed fir
  3. According to the kb, hotfix updates netio.sys to 6.1.7601.21991 (on SP1, x64). On my system the version is higher - 6.1.7601.22648, so I guess this is why the hotfix won't install. Most likely at some point another update has installed this newer version of the file. I don't see the freezing issue in my environment as well.
  4. The hotfix is not installed in my case and yet I'm not able to install it. I'm running a correct version of the hotfix ("Windows6.1-KB2664888-v2-x86.msu" on a 32bit system and "Windows6.1-KB2664888-v2-x64.msu" on a 64bit system), but very time getting "The update is not applicable to your computer" error. About my system: C:\>systeminfo | findstr /B /C:"OS Name" /C:"OS Version" OS Name: Microsoft Windows 7 Professional OS Version: 6.1.7601 Service Pack 1 Build 7601 C:\>wmic qfe | find "KB2664888" C:\>wmic qfe get hotfixid | find "KB2664888" C
  5. I don't see this issue on my computers, but out of curiosity I downloaded the hotfix KB2664888 and tried to apply: On Windows 7 SP1 32bit I run Windows6.1-KB2664888-v2-x86.msu and on Windows 7 SP1 64bit I run Windows6.1-KB2664888-v2-x64.msu. In both cases hotfix install exiting with "The update is not applicable to your computer" error. Same story on any Windows 7 computer I tried. Most reasonable explanation I can think of is that my OS patch level is higher than the hotfix was designed for. Another ideas?
  6. We've had a case when the issue occurred with EFSW 6.2 that was using some v4.5 drivers. Please supply me with the output from ESET Log Collector so that I can check if all drivers are correct and loaded properly. Marcus, thanks for looking into this. I sent you a pm with a log attached (zip archive).
  7. No, I haven't. I'm pushing hard on an idea to get rid of all Win2003 servers, so this bug in v6 isn't a priority for me. I'm keeping v5 on them until decommissioned. Terrum
  8. Thank you, I guess that was the cause. I think it wouldn't harm to add a mechanism in ERA Server which would recognize Agent upgrades even when a method other than ERA Component Upgrade task was used. This is really a basic feature many will benefit from. At least make it available so that one can use it when required to avoid the duplicates. Thanks.
  9. I've upgraded ERA Server (VA) to the latest version All internal server components are up-to-date. Next, I went ahead with upgrading ERA Agent on Clients to the latest version ( -> and I used a GPO method as described here to deploy the new Agent. Everything works great on the Client side - the new Agent gets installed after reboot, however, in ERA Server I'm getting a duplicated record created for each Client that was upgraded. The new record appears in the "Lost And Found" folder even though there is already existing record with exactly same name, same MA
  10. EFSW 6.2 (build 6.2.12007.0) was recently released as well, however it seems that the specific issue reported here was NOT resolved yet. I tested the new build on a Windows 2003 machine (a file server) and confirmed the same bug exists as in earlier 6.x versions: when EFSW 6.2 running on the server (Network Drives Scan: OFF), double click or right click on an MS Office file (for example .doc) takes at least several seconds until anything happens. After removing 6.2 and installing back 4.5 (Network Drives Scan: OFF) - the same operation on the same file takes no time at all! I'm lost at fig
  11. Hi Tomas, It doesn't work, this is what I'm getting when I click: "404 error We are sorry, the page you requested cannot be found. Go back or visit the Online help landing page to continue." Is there other link?
  12. So if the "ERA Component Upgrade" task only updates select components, leaving Tomcat and perhaps other things behind, would you recommend a fresh install of a "new" ERA 6.2 VA and migrating settings and clients from the "old" instead of doing in-place upgrade? Where from the new ERA 6.2 VA bits can be downloaded? It seems a working link hasn't been posted anywhere yet. Thanks.
  13. According to the latest ERA 6.2 release notes and corresponding ESET Remote Administrator Online Help, it is now possible to migrate ERA Policies from 5.x to 6.2 with Migration Tool 6.2.x. However, the links to the tool haven't been updated and only old version of the tool can be downloaded (which can't migrate the Polices). Please update existing or post a new link where Migration Tool 6.2.x can be downloaded from. Thanks!
  14. If you're using ESET ERA VA, there is a way to import and use a proper SSL certificate with ERA webconsole without generating a new csr (the cert should have a matching SAN record for the url you will be using to access the webconsole): 1. Export a certificate in PEM format as well as its private key from the server where from you created a csr (or from any other server as long as it has a matching private key). 2. Export your intermediate CA certificate in PEM format. If applicable, export your root CA certificate as well and merge both in one PEM file (it's a human readable format, so y
  15. Apparently this issue wasn't addressed in 6.2 - I upgraded my ERA VA to 6.2 yesterday and I still couldn't use Chrome to login because of the weak Diffie-Hellman key error. Someone was very kind to post is a simple fix here, but it remains unknown why ESET didn't do it in the first place. The fix is basically one parameter added to the /etc/tomcat6/server.xml, see the post for more details: ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WIT
  16. I had trouble access my ERA on virtual appliance running tomcat with a signed cert, my google chrome told me my diffie-hellman key was weak. I did this to my server.xml I added following line: ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA" To the connector block in server.xml so it became like this: <Connector port="8443" protocol="H
  17. I configured Components Upgrade task as described in this guide: hxxp://help.eset.com/test/era/6/en-US/index.html?component_upgrade.htm, selected my ERA VA host as the only target and start time - ASAP. The task started shortly and in a few minutes I got my ERA VA successfully upgraded to 6.1.33. As the guide says, Rogue Detection Sensor must be upgraded manually, ERA Linux upgrade instructions will give you a hint on how to do it: hxxp://kb.eset.com/esetkb/index?page=content&id=SOLN3670 Here is a quick recap to save your time: Download the RDSensor-Linux-x86_64.sh latest buil
  18. Thanks. The guide didn't make me 100% confident that this Components Upgrade task and all the steps as described is the right method to get your ERA Server VA self-upgraded to the new version. I will give it a try tonight. The guide says that ERA Rogue Detection Sensor must be upgraded manually, so when I upgrade my ERA Server VA to the new build, what do I do next to upgrade the Rogue Detection Sensor component? Anton
  19. Please provide a step-by-step guide on how to upgrade ERA Server Virtual Appliance 6.1.28 to version 6.1.33. Thanks!
  20. If you want to deploy the Agent - yes, it will select the correct version for you, but if you want to deploy the EEA on your clients - it will not. Example: In ERA create a client task to deploy EEA and select a 64-bit package (only one package can be selected). Assign the task to a group of workstations running a mix of 64-bit and 32-bit Windows clients - EEA will fail to install on any 32-bit Windows clients. And if you selected a 32-bit EEA package, then EEA will fail to install on any 64-bit Windows clients. It's surprising that ESET doesn't offer a universal package with both 32
  21. Could anyone from ESET please confirm if this is recommended and safe workaround for servers running EFSW v6?
  22. Mark, Speaking about EFSW v6 (the server solution), ESET released a newer build 6.0.12035 on March 31st (it was 6.0.12032 before). Which one do you have on your 2003 boxes affected by the issue? If it is 12032 then you could try the latest build (35) before downgrading the servers back to v5. Perhaps it will have a positive effect in your environment, but I wouldn't expect too much because there was no word in release notes about fixing the issue with files opening very slow over network. Anton
  23. Mark, What v6 build are you running? Is your server a Windows 2003 box by any chance? There is another thread on this forum where the same problem was reported - https://forum.eset.com/topic/4281-files-opening-very-slowly-over-network-from-client-pcs-to-server-after-upgrading-to-v6/ A solution that helped me was to go back to v5 on the affected servers. So far ESET is holding a remarkable silence about this apparent bug. Anton
  24. Thanks for responding here Peter. I'm using ERA v6 VA, how can I collect tracelogs from there?
  • Create New...