Applications deployed on device based collection are missing from devices.

Hi Chetan_SCCM​
this symptom set (apps targeted to device collections not appearing, plus policy not arriving, plus installed apps suddenly reporting Non-Compliant/Error) usually means the policy + state message pipeline broke somewhere, not that every app “went bad” overnight.

A few quick questions first (these narrow it down fast):

• Does this impact all devices or only a subset (e.g., a location/VPN/internet-only)?
• Any recent change in the last week: ConfigMgr upgrade/hotfix, certificate renewal (HTTPS/eHTTP), MP/DP move, boundary/boundary group changes, or co-management workload switch?
• Are user-based deployments still working, or are those also missing?

What I’d check, in order:

1) Confirm devices are still actually getting machine policy
On an affected client, run Machine Policy Retrieval & Evaluation and look at:

• PolicyAgent.log/PolicyEvaluator.log (do you see new policies being requested/assigned?)
• LocationServices.log (is the client finding a Management Point, correct site, correct boundary group?)

If the client can’t find/reach the MP, device-targeted deployments will “vanish” from Software Center and compliance will nosedive because the client can’t evaluate/report.

2) Verify Management Point health and IIS
On the site side:

• Monitor the MP role status, and check MPControl.log (MP responding/healthy).
• If you use HTTPS/eHTTP: check for TLS/cert issues and that clients trust the chain. A silent cert/TLS break often looks exactly like “policies stopped arriving”.

3) Validate the device collections are still evaluating properly
If collection membership stopped updating, devices won’t receive deployments anymore:

• Make sure the affected devices are still members of the collections.
• Check collection evaluation health (SMS_COLLECTION_EVALUATOR) and whether incremental updates are working.

4) If policy arrives but compliance is wrong, focus on app detection + state messages
On a client where the app is installed but reported Non-Compliant:

• AppDiscovery.log (detection method returning “not detected”?)
• AppIntentEval.log/AppEnforce.log
• StateMessage.log (are state messages sending successfully?)

If every app’s compliance went bad at the same time, it’s often state messages not processing (server backlog) or client cannot send state (MP/MP auth).

5) Quick isolations that save time

• From the console: Client Notification > Download Computer Policy and see if anything changes (and check BgbAgent.log on the client).
• Test one affected device on a “known good” network/boundary (HQ) to rule out boundary/MP discovery issues.

If you tell me whether it’s all devices or only certain locations, and paste a few lines around the error from LocationServices.log + PolicyAgent.log on one impacted client, I can point to the most likely culprit (MP comms vs collection eval vs state message processing) pretty quickly.

I’ve seen this when machine policy just stops behaving correctly on the client, even though everything looks fine in the console.

On a few affected devices, I’d pick one and validate whether device policy is actually updating (not just user policy). If machine policy isn’t refreshing, device-based deployments won’t evaluate and apps start showing non-compliant even if they’re installed.

I’d also double-check nothing changed recently around boundaries or boundary groups. A small boundary change can suddenly impact a lot of devices and cause both policy and content issues at the same time.

If this started across many devices at once, I’d definitely focus on recent infra or co-management changes rather than the apps themselves.

A few things that might be worth checking:

1. Co-management workloads
   In some co-managed setups, the Client apps or Device configuration workload can switch over to Intune without anyone noticing. When that happens, SCCM won’t deliver device-based deployments anymore and compliance usually drops as well.
   It’s a good idea to review the co-management settings and check the CoManagementHandler.log on one of the affected clients to make sure SCCM is still the authority for apps.
2. Machine Policy issues on the clients
   Another thing that can cause this is the Machine Policy agent getting stuck. If policy evaluation breaks, the device won’t receive new deployments and the compliance state becomes unreliable, even for apps that are already installed.
   You could take a look at PolicyEvaluator.log and PolicyAgent.log to see if there are any errors with policy downloads or evaluation.

These two checks usually help narrow down the cause when device-based deployments suddenly stop working in a co-managed environment

Did you check your boundaries? Is the detection method working?