cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Handler Assignments not working

Anybody else having issues with handler assignments not working correctly? I am not sure how long it has been happening but certainly with agent 571. Might be related to bug MA-10728 where connections are not being closed on handlers, but that is a long shot. Support actually cannot even seem to understand my question on this one so I have given up and come here. Basically, we have handler priority assignments based on tree location. There are maybe 10 tree locations defined. We use handler Groups. The assignment priority says

1) go to internal handler group (not including ePO server)

2) go to ePO server

3) go to DMZ handlers

We know it works. WE know our machines are in the appropriate tree location. We restart the agent every day. Still, thousands are assigned to the internal handlers. Most of the internal systems can also see the DMZ servers (either via internal or external route) and approximately 20% of our systems that are internal  have decided to work with the DMZ handlers. This is a pain in many ways. If I reinstall the agent, they typically point at the internal handlers. If I remove the DMZ handlers from the list, the systems talk to the internal handlers (apart from those that can't which are subsequently totally screwed because they can no longer talk to the DMZ handler and because they are on the DMZ, you can't easily fix the darn things). Our agent is typically installed from a package from ePO and contains all handlers. It is possible that only the DMZ could be seen at the initial install point, but it is unlikely and not relevant in view of what happens when you restart the agent or remove the DMZ handlers from the list.

Anyway. Just getting this out there. I don't expect a fix.

Labels (1)
5 Replies
cdinet
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 6

Re: Handler Assignments not working

I can see a problem with agents if dmz is removed and agents happen to be external at some points and can't reach epo.  

To discuss how the assignment rules work - if you have the list of ah's/handler groups, agents can and will use either one in the list.  It is not a top down parsing of the list within an assignment rule, it is a randomization of which one they choose.  How randomization happens, I can't answer specifically, but it does.

If agent connects to handler A, it will stick with that handler unless it cannot reach it.  It must be a failure to connect for it to switch.  If agent attempts handler A and the handler responds with any response code, such as 503 server busy, it will still continue to use handler A as long as it receives a response.  When it cannot receive a response, then it will randomly select another AH.  

If you want the agent to use ordered list of the handlers in the assignment, that is currently not how it is designed.  Submit a per - kb60021.

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?

Re: Handler Assignments not working

I suspected I might hear from you Caryn. I did reply yesterday but it seems to have disappeared. I am afraid I am going to have to disagree with you. The handler structure has Assignment rules with priority. Within those assignment rules there is also Handler priority. The word 'priority' stares me in the face, used by ePO. Not my word. I have also been through this with McAfee before, years ago. We know it should work. It works on thousands of systems and has done for years. For some reason we have started seeing lots of systems NOT picking the internal handlers on priority 1. I actually suspect it is related to max connections on the handlers, which in turn is related to a bug in agent 571. Support have been unable to deal with my queries on this and I closed two SRs in frustration. 

Today, I picked 127 servers that were showing as handler DMZ. I told them all to restart agent via an EEDK script. 83 of them then pointed to the internal handlers. I have also fixed others by installing our agent 572 package over the existing. Those that do not fix typically show other issues, such as firewall blocks.

Yesterday I added a HIPS block to 14 PCs to stop them talking to DMZ when they are on the internal network. Today I noted that a few had switched to internal handler and was surprised that more hadn't until I realised that a Policy Assignment Rule was trumping my rule. I made my rule the master and now more are switching. But, this also means some switched anyway without the block. The agent must have restarted.....I will now apply the block more widely and look at the handlers and expect to see more max connections errors in the apache log very soon!

cdinet
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 6

Re: Handler Assignments not working

Questions for you - 

Is it ever failing to connect to the one higher in the priority list? Does the higher priority one have a longer ping time?

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?

Re: Handler Assignments not working

Well, that is a bit hard to prove to be honest because the machines may have connected to that DMZ handler at any point in the past when the agent last restarted. After that, as you know, they will retain the 'last good'. I will need to hunt down when the agent restarted on a 'bad' system and look at the logs. Thankfully we do now restart the agent every day on PCs, so I should not need to look too far. Of course, I will be hit by machines that fail to connect for other reasons, but I am also 99% sure that they WILL show failure to connect because I have faith in the priority settings. I am also pretty confident that they will be failing to connect because of the handlers maxing out on connections (as verified by our apache error logs), which I am further confident is down to the aforementioned bug in agent 571, which is probably also partially  responsible for the mass loading of our handler1, which we have discussed elsewhere.

Re: Handler Assignments not working

I am pretty confident this is all about bug MA-10728 in agent 5.7.1, which is actually causing us huge issues now. As I have said, the agent handler group assignment priority does work but the non-DMZ handlers are getting full up on connections. So, the machines have to move to the next handler groups and assign the DMZ handlers. In addition to this problem, I have now shown you how it is adding massively to the creation of temp folders in c:\windows\temp because the machine can partially connect to a handler as a repo, but ultimately fails. It then does not clean up after itself. Ironically I now have an EEDK to delete these, itself creating more temp folders. Even worse than any of this is the fact that systems are either taking a long time to process any tasks (and potentially timing out on the task) and are failing to apply policy changes. Restarting the server service on the handlers does not seem to help - this does not clear the persistent connections. Restarting the agent on machines does help, but it will only clear the connection if it can still talk to the handler I guess. On top of all of this, we still do not have a full understanding of how the handlers are balanced as handlers or as part of the ePO repo. A ping to the ePO repo would probably give a similar response for all handlers so how does it choose which to use? I still think there is a point where it works alphabetically as our first alphabetic handler is still being 'hit' twice as much as the others.

Naturally we are now trying to push agent 5.7.3. With trepidation.

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community