Intune & ConfigMgr Error Code & Log Lookup

Root causes

• The rule checks the wrong registry view. A 32-bit installer, or a 32-bit install command, writes under WOW6432Node while the rule reads the 64-bit hive.
• A version rule uses "equals" but the installer writes a different string (1.4 versus 1.4.0.0) or a build number that changes on every release.
• An MSI product code detection rule was copied from the previous version; most vendors issue a new product code for each release.
• The installer is a bootstrapper that returns 0 while a child process is still copying files, so detection runs too early.
• A per-user installer ran as SYSTEM and wrote to the SYSTEM profile or HKCU, which a machine-wide rule never sees.
• A custom detection script writes to STDERR, returns nothing on STDOUT, or exits non-zero even when the app is present.

Remediation order

1. 1In AppEnforce.log find the exit code line and the detection state that follows it. Exit code 0 followed by NotDiscovered confirms the rule, not the installer, is failing.
2. 2On a device where the app installed correctly, check the real install location, registry key and version in the 64-bit and 32-bit views.
3. 3Rebuild the rule from those observed values. Prefer "greater than or equal" for versions, and a file or registry rule over a product code for apps that update themselves.
4. 4Run the detection script as SYSTEM (psexec -s -i powershell.exe). It must write to STDOUT and exit 0 only when the app is present.
5. 5Re-deploy to a pilot device and check three states: not detected before install, detected after install, not detected after uninstall.

Root causes

• The app deployed successfully and was then uninstalled by the user or another tool. A required app is reinstalled at the next check-in.
• A self-updating app changed its version, so a rule pinned to the old version or MSI product code no longer matches.
• The detection rule was wrong from the start: the wrong path, registry view or product code.
• The identity in the package does not match what the device reports for the installed app.

Remediation order

1. 1Open AppWorkload.log on the device and search for the app ID. Note whether detection ran after a successful install or after a later evaluation.
2. 2Check whether the app is actually installed. If it is gone, find out what removed it before changing the deployment.
3. 3If it is installed, compare the detection rule with the installed version, path and registry values, and correct the rule.
4. 4For self-updating apps use a "greater than or equal" version rule or a file-exists rule, not an exact product code.
5. 5Sync the device from Company Portal or Settings > Accounts > Access work or school > Info > Sync, then confirm the status clears in the Intune admin center.

Root causes

• A custom action failed, such as a script or helper that needs a user session, network share or file the SYSTEM account cannot reach.
• A previous version, or a leftover from a failed install, is still registered and blocks the new one.
• The installer needs permissions the SYSTEM account lacks, or a file is locked by a running process or security agent.
• A pending reboot from a previous install stops the new package from continuing.
• The MSI is a per-user package deployed machine-wide, or the 32-bit and 64-bit packages were mixed up.

Remediation order

1. 1Re-run the exact install command as SYSTEM with verbose logging: msiexec /i "app.msi" /qn /l*v C:\Windows\Temp\app-msi.log.
2. 2Search the MSI log for "Return value 3". The lines just above it name the failing action or error.
3. 3Clear the cause: close the locking process, remove the stale previous version, or restart if a reboot is pending.
4. 4Fix a custom action failure in the package rather than ignoring the exit code. Do not map 1603 to success.
5. 5Redeploy and confirm exit code 0 in the log, then confirm the detection rule passes.

Root causes

• Windows Update, an Office or Microsoft 365 Apps update, or another app deployment holds the global msiexec mutex.
• A hung msiexec.exe from an earlier failed install is still running.
• Several MSI-based Win32 apps targeted the same device and started at the same moment during enrollment or ESP.
• Another management tool or user-run installer is installing while Intune tries to install.

Remediation order

