Separate ConfigMgr content failures from detection failures before you repackage for Intune

When to Use This Guide

Use this guide when a Configuration Manager application installs from one distribution point and fails on remote clients, and the team is about to rebuild the same package as an Intune Win32 app.

Typical signs:

• The application works for clients on the same boundary group as the distribution point
• Remote clients stay at downloading, waiting, or past due
• Detection says installed on some clients and not installed on others after the same deployment
• Someone has already exported the source files to wrap as .intunewin

Do not treat an Intune Waiting state as proof that the ConfigMgr package was healthy. Fix or classify the ConfigMgr failure first.

The AppEnforce.log excerpt in Step 3 is an illustrative reference example checked against Microsoft documentation, not a lab capture. It shows installer exit 0, then a detection miss. It is not a content-distribution survey.

Already wrapped and assigned in Intune? This page is the ConfigMgr side. If the Win32 app is already in Intune and sits at Waiting, Pending or Failed, go to Intune Win32 app install stuck at Waiting and work through the Intune Management Extension evidence there.

For the broader coexistence decision, use Intune or Configuration Manager.

Scope and Assumptions

This guide covers Configuration Manager application deployments (not packages and programs, and not task-sequence steps).

It assumes you can:

• Open the application and deployment IDs in the console
• Read client logs under C:\Windows\CCM\Logs
• Check boundary groups and content distribution status
• Compare the ConfigMgr detection method with the Intune Win32 detection rule you plan to use

Primary sources: Troubleshoot application deployment in Configuration Manager and the Configuration Manager log file reference.

Two different failures

Write down the application ID, deployment ID, collection, and distribution point topology before you change the package.

Content miss or detection lie: the checklist

Tick the boxes on one failing client. The logs live in C:\Windows\CCM\Logs; the descriptions of what each log records come from Microsoft's log file reference. Record what the client actually wrote, not what you expected it to write.

It is a content miss if:

• LocationServices.log or CAS.log shows the client never obtained a distribution point location for the content. LocationServices.log records the client looking for DPs; CAS.log is the Content Access service that maintains the local cache.
• ContentTransferManager.log shows the download was never scheduled, or started and never finished.
• DataTransferService.log shows the BITS transfer failing or stalling.
• AppEnforce.log has no enforcement entry for this deployment type: the installer never ran.
• The console shows the content is not in Success state on a DP that the client's boundary group can use.

It is a detection lie if:

• AppEnforce.log shows the install command ran and the exit code was treated as success.
• AppDiscovery.log still reports the deployment type as not detected after that enforcement, or reports it detected before anything was installed.
• The installed state you can verify on disk (uninstall key, file version, registry value) does not match what the detection method checks.

It is neither, yet, if:

• AppDiscovery.log never mentions the deployment and AppIntentEval.log shows no applicability or requirement evaluation for it. That is a policy, collection or requirement problem. Fix targeting before you touch content or detection.

A content miss is fixed in ConfigMgr distribution and boundaries, and it does not justify repackaging. A detection lie is fixed in the detection method, and it will follow the package into Intune if you copy the rule unchanged.

Step 1: Correlate the identifiers

In the Configuration Manager console, open the application and record:

• Application name and CI Unique ID
• Deployment ID
• Deployment purpose: Available or Required
• Detection method type: MSI, file, registry, or script
• Install context: system or user
• Distribution point groups that should hold the content

On the client, the same IDs appear in the logs. Search for the deployment ID rather than the friendly name.

$LogRoot = "C:\Windows\CCM\Logs"
$DeploymentId = "<deployment-id-from-console>"

