System vs User context in Intune

What does Install behavior actually control?

Install behavior is set per app on the Program tab of a Win32 (.intunewin) app and has two values: System and User. It does not describe where an app ends up; it describes the Windows account that runs your install and uninstall commands.

• System runs the command as the local NT AUTHORITY\SYSTEM account. SYSTEM has full machine privileges, so it can write to C:\Program Files, register services, and write to the HKEY_LOCAL_MACHINE registry hive. It runs whether or not anyone is signed in. This is the default and the right choice for the large majority of deployments.
• User runs the command in the context of the currently signed-in interactive user. It can reach that user’s profile, %LOCALAPPDATA%, and the HKEY_CURRENT_USER hive. It requires a user to be signed in at the moment the command runs, and the command has only that user’s privileges.

A useful mental model: System context is about the device, User context is about the person at the keyboard. The installer you wrap still makes its own decision about where to write, so the context only sets the boundaries of what the installer is allowed to do.

When should you use System context?

System context is the default for device-wide application deployment, and you should reach for it unless you have a specific reason not to. Choose System when:

• The app installs for all users of the device (most MSI and EXE installers, line-of-business apps, agents, drivers, and runtimes).
• The installer needs to write to Program Files, create a Windows service, or modify HKLM.
• You want the app to install before anyone signs in, for example on a freshly enrolled Autopilot device.
• The app is assigned as Required to a device group rather than to users.

Because SYSTEM already holds administrative rights, you do not need to elevate inside your command. Your job is to make the command silent and non-interactive; see silent install switches for common installers and the patterns in Intune install and uninstall commands for getting that right.

When does User context make sense?

User context is the exception, used when an installer genuinely depends on the signed-in user’s profile and cannot be made machine-wide. Typical cases:

• Per-user installers that write to %LOCALAPPDATA%\Programs and register under HKCU (some modern app updaters and squirrel-style installers behave this way).
• Scripts that personalize the active user’s environment, profile, or per-user app settings.
• Apps that flatly refuse to install for all users and only support a single-user footprint.

The big caveat is the signed-in-user requirement. In User context the Intune Management Extension can only run the command when an interactive user session exists. If the device is sitting at the lock screen or no one has signed in, a User-context install simply waits. This also dovetails with assignment intent: an Available app installed from the Company Portal always has a user present, whereas a Required app targeted at devices may not.

How does the Intune Management Extension run each context?

On the device, Win32 app processing is handled by the Intune Management Extension (IME), the “Microsoft Intune Management Extension” service, which is installed automatically the first time a device is targeted with a Win32 app or a PowerShell script. IME checks for new Win32 policy roughly every hour, and also after a restart or when the service restarts.

The IME service itself runs as SYSTEM. For a System-context app it launches your command directly under SYSTEM. For a User-context app it uses a helper, AgentExecutor.exe, to drop into the signed-in user’s session and run the command there. You can see this play out in the logs at C:\ProgramData\Microsoft\IntuneManagementExtension\Logs: IntuneManagementExtension.log and AppWorkload.log record the workload, while AgentExecutor.log shows User-context executions. Reading these with CMTrace is the fastest way to confirm what really happened; the full map is in the Intune Management Extension logs guide.

Why does the wrong context cause silent failures?

The classic symptom is “it installs when I double-click it, but Intune says it failed” — or worse, Intune reports success while nothing is actually usable. This happens because your manual test ran as your own elevated user, but the deployment ran as SYSTEM (or as a non-elevated user), and the two environments differ in important ways:

• No mapped drives or UNC profile context under SYSTEM. A command that references the signed-in user’s mapped drive or profile path breaks when SYSTEM runs it.
• HKCU is not the user’s hive under SYSTEM. When SYSTEM touches HKEY_CURRENT_USER it reads SYSTEM’s own profile, not the person’s, so per-user registry writes silently land in the wrong place.
• No interactive desktop. An installer that pops a dialog or expects user input hangs or fails, because SYSTEM has no visible session. This is why silent switches are mandatory.
• Privilege mismatch in User context. A User-context command that tries to write to Program Files or HKLM fails because a standard user lacks the rights, even though it worked when you tested as a local admin.

The fix is always to test in the same context Intune will use. The quickest way to reproduce SYSTEM is to launch a shell as SYSTEM (for example with PsExec) and run your command there. Confirm which account you are in first:

whoami

Under a System-context reproduction this returns nt authority\system; if it returns your own account, you are not testing the context Intune actually uses. For broader isolation steps see troubleshoot Win32 app deployment failures.

How does install behavior interact with detection rules?

Detection rules are evaluated by the same context the install ran in, so they have to point at where the app truly lands. A System-context MSI that installs machine-wide should be detected via its MSI product code, a file under Program Files, or an HKLM key. A User-context app should be detected via a path under the user’s profile or an HKCU key. If a User-context install writes to HKCU but your detection rule checks HKLM, detection never matches and Intune keeps retrying or reports failure even though the app is installed.

Two ordering facts matter here. First, requirement rules (OS architecture, minimum OS, and any custom file, registry, or script checks) are evaluated before detection and before the install command runs, so a failed requirement means the context never even comes into play. Second, detection runs after install in the same account, which is why a context-aware app needs a context-aware detection rule.

System vs User context at a glance

Rule of thumb: start with System. Only switch to User when an installer cannot be made machine-wide, and then make sure both the assignment (a user must be present) and the detection rule (point at HKCU or the profile) are aligned to that choice.