SCCM - Application Deployment cycle schedule not working

Question

Hello!
I'm requesting help in troubleshooting an issue regarding the Application Deployment schedule cycle in an enterprise.

Problem:
Application deployments are not re-trying to install as per the evaluation cycle.
The AppDiscovery log shows that the evaluation is taking place in the expected schedule, but the apps that are validated as not discovery, the Retry is not getting trigged automatically.

Situation:
I've changed the Application Deployment schedule cycle to 1 day in the Client Settings.

]1

I deploy Applications as Required and I want to retry the installation every day if the Detection Method keeps failing.
If I run the cycle manually locally the installation gets trigged.
There are no errors in the client logs.
I have a Microsoft ticket open for more than 40 business days but we can't find the cause for this.

Objective: Be able to have the automatically scheduled cycle to trigger the installation of deployed not discovered Applications.

Steps that I took to troubleshoot:

• Checked the local logs - No issues found. AppDiscovery reevaluate apps daily / AppEnforce does not show apps getting trigged as expected.
• Created a dummy Application with a simple MSI, with a Detection Method that will always fail (changed the Product Code);
• Kept all the default settings of the Application / Deployment Type, and didn't add any Requirements or Dependencies.

Thank you!

Answer 1

I'm just putting the final conclusion of this problem.
I found the solution myself, because unfortunately after 3 months Microsoft Support could find the solution. For reference, the Microsoft Case was #28557827.

but I did a new analysis with a wide range of combinations to understand how the installation retry works, and I found that the results do not match with the information provided by Microsoft.
Microsoft’s final analysis was “The installation retry, during the scheduled Application Deployment evaluation (Client Settings), is not related with the Detection Method, but in fact based on the error codes.”

I created a total of 36 applications with the unique combinations of the following criteria, to see when the retry is being triggered.

What I’ve found was that if the Install Behavior is “User Context”, or Detection Method is “True”, or it’s deployed to a User Collection it will never retry the installation, no matter what combination we put it.
Also, It’s irrelevant the type of the Deployment Type (if it’s Script or MSI).

The installation will only retry in the following configurations:

As you can see, no matter what exit code value we have, the retry will always be triggered as long the detection method is false, the install behavior is not user context and the deploy is not user collection.

From my point of view, it makes sense that the detection method should be the main key and the trigger to the reinstallation. Even when the exit code is Success, if the application was not discovered after the installation, the installation retry should be triggered.

We used to deploy Applications as Required to User Collection because that’s how we divide the company (some applications are only installed for specific areas).
For the applications that we can use Install Behavior - System Context - since we always have to use Deploy as required to Device Collection to guarantee that the retry is triggered if necessary, we started to use Requirements in the Deployment Type to do the user separation.
But there are some cases that must run as the User Context (even without admin privileges required). In that ones, we have no solution to trigger the reinstall.
That’s why we use the Install Behavior - System Context when possible, instead of User Context. This is very limited since we might require to install applications with the logged user (for example: to access current user registry keys) with admin privileges, but with this option it’s not possible. Hope this could change in a future version of SCCM.

I’m really sorry, but I must say that I´m very disappointed with Microsoft’s support. All the questions and requests made on this troubleshoot seem always away from the core issue.
It took more than 50 business days for Microsoft to provide the last troubleshoot, which was not the correct solution for this.

Answer 2

Hi,

Could we know this issue happens on one machine or on all machines? If all machines, we could check if there is something wrong with detection method.

If some machine, please check if the evaluation is blocked by Microsoft defender Antivirus, try to close it to see if the problem is solved.

---

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

Hello Amandayou,
Thank you for reaching out.
This is affecting all machines in our company (+4000 workstations). I'm not able to disable Defender because is enable by policy.
The evaluation is not blocked because I'm able to see it in the AppDiscovery log