ConfigMgr Program Rerun Behavior


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:

So where are program execution results stored? In the registry: HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Execution 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.


imageA 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.


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 is cements the fact that advertisement schedules and past program execution status are two separate and distinct factors.


  1. Clients have no memory of advertisements or their schedules once the advertisement is no longer applicable to that client
  2. 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
  3. Advertisements and their schedules are independent from past program execution status
  4. New advertisement schedules will always trigger a client action to determine whether the program should run or not
  5. 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. Geraldo Coant July 22, 2011
  2. Varun November 22, 2012
  3. Jason July 10, 2013
  4. Shrikant May 26, 2015
  5. Azi Sidd July 28, 2016

Leave a Reply