Deployment Architecture to Scale Job Engine

The article discusses different deployment architecture scenarios to scale Privileged Access Manager (PAM) utilizing multiple job engine components.


PAM uses Job Engine components to automate scripts executed on managed servers and end-points.

Such scripts include password resets, removing accounts from local Administrator group on Windows computers or privileged account discovery.

PAM WEB Application manages policies and rules to define when and which scripts will be executed on certain servers.

Job engine component actually executes the script and passes the result back to PAM Vault.

Each job engine components is capable to execute multiple scripts in parallel on several different servers using several threads (configured on the Administration / Settings screen).

However, in some cases it is desirable to scale the script execution even more or to target servers in isolated networks.

Component Architecture

PAM contains several components.

When PAM is deployed on a single host all components are installed on the same server and they communicate between each other inside this server.

One of these components is Jobs Engine. Jobs engine connects to a central PAM Vault using the shared database or directly using HTTPS protocol – more about it later.

Job Engine executes jobs from the jobs queue on remote managed servers and updates the job queue with the results.



Job engine could be installed on a separate host than the main PAM WEB application to improve performance of the job execution or to target servers in the networks unreachable by PAM WEB application.

Job Engine should be instructed to use PAM WEB Application to access the job queue.

There are several scenarios connecting Job Engine to the PAM WEB Application each targeting slightly different use case and requiring a slightly different configuration.

Use Cases for Job Engine Deployment

1. Local Job Engines sharing database with the WEB Application

In this scenario, multiple job engines are installed on different computers connected to the same database shared with PAM WEB Application.

This setup helps to improve performance of the job execution with multiple job engines executing jobs from the same queue on servers simultaneously.

PAM balances job execution between several job engines but a job engine can execute any job from the queue.



Configuration for the Local Job Engine setup assumes that PAM server is installed and operating with some external database.

To add new Local Job Engine run PAM setup on a qualified computer, select only Worker process to install (do not select Database) and connect to a Database on the setup screen when prompted. After the installation, new local job engine will start processing jobs from the job queue reducing the load on other job engine nodes.


2 . Remote Job Engines operating in isolated networks

In this scenario Job Engine is installed inside the isolated network that cannot be reached from the PAM WEB Application directly.

In this setup Job Engine connects to the WEB Application using specially created service account using PAM API over standard HTTP(s) protocol.

In this case job engine processes only those records from the job queue the specified service account has access to.

This way system administrators can designate certain records for specific job engines to process.



Configuration for the Remote Job Engine setup assumes that PAM server is installed and operating.


To start configuring remote job engine add a service account in Administration / Local Users to identify new remote job engine. Assign Service role to this account using Administration / Global Roles screen. Grant Record Control: Editor, Session Control: None and Task Control: Execute permissions to the service account for the records that should be served by this remote job engine.

To add new Remote Job Engine in an isolated network run PAM setup on a qualified computer, select Database, Directory and Worker process to install. Make sure that PAM WEB Application is accessible from the remote job engine computer using WEB GUI. Connect newly installed remote job engine with the PAM Server using the following command line command executed from $PAM_HOME folder


bin\PamDirectory.cmd XTConnect web {pam.server} {pam.user} {pam.password}



bin/ XTConnect web {pam.server} {pam.user} {pam.password}



{pam.server} is the URL of the PAM WEB Application (such as

{pam.user} is the service account designated for this remote job engine

{pam.password} is the service account password (or dash to make command to prompt for the password)


This command should return an Ok response when it is executed successfully. If you receive an error message or anything other than Ok, correct the error and rerun the command.

After you receive this Ok response, restart the PAM service (PamManagement or pammanager) on this new remote node to complete the configuration.

After configuration the remote job engine will start monitoring the job queue and execute jobs designated to this remote job engine on the servers in the isolated network.


For installations with enabled Federated Sign In and port different than default https (tcp/443) generate token for Service account and add on remote worker in $PAM/web/conf/ file:




To generate Token:

  • go to Administration/Tokens as a user with Service Administrator global role

  • generate tokens with the IP filter

  • add in IP Filter IP address of remote worker

3. Hybrid setup

It is possible to use multiple job engine nodes connected using different setups described above.

Remote Job Engine configuration could be used to limit the scope of jobs from the job queue even for the networks that could be reached from the central PAM WEB application.

It is also possible to grant a service account an access to all records in the vault so the remote job engine will be used to improve overall performance of the job queue execution.