cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

EEDK Package will not pull from distributed repositories

Jump to solution

After many years of working with ePO, I am starting to think I might be going mad. I am looking to re-design our repo structure for various reasons and I have a policy with just 4UNCs, a SAR and McAfee http. If I try to push a product deploy, it fails with 'Unable to find a valid repository'. If I add the ePO repo, it works, but of course it takes it from one of the handlers. I really dont want it to do that (I would not mind it doing that so much if there were some way to disable the ePO server from being an option, but I have never been able to find a way to do that either!).

Does a deploy need to come from a handler? Surely not? Surely it can come from a different repo? If it cant, why have all my repos got the software?!?!?!?!

 

1 Solution

Accepted Solutions
McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: EEDK Package will not pull from distributed repositories

Jump to solution

Regarding... like a flag you can set that says 'just use the repo' anyway.

As you said, the agent compares the sitelist and if the repo catalog version is lower than epo, it won't use that site.  That is not a bad thing, as the agent won't use an out of date site.  What makes it out of date?  Any addition to the repository, such as dat, other point product, etc, without replication, can make it out of date.  What type repositories are these?  If they are superagents, it is much more efficient to use lazy caching instead of replication.  That way, you reduce bandwidth usage, the Sadr's can pull from epo or agent handlers, and sites will always be up to date sites. 

how do you control which of the handlers gets used?  That is set in the agent handler assignments, but basically if there is more than one ah in the assignment rule, the agents can talk to any one of them - they won't necessarily choose first in the list, as it is meant to be a randomization to balance the load.  So yes, potentially an agent handler could be communicating with a different AH than itself.  The agent will update from an AH that it is talking to if a repo is not available. I know you asked to not be asked to raise a per, but it is not really bad design as you think. If all the agents used the first handler in the agent handler assignment rule, then that one would be over-used and the others not utilized, which defeats the purpose of having them there. You can submit an IDEA (kb60021) to have the ability for the AH's also to be listed in the agent repository policy so that they can be specifically enabled/disabled. However, that might not be feasible, as they are considered the master repository and as it is now, if you disable the epo server in that policy, you also disable the agent handlers. 

I believe lazy caching instead of replication would be your most efficient method.  Don't do both. 

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?

3 Replies
McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: EEDK Package will not pull from distributed repositories

Jump to solution

You can disable the epo server in the agent repository policy.  That would also disable agent handlers from being used as a repository.  There are several reasons why a client would return unable to find valid repository.

1.  It can't be reached

2.  Problem with the repository itself (example, returning a 503 or 500 error) - check credentials on unc repos and macmnsvc log on the sadr for errors.

3.  not an up to date site - the order of operations should be this - pull first, then replicate, then clients update after replication complete and before next pull.  Replicate also after products have been checked into the repository.

4.  For sadrs, do not use lazy caching in conjunction with replication - use one or the other, as it can lead to locked files, failed replications and other issues.

The best place to look for the reason why the clients are giving that error is in the mcscript log on the client.  Depending on the version of agent, there also may be an mcscript deploy log.  Those are located in c:\programdata\mcafee\agent\logs. 

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: EEDK Package will not pull from distributed repositories

Jump to solution

Thanks for your input. We are not using Lazy Caching. I am aware of the other comments. Probably worth adding that one should not try using P2P with SARS as that breaks the agents. Or at lest it did with a certain version. We are still picking up the pieces from that disaster!

I think the issue here was actually that replication had failed. There is some logical sense here, but it is also very arguable that it should be configurable. So, I tell a machine to deploy a product. A product that has been unchanged in the repo for months. When the deployment task runs, it simply compares ePO sitelist to repo sitelist. If the two dont match, it wont use the SAR. It ends up back with the ePO server. That's bad. There should be a way around this - like a flag you can set that says 'just use the repo' anyway. As things stand, if you want the deploy to always work, you need to have the ePO server set in the repo policies. But should you do this? Maybe it is actually better not to and have the deploy fail rather than eat bandwidth. Also, we are a global company. In the time it takes to download and replicatd everywhere, there will be a discrepancy in sitelist. If we dont have the ePO server included in the repos, any that update during this time may fail.

Also, as I said, how do you control which of the handlers gets used? How do you ensure the load does not go to the ePO server itself? Yes, you can use handler groups, but that only applies to ASCI doesnt it? I ran an update from my ePO server and it used handler2. I ran an update from Handler2 and it used Hander7. That seems daft in itself - why would a handler use a different handler to update itself?

Please dont suggest I raise a PER type thing. Its not an enhancement. It's bad design, regardless of whether it is intended behaviour.

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

Re: EEDK Package will not pull from distributed repositories

Jump to solution

Regarding... like a flag you can set that says 'just use the repo' anyway.

As you said, the agent compares the sitelist and if the repo catalog version is lower than epo, it won't use that site.  That is not a bad thing, as the agent won't use an out of date site.  What makes it out of date?  Any addition to the repository, such as dat, other point product, etc, without replication, can make it out of date.  What type repositories are these?  If they are superagents, it is much more efficient to use lazy caching instead of replication.  That way, you reduce bandwidth usage, the Sadr's can pull from epo or agent handlers, and sites will always be up to date sites. 

how do you control which of the handlers gets used?  That is set in the agent handler assignments, but basically if there is more than one ah in the assignment rule, the agents can talk to any one of them - they won't necessarily choose first in the list, as it is meant to be a randomization to balance the load.  So yes, potentially an agent handler could be communicating with a different AH than itself.  The agent will update from an AH that it is talking to if a repo is not available. I know you asked to not be asked to raise a per, but it is not really bad design as you think. If all the agents used the first handler in the agent handler assignment rule, then that one would be over-used and the others not utilized, which defeats the purpose of having them there. You can submit an IDEA (kb60021) to have the ability for the AH's also to be listed in the agent repository policy so that they can be specifically enabled/disabled. However, that might not be feasible, as they are considered the master repository and as it is now, if you disable the epo server in that policy, you also disable the agent handlers. 

I believe lazy caching instead of replication would be your most efficient method.  Don't do both. 

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?

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator