cancel
Showing results for 
Search instead for 
Did you mean: 

Setting up a Lazy Cache SAR

I want to evaluate using a Lazy Cache SAR as opposed to any other kind of repo. So I sort my policies out and my SAR creates the folder structure. I use the same SAR to run a policy to update only from that SAR (from itself in effect). It fails. Unable to find a valid repository. Now, I havent replicated, but we are told one should not combine replication and Lazy Caching. Bit puzzled. Does it take a while to set up the files/folders? I see I have a sitelist file and various folders in CURRENT......

11 Replies
McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 2 of 12

Re: Setting up a Lazy Cache SAR

That is correct, don't replicate if using lazy caching.  On that sa repo, go to c:\programdata\mcafee\agent\logs and look at the macmnsvc log.  It will show any failures to get files from the master repository.  If you post any log entries, be sure to remove any sensitive info like servernames, IP, etc.

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?

Highlighted
McAfee Employee Hawkmoon
McAfee Employee
Report Inappropriate Content
Message 3 of 12

Re: Setting up a Lazy Cache SAR

Hi 'Andrew',

This is a tricky one!
(Bit of a read sorry)

So support and what cdinet say is correct!

You could mix the two setups in an estate however, there is an 'problem' with mixing SADR 'replication' with an SADR 'lazy cache' setup, put simply one blocks the other!

This would be why support and cdinet advise against such a setup! It can become complex and is difficult to maintain
For example: Each failure reported by the 'replication' task could trigger an investigation as to why, when in truth there is no fault to address, this costs time!

Here when you replicate, SADR, ePO pull or replication task, that operation expects to get access to  read/use, the 'sitelist' file.
(This action/the process obtains the locations (addresses) to visit, the folder path to browse and password information etc. to allow it to complete its operation.)

If this location cannot be accessed (depending on the configuration defined) the 'task' (process) will move onto the next allowed site, (if this file is locked it will fail) and attempt to update from that location and so on. Note: It could also report a  'fail' if you only have one location defined.
(Its configuration dependent)

When you enable 'lazy cache' (LC) for an SADR setup, most admins do so to reduce network traffic across the estate, LC allows such traffic to be retained within the local (defined) area.
As with a 'replication' task, it (LC) wants to get addresses/locations , path details etc to complete, from the same 'sitelist' file. The issue comes from the LC setup retaining (as designed) a lock on that 'sitelist' file.
This lock will stop a normal replication from completing as it never gains access to the 'sitelist' file  (addresses, password etc) to allow it to run from the 'sitelist' file.
Where the LC setup (lazy cache) will interrogate all locations its configured to access to respond to the data request (DAT update for example) it has received from a client.

 

I mentioned you can mix the two setups, however you need to be very careful with the configuration, and the administration of such a setup, the overhead to maintain this configuration will be complex and will increase the work required to deal with issues as they/if they appear.

In the event of a new malware outbreak and the release of a DAT/AMcore update to combat the malware a company will want to push that update to the estate in a controlled manner as quickly as internal process allows.
The fastest and most controlled way to do this is with an update task used in conjunction with a replication task!

With a lazy cache setup, running an update task will trigger clients to seek the wanted update. However, each device will have to seek the requested 'update' from all of the configured locations to find it, if no location has it yet then they will (configuration dependent) turn to the ePO server, or the main McAfee update website..

To run a replication and update is a managed process, something an admin may want to have in such an operation, where lazy cache offers no admin management, both are subject to network connections and the time involved getting data from 'a' to 'b'.

 

 

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: Setting up a Lazy Cache SAR

Go good to hear from you both so quickly. I am finding the forums far more satisfactory than support these days. Still, you could be the same people 8-)

Anyway, the whole repo situation is a big thing right now. We had some issues and I have a couple of SRs open which are slowly going nowhere useful. My major gripe with those is understanding exactly how and when the agent re-evaluates the repo list. The functionality here has never been good under the premise that it only does it when the policy changes. In the growing days of home working and VPN, this is not good. I also suddenly fell upon the news in the product manual that a 'ping-time' selection' list only uses 5 of them to evaluate. I am really not sure that is true though - if I enable 120 repos, the first update takes an eternity. I also see there was a bug in a recent agent that was fixed - the bug was that repos were evaluated each policy enforcement. But thats actually a GOOD bug! OK, maybe a bit severe, but it is more along the lines of what we really want. In addition to this, we have multiple HTTP issues (probably because we use ZScaler...) and I also discoveed that Riverbeds dont compress HTTP traffic, so we are also testing out good old UNCs. Anyway, I digress (but at least you get some background).....

I can cope with a mix of SARS that do and dont Lazy Cache. The Lazy Cachers are simply not set to replicate. I understand we might want to get an emergency release quick, but not at the expense of our network. Our replication can take hours and in that time, many of the systems will revert back to the ePO server (which in turn will slow the replication of course). Looking at the logs (oh those logs drive me nuts) I see various curl errors and proxy errors and I am back in the world of open SRS where systems cannot use HTTP to the handlers for some weird reason (not java keep alives, we have done those).

Not sure where to look at the moment..................

McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 5 of 12

Re: Setting up a Lazy Cache SAR

Send me your SR numbers in private message and I can take a look at the 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?

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

Re: Setting up a Lazy Cache SAR

By the way, we are not the same people lol 🙂

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: Setting up a Lazy Cache SAR

How would I send a private message?

I have this error in masvc
2019-05-08 15:15:32.630 masvc(6284.6212) Updater.Debug: Script progress muecProgressEvent "3" Message "Error occurred while downloading catalog.z."

In Mcscript
2019-05-08 15:15:32 E #7624 downloader Downloading file from http://THESAMESERVERASTHEHOST:8512/Software/catalog.z to C:\ProgramData\McAfee\Agent\\catalog.z failed.
2019-05-08 15:15:32 X #7624 ScrptExe Line 223: Progress Error occurred while downloading %1., 4, catalog.z,
2019-05-08 15:15:32 X #7624 MueEep Script progress details : Event Type = " 3" Progress = " 4" Progress MAX = " 0" Message = "
2019-05-08 15:15:32 I #7624 ScrptMgr Error occurred while downloading catalog.z.

If I try to find catalog.z, it aint there on the server
McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 8 of 12

Re: Setting up a Lazy Cache SAR

So then it would seem the sadr isn't pulling the files from epo.  Check the macmnsvc log for errors getting files from epo server.

As for how to send private message, at the top right of the community page next to your login, there is an envelope.  Click on that and to for the TO field, just enter cdinet.

 

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: Setting up a Lazy Cache SAR

I cant find anything useful there. I'll set up another one and see if I get the same.

McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 10 of 12

Re: Setting up a Lazy Cache SAR

Please upload the logs from that sadr to your SR and I will look at them.

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

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