A quick summary on User/System context for app deployments
I see posts about this on Reddit pretty often. Usually the OP is trying to copy a configuration file to the target user’s appdata folder. They run the script manually on a workstation, and it all works fine, but when they try deploying it through Intune, it fails! What is happening here? Well, in nearly every case, when the OP is testing their script manually, they are running it as the logged in user on their test machine, but deploying it as system with their Intune app. Their script almost always contains a CMD or PowerShell script using variables for a file path of the logged in user. Examples are variables like %appdata% and %username% in CMD files, or $env:userprofile in PowerShell. The screenshot below shows an example. The red box shows examples of command line and PowerShell variables and what they return when I issue them as the logged in user (cookie). Also, you can check to see who the session is running as by using the command whoami:
Generally, we don’t install applications in user context because most applications need admin rights to be installed. But, for Win32 apps (or other scripts) that copy or move files around within the user profile, it’s important to know how your script works and any file path variables it uses. For example, lets issue the same variables we did in the screenshot above from a command prompt running in the system context, and then we will cover how to open a command prompt or PowerShell session as system:
So, if the goal of your script is to do something as the logged in user profile (such as copy a config to a directory within the logged in user’s profile), you can see why the script fails if you are deploying it in the system context when those file path variables are used. If you forgot where to set how an app is deployed, the screenshot below is where you can set to run as user/system for a Win32 App. Once the app has been created, you cannot change this value. You’ll have to rebuild your app if you need to change this:
And if you are using the scripts section in MEM to deploy a script:
How to open a command prompt or PowerShell session as system
There are a bunch of other blogs on this, but I’ll quickly cover it within this post to save you from opening another tab. Download PSTools from this link – https://docs.microsoft.com/en-us/sysinternals/downloads/psexec. Once downloaded, extract the files to your PC. If you will be using the PC for testing in the future, I suggest extracting to c:\windows\system32. Next, open CMD as admin. If you extracted the PSTools files to a directory other than c:\windows\system32, navigate to that directory. Then issue one of the commands below depending on if you want a command prompt or PowerShell session. -s specifies to run as system, and -i specifies an interactive session
psexec -s -i cmd
psexec -s -i powershell
A separate PowerShell window will open. If you type whoami, you will see nt authority\system is returned:
Now you can properly test your scripts from a user or system context!