Select-String -Path "$LogRoot\AppDiscovery.log", "$LogRoot\AppEnforce.log", "$LogRoot\CAS.log", "$LogRoot\ContentTransferManager.log" `
    -Pattern $DeploymentId -ErrorAction SilentlyContinue |
    Select-Object Path, LineNumber, Line |
    Select-Object -First 40

Expected output shape:

Path       : C:\Windows\CCM\Logs\AppDiscovery.log
LineNumber : <line>
Line       : <timestamp> <application or deployment identifier>

If discovery never mentions the deployment, the client is not evaluating that assignment. Check collection membership and policy before you rebuild the source.

Step 2: Decide whether content ever arrived

Read these logs in this order:

A client that never leaves downloading is a boundary group, distribution point, or network problem. Repackaging that content for Intune does not test those ConfigMgr location services, but it also does not prove the installer is sound.

Check locally that the boundary group can see a distribution point that holds the application:

• The device's IP and AD site match the expected boundary
• The application content status is Success on that DP
• Fallback to neighbour or default site-wide DPs is intended, not accidental

Step 3: Decide whether detection is the liar

If AppEnforce.log shows a success exit code and AppDiscovery.log still reports not detected, stop wrapping the package. The detection method is wrong for the installed state.

Reference example (illustrative)

Illustrative AppEnforce excerpt, checked against Microsoft documentation for the enforcement and discovery sequence. The process exited 0, that code was matched to Success, and status switched to Success. Detection then reported the application was not discovered, and status switched to Failure. Installer exit 0 is not detection. Discovery can still fail after a successful enforce.

Example excerpt:

Common mismatches:

• MSI product code from a bootstrapper, not the installed product
• File rule pointed at the installer cache instead of the installed binary
• Registry rule in the 32-bit view for a 64-bit install, or the reverse
• Script detection that writes to STDERR on the success path

For MSI detection, avoid the Windows Installer WMI provider, which can trigger consistency checks. Use uninstall registry keys:

$ProductCode = "{PRODUCT-CODE-GUID}"
$Roots = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
)

foreach ($Root in $Roots) {
    Get-ChildItem $Root -ErrorAction SilentlyContinue |
        Where-Object { $_.PSChildName -eq $ProductCode } |
        ForEach-Object {
            Get-ItemProperty $_.PSPath |
                Select-Object DisplayName, DisplayVersion, Publisher, PSChildName
        }
}

Expected output shape:

DisplayName    : <application name>
DisplayVersion : <version>
Publisher      : <publisher>
PSChildName    : {PRODUCT-CODE-GUID}

If this key is present and ConfigMgr still says not installed, fix the detection method. The Intune Win32 rule will fail the same way if you copy it unchanged.

The lookup tool has a runbook for each side of this failure. 0x87D00324 is the pattern in the reference example above: the installer exited 0 and the detection rule still evaluated false. 0x87D1041C is the Intune variant, where the app was found once and a later detection no longer matches.

When you rebuild the rule for Intune, generate the custom detection script instead of hand-copying ConfigMgr clauses. The Intune Win32 detection and requirement script builder covers file, registry (both views) and MSI product code checks, and writes STDOUT and exits 0 only when the app is present, which is the contract Intune evaluates.

Step 4: Compare the Intune Win32 model before you migrate

A working ConfigMgr application can still fail as Intune Win32 when:

• The install command is not silent
• The detection rule requires every listed condition, and you copied three ConfigMgr clauses that are never true together
• User-context ConfigMgr installs become device-context Win32 assignments
• The content is larger than the Win32 size limit or depends on a DP-side transform
• A ConfigMgr dependency chain has no Intune equivalent yet

Write the Intune install command with the Intune Win32 install command builder so the silent switch, working directory and return codes are explicit before you wrap the ConfigMgr source. If the wrapping is the slow part, Intune Win32 app packaging tools compared (2026) sets Robopack, Patch My PC, Advanced Installer and PSADT side by side. Installer exit codes 1603 and 1618 are the two failures you are most likely to meet on the first pilot install.

If the application is a common third-party app such as a browser, runtime or PDF reader, check whether a catalog-based tool already publishes it as a maintained Intune Win32 app before you hand-wrap the ConfigMgr source.

Step 5: Recover one pilot deployment

On one failing client:

1. Confirm collection membership and that policy has arrived.
2. Confirm a DP in the current boundary group has the content.
3. If content is missing, distribute it and retry. Do not change detection yet.
4. If content arrived and the installer ran, compare the exit code with the detection result.
5. Correct the detection method against the installed state.
6. Only then export source for an Intune pilot.

Rollback:

• Stop the ConfigMgr deployment to the pilot collection if you need a clean retry
• Do not delete the application object to clear a detection mistake
• Leave production collections on the last known-good revision

Sources

• Troubleshoot application deployment in Configuration Manager
• Log file reference for Configuration Manager
• Related AdminSignal guides: Intune Win32 stuck at Waiting, Intune vs ConfigMgr, Configuration Manager hub

Correction record

24 October 2026 — Relabelled: The AppEnforce excerpt in Step 3 is now presented as an illustrative reference example checked against Microsoft documentation. It was previously labelled as a home-lab capture; it is not a lab-tested result.

26 September 2026: Added an AppEnforce excerpt. Installer exit 0 was treated as Success, then the application was not discovered and status switched to Failure. Installer exit 0 is not detection.