Filters vs targets: Best Practice for targeting software polices and tasks
Created: 28 Jul 2010 | 4 comments
Sorry for the misleading title, but I'm looking to collect experiences and information relating to filters vs. targets.
What's best, what works best for you?
How do you target software in your environment?
discussion Filed Under:
Comments
Not sure I fully understand your question
Not sure I understand your question. A filter is a dynamic list of computers meeting specific criteria, e.g. "All Windows Workstations" or "Computers with at least 1GB of RAM." A target is what you apply a policy or task to; e.g. "All Windows Workstations" (filter) "in Europe" (organizational group) "with at least 1.5GB of RAM" (filter). So these are distinct concepts, even though they are related since a target can be based on a filter.
What are you looking to do? Or what are you wondering, exactly?
Mike Clemson, Systems Engineer
Intuitive Technology Group -- Symantec Platinum Partner
Best practices.
Picture a scenario. I have a package that I want to target at different sites or subnets.
I can create a filter for each subnet, then create a filter encompassing all of the subnets that I want, then target the policy at the one filter.
Or I can, in the policy, list each filter separately in the target and do it that way. I've noticed that it's quite slow doing it this way, so I'm wondering what is considered best practice and/or has the least performance hit to the NS.
In the NS6 days, you would do all of the work in the collection. But with targets now, I'm concerned about performance. I've heard mixed advice about this, which is why I was wanting to canvas some opinions. Some have said to create lots of smaller filters and combine those as the target, whilst others have said to combine filters and target less filters in the actual policy. Adding confusion is the fact that some of the built-in agent rollout policies now use targets instead of filters, but it's not consistent... and hopefully that explains what I'm looking for.
As mclemson has indicated
You can't really have a target without at least one filter or organizational group. As defined, a target is the end result of whatever you have combined (org group + filter, filter exclusion, just an org group, etc.).
Building a GOOD static organizational tree, or having a sound AD tree that you can import as a organizational tree would be the first step. Although not entirely realistic, the tree should not change 'much' and accurately reflect your environment. That way, when you build your filters, they can accurately parse out what systems you actuall want to target.
For example, you can select all the systems in Europe -> Amsterdam -> Sales Office 1 (Org View + Groups). Then you can apply the aforementioned all systems with at least 1.5GB of ram filter, to target those systems.
If you just build filters, your NS has to parse through all the computer records in your database to come up with an accurate target, which = more overhead. Really collections weren't much different, and in my opinon, probably more resource intensive than the 'targeting' process laid out in this discussion.
Jim Harings
HP Enterprise Services
1st Rule of Connect Club: Mark the post that helped you the most as a 'solution'. 2nd Rule of Connect Club:You must talk about Connect club.
So, Best practices:
- Make filters specific
- Use multiple filters but don't make them all encompassing. It is better to use aggregate filters rather than putting all the logic into a single filter
- Use targets to combine filters with organisational groups
- Build an organisational group that represents the organisation (very time consuming) or use A/D if possible
- My experience is that targets are slow (in the policy applies to area) but your mileage may vary...
The reasoning for this thread is that I have seen inconsistencies with what's out of the box from Symantec, and I've found that creating targets can be quite slow at times.
Would you like to reply?
Login or Register to post your comment.