Using PSEXEC to Manually Test System Context Installs

MDMs and PCLM tools typically install applications in the System Context to allow all users of the PC to utilize the installed application.

Photo by Pixabay on

In order to accurately test (we call this a pre-flight test) packages prior to deploying them with your MDM, you will want to leverage PSEXEC. This will ensure that the manual installation test correctly mimics the System Context installation that will be performed by your MDM.

Install PSEXEC

• Download Sysinternals Suite from
• Save to Desktop
• Right-click on the ZIP and select Extract all then Extract

Copy PSEXEC apps into the System Folder

• Copy PSEXEC.exe and PSEXEC64.exe from the extracted folder to C:\Windows\System32 folder

Run the installation using PSEXEC
• Run Command Prompt as Administrator
• Type psexec \ -i -s cmd.exe (this will open a new command prompt window; Note – for VMS type psexec -i -s cmd.exe)
• Type whoami to confirm that it is running as NT system user

Now you are ready to test the installation of your application using the command line which is now running in System Context.

Let me know if you have any questions or comments about these instructions!

3 Simple Steps to Deploying Win32 Applications with your MDM

Application management for Windows is hard. There is so much variation in the types of application packages that need to be deployed, moving from a PCLM tool to a modern tool like Workspace One can feel like TOO big of a job to do all at once.

Photo by on

Never fear! All problems can be solved if you look at them in meaningful chunks.

There are three segments of the application deployment process that need to be addressed if you are going to make the move to Modern Management:

  1. Packaging
  2. Install Context
  3. Logging

Depending on how mature your organization is on these three aspects of application deployment, you may find moving to Modern Management easier than you thought.


In our organization, we already had a very mature capability for Packaging our hundreds of natively installed applications.

What do I mean by mature? In our case, the bits that needed to be installed were wrapped in a script (e.g.- VBS, Powershell) which performs a series of pre-execution checks (for example – is the app already installed), executes the required installation command(s) in a specific sequence, and produces a log file. A standard format README file is also created for each package to indicate details such as installation command line, how to know when the installation is completed, installation context, reboot required, etc.

This consistency allows every application whether a single MSI, Executable, or combination or series including transforms and patches to be installed in a consisten and repeatable way. The process is executed the same way every single time.

Our MDM toolset is able to deploy application in ZIP format which aligns perfectly with the package approach that I just described. Please note that NOT ALL MDMs are able to deploy ZIP format. If you are using an MDM that does not support deploying ZIP format, then you will need to create a format that is supported by your MDM. A word of caution, creating a format such as MSI or EXE may or may not be supported by the vendor so ZIP is really a nice format to be able to use.

Install Context

The vast majority of applications should be installed in the System Context rather than the User Context. This eliminates concerns around whether the user of the PC has Administrative rights for installation of applications. It also ensure that the application is installed for All Users on the PC instead of for a single user. If you need to manually test whether the application successfully installs in System context, you will want to use PSEXEC to execute the installation. I will share more in a future post about how to use PSEXEC to install in System context manually.

95% or more of our application packages were built for installation in the System Context so that made our move to Modern Management easy. For situations where existing packages were being installed as User Context, we revised the packages to eliminate the need. In some cases, it was just a matter of deleting unnecessary code. In other cases, we leveraged Active Setup to copy needed files to user directories. If the packages could not be revised, then we leveraged a third-party tool to provide automatic elevation for User Context package installation on our PCs.


I am a very lazy coder so it is pretty funny for me to identify logging as the last item in the must haves list. It is important that the installation logs that are created by your packages write to a consistent location and that the location is easily accessible by a Standard User on the PC. No matter how great a package you have created, when you begin deploying a package with an Electronic Software Distribution tool you will see errors in installations and you will need quick access to the logs on a PC in order to determine the issue (which is typically within the package and not very often due to an issue with the tool).

I can’t tell you how many times I ‘ve been told, I tested in on my PC and it worked by an App Owner. The reality is that when you take that package and install it on 1,000 PCs you are going to run into scenarios that you did not account for in your package. Logging is essential to identifying these scenarios.

So that’s all that I wanted to share on this topic today. We were able to reuse hundreds of packages that were originally prepared for distribution using a PCLM tool and successfully deploy them with our MDM tens of thousands of times on Windows 10.