Intune – Comparing System vs User for everything!

One thing which often causes confusion in Intune is the option to “Deploy in User Context”, or System vs User. This and 32/64 bit (which you can read about in Rudy’s blog here) cause the most issues in deployments.

This post will look at the differences between them and use cases for each.

The first thing to note for all options is the Environment Variables (to quickly check type “Set” in a command prompt)

System Context

Temp points to c:\Windows\Temp
Local App Data: C:\WINDOWS\system32\config\systemprofile\AppData\Local
App Data: C:\WINDOWS\system32\config\systemprofile\AppData\Roaming
User Profile: c:\users\Public

User Context

Temp points to c:\users\username\AppData\Local\Temp
Local App Data: c:\users\username\AppData\Local
App Data: c:\users\username\AppData\Roaming
User Profile: c:\users\username

Application Deployment

This is the one most likely to cause you issues when first starting out with Intune.

Working on the assumption that users don’t have admin rights (if they do, you have bigger problems than this!):

System Context

Runs as the SYSTEM user in Windows, full admin permissions, it can access absolutely anything on the system, BUT there is no user profile (well, there is, but it’s of no use) and out of the box, you can’t easily access the logged on user details.

If you want to access the logged in user, you can get creative with PowerShell, or my suggestion is to use PSADT with the ServiceUI.exe (you can read about that here)

This is most suitable for your standard Win32 applications which you would traditionally require someone with elevated rights to install.

Obviously, the one potential issue is around testing, it’s nice to be able to test on a local machine before pushing to Intune. For this, you can use Psexec from the incredible PSTools toolkit

Simply launch an elevated command prompt, navigate to the folder you have saved PSTools in and run this

PsExec.exe -s -i cmd.exe

That will give you a command prompt running in the system context.

User Context

Selecting this, will install applications as the Logged on User, you have full access to the user profile, but nothing outside of that, so writing to Program Files, Windows etc. will fail.

If the application requires elevation, it will also fail during deployment.

This is best suited to Applications which target the user context, the likes of Teams, VS Code, OneDrive which live in %LocalAppData%, MSIX, AppX and some MSI installers. Store apps also fall into this category as these are AppX or MSIX packages.

One other thing to note: If you are wrapping MSI into Win32, you might come across occasions where the MSI itself is hard-coded and forces the User Context. If you find one of these, you can either edit the MSI with something like Orca, or if you wrap it with an installation script (PowerShell or Batch, whatever you prefer) and it will unlock the option to choose.

PowerShell Scripts / Remediations / Application Requirements

The other one which causes issues, PowerShell scripts, whether deployed through the Scripts blade, Proactive Remediations, or an Application Requirements script.

System Context

When running any script in the System context, as with the applications, it runs in the SYSTEM user account.

For file manipulation, this means it can access everything, but again, no access to the user profile without some looping through the c:\users and seeing which user is open at the point of running the script.

For the registry, it has full access to HKLM, HKCR and HK Users, but the HKCU will NOT be the current logged in users.

This is best suited for anything targeting the whole machine or anything you don’t want the user editing!

User Context

Scripts running in the User Context run the same as if a user ran a script directly (although bypassing any execution restrictions) and any interaction will appear on the users desktop.

For file manipulation, it can access the users profile, but nothing outside of that (unless you have tweaked folder permissions). If you are using OneDrive, it’s always worth checking the locations are redirected correctly and also the OneDrive client will need to be running to access the folders.

For registry, you can access anything in the HKCU hive, but nothing outside of that.

This is suited for user customisations, background images etc.

It’s always worth keeping in mind, that anything deployed in the User Context can of course be removed or changed via the users as they obviously have full permissions.

Policies

When using Settings Catalog you may have noticed some of the settings have the option of Device or User settings, the same settings, deployed a different way

System Context

These settings are at the device level, the majority of policies are registry keys so these write to:

HKLM\Software\Policies\Microsoft

They will apply to any and every user logged into the machine, even if your policy is targeting users, if a non-targeted user logs into a machine where the primary user IS targeted, the policy WILL apply to them.

Clearly, being in HKLM, the users will have no way of manipulating these settings

These are best for your critical policies, you don’t want users being able to change bitlocker encryption for example. There are a lot of policies which simply can’t run in the User Context so you won’t find these in Settings Catalog with (User) options.

User Context

These settings run at the user level so the keys are written to

HKCU\Software\Policies\Microsoft

These will target any users who log into the device, as long as the assignment is a user-group.

As with the scripts, any policies deployed at the user level CAN be changed by the users.

These are best for Office and Edge type policies where it’s more for user preference than baselining the machines.

---

Hopefully this clears things up a bit!