Why Recreating SCCM Application Deployments “Fixes” Issues — and What’s Actually Broken

Introduction

If you’ve worked with SCCM long enough, you’ve probably run into this situation:

An application that was deploying fine suddenly stops installing on devices. Compliance drops, statuses flip to Error or Error with Success, and running client actions doesn’t seem to help.

Then someone recreates the deployment or simply updates the deployment time — and suddenly everything starts working again.

This article explains why that happens, what is actually broken under the hood, and why recreating deployments works even though it doesn’t really fix the root cause.

The common symptoms

In enterprise environments, this issue usually shows up as:

• Required applications not installing on new or existing devices
• Compliance states changing to Error or Error with Success
• Application Deployment Evaluation Cycle not triggering enforcement
• Detection logic confirming the app is already installed
• Recreating or modifying the deployment immediately fixing the issue

At first glance, this looks like an application packaging problem — but in most cases, it isn’t.

What an SCCM application deployment really is

An SCCM application deployment is more than just an application and a detection rule.

Behind the scenes, it includes:

• A Configuration Item (CI)
• A CI version
• Policy references tied to that CI
• Evaluation and enforcement logic on the client

When everything is healthy, the client:

1. Receives policy
2. Evaluates the CI
3. Runs detection
4. Enforces installation or marks compliance

When this chain breaks, applications can stop re-evaluating even though nothing changed in the app itself.

Why existing deployments stop re-evaluating

In many real-world cases, the failure happens before installation logic ever runs.

Common causes include:

• CI metadata not being reprocessed on the client
• Delta policy evaluation failures or timeouts
• Clients unable to download or process existing CI versions
• Policy infrastructure issues (Management Point, IIS, SQL) affecting existing policies more than new ones

The key distinction is this:

Existing deployments rely heavily on delta policy processing, while new or modified deployments force full policy regeneration.

Why recreating the deployment “fixes” it

When you recreate or modify a deployment, SCCM:

• Generates a new policy revision
• References a fresh CI version
• Forces the client to fully reprocess policy instead of relying on deltas

That’s why the application suddenly installs.

You didn’t fix the application — you forced policy regeneration.

Why applications show “Error with Success”

This status is confusing but very common in these scenarios.

It typically means:

• Detection logic succeeded (the application is installed)
• CI evaluation failed or timed out
• Compliance evaluation never completed cleanly

From the client’s perspective:

• Enforcement succeeded
• Compliance state could not be finalized

So SCCM reports a mixed result.

Logs to review when this happens

When troubleshooting this behavior, the most useful information is on the client side. You don’t need to read every log — focus on where the chain breaks.

Key logs to review:

• PolicyAgent.log : Confirms whether the client is receiving and processing updated policies.
• AppIntentEval.log : Shows whether application intent and CI evaluation are occurring or timing out.
• CIStore.log : Helps identify CI version processing or corruption issues.
• CAS.log and LocationServices.log : Confirms content location resolution is functioning correctly.
• DataTransferService.log : Useful for ruling out content download issues if enforcement does begin.

If these logs show policy receipt but no meaningful evaluation for existing deployments, it strongly points to policy processing, not packaging.

What to check before recreating deployments

Before using deployment recreation as a workaround, it’s worth checking:

• Whether multiple devices show the same behavior
• Whether new deployments work while existing ones don’t
• Recent site maintenance, IIS restarts, or SQL activity
• Whether other applications are affected in a similar way

If recreating deployments becomes a routine fix, the underlying issue is almost always policy infrastructure health, not the application itself.

Final thoughts

Recreating SCCM application deployments works because it resets policy processing — not because the deployment or application was broken.

Understanding this distinction helps avoid repeated workarounds and points you toward the real root cause when application enforcement suddenly stops behaving as expected.