Configuration and Sizing

The distributed engine sizing guide is in development and will be available here when completed.

Requirements

Windows Server 2012

Starting in Verify Privilege Vault version 8.9.000000, DEs require that one of following two server features be installed when the Verify Privilege Vault website is running on a Windows Server 2012. This depends on which protocol is selected in the engine's callback settings. If HTTPS is selected, the HTTP activation is required. If TCP is selected, then TCP activation is required. This accomplished by going to one of the following in Windows Server 2012:

  • .NET Framework 4.5 Features > WCF Services > HTTP Activation
  • .NET Framework 4.5 Features > WCF Services > TCP Activation

If the feature is not installed, there will be an error message in the DE logs: (405) Method Not Allowed. ---> System.Net.WebException: The remote server returned an error: (405) Method Not Allowed.

Distributed Engine Installation

All interaction between the SSC tenant and your on premises network uses our distributed engine service to communicate. The work tasks that distributed engine completes includes Active Directory authentication, password changing, and heartbeat. The machine where the engine is installed must be able to communicate outbound on port 443.

For more information, see the Distributed Engine Overview.

To install the Distributed Engine:

  1. Navigate to Admin > Distributed Engine

  2. Click the Add Engine button, and in the Download Engine window select the related Processor Architecture for either 64-bit or 32-bit, and select the related Preconfigured Site. Click Download now.

    You can install distributed engine on your workstation or laptop for testing purposes, but for production installs, the distributed engine server should be installed on a server. Verify Privilege Vault uses the distributed engine to communicate with your domain, so if your machine is turned off, users cannot log on with their domain accounts, and heartbeat and remote password changing will fail.
  3. Run setup.exe as an administrator to install the engine service. This will install into Thycotic Software Ltd\Distributed Engine.

  4. Go to Admin > Distributed Engine.

  5. Under the Sites and Engines tab, expand the Pending Engines section. After you have installed an engine, it should appear here.

  6. Select the engine by checking the box next to it, and select the related option - Assign and Activate Selected Engines, or Assign Engines. The Activate window will appear.

  7. In the Site drop-down list select New Site to add a new site, Default - to add your default site, or select the related site from the list. Click Activate. The site with assigned engine will appear in the list of all the sites below. Expand it to view the details.

  8. Validate the engine's connectivity:

    1. Under the Sites and Engines tab, click directly on the related site.

    2. On the Site page under the Site tab, click Validate Connectivity, then in the Validate Connectivity window set the related Timeout in seconds (how long in seconds to wait for a successful round trip from site to bus to engine back to site), and click Validate. It may take several minutes for the engine to register. If it does not immediately validate wait a few minutes and try again.

    Configuring Engines for PowerShell Use

    Secret Server can be configured to use PowerShell for several key task types:

    • Discovery

    • Secret Heartbeat

    • Secret Password Change

    • Script Tests

    However, customers using PowerShell extensively for these tasks may experience high CPU usage, as PowerShell is more resource-intensive compared to cmd or bash. To address this, you can limit the number of "shells" (tasks) a user can run on a machine. These "shells" represent the tasks the engine is executing under the user account associated with the Engine Service.

    This limit is controlled by the MaxShellsPerUser setting for WinRM, which PowerShell uses. You can configure this setting through Group Policy, the registry, or directly with PowerShell. If MaxShellsPerUser is set, the engine will only execute the allowed number of PowerShell tasks and queue any additional tasks in the Service Bus for later execution. If it’s not set, the engine will run tasks as normal without restriction.

    In cases where PowerShell scripts are unreliable or prone to timeouts—especially under heavy loads from Secret Server—the engine may encounter issues. Since the Distributed Engine allows scripts to run for up to 15 minutes, extended timeouts can cause problems. To mitigate this, you can use the Prefetch feature, which controls how many tasks the engine can consume at one time. For instance, you could limit the number of concurrent Secret Heartbeats by setting a specific prefetch value.

    Additionally, a configuration setting allows you to match the prefetch count for all consumers that use PowerShell to the MaxShellsPerUser value. This setting can be found in the app-prefetch.config file located in the application directory.