1. 1List the running installers: Get-Process msiexec | Select-Object Id, StartTime. Note which one has been running for a long time.
2. 2If it is the earlier failed install and nothing is progressing, stop that process, then retry the app.
3. 3Otherwise let the other install finish. Intune treats 1618 as retry by default, so a short wait normally clears it.
4. 4If it recurs at enrollment, use app dependencies or reduce the number of required MSI apps installing in parallel.
5. 5Confirm the retry succeeds in the log and the detection rule passes.

Root causes

• The package replaced files that were in use and needs a restart to finish.
• The deployment return codes were changed or removed, so 3010 is no longer mapped to a soft reboot.
• The app behavior is set to "No specific action" or "Determine behavior based on return codes" with a mapping that does not match the installer.
• Detection depends on a file or key that only appears after the restart, so the app reads as not detected until the device restarts.

Remediation order

1. 1Open Apps > the app > Properties > Return codes and confirm 3010 maps to "Soft reboot". The defaults are 0 and 1707 success, 3010 soft reboot, 1641 hard reboot, 1618 retry.
2. 2Set the Device restart behavior to match your change policy, and tell users when a restart will be requested.
3. 3If detection needs the restart, schedule it, or change the rule to something that exists before the restart.
4. 4Restart a pilot device and confirm the app moves to Installed and detection passes.

Root causes

• An enrollment platform restriction sets Windows (MDM) to Block, or the restriction that applies to the user blocks it.
• Personally owned Windows devices are blocked and the device is not recognised as corporate-owned (no Autopilot record, corporate identifier or enrollment manager).
• A self-deploying or pre-provisioning device is being reused, and its earlier Intune record keeps the device blocked.
• The MDM log shows DeviceNotSupported with the text "Enrollment blocked for AP device by SDM One Time Limit Check".

Remediation order

1. 1In the Intune admin center go to Devices > Enrollment > Device platform restriction. Open each restriction that applies and set Windows (MDM) to Allow.
2. 2If personal Windows devices are blocked, register the device as corporate-owned (Autopilot or corporate identifier) instead of loosening the policy.
3. 3For a reused Autopilot device: Devices > Windows > Enrollment > Windows Autopilot devices > select the device > Unblock device. Delete the stale device record if it exists.
4. 4If the message says too many devices, that is error 0x80180013. Check the device limit restriction.
5. 5Retry enrollment and confirm the DeviceManagement-Enterprise-Diagnostics-Provider log stops reporting DeviceNotSupported.

Root causes

• The user already has the maximum number of enrolled devices under the device limit restriction.
• Old, retired or rebuilt devices are still registered to the user because they were never removed.
• The device limit restriction is lower than the number of devices the user legitimately needs.

Remediation order

1. 1In the Intune admin center open Users > the user > Devices, and delete or retire the stale devices.
2. 2Check Devices > Enrollment > Device limit restrictions for a lower limit assigned to this user or group.
3. 3For shared or bulk deployments, enroll with a device enrollment manager account or use Autopilot with a pre-assigned user.
4. 4Retry enrollment after the stale records are removed.

Root causes

• MDM automatic enrollment is turned on for the user and the legacy Intune PC software client (the old agent) is installed on the device.
• The device is still under another management authority that blocks MDM enrollment.

Remediation order

1. 1On the device, check Programs and Features for the legacy Intune client. Uninstall it if it is present.
2. 2Run dsregcmd /status and confirm the join state and tenant are what you expect.
3. 3Review the DeviceManagement-Enterprise-Diagnostics-Provider Admin log for the enrollment event and error.
4. 4Only if the old client cannot be removed, change Entra ID > Mobility (MDM and MAM) > Microsoft Intune > MDM user scope for the affected users, and put it back afterwards.
5. 5Retry the Entra join or automatic enrollment.

Root causes

• The user UPN uses an unverified or non-routable suffix such as .local (joe@contoso.local).
• MDM user scope is set to None, so the user is not in scope for automatic enrollment.
• The device has no valid Entra ID join or primary refresh token, so the enrollment task cannot authenticate.

Remediation order

