Restart behavior and exit codes in Intune

What do exit codes tell Intune?

Every Win32 app install command ends with a numeric exit code, whether the command is an MSI, an EXE, a wrapped .cmd, or a PowerShell script. After the command exits, IME compares that number against the app’s return-code table and maps it to one of five result types: Success, Retry, Soft reboot, Hard reboot, or Failed. That result type, not the raw number, is what drives the deployment status you see in the Intune portal and the experience the user gets.

This is the same exit-code-to-result mapping described in return codes and install behavior in Intune; restart behavior is the part of that pipeline that decides what happens specifically when a code signals a reboot. It is worth understanding the full sequence so you know where the reboot decision lands relative to requirements and detection.

What are the default return codes?

When you create a Win32 app, Intune pre-populates a set of common codes so most installers behave correctly without any tuning. These defaults reflect the standard Windows Installer (MSI) conventions, which is why they work for the majority of MSI and well-behaved EXE setups. Keep them in place and only add or change a mapping after you have tested the installer and confirmed the code has a stable, documented meaning.

One rule matters more than any other here: never remap a real failure code to Success to make a deployment look healthy. If a PowerShell script genuinely failed but exited 1, the fix is in the script (exit 0 on the intended success path), not in the return-code table. Masking failures hides broken installs and produces devices that report compliant while running the wrong software.

How do soft and hard reboot codes differ?

Both 3010 and 1641 signal that a restart is needed, but they tell IME very different things about when and who reboots, which is why they are separate result types.

• Soft reboot (3010): the installer finished its work successfully and is reporting that a reboot is needed to complete (for example, files in use that will swap on restart). IME treats the app as installed and can continue processing other queued Win32 apps. The reboot is surfaced to the user according to your restart behavior, but it does not block the rest of the queue.
• Hard reboot (1641): the installer is initiating the restart itself, typically because the system cannot safely continue without it. IME does not start the next Win32 app until the device has restarted. This is why a single app returning 1641 can appear to “stall” the rest of a deployment until the reboot occurs.

Because IME processes Win32 apps on a device serially, a hard-reboot result effectively gates the apps behind it. If you are layering several Required apps onto a fresh device, place any app that legitimately returns 1641 with that ordering effect in mind, and prefer installers that return 3010 where the vendor supports a deferred reboot.

Which restart behavior should you choose?

The Device restart behavior dropdown lives on the Program tab of the Win32 app, right beside the install/uninstall commands and the install context. It has four options, and the same return code can produce a noticeably different user experience depending on which one you pick.

Install behavior (System vs User) sits on the same tab. Most Win32 apps run in System context as the local SYSTEM account, which is device-wide and the common default; a restart triggered there affects the device, not just a session. If you must run in User context, remember the user has to be signed in, and reboot prompts then compete with active user work. See Intune install and uninstall commands for how the context choice interacts with your command syntax.

How does restart behavior fit the app lifecycle?

Restart handling is one step inside the broader sequence Intune follows for every Win32 app. Requirement rules are evaluated before detection and before the install command ever runs, so a device that does not meet the OS or hardware requirements never reaches the exit-code stage at all. Only when requirements pass and detection reports the app as not installed does IME run the command and read the result code.

After a reboot triggered by a soft or hard reboot result, detection runs again to confirm the final state. This matters because an app can legitimately report “installed” only after the post-reboot detection passes. If you want the full picture of how install, detect, update, and uninstall connect, the Intune app lifecycle overview maps the whole flow, and restart behavior is the part that governs the gap between the install command exiting and detection confirming success.

How do you verify reboot behavior in a pilot?

The most reliable way to know whether an installer requires a restart, and what code it returns, is to run it the same way IME will and capture the exit code. Test in System context where possible, since that is how the app will usually run, and record the code before you map anything in Intune.

Start-Process -FilePath ".\setup.exe" -ArgumentList "/quiet /norestart" -Wait -PassThru | Select-Object ExitCode

If the installer returns 3010, that confirms a soft reboot is expected and you can let the default mapping handle it. A /norestart (or equivalent) switch is useful here because it lets the installer report that a reboot is needed without rebooting your test machine immediately, so you see the code rather than losing the session. Then assign the app to a small pilot group:

• Start with a Required or Available assignment to a handful of representative devices, not the whole fleet.
• For an Available pilot, install from the Company Portal and watch the toast and any reboot prompt the way a real user would.
• Confirm the device reboots (or does not) exactly as your restart-behavior choice implies, and that detection passes afterward.
• Only widen the assignment once the reboot experience matches your intent.

Remember the timing model while you wait: IME checks for new Win32 app and PowerShell policy roughly every hour, and also right after a device restart or when the IME service restarts. A manual sync (Settings > Accounts > Access work or school > Info > Sync, or from the Company Portal) forces an immediate check-in. This is distinct from the general Windows MDM check-in, which runs on a more variable schedule (commonly around every eight hours). When a hard reboot is involved, the post-restart check-in is what kicks off the next stage of processing.

Which logs confirm what happened?

When the portal status and the device state disagree, the IME logs are the authoritative source. They live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, and CMTrace renders them with proper formatting and color. The most relevant files for exit codes and restart behavior are:

• IntuneManagementExtension.log — overall IME activity, policy check-ins, and service lifecycle.
• AppWorkload.log — per-app processing, including the install command result and the mapped return-code type.
• AgentExecutor.log — execution detail for scripts and certain install actions.
• ClientHealth.log — IME health and service state, useful when processing seems stalled.

Look for the recorded exit code in AppWorkload.log and confirm it matches what you saw in testing. If an “installed” device reports failed, the usual causes are an unmapped exit code or a detection rule that does not pass after the reboot. For a structured way to isolate these, work through troubleshoot Win32 app deployment failures alongside the logs.

What are the common mistakes?

• Remapping failures to Success. It hides broken installs and produces non-functional but “compliant” devices. Fix the installer or script exit code instead.
• Ignoring the difference between 3010 and 1641. Mapping a hard reboot as a soft reboot (or vice versa) misrepresents whether the queue should continue, leading to apps that appear stuck or reboots that arrive unexpectedly.
• Choosing “Intune will force a mandatory device restart” by reflex. Forcing reboots without warning frustrates users. Reserve it for deployments that truly cannot function without one, and communicate the window.
• Skipping the pilot. Assuming an installer is silent and reboot-free without testing is the fastest route to a fleet-wide forced restart in the middle of the workday.
• Not checking the logs. Guessing at status instead of reading the recorded exit code in AppWorkload.log wastes time and leads to the wrong mapping.