I have a few question about LazyCaching . We have just upgraded ePO from 4.5 Patch 4 or to EPO 4.6.6, I also upgrade what I can from that starting point.
ePO 4.6.6 build 176
Product Coverage Reports 220.127.116.117
VirusScan Enterprise 18.104.22.1685.Srv 7235.0000
I was not present when the repository was setup when we were on ePO 4.5. We control the network traffic, setup was
Curret setting with ePO 4.6.6
ePO server(only one) at top of the lists and enable, then a lists of all the Super Agent site 30 enable.
Client Repository List
ePO server at the top of the lists but disabled, then a lists of all the Super Agent site 30 enable.
I looked at the McAfee Clip on the web site about LazyCaching , and it look like a client ask it local Super Agent then wait for the local Super Agent to get the update. When it has arrived at the local Super Agent the client then get the update form that local Super Agent
However, I noticed that Client and Super Agent request for an update, Dat file, they try any Super Agent before finding one that could update them, and it may not be the local Super Agent. Bear in mind that a couple of Super Agent sites have a low connection speed, as they are small sites.
The document say “When a client system first requests content, the Super Agent assigned to that system caches that content. From that point on, the cache is updated whenever a newer version of the package requested”
3. Distributed Repositories, Action ,View Package some of the site say “Failed to verify site catalog, no repository public key matches signature”, or some similar error of missing package?
Curret setting with ePO 4.6.6
Please note that Lazy Caching and replication are effectively opposites, and you should only be using one or the other - not both. (The whole point of lazy caching is to reduce the amount of bandwidth used, by only transferring files that are required - so if you then do a replication to the repository, you remove this benefit.)
The client machines have a number of different ways of choosing which repository to use, such as ping time and subnet distance. These methods are normally pretty good at locating the nearest repository, but they are not perfect: if it is important to you that clients only go to a particular repository, then you will need to use the "use order in repository list" option in the agent policy, and configure the list accordingly. (Usually this means that you would create one policy per repository, and assign the policy to the machines that should use that repository.)
Thank for your answer it has helped. However, I still not sure, if you look at a client log, I uploaded. You will see that the client look for as Super Agent to get it, updates, Dat file. It may find a Super Agent that has the Dat, half get the Dat then look some where else.
I uploaded a log for a Client, it a laptop that not been on the network for sometime, so was showing as unmanaged. After a few send to the ePO to became manage again. I then added the correct policy. It then started to look for the latest DAT file.
I bit worried if I just use LazyCaching at 09:30 Agent Client will look for a Super Agent and may find a Super Agent site other than ePO server that up to date and it will get all the traffic.
Looking at LazyCaching video the client ask for the update from a Superagent , then wait for the Super Agent in it domain to pull the update. After that Super Agent has recived the update it aviable for all the client in that domain.
It's difficult to tell from this log exactly what is happening - you would need to check the agent log (rather than the agent monitor log) and then also cross-reference the agent log on the superagent machine to get a better idea.
But before anything else, make sure you are *only* using Lazy Caching, not replication.
Also, you should check the network connectivity between the clients and superagent repositories - if the connection is very slow then the download can time out. (I don't think this is the case for you, but it's worth checking.)