1. 1Open Task Scheduler > Microsoft > Windows > EnterpriseMgmt and check the last run result of the automatic enrollment task.
2. 2Look for event 76 in the DeviceManagement-Enterprise-Diagnostics-Provider Admin log.
3. 3Give affected users a verified, routable UPN suffix in Active Directory Users and Computers.
4. 4Check Entra ID > Mobility (MDM and MAM) > Microsoft Intune and set MDM user scope to Some or All, including the affected users.
5. 5Run dsregcmd /status. If AzureAdPrt is NO, sign out and back in, then run gpupdate /force and retry.

Root causes

• The device does not have a physical TPM 2.0. Virtual machines, including Hyper-V virtual TPMs, and TPM 1.2 chips cannot use self-deploying mode.
• TPM attestation endpoints for the TPM vendor are blocked by a firewall or proxy.
• Specific TPM firmware has a known attestation problem, for example Infineon SLB9672 firmware 15.22 with an EK certificate.
• The ESP timeout is shorter than the time needed to install the required apps and policies.
• The Windows version is too old: self-deploying needs 1709 or later, and 1809 or later for hybrid join.

Remediation order

1. 1On the device run Get-Tpm and confirm TpmPresent, TpmReady and a 2.0 specification version. A virtual machine cannot use self-deploying mode.
2. 2Open the ModernDeployment-Diagnostics-Provider Autopilot log and note which phase timed out.
3. 3Allow the TPM attestation URLs for your TPM vendor through the firewall and proxy, and bypass TLS inspection for them.
4. 4Update the BIOS and TPM firmware from the OEM, particularly for the Infineon and Intel firmware TPM attestation issues.
5. 5If the timeout is during the ESP, raise "Show an error when installation takes longer than specified number of minutes" and remove non-essential blocking apps.
6. 6Delete the stale device record in Intune, reset the device and retry.

Root causes

• The endorsement key (EK) certificate cannot be retrieved or validated, often because the TPM vendor URL that serves it is blocked.
• The TPM is virtual, disabled, in a failed state or a version that does not support attestation.
• Firmware with a known attestation bug, for example Intel firmware TPM on Tiger Lake needing the November 2021 cumulative update or later.
• Proxy or TLS inspection breaks the attestation request.

Remediation order

1. 1On the device run Get-Tpm, then Get-TpmEndorsementKeyInfo -HashAlgorithm sha256 and confirm an EK certificate is present.
2. 2Check the User Device Registration Admin log for the exact attestation failure that precedes the error.
3. 3Open the TPM vendor attestation and certificate URLs to the device, bypassing TLS inspection and authentication on the proxy.
4. 4Install the latest OEM BIOS, TPM firmware and Windows cumulative update.
5. 5If the TPM is in a failed state, clear it from firmware setup. Back up the BitLocker recovery key first, because clearing destroys TPM-held keys.
6. 6Delete the device record in Intune and Entra ID, then reset and retry.

Root causes

• The SoftwareDistribution download or datastore folder is corrupt or has files missing.
• The component store has missing or damaged payload files.
• A security agent or cleanup tool removed update files mid-install.
• On ConfigMgr clients, the update content was removed from the cache before install.

Remediation order

1. 1Merge the Windows Update traces into a readable file with Get-WindowsUpdateLog (it writes WindowsUpdate.log to the desktop), then search it for the error code.
2. 2Stop the update services: net stop wuauserv and net stop bits.
3. 3Rename C:\Windows\SoftwareDistribution to SoftwareDistribution.old, then start the services again.
4. 4Repair the component store: DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow.
5. 5On a ConfigMgr client, restart the SMS Agent Host service and run the Software Updates Scan and Software Updates Deployment Evaluation cycles.
6. 6Retry the update and check the log for the same error.

Root causes

• The update requires user interaction and the install ran when no one was signed in, such as on a kiosk or a device at the sign-in screen.
• The process calling the Windows Update Agent runs in a secondary logon (RunAs) context that cannot show the interactive prompt.
• A deployment ran during Autopilot ESP or first sign-in before a user session existed.

