Jump to content

terrum

Members
  • Posts

    34
  • Joined

  • Last visited

About terrum

  • Rank
    Newbie
    Newbie

Profile Information

  • Gender
    Not Telling
  • Location
    Canada
  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 first and only then re-install the 2957189. This is just a guess, it may or may not help to update netio.sys on your test client to 6.1.7601.22648. Oh, and don't forget to take a full backup of you system before you start
  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:\> As you can see, it's a Windows 7 SP1 machine, it doesn't have the hotfix installed but the hotfix doesn't want to install. I tested on a few machines and getting the same results everywhere. Could ESET or anybody who managed to install the hotfix, run the above commands on the computer where the hotfix was installed and post here the output as well as full file name of the executable that was used to install the hotfix, please?
  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 6.2.11.1. All internal server components are up-to-date. Next, I went ahead with upgrading ERA Agent on Clients to the latest version (6.2.171.0 -> 6.2.190.0) 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 MAC, same everything just in a different folder!! The old record becomes orphaned. I have to delete the old record and manually move the new record from "Lost And Found" to the correct folder to get things back to normal. I'm curious if anybody else noticed the same. Any ideas why this is happening and how to prevent it? Perhaps a setting in ERA Server or something else that can help to avoid the duplicates? Thanks!
  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 figuring out why this hasn't been fixed yet, as the issue is easy to spot and can be reproduced at will at any time.
  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 you can open it in notepad). Be careful not to change anything and don't add any empty lines, do copy all and then paste into a new file, first the intermediate cert and right below it the root cert. Save the new file in PEM format too. Note: You can skip some or all of above if your public certificate provider allows you to download one or all of above directly from them. 3. Now convert the cert and the key into PKCS#12 container (install openssl if you didn't do it already): "openssl pkcs12 -export -in mycert.pem -inkey mykey.pem -out myserver.p12 -name tomcat -caname root_ca -chain -CAfile cacert.pem" Parameters used: mycert.pem and mykey.pem - your cert and the private key (see step 1) cacert.pem - intermediate and root CA combined (see step 2) myserver.p12 - the PKCS#12 container you need to take to ERA VA (root user home folder will do) 4. Open putty and login to ERA VA as root. Run the following command: "keytool -importkeystore -deststorepass mypass -destkeypass mypass -destkeystore keystore.jks -srckeystore myserver.p12 -srcstoretype PKCS12 -srcstorepass p12pass -srcalias tomcat -destalias tomcat" Parameters used: mypass - a password to protect your certificate and the private key stored in keystore p12pass - a password you entered to secure the PKCS#12 container (see step 3) myserver.p12 - your PKCS#12 container (see step 3) keystore.jks - your new keystore container 5. Copy the keystore file to /etc/tomcat6/ 6. Make a backup copy of the /etc/tomcat6/server.xml somewhere (in root user home for example). 7. Edit /etc/tomcat6/server.xml so that the connector block looks like this: <Connector port="keep your port ### here, usually it's 443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/etc/tomcat6/keystore.jks" keystorePass="mypass" keyAlias="tomcat" /> 8. Now reboot ERA VA and try to login to webconsole - you should no longer see certificate error message as long as the url you're using has a matching record in the certificate's SAN list! Kudos to alexkasko for posting an example here
×
×
  • Create New...