Very odd. I have been trying all types of combinations of package types, delivery methods, and types of OS's. It always shows. What combination of package and delivery method are you using? Also, i would try one of the default delivery methods with the Clear Preferred Server batch file to see if it shows up, maybe it doesn't like something or is a bug. Is this console on the core or off the core? If off try it on the cores console?
Just some other things to try while someone from LD comes up with an answer. ;-)
- You can run a coredbutil on the core
- Restart the core
- Re activate the core
- Re apply the SP on the console if off the core.
- Re apply the SP on core.
Hope this helps in some way...
That option is only available for a task that has not been started. If this task has been ran once that box is greyed out. Try creating a brand new scheduled task you should be able to select that box up to the point it is started.
Oh wow, how the heck did i not test that with a previously used task. I was testing all sorts of combinations with a new task.
Yeah, jason, it doesn't show once the task has been run.
Why is that the case, is there a reason it is not available after a task is run? Seems like it would be useful at that time as well.
Jason, that was it. Thank you. I agree though, I wonder why we can't check this after a task has been run. Anyways, it worked.
I've just upgrade my core to 8.8sp3 ... can someone please explain what this new feature is good for? i really don't get?
i was able to re-deploy packages before by restarting the task/policy?
what's the difference here?
thanks in advance ...
Basically, if you have a run once policy, it will only run once and never again on a machine. The only way to get around this prior to SP3 was to delete or have a SQL editor modify the database.db3 file. Now you are able to use this check box to allow a run once policy to reapply to machines. This is handy especially if you are testing a scheduled task.
In the past if you had a policy job that for example was to install Winzip, and you chose "Required / Once" in the delivery method, it would only run one time, the unique ID if that tasks would be stored in the client database, and it would not run again....
There are exceptions to that I am finding....
We have a Tech that has a baseline "Custom Group" of patches he adds new patches to each month. He has one Pollcy Task that is using a delivery method that is set to "Required / Once" yet he keeps that same task and reuses every month... now, I thought it should not run again on a system, right? I tested this by patching a test box with a small amount of patches in the custom group, they patched. I put in more patches, right clicked on the task and chose start. It would not run again... which is how it should be... but the Tech swore it would & did...
So, I worked with him and went through his settings, well in the "schedule" section of the task he has his set to "repeat daily" (which should not be needed on a policy normally) and what we found is that then sets the "schedule these devices" to "ALL" from the default of "Devices that did not succeed."
I believe the "All" might actually be the same as the new checkbox to rerun a package.
Thanks a lot, Jeff & James.
I'm experiencing the same what James' tech said. When I cancel and restart a policy based task (required once) the package is deployed again.
In my case it's also a vulscan-package which runs every month. But this also works with other task as well.
okay .. excessive testing tomorrow :-)
Thanks guys, good thread!