Are you saying the toolkit interprets it as failed or is it the software distribution system (i.e. SCCM) or both?
If you’re utilizing the Application deployment model in SCCM you can define return codes on your Deployment Types. Setting return code 60012 to Fast Retry, might be a solution.
Currently I am pushing it as a package. SCCM interprets it as a fail and the user does not get a prompt asking if they would like to install now or defer again.
As far as I can tell the toolkit thinks it failed because it says the installation did not complete and the powershell tooltip goes away.
Had a look at the documentation:
60012 A UI prompt timed out or the user opted to defer the installation.
When the toolkit detects a deferral, all that happens is that the toolkit subtract 1 from the string DeferTimesRemaining of the corresponding subkey of your deployment in HKEY_LOCAL_MACHINE\SOFTWARE\PSAppDeployToolkit\DeferHistory.
AFAIK it does not add any mechanism to re-run the deployment, so that will have to be triggered elsewhere. Not sure how you accomplish that when deploying it as package in SCCM (I only use packages in OSD/Task Sequences myself, i.e. where the circumstances are more predictable).
I’d recommend you to have a look at the Application model rather than Packages where you have a detection method of each deployment type (which most of the times is a MSI Product Code), and the deployment will re-run until the application is detected on the target device.
So that is the expected behavior, if I were to get it to push again then they could still defer the standard 2 more times before it would force them to accept it.
That helps
I’ll take a look at applications and see what I can figure out.
A couple of heads up / gotchas regarding the application model is that (1.) the (CM) Client Settings dictates the interval of re-evaluation of software deployment and (2.) due to the default settings (SCCM Application Model and Powershell Application Deployment Toolkit combined) allows for up to four weeks deployment windows of a single application. So in short: don’t allow deferrals for critical third party software updates.
I do use the toolkit for some critical updates (flash player for Windows 7 for example) but I tend to make those silent, and allow reboot pass-through in the script, rather than having the script asking the user to close a given application (iexplore).
Obviously there’s more to learn about the application model, but most other things are pretty straight forward.
Settings for packages should be like below when you want to use the deferral prompts etc:
The program for the package needs to be set to run --> Only when a user is logged on and Allow users to interact with this program
The deployment schedule you should set to --> Occurs every 1 days effective <date> <time> and the Rerun behavior --> Rerun if failed previous attempt.
So if the user defers the installation the toolkit will report an exit code of 60012 and sccm will treat that as an error and will then rerun/retry the deployment the next day. It will retry this until all deferals are finished or the application has been installed successfully.
