Can anyone tell me the difference between super agent and agent handler in details.
Your question has already been answered in this thread. If you have a question or concern relating to your specific situation, please provide sufficient detail to allow us to assist you.
As previously explained, for remote systems, you need an agent handler in a dmz so those systems can reach epo, not a superagent, as that is only a repository. KB66797 is the kb for required ports open for communication.
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Apologies for opening this discussion again, but I need some advice.
We are building a separate environment in our DMZ with a handful of workstations and servers. We need to manage these endpoints with a number of different policies. And at the moment, they have no agent installed.
I was looking to install a super agent relay onto one of the DMZ servers, open the ports and use that as a go between for the endpoints and ePO server. However, when putting this past McAfee, they advise that an Agent Handler is the only way forward.
I cant see why a relay wouldnt work. It seems like a simple path for my endpoints (in the DMZ) to pick up agent installs,VSE, policies etc via the Agent relay.
Can anyone advise if this is a good approach or why an Agent Handler would be better suited please.
Cheers
It may have something to do with the port setting. Meaning, relay server seems to only use 8083/UDP to establish communication; while Agent Handler uses a host of TCP/UDP ports to establish a secure connection back to ePO/SQLDB
Ports needed by ePolicy Orchestrator for communication through a firewall Technical Articles ID: KB66797 Last Modified: 11/10/2016
I have a feeling it has to do with how the policies get distributed. The way I understand it, an Agent Handler is more than just a distributed repository; it can handle policy and wake-up requests on behalf of the ePO server. An Super Agent is just a repository that can server files and trigger wake-ups; I don't believe it can hand out policies, and the systems would actually check in back to the ePO server. Since your DMZ systems wouldn't be able to talk back to the ePO server, there's nowhere to get that info.
Hi,
Yes, You explained openly differences Agent Handler vs SuperAgent.
Also this is important that "The agent handler requires an always-on, low-latency (<10 ms) connection directly to the SQL database. Most environments will be fine with no additional agent handlers, unless there is a desire for DMZ communication."
So, we have one more question that How can we control remote clients that no connection with ePO server?
regards,
Replying via airplane. Used other posts for simplicity and added comments as needed.
1. Super Agents w/ Lazy Caching - Super Agents is simply a feature of the McAfee Agent that when enabled allows select endpoints to serve content from the Master Repository to endpoints. Lazy Caching means that instead of synchronizing content on a set schedule, the agent will request content as it is needed.
2. Super Agent Distributed Repositories (often called SADRs) - You can designate systems to be Distributed Repositories and the master repository in its entirety will be synchronized to these systems. It is then possible via McAfee Agent repository policies to point systems to the appropriate distributed repository either by a set list, or based on ping times. Use this when you are in bandwidth sensitive locations. Instead of getting content from the ePO server, will be a system close to orhers in order to provide content, likely to be on the same segment.
3. Agent Handlers. The ePO application server is an agent handler. The Agent Handler service is a separate service from the ePO web application. It runs Apache and faciliates connectivity to the ePO database and is reponsible from consuming agent events and translating them into SQL inserts. The Agent Handler service is also a "proxy" of sorts to the master repository on the ePO server. When an agent checks in to the agent handler and requests a package, that package is delivered over HTTP via the Agent Handler. Agent handlers should be carefully placed. The handler should have a similar latency as the ePO server has with its SQL db backend. The agent handler requires an always-on, low-latency (<10 ms) connection directly to the SQL database. Most environments will be fine with no additional agent handlers, unless there is a desire for DMZ communication. These are overused and not well understood.
This is a starting point. Check out the guides for more info.
New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.
Thousands of customers use our Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership: