Jump to content

cssinfo

Members
  • Posts

    14
  • Joined

  • Last visited

Everything posted by cssinfo

  1. 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.
  2. So, just confirming, the patch did the trick ! Thanks !
  3. 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.
  4. Oh thanks guys, I didnt see this post. Just applied the fix ! Will give back news as soon as possible !
  5. 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 !
  6. 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 !
  7. Same exact problem here ! the 32bit AIO works perfeclty, but it always fail when i try to do the 64bit ...
  8. 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 !
  9. 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
  10. 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...
  11. 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.
  12. 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 !
  13. 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 : Did the trick for me !
×
×
  • Create New...