bbahes

And the mirror should be able to be hosted on the DEDICATED VM containing the ERA6 server. I don't want to rely on a client mirror or a windows based caching proxy. That's not a problem - you can run the Mirror tool on the same server that is running ERA v6 and update clients from the mirror created by it. Yes. But still it is not commanded by ERA. It's configured with command line utility so the whole process is unknown to ERA. Also it's won't download PCU's.

And the mirror should be able to be hosted on the DEDICATED VM containing the ERA6 server. I don't want to rely on a client mirror or a windows based caching proxy. Actually it's Apache proxy they use, even in their appliance, however it's missing the point and that is that ERA should be in charge of downloading and distributing updates.

They are improving by each release...hopefully they will bring back mirror feature back to ERA where it belongs.

If I have security escalation I will ban all clients from internet access and have only ERA push latest security updates to clients. Waiting for client to do this by him self, and hopefully report back to me, is, if you ask me very risky, especially in security escalation situations. I know you won't change your approach to this subject, but you have to understand implications of your design.

That's the "problem" with ERA 6. It transfers this responsibility to clients. Pretty risky if you ask me. However this won't be changed as ESET pointed this several times.

I have to manually restart so many workstations, is this going to be fixed anytime soon? Anyone?

Hm...so I noticed CPU usage of era.exe went down to 0-5% after I exit ERA Administrator Console. EDIT: Service restart didn't help. EDIT: After some time after service was restarted CPU usage is back to 0-5%. If anyone from ESET support wants memory dump I will send it.

It was idle for few minutes then back on 80-90% CPU

Must have been mirror update...it's now idle.

Since I updated to version 5.3.39.0 I'm having era service high CPU usage...around 80% Any thoughts ? I have memory dump ready.

I was able to upgrade clients to 5.0.2260.x with this release.

Shutdown/Restart could be only way they are able to prevent on-demand scan. Thanks @Gonzalo Alvarez I will give it a try.

No. Still have many clients not connecting to ERA...

Hi! Maybe this topic was already posted, but I could not find one... I have ERA v5.3.33.0 and clients v5.0.2254 and v5.0.2260. When I push On-Demand Scan after short period of time I get message in log "Interrupted by user". What policy rule I have to set in order to prevent user from stopping On-Demand Scans? PS. I have password set in "Windows desktop v5 → Kernel → Settings → Protect setup parameters → Password to unlock". Thanks!

Now I can't wait

Thanks for this info.

Seems you are missing Thawte root CA certificate that should be available in system. Have you updated this system recently or updates are disabled since older ERA release? It's just debian 8 test machine

