Working with the restart behavior of Applications in ConfigMgr 2012

This week I will do a small post about working with the restart behavior of installations in combination with the Application Model in ConfigMgr 2012. In previous versions there was sometimes a need to use a batch file to catch some weird installation return codes. The nice thing about ConfigMgr 2012 is that it gives us a possibility to specify those return codes and to react on it. In the rest of this post I will show in three steps how to configure ConfigMgr 2012 to work with return (restart) codes.

Step 1: Return codes

RetuCodeRestThe first thing I always do is running the installation of an application a few times and see which return codes it gives me. Based on those experiences I create, if needed, some extra entries in the Return Codes –tab of the Properties of the Deployment Type. By default the following return codes are pre-defined:

  • 0 – Success (no reboot)
  • 1707 – Success (no reboot)
  • 3010 – Soft Reboot
  • 1641 – Hard Reboot
  • 1618 – Fast Retry

Step 2: Enforce specific behavior

UserExpeBehaThe second thing I do is determining how I think the client should react on the return codes. This can be configured, on the User Experience –tab of the Properties of the Deployment Type, by selecting one of values under Should Configuration Manager enforce specific behavior regardless of the application’s intended behavior?. The following options are available (including small explanation):

  • Determine behavior based on return codes – (Default) The client will perform any action needed based on the return code of the application.
    • Note: In this case a good configuration in the first step is very important.
  • No specific action – The client won’t perform any action.
    • Note: In this case it is possible to completely suppress a restart.
  • The software install program might force a device restart – The client is told that the installation will force a restart.
  • Configuration Manager client will force a mandatory device restart – The client will always perform a restart.

Step 3: Restart behavior

ClieRestSettThe third, and last, thing I do is more a general client setting. From the moment we decide to restart the device we should think about the configuration of the Computer Restart –settings in the Client Settings. The following Device Settings can be configured:

  • Display a temporary notification to the user that indicates the interval before the user is logged of or the computer restarts (minutes) – Default is 90 minutes.
  • Display a dialog box that the user cannot close, which displays the countdown interval before the user is logged of or the computer restarts (minutes) – Default is 15 minutes.


The combination of these three steps gives us a lot of options to work with the restart behavior of installations. In most cases the default configuration is perfect, but in some case some tuning is needed. For example, the installation of an application is not allowed at any time. This can be achieved by either configuring a custom return code in the first step, or by specifying No specific action in the second step.

Note: There are also Maintenance Windows and/ or Business Hours, that can influence the restart behavior. I didn’t mention them here, because, yes they can exist, but there should always be a moment that we “touch” a users’ device and this is about that moment.


24 thoughts on “Working with the restart behavior of Applications in ConfigMgr 2012

  1. hi, nice post thanks! do you know how the client will react during a task sequence to those return code if they’re set to hard reboot or soft reboot?

  2. The following note about “No specific action” is somewhat unclear:
    •Note: In this case it is possible to completely suppress a restart

    Does this mean that No specific action merely tells ConfigMgr to ignore a restart request by an application installer, or does it have some kind of super-power whereby it can suppress ANY attempt by an application to reboot the system? The note above would seem to indicate that it has the supreme power of suppression, but I think it may be just be inaccurately worded.

    I’m just trying to get a definitive answer on this.


  3. It really means what it states. You can change the reaction of the client to a return code of an installer and that includes the reaction to for example a 3010 message of the installer.

  4. To clarify, can it suppress an installer from rebooting a machine? Say, for example, a command line of shutdown -r -t 0? Would it block that? That’s what I’m trying to answer: Can SCCM block a reboot?


  5. Hi,
    I have a vbscript as a program. The vbscript does some checks and accordingly returns a value to SCCM 2007. The value can either be 0 or 3010. So, based on my understanding from this article, if i select the option “Program controls reboot” in the After Running drop down options, then SCCM will reboot if program returns 3010, and it wont reboot if the program returns 0.
    Please advise.

  6. Yes, your understanding is correct. Do keep in mind that this post is written for ConfigMgr 2012, as it gives you some additional options to change the reaction to a return code.

  7. Hi,
    Thank´s for a good explanation!
    I made a transform for msi and filled in the REBOOT = ReallySuppress and did not understand why the computer restarted until I read your blog. It is bad that CM does not cares about what you have typed in the package …

  8. Hi Tony,
    ConfigMgr does care about the configuration, that’s why and how it can respond to the exit code. Because that’s basically all it does, it responds to the exit code of the installation.

  9. Hi!
    Im removing a KB update package with dism using a package. There are other steps after it, but it stops because of the 3010 return code. Is the only way suppressing the reboot to go with TS and select continue with error? As an application requires detection methods, and with packages I can not set behaviour to return codes.

  10. Hi Peter,

    I have a custom Powershell script that I am trying to run via a .bat script that wraps the Powershell command. How would I pass back the return code from the powershell script? Do I write back to a COM object or variable, or can I simply just do ‘exit 0’ or ‘exit 3010’ or whatever I like from the .ps1 and it will be automatically picked up by the ConfigMgr 2012 client?

  11. Hi Michael,

    When you wrap the PowerShell script in a .bat file then the ConfigMgr client won’t know anything about the exit code of the PowerShell script. It will only know the exit code of the .bat file.


  12. I have also found that some applications will return a 1641 code and hard reboot the system. This causes the task sequence to prematurely end. We were using the “/qn” command to suppress the UI which does nothing to prevent a reboot. By changing the command to “/quiet /norestart” the task sequence was able to suppress the reboot caused by the 1641 code, thus allowing the task sequence to continue uninterrupted.

  13. Lets say you use a script to install the application (PSappdeployment). The script includes 4 modules to be installed in a correct order. When running the script manually it automatically restart after the second module (In the middle of the installation). Will SCCM be able to suppress that reboot? To me it dont seem like the exit code here got anything to say, seeing as the installation never finishes.


  14. Sorry for the late reply. I completely missed out on the notification email. ConfigMgr can only respond to an error code that it receives. If you use a script to start an installation and you use ConfigMgr to start the script, ConfigMgr will respond to the result of the script and not to the result of the installation.

  15. What is the behavior if the application is installed as a dependency, the return code is 3010, and the setting is based on the return code? Does the dependent application wait for the user to allow the reboot, or does it still install right away? If it does wait until the reboot completes, how does this not interrupt the deployment of the primary application? I could see the dependent application not installing until the next enforcement cycle runs and sees that it is still not there.

  16. The 3010 return code will cause the dependent application to wait for the reboot to compleet. That indeed might interfere with the installation behavior that you would like to see. In some case it might be easier to use a task sequence to catch that type of behavior. The most important part is test, test, test. Make sure that you understand the behavior and build on that.

  17. Hi Peter,

    I use a vbscript to run an application with all the return codes you have mentioned set in the return codes tab and Determine behavior based on return codes selected. This script has dependencies which reboots and then the execution of the vbscript starts. It has two commands with noreboot command but while it succesfully runs the first one without any problems it reboots before the installation gets completed for the second command. So could it be a diffcode that i need to put in the return code tab or if i use a cmd that wrap the vbscript with whatever return codes to be presented as success to SCCM that would fix this ?

  18. Hi Mank,

    You need to know the exit code that triggers the restart. Once you know that, you can catch it in your wrapper script. Also, make sure that don’t start your second action before the first one is finished.


Leave a Comment