cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nick_B
Level 10
Report Inappropriate Content
Message 1 of 3

ePO Client Task Assignments - Best Approach

Jump to solution

Dear McAfee Community,

I was looking for some feedback on the approach which we have adopted over the last few years. The strategy appears to be working well, but I was looking to see what other ePO professionals' opinions were.

A popular strategy when it comes to Product Deployment and Product Update tasks is to schedule a Daily and a Run Immediately client task for the security products in use at a given organisation.

If we look at the breakdown of the client task to deploy HIPS, for example, it usually follows something along the lines of a start and end time, an option to start the task every two or three hours during the repeat time, enabling randomisation and a missed task delay time. See the snip below taken from our Lab, but which is a very popular scenario at real customer sites.

Client Task Assignment Creation - Best Approach.PNGDaily Schedule with standard options

 

So I guess the main question is, what is the difference between having the task start every two hours over a 24 hour period with a randomisation period that fits nicely into the start time interval, as seen in the screenshot above and...

Having the start and end times the same as in the above scenario, but NOT have the task start over during the repeat window but instead the randomisation is simply increased, so for example 23 hours and 59 minutes. The second screenshot refers to this fictitious scenario. As the option to start the task every x hours y minutes cannot be turned off it has been set to 24 hours, which should have the same effect. Note that this second option we are exploring has not been used in any of our customers' environments, it is a theoretical scenario so to speak. Note the large randomisation window to cover the entire day.

Client Task Assignment Creation - Best Approach - Large Randomisation Window.PNGDaily Schedule Deployment Task - Large Randomisation Window

So, what do you think would be the best approach to product deployments (and updates) of the two setups depicted above and why is one more efficient than the other?

I look forward to your thoughts!

Labels (2)
1 Solution

Accepted Solutions
McAfee Employee cdinet
McAfee Employee
Report Inappropriate Content
Message 2 of 3

Re: ePO Client Task Assignments - Best Approach

Jump to solution

Take a look at kb90961 that has a couple of links for other best practices for scheduling and avoiding max connections.  A lot of your considerations need to also take into account the number of clients being managed, number of products being deployed, how many repositories, agent handlers, etc. for scalability.

In your first scenario with task running every 2 hours, that can overload a server with too many repository requests, even with randomization - again, relative to number of clients, repositories, etc.  You might want to point systems to use distributed repositories rather than epo server or agent handlers to offload that traffic away from the servers.  Keep in mind that every time a client runs a deployment or an update task, that is still a connection to the repository and minimum downloads of the sitestat.xml, pkgcatalog.z and detection scripts for each product being updated or deployed, even if no updates are needed.  So those are also bandwidth considerations.

In my opinion, a run immediately deployment task is in order to catch new systems, plus a daily task once a day.

For scheduling, there are certain things to consider.

1. Repositories must be up to date sites, or agents won't use them.  So schedule should follow this:

An update to master repository occurs, whether it is check in new product or pull task for dats and other content.

Then replication must occur after that happens

Clients should then update or run deployments after replication and before any new pull happens.  The workaround for that, is to use superagent repositories with lazy caching enabled and not use replication.  That keeps the sites up to date without having to worry then about the scheduling around those.

2. Consider high network bandwidth times and schedule tasks outside of those times.

3. Consider strategic placement of repositories and their assignments in policies to systems to minimize wan traffic for downloading files.

4. The randomization window is all based around the above considerations.

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?

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

Re: ePO Client Task Assignments - Best Approach

Jump to solution

Take a look at kb90961 that has a couple of links for other best practices for scheduling and avoiding max connections.  A lot of your considerations need to also take into account the number of clients being managed, number of products being deployed, how many repositories, agent handlers, etc. for scalability.

In your first scenario with task running every 2 hours, that can overload a server with too many repository requests, even with randomization - again, relative to number of clients, repositories, etc.  You might want to point systems to use distributed repositories rather than epo server or agent handlers to offload that traffic away from the servers.  Keep in mind that every time a client runs a deployment or an update task, that is still a connection to the repository and minimum downloads of the sitestat.xml, pkgcatalog.z and detection scripts for each product being updated or deployed, even if no updates are needed.  So those are also bandwidth considerations.

In my opinion, a run immediately deployment task is in order to catch new systems, plus a daily task once a day.

For scheduling, there are certain things to consider.

1. Repositories must be up to date sites, or agents won't use them.  So schedule should follow this:

An update to master repository occurs, whether it is check in new product or pull task for dats and other content.

Then replication must occur after that happens

Clients should then update or run deployments after replication and before any new pull happens.  The workaround for that, is to use superagent repositories with lazy caching enabled and not use replication.  That keeps the sites up to date without having to worry then about the scheduling around those.

2. Consider high network bandwidth times and schedule tasks outside of those times.

3. Consider strategic placement of repositories and their assignments in policies to systems to minimize wan traffic for downloading files.

4. The randomization window is all based around the above considerations.

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?

Nick_B
Level 10
Report Inappropriate Content
Message 3 of 3

Re: ePO Client Task Assignments - Best Approach

Jump to solution

Thanks Caryn, I wasn't familiar with that KB until now.

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