cssinfo
-
Posts
14 -
Joined
-
Last visited
Posts posted by cssinfo
-
-
7 hours ago, Erwin - IT support groep said:
They user that I use should have full admin rights. I used this user to push Endpoint 6.6 for the first time a few months ago. I will use a other user with full admin rights, just to be sure.
I want to deploy the endpoint to a Windows 7 machine. If that machine works then I will deploy it all over the company. Most of the pc's are Windows 7, some of them are W10
I dont know what to say, I just retested an upgrade With these exact paramaters on a client running Enpoint 6.6 + Agent 6.5 this morning..
Maybe recreate a new AIO installer just to be sure.
-
On 11/1/2018 at 10:51 AM, cssinfo said:
Oh thanks guys, I didnt see this post.
Just applied the fix !
Will give back news as soon as possible !
So, just confirming, the patch did the trick ! Thanks !
-
5 hours ago, Erwin - IT support groep said:
@Cssinfo
Thanks for the answer I did this part "ESMC_Installer_x64_fr_CA.exe --silent --accepteula" but that isn't working. If I try to install the all-in-one installer with they hand on the machine, it is working fine. Might there be a problem that I want to overwrite version 6.6?
That is very weird because Ive been upgrading 6.5 and 6.6 client with this package ...
Are you sure your deploy user have total admin rights ? (My deploy user is a domain admin)
What are you pushing it to ? Win7, 8 , 10 ? We are running on Windows 10 1703 and 1803 here, both are working fine with the upgrade.
-
Oh thanks guys, I didnt see this post.
Just applied the fix !
Will give back news as soon as possible !
-
If you are pushing the agent only :
Be sure to include install_config.ini as additional file
here are my parameters : msiexec.exe /i "agent_x64.msi" ALLUSERS=1 /qn /norestart /log output.log
If you are pushing the AIO installer :
ESMC_Installer_x64_fr_CA.exe --silent --accepteula
I included a screenshot of my both of my Package, been deploying this way without any problems !
-
If it can help :
From what I've been observing, each 24 hours I have to reboot the server so it will accept connection from the new agents (7).
But server still accept connection from all computer still running on the old agents (6.5 or less)
Also, when the problem happens the SQL Server process jumps from 700mb - 800mb to 2.7 gb of ram usage and never drops until I reboot the server (around 1200 clients here).
Is it only SQL Express that is too limited for the new amount of data the agent are sending to it ?
Upgrading to SQL Standard would solve the problem ? (More global ram allowed, more ram per sesson, etc..)
In fact , this was my next step of debbuging until I found this post on the forum.
Waiting for news on this !
-
Same exact problem here ! the 32bit AIO works perfeclty, but it always fail when i try to do the 64bit ...
-
Even if client updates itself using proxy, it does not mean it is server cached file, and instead it may be downloaded from ESET servers -> in packet sniffer it would looks like HTTP Proxy is downloading this file. I would suggest you to measure traffic LAN<->Proxy and Proxy<->ESET. In case there will be extensive traffic to internet, slowdown may be caused by your connection to internet.
You are right, I found out that it's looking at the proxy server but in fact the proxy server is downloading it from eset servers ... Why is it doing so ?
I have multiple client downloading the same updates, why is not cached ?
It seems to affect mostly my old clients Endpoint 5.0.2237 (still in the process of upgrading to v6).
We have a 300mbps internet connection wich is fast with every internet service we use and should not be a problem, but I have noticed that every download I make from eset server (even like downloading a package directly from your website) never downloads any faster than 500-600 kb/s while downloading from every other website will run higher than 10 mb/s.
So why are some update are not cached from the server ? and do you guys throttle downloads speed ?
Thank you
Unfortunately caching won't work for older clients (older than v6). There is also issue with v6 that will be fixed soon - but it should not have high impact on traffic.
Well that explains a lot !
-
Even if client updates itself using proxy, it does not mean it is server cached file, and instead it may be downloaded from ESET servers -> in packet sniffer it would looks like HTTP Proxy is downloading this file. I would suggest you to measure traffic LAN<->Proxy and Proxy<->ESET. In case there will be extensive traffic to internet, slowdown may be caused by your connection to internet.
You are right, I found out that it's looking at the proxy server but in fact the proxy server is downloading it from eset servers ... Why is it doing so ?
I have multiple client downloading the same updates, why is not cached ?
It seems to affect mostly my old clients Endpoint 5.0.2237 (still in the process of upgrading to v6).
We have a 300mbps internet connection wich is fast with every internet service we use and should not be a problem, but I have noticed that every download I make from eset server (even like downloading a package directly from your website) never downloads any faster than 500-600 kb/s while downloading from every other website will run higher than 10 mb/s.
So why are some update are not cached from the server ? and do you guys throttle downloads speed ?
Thank you
-
Could you please verify that files are actually server from cache and not downloaded from ESET download servers? This may happen especially for initially downloaded files due to their low max cache time. Nano updates should not be affected as they are updated few times a day.
Yes absolutely.
I even verified with a packet sniffer, each time the eset antivirus ask for an update it goes trough the ip of the proxy server...
-
Agreeing with MichalJ. In the early days of ERA6 (pre-global release) I raised a few "pain point" issues on the forum here. The things I suggested are now standard features in 6.3. If ESET don't know what you don't like, how can they improve?
Very happy ERA6 user for 170 seats across 6 licenses.....
Jim
Same here !
I'm a VERY happy costumer of ERA 6 for 1200 seats across 3 licenses !
From what I read , most of the user complaining about ERA 6 simply didn't read the documentation. They just excpect it to work like ERA 5 without even trying to understand that it's a completely new product.
For my part I think ERA 6 is WAY better than ERA 5 .
But before moving from 5 to 6 I took time to read ALL the available documentation, and the deployment was a breeze.
-
I get the same bad performance on my network also.
I installed ERA 6.3 with the Apache HTTP Proxy on a Windows Server 2012 R2 virtual machine.
I'm a bit disapointed by the performance of the Proxy. From what I have seen it looks like it give only a 500kb/s speed to the clients ...
On my old ERA 5 server, using the bulit-in mirror it was giving way faster updates.
I really like the new ERA 6.x but the only downside is the poor proxy performance.
Is there any settings we can change on the appache proxy to resolve this ?
Thank you !
-
I confirm that the problem is still present with Endpoint 6.1.16.1
Using Office 2011 14.6.4 and El Capitain 10.11.5
However the fix mentioned earlier :
#!/bin/bash
# Restore ownership of user preference files.for preffolder in /Users/*/Library/Preferences; doif [[ -d "$preffolder" ]]; thenuidgid=$(stat -f "%u:%g" "$preffolder")chown -hR "$uidgid" "$preffolder"fidoneDid the trick for me !
Upgrade endpoint 6.6 to 7.0 with PDQ deployment, need help!!
in ESET PROTECT On-prem (Remote Management)
Posted · Edited by cssinfo
You can deploy the new agent with PDQ and update the AV with the ERA web concole