Steps to reproduce:
1. Create a filter on your parent (top level) SMP server.
2. Add members to this filter, at least 2 machines.
3. Replicate this filter down the hierarchy to all child (bottom level) SMP servers.
4. At this point everything looks well and accurate membership count is reflected.
5. On the parent SMP server, modify the filter and add a new machine to the membership.
6. Replicate this filter down the hierarchy to all child (bottom level) SMP servers.
7. Observe the filter membership on the child SMP (bottom level) server. Notice that it now shows 0 members.
8. Right click on the filter, and choose View as XML. Notice that the inclusion section does reflect proper membership count.
No error messages are indicated.
The product is working as designed.
The filter update process would otherwise be very costly if targets and filters where updated for active and inactive polices. That’s why we have a separate resource update schedule for updated policies, so that when a policy does get enabled, it will update the filter on a quicker schedule. A common configuration change per environment, is changing the delta resource membership update from the default 5 minutes, to X minutes. Based on your specific environment. The policy update should remain at every 5 min for this very reason. Remember, if you're always trying to use filter/targets for reporting, that is not the intended use (we have reports for that). Instead they are used to deliver policies and scheduled tasks to computers. If a filter/target is not being used for any active policy or task then it doesn't’t NEED to be current because it would have no effect on the computers even if they were accurate.
If on the other hand you “schedule” a task for sometime in the future, this schedule (and its target/filter) are replicated down the hierarchy. With the active schedule item replicated with a target/filter, that target/filter gets updated.
Tasks: You will want to schedule them for a future run date. If you do this, the filter membership count on the child will reflect properly. If using the Run Now option on the task schedule, then you will experience the behavior described in the Problem section above, but it does not matter. Please see the detailed description below for why.
Managed Policies: Make sure you enable (turn on) the policy and then replicate it down the hierarchy. If you leave it disabled (turned off) and replicate it, you will experience the behavior described in the Problem section above.
Tasks work via task instances, each active instance actually targets the computer directly. At the moment that the task is fired, for every computer in the target (as identified at the time the task runs) a task instance is created; however, once the instances are created, the tie to the target that created it is gone. Each task instance is now an independent object that is tied to one computer. These task instances are replicated down the hierarchy and delivered to the client. Once the task executes on the client, it reports the results back to the local NS through its Site Server.
If you schedule the task for a future date, that is applied to this target, which includes the filter in question, you will not see the behavior described in the Problem section above.
For Managed Software Policies:
You must enable (turn on) the policy on the parent and replicate it down the hierarchy. If you replicate this policy down the hierarchy turned off, the behavior described in the Problem section is exhibited.
Symantec Management Platform 7.1