Remediation order

1. 1Merge the Windows Update traces into a readable file with Get-WindowsUpdateLog (it writes WindowsUpdate.log to the desktop), then search it for the error code.
2. 2Sign in to the device and let the installation start, then allow the restart.
3. 3For shared or kiosk devices, set active hours and restart deadlines so installs complete without needing someone signed in.
4. 4If a script or tool starts the install, run it as SYSTEM or in the user session, not through RunAs.
5. 5Retry the update and confirm the log no longer reports WU_E_NO_INTERACTIVE_USER.

Root causes

• The recovery partition is too small for the WinRE update (the well-known KB5034441 failure).
• The Windows Installer service or its registration is damaged, or its startup type was changed by policy.
• A previous version of the component is half-removed, or a file is locked by a security agent.
• A pending restart blocks the new servicing operation.

Remediation order

1. 1Merge the Windows Update traces into a readable file with Get-WindowsUpdateLog (it writes WindowsUpdate.log to the desktop), then search it for the error code.
2. 2Check the Application event log for MsiInstaller events around the failure time. They name the product that failed.
3. 3Run reagentc /info. If the update is the WinRE one, resize the recovery partition or follow the Microsoft guidance for the KB.
4. 4Check the Windows Installer service is left at its default Manual startup type and that no policy changes it.
5. 5Repair servicing: DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow, then restart.
6. 6Retry the update.

Root causes

• The downloaded payload is incomplete or corrupt, often from a proxy, firewall or delivery optimization peer that returned bad data.
• Stale files in SoftwareDistribution\Download conflict with the current update metadata.
• A servicing stack problem stops the handler consuming the downloaded content.

Remediation order

1. 1Merge the Windows Update traces into a readable file with Get-WindowsUpdateLog (it writes WindowsUpdate.log to the desktop), then search it for the error code.
2. 2Stop wuauserv and bits, then delete the contents of C:\Windows\SoftwareDistribution\Download. Restart the services.
3. 3Check that no firewall, proxy or TLS inspection modifies traffic to the Microsoft update endpoints, or to your WSUS or distribution point.
4. 4Run DISM /Online /Cleanup-Image /RestoreHealth and sfc /scannow.
5. 5On Windows 11, Settings > System > Recovery > Fix problems using Windows Update > Reinstall now is a supported repair.
6. 6Retry the update and confirm the download completes in the log.

Root causes

• The configured maximum run time is shorter than the installer really needs.
• The installer is waiting on a hidden prompt, a locked file, or a user who is not there, so it never finishes.
• The maintenance window on the client is shorter than the app run time, so the install is cut off.
• A slow or throttled content download runs inside the allowed time.

Remediation order

1. 1In AppEnforce.log find the line showing the command started and the later timeout. Compare the elapsed time with the configured limit.
2. 2Run the install command as SYSTEM (psexec -s -i cmd) and time it. If it waits for input, fix the silent switches.
3. 3Raise "Maximum allowed run time (minutes)" on the deployment type to a realistic value, and keep it below the maintenance window length.
4. 4Check the client maintenance windows are long enough, and that the client received the policy.
5. 5Redeploy to a pilot device and confirm the exit code is returned before the limit.

Root causes

• The content was never distributed to a distribution point that serves the client, or the distribution failed.
• The client is outside every boundary group, or the boundary group has no content source for its site.
• The distribution point is unreachable from the client: DNS, firewall, certificate or HTTPS mode mismatch.
• The content version on the distribution point is older than the one the deployment now references.

Remediation order

1. 1In CAS.log find the content request and the result. LocationServices.log shows which distribution points were returned.
2. 2In the console open Monitoring > Distribution Status > Content Status for the application and confirm it is on the expected distribution points.
3. 3Check the client IP is inside a boundary group with a content source, and that fallback is set the way you intend.
4. 4Browse to the distribution point content URL from the client to rule out DNS, firewall and certificate issues.
5. 5Redistribute or update the content, then run the Machine Policy Retrieval cycle and retry the deployment.

