Carol gives an excellent article here on how to schedule a job. I did find out something interesting today. When you create the set that you are going to use for the MPR which you plan to flip on and off, a lot depends on what you are doing in your script which you plan to run when you flip.
1- You can run a script to act on the members of the set.
2- You can run a script that will do an Xpath query and pull certain objects and then act on that.
My script falls into number 2 but the set I chose as target resource for the MPR also had members that came up in the Xpath query. I see all these failures in the logs yet the script does make the changes to the members as requested. Mystery? Well the solution was if you are running a script that will create “its own collection of objects” then don’t give it double work by giving it the same target resource set members to process as well. When you flip on Run On Policy Update (ROPU), you are specifying that your workflow should be applied on all members of the target resource. It is best if you could do an empty set, except to trigger action you must give an instance of the target resource to process. So add ONLY one member to the set (no more) which you know will not appear in the Xpath filter’s collection.
Solved it for me, no more errors in logs.