Change the "Fast Retry" interval for Package and Program deployments

Bronze Contributor

Hi all,


I've created a Package and Program for a driver update utility I'm deploying which I've configured to run on a schedule. I've configured my script to exit with error code 1618 (the "Fast retry" exit code) under certain conditions (the computer is running on battery, or an update would require a hard reboot and the user chose to defer).


Unlike the Application model, which I believe has a retry interval of 4 hours when a "Fast retry" exit code is returned, my Program seems to re-run after only 10 minutes.


I found some information that indicated this setting is stored in the Site Control File. From this article on Anoop's site, I learned that as of SCCM 2012 this file is stored in the DB and used the query provided to view it. Sure enough, I think I've found the relevant property under the "Software Distribution" CLIENT_COMPONENT node: "Execution Failure Retry Interval", but editing this directly appears to be unsupported and scary.


Is there any supported way to change this interval?

4 Replies
best response confirmed by Ryan Steele (Bronze Contributor)

@Ryan Steele 

It's actually not unsupported or scary really, it's all just WMI. covers the details (although this does make it look way more complicated that is really is particularily if you use PowerShell). The method that I think you are referring to on Anoop's site though is directly editing the DB which isn't supported though.


Test in your lab environment first of course.


This also sounds like a great blog topic and I haven't created a new one in a couple of months now, so maybe I will this weekend.


@Ryan Steele As a follow-up here, I reached out to the product group as I was going to write some sample code for you, but alas, the SDK documentation is out of date 🤨. I'm trying to figure out what the best and supported path is though.

@Deleted Thanks Jason, much appreciated!


As a workaround, I modified my script to pause for 20 minutes before exiting with error code 1618, but this isn't ideal as it blocks other updates from installing during that interval. 

@Deleted I'd be very interested in what is the best and supported path too.