Root causes

• The WMI repository is corrupt, so the ConfigMgr namespaces such as root\ccm are missing.
• The ConfigMgr client install was interrupted or only partly removed, leaving MOF registrations behind.
• A security agent or cleanup tool deleted WMI repository files.
• The client was installed from a snapshot or image that was not prepared for imaging.

Remediation order

1. 1Confirm the namespace is missing: Get-CimInstance -Namespace root -ClassName __Namespace | Where-Object Name -eq "ccm".
2. 2Check the repository: winmgmt /verifyrepository.
3. 3If it is inconsistent, try winmgmt /salvagerepository and restart the Windows Management Instrumentation service.
4. 4Reinstall the client: ccmsetup.exe /uninstall, remove leftovers in C:\Windows\CCM, then reinstall using your normal client install method.
5. 5Use winmgmt /resetrepository only as a last resort, because it removes data other management software relies on.
6. 6After the reinstall, confirm CcmExec.log and PolicyAgent.log no longer report the error.

Root causes

• A domain GPO sets "Specify intranet Microsoft update service location" and points the device at a different WSUS server than the ConfigMgr software update point.
• Local policy in registry.pol holds Windows Update settings that no longer match what ConfigMgr configures.
• The Windows Update workload is split between ConfigMgr and Intune, and the two sources set conflicting scan sources.

Remediation order

1. 1In WUAHandler.log find the line "Group policy settings were overwritten by a higher authority" and note the server it names.
2. 2Run gpresult /h gpresult.html and find which GPO sets the Windows Update server policy.
3. 3Remove or filter that GPO for ConfigMgr-managed devices so the software update point is the only source.
4. 4If local policy is the cause, back up and rename C:\Windows\System32\GroupPolicy\Machine\registry.pol, then run gpupdate /force.
5. 5Restart the SMS Agent Host service and run the Software Updates Scan and Deployment Evaluation cycles.
6. 6For co-managed devices, check the Windows Update policies workload slider and whether Intune also sets a scan source.

Root causes

• A custom OMA-URI setting where the device returns formatted XML that differs from the XML in the policy, so Intune reads the mismatch as a failure.
• A known issue with a specific policy type where the setting is applied but reported as errored until the next check-in.
• The setting genuinely failed to apply because the CSP rejected the value or the OS does not support it.

Remediation order

1. 1Open the profile in Intune and find the setting that reports Error. Note the device and the time of the last check-in.
2. 2Sync the device and see whether the error clears. A known reporting issue goes away at the next check-in.
3. 3On the device open the DeviceManagement-Enterprise-Diagnostics-Provider Admin log and look for the CSP result for that setting.
4. 4Check the setting is actually in effect (registry key, CSP value or behavior). If it is, the report is cosmetic.
5. 5If the setting is not applied, correct the value or data type. For custom OMA-URI VPN profiles, use the built-in VPN profile type if one exists.

Root causes

• The TPM was reset to factory settings, which removed the device identity stored in it.
• The device record was deleted in Intune or Entra ID while the device still believed it was enrolled.
• A broken Entra registration after a hardware or motherboard change.

Remediation order

1. 1On the device run dsregcmd /status and check AzureAdJoined, and for the MDM section confirm the MDM URLs are present.
2. 2Check Settings > Accounts > Access work or school and look for the work account and its Info > Sync result.
3. 3Open the DeviceManagement-Enterprise-Diagnostics-Provider Admin log for the enrollment or sync error that follows the attempt.
4. 4If the TPM was cleared or the identity is lost, re-enroll the device: remove the work account, delete stale device records, then enroll again.
5. 5After re-enrollment, sync and confirm the device reports compliance within the next check-in.