Application stuck installing or failing detection: AppDiscovery, AppEnforce and CAS logs

An application that sits on Installing for two hours, fails with "not detected after installation" or never finishes downloading is a familiar Configuration Manager problem (you may still call it SCCM or MECM). The console shows the outcome; the client logs show the reason. In this post I'll follow one deployment through the logs in the order the client processes it, and fix the usual cause at each stage.

Symptoms#

• Software Center shows Downloading with no progress, and the device stays In Progress in Monitoring › Deployments.
• The app shows Installing for a long time, then fails with 0x87D00213.
• The app fails with 0x87D00324 although it's clearly installed, or it reinstalls at every evaluation cycle.
• The app never appears in Software Center, or the device is listed under Requirements Not Met.

Why it happens#

Every application deployment runs through the same pipeline on the client, and each stage writes its own log in C:\Windows\CCM\Logs:

Most failures come down to five causes:

• A detection method that doesn't match reality: wrong product code, path, registry view or script output.
• An installer waiting for input. In system context nobody sees the prompt, so it runs until the Maximum allowed run time (120 minutes by default) expires.
• Unmapped exit codes. Only codes on the deployment type's Return Codes tab count as success, reboot or retry.
• Content the client can't get: not distributed, no usable distribution point, or a cache that's too small.
• A command line the client can't build, such as a .ps1 file called directly.

How to fix it#

1. Force a fresh evaluation#

Note the deployment type name: the log lines about it carry that name, its DeploymentType_… ID and its revision. On the client, run Machine Policy Retrieval & Evaluation Cycle and then Application Deployment Evaluation Cycle from control smscfgrc › Actions, or from an elevated PowerShell prompt:

$ids = '{00000000-0000-0000-0000-000000000021}', '{00000000-0000-0000-0000-000000000121}'
foreach ($id in $ids) {
    Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{ sScheduleID = $id }
    Start-Sleep -Seconds 30
}

2. Check evaluation in AppIntentEval.log#

Search for the app name. Applicability = Applicable, ResolvedState = Installed means a required deployment wants to install it. Applicability = NotApplicable means a requirement rule failed, so fix the rule or the targeting, not the installer. Dependencies are evaluated here too; one that can't install blocks the parent.

3. Prove the detection method#

In AppDiscovery.log, find Performing detection of app deployment type <name> and the result below it. If the app is installed but the log says +++ Did not detect app deployment type, the rule is wrong. Check these traps:

• Windows Installer rules: a new version usually has a new product code.
• File and registry rules: This file or folder is associated with a 32-bit application on 64-bit systems (and its registry equivalent) moves the check to Program Files (x86) or WOW6432Node.
• User installs are detected in the user's context; a system install can't be detected through HKCU.
• Script rules: exit code 0 with STDOUT output means installed; exit code 0 with no output means not installed; a non-zero exit code, or STDERR without STDOUT, means detection failed. Any stray output counts. Unsigned scripts also fail if Computer Agent › PowerShell execution policy in client settings requires signing.

$min  = [version]'4.2.0'
$keys = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
$app = Get-ItemProperty -Path $keys -ErrorAction SilentlyContinue |
    Where-Object { $_.DisplayName -like 'Contoso Agent*' } |
    Where-Object { $v = $null; [version]::TryParse([string]$_.DisplayVersion, [ref]$v) -and $v -ge $min }
if ($app) { Write-Output 'Detected' }
exit 0

Test rules the way the client runs them: from a SYSTEM prompt (for example Sysinternals psexec -s -i powershell.exe), on a device with the app and one without it.

4. Follow the content download#

If Software Center is stuck on Downloading, search CAS.log for the deployment type's content ID. LocationServices.log lists the distribution points the management point returned; DataTransferService.log shows the BITS job and its URL.

• 0x87D00607 (content not found): no distribution point the client may use has the content. Check Monitoring › Distribution Status › Content Status and the client's boundary group; see boundaries and boundary groups explained.
• Content larger than the client cache (5,120 MB by default) can't download. Raise the size under Client Cache Settings in client settings.
• If the source files changed, run Update Content on the deployment type.

5. Read the enforcement in AppEnforce.log#

Here the installer succeeds, but the detection that runs afterwards doesn't find the app, which is exactly what 0x87D00324 means:

Prepared command line: "C:\WINDOWS\system32\msiexec.exe" /i "ContosoAgent.msi" /qn /norestart
Looking for exit code 0 in exit codes table...
Matched exit code 0 to a Success entry in exit codes table.
Performing detection of app deployment type Contoso Agent 4.2 - MSI(ScopeId_.../DeploymentType_..., revision 3) for system.
+++ Application not discovered. [AppDT Id: ScopeId_.../DeploymentType_..., Revision: 3]

The default return codes are 0 and 1707 (success), 3010 (soft reboot), 1641 (hard reboot) and 1618 (fast retry, used when another installation is running). For other codes, use Tools › Error Lookup in CMTrace.

Verify the fix#

Editing a deployment type creates a new revision; rerun the actions from step 1 so the client picks it up. Good looks like this:

• AppEnforce.log matches the exit code to a Success entry, the detection that follows finds the app, and later evaluations don't reinstall it.
• Software Center shows Installed, and after Run Summarization the device shows Success in Monitoring › Deployments.

On the device, you want InstallState to be Installed and ErrorCode to be 0:

Get-CimInstance -Namespace root\ccm\ClientSDK -ClassName CCM_Application |
    Select-Object Name, InstallState, ErrorCode

Prevent it next time#

• Test every install and uninstall command silently as SYSTEM before creating the deployment type.
• Prefer Windows Installer or file-version rules; when you need a script, follow the exit code and STDOUT rules.
• Distribute content before deploying, and pilot with an Available deployment to a small collection.
• Packaging for Intune too? See Win32 app not detected (0x87D1041C).

References#

• Log file reference - Configuration Manager (Microsoft Learn)
• Application evaluation technical reference (Microsoft Learn)