McAfee Agent 5.7.0.194 error 503 issue

[HugsNotDrugs]

Hi! I am experiencing an issue where a newly installed Agent 5.7.0.194 is unable to successfully communicate with the ePO. All attempts break with error 503 (server busy), similar to the description from a reportedly fixed bug in this version with signature MA-6006. I sometimes also see network return code = 1008. What I was able to determine is that no McScript logs are created in the Agent installation folder and after I use the Wake Up command from the ePO this Agent problem is fixed all of the sudden. Has anyone have an idea what might be the cause of that or maybe experienced similar problems?

[Former Member]

Hello @HugsNotDrugs 

Thanks for your post.

Please so check the server.log and see what you are seeing.

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?

[cdinet]

Server busy could have different causes.  With that response from the server, you should check the server log on the agent handler or epo server that the client is trying to talk to (install directory, db\logs).

One common cause of server busy is too frequent communication interval and/or too frequent client tasks running and making repository requests.  Another is if datachannel communications are failing due to too many ldap user lookups for user based policies.  One fix for that is to enable database mirroring in server settings under user policies in epo.  That isn't actual sql db mirroring, it just caches the ldap user info so the servers don't have to do ldap lookups constantly.

[HugsNotDrugs]

So it has turned out the errors on the ePO servers are matching the description in the McAfee KB60776. We have implemented some of the changes from the KB and the issue has stopped for now. What I am wondering however is how to prevent this sequence error from the KB article from happening in the first place? The solution described in the article feels more like a workaround as it is mitigating the reaction of the ePO to the errors but not preventing them.

[cdinet]

There are a couple of reasons for sequence errors.

1.  A system was restored from snapshot (or epo) where sequence numbers might not match.  Over time they might start matching up if the server was expecting a higher number than client is sending.  Each asci attempt the sequence number will increment on the client.

2.  System was imaged from a golden image where the agent guid was not removed, giving all images then the same guid.  The agent install guide has section for using agent on an image.

3.  EPO database was restored, which changes what epo is expecting from client.  

So yes, it is a workaround, but once you identify cause, you won't run into that problem.  Keep in mind, 503 errors can be received for multiple reasons.  Epo can be showing server busy errors in server log, sequence errors, invalid response from agent, agent is using wrong communication key, or failed to initialize server errors as some examples.  So looking at server log for why it sent a response is key to understanding why the agent can't communicate.  If the agent is not getting a response back from server at all, that is a different type of communication failure and has other causes.  You won't see any mcscript logs with communication failures if the agent can't get tasks from epo to run them for updates/deployments.  Those are only generated if a task actually runs.

[HugsNotDrugs]

thank you for a detailed response @cdinet

the error I am registering is explicitly one from the KB60776:

"Rejecting agent due to an invalid or duplicate sequence number"

it also seems to be instantly fixed, if I run the "wake up" command for that system from the ePO - otherwise the error continues to repeat for days, form what I have been able to determine so far

I have attempted to implement the workaround from the KB, avoiding the "not recommended" part of it, but it does not seem to fix the issue

do you know why "disable sequence error checking on the ePO server" function is not recommended?

[Hawkmoon]

Hi,

If that option is 'disabled' you run a very real and high risk of getting a system tree full of duplicate systems.(GUIDs)

As each system calls home with a number as ePO is no longer checking if that number is high it  accepts and creates an entry in the system tree ...duplicate created.
This is magnified if you manage an estate that use Drive Encryption (MDE), as the remediation steps to deal duplicates with MDE can take a very long to action and complete.

Hence its not recommended.

Do have a read this article for some additional information:
Queries, system actions, and server tasks in ePolicy Orchestrator to help with identification and remediation of duplicate McAfee Agent GUIDs
Technical Articles ID: KB67473

[cdinet]

In addition to what @Hawkmoon stated, sequencing is there as a security measure to prevent man-in-the-middle type connections also.

[HugsNotDrugs]

It appears my problem is related to the emergency issue KB94195.

[cdinet]

Good to know.  The workaround for disabling sequence checking should be a temporary measure.