Not long ago I build a new ePO 5.3 server running Windows 2012 R2 to run alongside our existing 4.6.8 and we will migrate clients in time. Part of that process I also created some other servers to make into SuperAgent repositories, again also running Windows 2012 R2 on VMWare.
My problem is that every day for the past few weeks, at least one, but can be several of the SuperAgent repositories disappear / go offline. By this I mean the repository will not show in the distributed repositories chart and list. Other times, in the Repository policy within ePO, that repository will move to the bottom of the user defined list (which we use) and go into a disabled state. There has also been a time where the repository folder (set to D:\AntiVirus\ePOSA in the ePO policy) appeared on the C drive. There are times where the clients fail to update saying they cannot find the catalog.z file (checking the folder on the SuperAgent I can confirm that file is missing) and other times the clients fail with unable to find a valid repository.
Then today, after removing the SuperAgent policy assigned to a server, uninstalling the agent, reinstalling the agent and assigning a newly created SuperAgent repository (this time the path is set to C:\AntiVirus\ePOSA) all seemed to be working until an hour or so later the repository again disappeared. Logging into the server in question, I loaded the agent monitor and when clicking "collect and send props" after a few seconds a red line appeared saying "Agent failed to collect properties".
I have been using ePO since version 4 and never had this problem. I appreciate there are a lot of different problems described in this post but I'm convinced they all point to the agent installation on the SuperAgent. The agent installed is 18.104.22.168. Is there something I am missing, something I have overlooked?
If anyone is able to help, I'm more than happy to post log files to help identify the fault, just tell me which ones.
If it helps, the ePO database is SQL and is on a separate server. We have 2 agent handlers, the ePO server itself and one in the DMZ. I believe I have set these up correctly but maybe worth checking with someone.
I have started eriencing exactly the same issues and I now have over 100k endpoints trying to update from HttpMcAfee as all my SuperAgent repos have gone dead with all the same symptoms as yours. Also, I have the macmnsvc process running at constant high cpu on the affected SA repos. Must be a link here and Lazy Caching has been cited in other posts.
Next step for me is to drop Lazy Caching and see if straight replication will fix it.
The only "cure" to date has been to do the following:
1. Remove lazy caching and go back to replicated repositories.
2. Reinstall the agent. This drops the CPU usage back to normal.
3. Reduce the frequency of endpoint content update tasks. It is a tricky one this as it can be that you need to go longer than a passing mobile user would be logged in and they can miss updates.
I have seen the number of agent connections going higher and higher but the SA agent does not appear to be working at any speed and does not use more than a few kb of network bandwidth per connection. Connections time out and endpoints cannot obtain their updates, move on to the next SA and finally end up at HttpMcAfee.
All versions of the V5 agent seem to do the same. It's a much more complex product but perhaps too smart for its own good?
Sorry for not replying to you sooner but had some time off work on leave. I would say it’s nice to be back but ....... 🙂
Not long after posting this deleted the SA and recreated them as UNC repos. I had to get it up and running ASAP as it was causing problems for us.
It’s nice to know I'm not the only person experiencing these problems with SA's not working. & Isathiya did you get your SA's working again by turning off lazy caching? I want to give it a go but doing so will disrupt staff so if you say it worked for you, I’ll feel happier to give it a go. @