Submit a ticketCall us

WebinarUpcoming Webinar: Know What’s Changed – with NEW Server Configuration Monitor

Change management in IT is critical. But, even with a good change management process, changes are too often not correctly tracked, if at all. The configuration of your servers and applications is a key factor in their performance, availability, and security. Many incidents can be tracked back to an authorized (and sometimes unauthorized) configuration change, whether to a system file, configuration file, or Windows® Registry entry. Join SolarWinds VP of product management Brandon Shopp to discover how the new SolarWinds® Server Configuration Monitor is designed to help you.

Register now.

Home > Success Center > Network Performance Monitor (NPM) > Check 'Replace a process level token' account privilege of user which runs Solarwinds Orion Module Engine service

Check 'Replace a process level token' account privilege of user which runs Solarwinds Orion Module Engine service

Created by Abdul.Aziz, last modified by Jonathon.Privett on May 02, 2018

Views: 1,322 Votes: 1 Revisions: 10

Updated April 18, 2017


After upgrading to NPM 12 and SAM 6.2.4, Orion fails to validate the login information required to run a test on a customized alert or action, for example, Configure Action: Execute an external program. The following error is displayed after entering the login credentials:

Check ‘Replace a process level token’ account privilege of user which runs SolarWinds Orion Module Engine service.


  • NPM 12
  • SAM 6.2.4


This issue is related to the AD/LDAP login method compatibility.


  1. Create a SolarWinds user account with administrator privileges (local or domain).
  2. Open services.msc and configure the SolarWinds Orion Module Engine service to log on as the user account that was previously created.
  3. Add full control permissions to the script folder for the user account.
  4. Add the user account to the Replace a process level token Local Policy.
  5. Restart the Orion services.


You can also try using the User Principal Name (UPN) login convention, such as, user@domain instead of domain\username on the test page of the alert or action.


If all else fails see this article:


Last modified