Successfully Tested On: Windows 7 Enterprise SP1, Windows 8 Enterprise, Windows 8.1 Enterprise, Windows 10 Enterprise versions 1507 - 21H1, Windows 10 Long-Term Servicing Branch (LTSB) versions 1507 & 1607, Windows 10 Long-Term Servicing Channel (LTSC) versions 2015 - 2019
When creating SCCM applications, one of the installation behavior options is “Install for system.” When this option is selected, installs will be ran as the NT AUTHORITY\SYSTEM user to install the application for all users on a computer. The alternative to this is to use the “Install for user” option which will run the installer using the currently logged-on user’s rights.
Generally the “Install for system” option will work fine since the SYSTEM user has escalated administrator rights, but I have seen several instances when executing files as SYSTEM user behaves differently than a standard administrator user (see the end of this post). For this reason, I have found it saves time to test installs by running them as SYSTEM user prior to importing the files into SCCM.
First download PsTools (PsExec) from Sysinternals here: https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
Extract the PsTools.zip folder to your hard drive.
Open an escalated command prompt (right-click, run as administrator) and change directories to the PsTools.zip extracted data. Launch PsExec.exe with the -i and -s switches while pointing to cmd.exe:
PsExec.exe -i -s %SystemRoot%\System32\cmd.exe
At this point a new command prompt window should open. Type whoami to verify that you are now running as NT AUTHORITY\SYSTEM.
You can then use this prompt to run and test your install files.
I mentioned I’ve occasionally seen items execute differently as SYSTEM user than as a regular administrator user.
One of the only consistent issues I’ve seen with SYSTEM user is when creating CLI printer installs. I used to use the built-in Windows printing scripts prndrvr.vbs, prnmngr.vbs, and prncnfg.vbs to install printers. For some reason a few of these VB scripts will not execute properly under SYSTEM user (although they work fine when ran from regular administrator accounts) so I’ve had to resort to other options.
I will sometimes, but very rarely, see an EXE that errors out or doesn’t complete as expected when ran as SYSTEM user. Use the above method to be sure your files will run as expected.
Q's Tech Babble 
[…] Any Administrator user can be specified. If using the built-in Administrator or a directory users, the password will need to be entered and then it will be saved in the task. If using the built-in System user, a password does not need to be specified. Be aware that some actions might execute differently via System user, so be sure to test. […]
LikeLike
[…] the aforementioned visual basic scripts will not complete when ran as the SYSTEM user (see the post Run Command Prompt as NT AUTHORITYSYSTEM to test SCCM Applications to learn how to test such […]
LikeLike