1 of 1 people found this helpful
Agents will walk through their local copy of the sitelist which contains a list of the repositories.
Sitelists on the client are updated along with the policy from the ePO server. On a sitelist update from ePO the agent recalculates their own version to add in distance metrics and availability information. This is then stored locally. So, the result is the agent should always have a local list of what it thinks are valid repositories to use, and the order in which it will try to use them. At the end of this list is the defined fallback repository.
So, if the first repository does not respond the agent will walk through the local list until if all else fails it hits the fallback.
The idea is that you make the fallback always available (but not necessarily the best choice).
For example by using the McAfee Ftp or Http sites.
That way even if the ePO server and all distributed repositories are unavailable clients should eventually fail over to the McAfee update site - providing they still have an internet connection.
You can configure this as you wish, this is just an example.
hi rackroyd, thanks for the reply.
Your answer comes close to what I'm trying to figure out. The thing is that in my situation, the ePO server goes down for a couple of days (it's a lazy admin that doens't notice this, I know..) while the Distributed repositories stay active, albeit increasingly out-of-date. After a couple of days, the Agents sit there with an out-of-date SiteStat.xml, containing an out-of-date catalog time stamp. When starting their update, will the Agents compare the updates from the Distributed repositories with their SiteStat.xml, decide that they match, and stop the update? In that case, the Agents would never receive a newer update until the ePO server is live again, because only then the Agent will get its SiteStat.xml renewed and will it realise that the HTTP fallback is the only up-to-date repository.
I think in this situation the Agent will not try the HTTP fallback, because the Distributed repositories are still available and higher up the priority list, while they are tricked by their old StateStat.xml into believing they already have the latest update.
Thanks for your further assistance.
Apparently I'm misusing SiteStat.xml in my posts, It should have been SiteList.xml.
I did wonder
sitestat just tells you if a site is valid or not.
1 of 1 people found this helpful
The thing to remember here is the distributed repositories will be replicating from the master repository - which is on the ePO server.
So if the ePO server fails, all the distributed repositories stop replicating too.
Unless the agents hit a repository that is still being updated (because it's a mirror or a McAfee-hosted site for example) then they won't be getting new updates as only the old ones will be available to them.
So, yes it is possible.
I take from your answer that when you configure the Agent policy to use the Master Repository, Distributed Repositories and a fallback Repository in the form of McAfee HTTP, Agents will download their daily DATs from HTTP fallback in case the ePO server is down for more than a day.
Can you confirm this? That would fully answer my initial question.
Should do, yes.
If it's critical I recommend you test & verify expected behaviour yourself too though