Video Screencast Help

Policy availability on client computer lagging after machine added to filter

Created: 28 Feb 2013 • Updated: 19 Mar 2013 | 5 comments
This issue has been solved. See solution.

I have a workflow that adds a computer to a filter then runs an update configuration task (to make the computer update in hopes of picking up the policy immediately).  The workflow seems to be working, but updating configuration is not helping because the computers we are testing on are not getting the policy for a couple minutes.  Even if you update config manually on the agent is does not bring down the policy for a couple minutes.  After the couple minutes are up you can update config and everything comes down just fine.

The problem is that since the policy isn't available to the machine immediately, automating the update configuration doesn't work to run the task immediately as required.

Any suggestions to make the policy immediately available to the computer upon the computer being added to the filter (so that the automated update configuration in the workflow will cause the desired result instead of essentially causing nothing to happen)?

Note:  this worked in 6.x, but we are experiencing this issue in migrating to 7.1.

Operating Systems:

Comments 5 CommentsJump to latest comment

TGiles's picture

You have to remember that before a computer can get an updated policy the SMP server must run its scheduled task for policy updating. By default the SMP will update its client policy information every five minutes. If you assign a new policy to a computer and then tell the client machine to update its policy it won't find out about this new policy until the task runs. This is basic functionality of the SMP.

Nonos's picture

You want something to execute as soon as possible on a targeted computer? => Use a task?

Alex Bizjajev's picture

I would echo TGiles: try to add NS.PolicyFilterUpdate task to your workflow before agent policy update.

You may launch it with cmd like: schtasks /run /TN "NS.Policy Filter Update.{c1aa60e3-43cf-49b8-a7cb-8531b06bf871}"

Thank you,


M Rutledge's picture

I had the same issue with one of my workflow projects.  I resolved the issue by adding a process that updates the Policies associated with the filters.  The new process happens after the filters have been updated but before the Execute Update Client Configuration component.   See the attached file for documentation of the Embedded Model component I am using.

Update Policies After Computers Have Been Added To Filters.docx 141.82 KB
dpbees's picture

This helped a lot.  Getting the Target Guid and using the Stored Procdure to update it was the key.

Ran a quick task to update config at the end to make it come down quickly.

Thank you!