Managing applications through Configuration Manager in Intune
ConfigMgr 2603 -- Application Deployment Status summarization permanently stale/inconsistent across nearly entire deployment catalog, confirmed not caused by SQL resource contention
We're seeing a persistent, sitewide bug in Application Deployment Status reporting that we've now fully isolated from infrastructure causes through direct SQL-level investigation. Posting the full repro in case others are hitting this on 2603 (previously 2503), since it looks related to the summarization defect referenced in KB32851084 but is not resolved by it.
Symptom
Deployment Status > Error tab shows Asset Details rows that contradict their own Category label -- e.g. a row categorized "Success" or "Already Compliant" sitting under the Error status filter, alongside genuine "Evaluation failed" rows. Error codes across most rows are 0x87D00314 ("CI Version Info timed out") and 0x87D0289 ("Failed to decompress CI documents").
The Asset Details grid total also does not reconcile with v_AppDeploymentSummary. For one specific deployment, the grid shows ~396 total assets across all rows, while the same AssignmentID's Error column in v_AppDeploymentSummary shows 1,620. These are two different data sources feeding the same console view, and neither is internally consistent with the other.
Scope
This is not isolated to one application. Querying v_AppDeploymentSummary across our full deployment catalog (~6,200 AssignmentIDs going back to 2018) shows the overwhelming majority frozen -- ModificationTime unchanged for months to years, in many cases 2,000+ days, despite the console displaying a same-day "Last Update" timestamp on the summarizer as if it had just run.
Ruled out: SQL/infrastructure contention
We initially suspected this was caused by resource starvation on the site server. Investigation of statesys.log (SMS_STATE_SYSTEM) showed intermittent "Failed to get a SQL Server connection" errors (message 600) and "severe error, suspended file processing" events (message 6101), correlating with SQL Server's Maximum Server Memory being set to 90 GB on a ~100 GB co-located SQL + site server host, leaving only ~4.5 GB available memory during business hours.
We reduced Maximum Server Memory to 76,000 MB, restoring ~26 GB of headroom. Following the change:
The SQL connection failures and severe processing suspensions stopped entirely (confirmed via statesys.log over the following 24 hours).
Page Life Expectancy and Buffer Cache Hit Ratio returned to healthy, stable levels.
statesys.log showed SUM_SummarizeAssignmentCompliance actively processing thousands of AssignmentIDs sequentially, starting from our oldest (2018) assignment forward -- confirming the summarization process itself is running.
However, despite this, v_AppDeploymentSummary.ModificationTime has not moved on any previously-frozen assignment, and the Asset Details grid in the console still shows the same Category/Status mismatches and unreconciled totals as before the fix. So whatever SUM_SummarizeAssignmentCompliance is doing, it is not what updates this specific table/column, and whatever process is supposed to do that is still not running or still failing silently -- independent of the SQL resource issue we found and fixed.
Conclusion
This looks like a genuine product defect in the Application Deployment Summarizer / Asset Details reconciliation pipeline, not an environmental or resource issue on our end. We've ruled out the most likely infrastructure explanation with direct before/after evidence.
Questions for anyone who's seen this on 2603:
Is there a documented distinction between what SUM_SummarizeAssignmentCompliance updates versus whatever populates v_AppDeploymentSummary.ModificationTime and the console's Asset Details grid?
Did KB32851084 (2503) or any later cumulative update actually address the Asset Details grid / summary table reconciliation specifically, or only the error-code miscategorization described in that KB?
Is there a way to force a full re-summarization of v_AppDeploymentSummary for a specific AssignmentID (not just "Run Summarization" from the console, which does not appear to touch these rows)?
Happy to share the SQL queries and full statesys.log excerpts used to build this repro if useful for tracking this as a confirmed defect.