So what exactly do each of these options do in an advertisement? The TechNet documentation is actually pretty sketchy and thus this post (inspired by MVP extraordinaire, Torsten Meringer). Note that everything below is specific to mandatory advertisements; i.e., those with a schedule. If the advertisement is not mandatory or is executed manually, the Program Rerun Behavior setting has no impact.
Never rerun advertised program
The first option is fairly straight-forward. Essentially, a program will never be rerun on a specific client under any circumstances including adding a new schedule to the same advertisement.
Scenario 1, Additional Schedules
Any additional schedules added to the advert will essentially be ignored as shown in the following excerpt from execmgr.log on the client:
Scenario 2, Additional Advertisements
So, what happens if we create another advertisement for the same program? As expected, the program does not rerun:
Scenario 3, Remove From and Re-add to Collection
And how about if we remove the client from the collection, update the policy, and then re-add the client to the collection where the advert is applied?
The above log file snippet shows the old advert getting deleted because the system was removed from the collection followed by a new instance of the advert being created because the system was added back to the collection.
This shows that the client does take into account previous executions of the program even though it is a new and separate advertisement instance. Minor variations are also possible but each is similar enough to one of the above that you should be able to deduce the results.
Always rerun program
This option is essentially the opposite of the last one and is useful for recurring adverts that you always want to run. It’s pretty clear what will happen if you add multiple schedules to a single advert with this option selected or if you create multiple adverts for a single program: they will all execute on time regardless of the outcome of any previous executions. That covers scenario 1 and 2 from above, the only question is what happens for scenario 3: removing the client from a collection and then re-adding it. So what should happen? It’s the same advertisement with the same schedule so should the client rerun it or not? If we use the results from above, specifically that the client maintained the status of the last program execution, it is logical to conclude that the program will not rerun because it already ran for the schedule in the advert. Let’s find out.
Notice it starts with the policy being deleted for the advertisement and then added back after the system is added back to the collection. But then notice at the bottom that the program is (re-)scheduled to run even though it already ran once from the same advertisement.
The conclusion to draw here is that the client does not actually maintain any knowledge that the advertisement previously existed or even executed so it schedules another execution of the program. This does in fact line up with our conclusion in scenario 3 above: the client does maintain a status of previous program executions but in this case, the setting Always rerun program tells the client to not care about previous execution status.
Rerun if failed previous attempt/Rerun if succeeded on previous attempt
These two are also essentially opposites and behave as expected according to our two conclusions from above:
-
Clients have no memory of advertisements or their schedules once the advertisement is no longer applicable to that client
-
Clients do maintain past program execution status even if the advertisement that caused them to run is no longer part of the client’s policy
This second conclusion is important for these last two settings and is what differentiates them. In all scenarios, if a new execution time is dictated — by a new schedule, new advertisement with a new schedule, or an advertisement removed and then re-added to a client — the status of the previous execution attempt is evaluated first and according to which setting is chosen — succeed or fail) the client either runs or does not run the program again. If the program never executed before then no comparison is needed and the program simply executes according to its schedule. The below snippet shows an advertisement set to Rerun if failed previous where the program ran successfully according to another schedule and thus did not rerun. The same behavior occurs if the situation is reversed: the advertisement is set to Rerun if succeeded and the previous attempt failed. Of course, if the previous execution status does match, then the program will run again.
The only real question to address with these options is what constitutes a failure or success? These statuses are explicitly determined by the return codes return from the executing the program. So what return codes mean success and which mean failure? That’s defined in the site control file:
PROPERTY <Success Return Codes><REG_SZ><{0}><0>
PROPERTY <Reboot Return Codes><REG_SZ><{1604,1641,3010,3011}><0>
Any program execution
returning one of the above will be considered a success. Any not returning one of the above are considered a failure. The failure codes are not explicitly defined because it is essentially an open-ended set. There are a handful of return codes that will trigger an automatic program retry; I covered this in a previous post: http://myitforum.com/cs2/blogs/jsandys/archive/2011/01/16/configmgr-and-failed-program-retry.aspx.
So where are program execution results stored? In the registry: HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile ClientExecution History (remove the Wow6432Node if on a 32-bit client). There will be separate sub-keys for the different contexts that programs have run under.
A handful of notables
-
Rerun if failed previous is the default option and is set by the new advertisements wizard; you must manually change this.
-
If you right-click an advert and select Re-run Advertisement, it will automatically flip the advertisement to Always rerun program.
-
Rerun if failed previous will not automatically rerun a program. Programs will only run according to the schedules defined in applicable advertisements — I covered this in the same previous post that I mentioned just above.
Summary
Not much to sum up except to re-state my two main conclusions, add a few, and consolidate the expected behavior in a table. In general scenario 1 and scenario 2 results are as expected (to me at least). Scenario 3 is where things got a little interesting because of our first conclusion which is independent of past program execution — this is worth listing as a third conclusion also because it cements the fact that advertisement schedules and past program execution status are two separate and distinct factors.
Conclusions
-
Clients have no memory of advertisements or their schedules once the advertisement is no longer applicable to that client.
-
Clients do maintain past program execution status even if the advertisement that caused them to run is no longer part of the client’s policy.
-
Advertisements and their schedules are independent of past program execution status.
-
New advertisement schedules will always trigger a client action to determine whether the program should run or not.
-
Once an advertisement schedule triggers a program execution, actually program rerun behavior is determined by the Program rerun behavior and the program’s past execution status; i.e., programs rerun only at scheduled times according to the rerun behavior.
Scenario Behavior
Scenario 1 (New schedule, Same Advertisement) |
Scenario 2 (Additional Advertisement) |
Scenario 3 (Advertisement re-applied due to Collection Membership change) |
|
Never rerun advertised program | Program does not rerun | Program does not rerun | Program does not rerun |
Always rerun program | Program reruns | Program reruns | Program reruns |
Rerun if succeeded | Program reruns if previously succeeded only | Program reruns if previously succeeded only | Program reruns if previously succeeded only |
Rerun if failed previous | Program reruns if previously failed only | Program reruns if previously failed only | Program reruns if previously failed only |
1. What happens if the ‘Deployment’ is still out there and your re-install the client? Does that knowledge of Program Execution go away and thus restart the Deployment?
2. What if you go into the deployment and change the ‘Rerun Behavior’ but do not add another schedule? Nothing, I presume? It only evaluates the ‘Rerun Behavior’ upon additional schedules?
I feel that ‘Rerun Behavior’ for Packages is pretty clear-cut. When it comes to OSD TS’s, though, there is some nuance. What if I deploy an OSD TS to a lab of 30 machines with ‘Always Rerun’ set. 6 machines fail, so would I change the behavior to ‘Rerun if previously failed’ and add another schedule?
1. Not sure honestly. Program execution history is stored in the registry so it most likely depends on whether this gets wiped out or not with the uninstall.
2. Unless you add a new schedule, changing the behavior is irrelevant.
For your last question, yes.
Thanks, Jason. I’m finding that on some Labs I have to choose ‘Always Rerun’ on that first schedule because it remembers that TS being successfully run on it before. The problem with that is that after it completes the OSD TS it then grabs policy again and keep imaging itself. I’m flabbergasted that this is typical behavior. See the below blog post discussing this exact behavior.
https://blogs.msdn.microsoft.com/george_bethanis/2014/07/29/why-an-osd-task-sequence-is-triggered-to-re-run-on-a-cm12-client/
Right, because the re-run behavior isn’t per deployment, its per program/TS.
Correct. I’m just trying to determine the best way of handling this going forward. I guess when we refresh labs in the Summer I should just copy the TS and deploy that. My goal would be that I wouldn’t need any Techs to do manual intervention in these areas.