I've tried it. [root@era /]# openssl s_client -connect edf.eset.com:443 socket: Connection timed out connect:errno=110 This is my output: CONNECTED(00000003) depth=1 C = US, O = "thawte, Inc.", OU = Domain Validated SSL, CN = thawte DV SSL SHA256 CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/CN=edf.eset.com i:/C=US/O=thawte, Inc./OU=Domain Validated SSL/CN=thawte DV SSL SHA256 CA 1 s:/C=US/O=thawte, Inc./OU=Domain Validated SSL/CN=thawte DV SSL SHA256 CA i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=© 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3 --- Server certificate -----BEGIN CERTIFICATE----- MIIEejCCA2KgAwIBAgIQIGl32e02Z73kexiNsGydyDANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMdGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE b21haW4gVmFsaWRhdGVkIFNTTDEgMB4GA1UEAxMXdGhhd3RlIERWIFNTTCBTSEEy NTYgQ0EwHhcNMTUwMTEyMDAwMDAwWhcNMTcwMTExMjM1OTU5WjAXMRUwEwYDVQQD DAxlZGYuZXNldC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG HEYSr1+zpVMbOW0OHPic+AdHQSHc0BuLJHbVqTUC8gG8rE1B2VBz8uKADYWPKI+J LIvL1gqnlp4iU9R+Ihkem8mHNGdxR/OpsQhy3mVPYhNeiE8DuQerABQVro61kg9K 4ix0R37x2It1TDZCYQHXMDrDwRG0AHFNbxhkRBisICk9Dnq6HiSwp8KktNnf6IKV XUMMD36CsotcPd5A5TOpKxcX0JUAbdquKKlZxXwm2KKGNtaaiymsGbDF/sCqZfgC Dj8cHwHFXXlyT3Chlj7EFGcWMQIU+ZOaeAVNDsF31YiqzxuZWiZvnFvGZky1p6BT yCtcObY5GWWVjUvLa4f3AgMBAAGjggFyMIIBbjAXBgNVHREEEDAOggxlZGYuZXNl dC5jb20wCQYDVR0TBAIwADArBgNVHR8EJDAiMCCgHqAchhpodHRwOi8vdG0uc3lt Y2IuY29tL3RtLmNybDByBgNVHSAEazBpMGcGCmCGSAGG+EUBBzYwWTAmBggrBgEF BQcCARYaaHR0cHM6Ly93d3cudGhhd3RlLmNvbS9jcHMwLwYIKwYBBQUHAgIwIwwh aHR0cHM6Ly93d3cudGhhd3RlLmNvbS9yZXBvc2l0b3J5MB8GA1UdIwQYMBaAFH0p MS/BHm6uMQVqs+sczandroCaMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDAQYIKwYBBQUHAwIwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNo dHRwOi8vdG0uc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vdG0uc3ltY2Iu Y29tL3RtLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAM3oYfThOui6KydglWVW1MTgA hGZzd5kkLuJi7tEfbqbhr4Ysa0kGg4cMklMEnbWhhCY5xds8VBcacLmxEG3HZF3j DvmfKlm0hIg0cTS9YCKM83v3n3HK6zIphKNYiNxI4v+a/quFr7Vsj/3vBfToF55o Zcwbn5lB7Q+7rQnu3mnbFx4vWcRs2Fbiqs9JljxOpWgWHoWQmGykUGLdP/vuakLe 4FerbQqVmSnEk7QyabkLbY9556isfa1Z2eMcQcFAdkoSUCyG37i47pGK0yQGxSje Ej/nAtc2J4kXpUgdvXA/AKE+VswfainR05roRijYUew5ogvWzK4AQ49k0tQrgA== -----END CERTIFICATE----- subject=/CN=edf.eset.com issuer=/C=US/O=thawte, Inc./OU=Domain Validated SSL/CN=thawte DV SSL SHA256 CA --- No client certificate CA names sent --- SSL handshake has read 3076 bytes and written 415 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 623958F8E73B0F5AD3F35364281AF16E56E3585051E9FF178993A72D2F9F4A87 Session-ID-ctx: Master-Key: 5879CCBA56B80E53E0A66907C5EF30C0DE812EB25FD037AFACF67983E1DC5D8344FAB7E04A3D47D42565541C1F949630 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 5b 06 e1 22 e4 b9 99 33-d7 ed 72 cc ee 71 30 ee [.."...3..r..q0. 0010 - cd 26 27 e6 aa 39 01 24-26 06 a0 9b f8 6c 91 f3 .&'..9.$&....l.. 0020 - 1c 57 3b de c7 40 c4 fb-cb 73 74 29 6f 88 0d 46 .W;..@...st)o..F 0030 - 24 24 5b ff c3 38 96 bc-03 99 ae 49 b5 8b 22 ee $$[..8.....I..". 0040 - b5 3a 41 10 94 eb 1a 17-94 b9 79 5d df 96 be 17 .:A.......y].... 0050 - 87 a9 6e 18 99 4f a0 e0-22 43 20 56 40 d0 e5 4e ..n..O.."C V@..N 0060 - 3e e6 7f e4 18 29 a6 e7-51 eb ff a9 6c 31 1f 47 >....)..Q...l1.G 0070 - 11 4a 03 4e 3c ce d5 47-d4 1b ef 21 e5 6c 34 b9 .J.N<..G...!.l4. 0080 - 4a 52 ac c9 f6 5d d9 83-30 1e aa 57 da 64 9b 0c JR...]..0..W.d.. 0090 - c2 5a 3f a0 89 59 4e 76-3f eb 6e cb 91 5e 39 ac .Z?..YNv?.n..^9. 00a0 - 82 19 a2 eb 5e ae a5 8b-f0 c4 fc 6a e4 cd d1 a2 ....^......j.... Start Time: 1467035492 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate)

Should not be the case. Client's and ERA should connect directly to ESET servers, my guess is that you have proxy setting configured in policy. In ERA server you mean? It is a fresh new installation... True, not in new installation. Check this post https://forum.eset.com/topic/6230-activating-era-62-error/?hl=licensemodule

Should not be the case. Client's and ERA should connect directly to ESET servers, my guess is that you have proxy setting configured in policy.

From the coloring of ssh client and root user my guess is that you are using virtual appliance? Did you install and configure apache proxy for clients? Check "How do I enable Apache HTTP proxy on my ERA Virtual Appliance after initial configuration?" on: hxxp://help.eset.com/era_deploy_va/62/en-US/index.html?va_faq.htm Correct. As I said earlier I am using a virtual appliance installed on a XenServer environment. No I hadn't enabled Apache HTTP proxy on ERA VA but I did after your post! check configuration: hxxp://help.eset.com/era_install/63/en-US/http_proxy_installation_linux.htm

From the coloring of ssh client and root user my guess is that you are using virtual appliance? Did you install and configure apache proxy for clients? Check "How do I enable Apache HTTP proxy on my ERA Virtual Appliance after initial configuration?" on: hxxp://help.eset.com/era_deploy_va/62/en-US/index.html?va_faq.htm

Maybe because people don't have time to troubleshot your products? I still have problem on 5.0.2260 and 5.0.2254 EES and EAV products. I am waiting for your Internet Protection Module 1256 to see if problem persists.

Is there a web page where I can follow module, database, product versions, or subscribe to be notified when new versions are released?

Still having problems on few clients. I was able to walk to one of them, restart and everything works now. I could get memory dump from few clients that have this problem but they are up and running almost few days...to I'm unable to give memory dump from the moment problem started. Might I just add one comment, some of these clients are able to download updates but they don't report to ERA.