Understanding the "Run On Policy Update" Workflow feature
I remember Andreas unveiling this little gem at the MVP Summit back during the early betas and I remember getting the "we can really shoot ourselves in the foot with this one...cool!" It's a seriously powerful little feature but I fear my lack of understanding of how it completely functions is making me a fearful.Here is the description in the WF General tab:"Indicates whether a workflow definition used to define an action process should be executed when a policy rule that refers to the action process is created or updated, or the membership of the set to which such a policy rule applies is updated."So, things I infer from this description:- Only applicable to Action WF- MPR must be: - created (as in the first time itis associatedwith an Action WF) - updated (any update, enabling or disabling?) - setmembership is changed (one of the requestor or target set definitions has changed)I think the big gray area for me is the "updated" clause, specifically around enable/disable of the policy itself.We just staged 35k accounts to portal with all of the policies disabled and now I'm going through to enable them one by one (a mass enable/disable dialog would be helpful). Here is what I'm observing - I see a ton of "System Event Request, PostProcessing System Event" requests all triggering the first policy I just enabled. I am assuming this will attempt to process all 35k accounts against the policy which is what I expect since this is the first time we're turning them on; however, I have some concerns:1. Is this sort of thing going to happen everytime I disable/re-enable a policy simply because I was troubleshooting something? This would not only clog up the system with a bunch of requests but may be completely unncecessary.2. Is this behavior we can alter? After enabling a policy, a dialog warning would be preferential disclaiming, "This policy is attached to Action WF that due to the Run On Policy Update switch will be forced to reconcile. Are you sure?" Making the behavior defeatable would be a best, but I'm not sure if this is allowed in the architecture.Could the PG please shed some light on the caveats surrounding this feature?Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
October 26th, 2009 11:14pm

One other operational consideration to throw in here - it appears as if the System Events are processing sequentially but I want to make sure. I hope this is the way it's working and it's not trying to trigger all of the WF affected by the 10 MPR I just enabled. So, does the System Event process wait for the first MPR actions to complete before firing the next? This brings up a Design and Operational consideration where you should likely know in which order the policies should be enabled as it could compromise processing.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2009 11:18pm

Hi Brad,Perhaps this blog post answers some of your questions about the Run on Policy Update feature: http://blogs.technet.com/doittoit/archive/2009/11/08/run-on-policy-update-retroactive-policy-enforcement.aspx>One other operational consideration to throw in here - it appears as if the System Events are processing sequentially but I want to make sure. The System Events are requests created for each "Run on Policy Update" enabled workflow to run. As soon as your Request to enable the MPR is completed (ie. committed to the FIM Service db), the "Run on Policy Update" enabled workflows attached to the enabled MPR are run for all members of the MPR's ResourceFinalSet. The workflows are created sequentially, but as soon as they are created and started, their execution is managed by the Windows Workflow Foundation workflow scheduler.
November 8th, 2009 7:28am

Thanks very much for the detailed post Nima! That exposes several areas I was not aware of.My only other question is regarding the system event processing.You mention that they are issued sequentially and then process asynchronously which I get; however is there is any ordering imposed by the sequential process? For instance, if two ROPU enabled workflow are triggered within a few seconds of each other, will the system event processor process all of the first WF events before moving on to the second?Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com
Free Windows Admin Tool Kit Click here and download it now
November 9th, 2009 8:39pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics