Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Deployment Manager versions and installation

Updated on July 14, 2022

Frequently asked questions regarding the versioning and installation of Deployment Manager.

What version of Pega Platform is required for Deployment Manager?

The list of supported versions of Deployment Manager and their corresponding platform versions can be found on the Deployment Manager marketplace page, along with a link to download the latest version. See Installing or upgrading Deployment Manager 5.x for the Pega Platform compatibility matrix.

If you want to know more about managing Pega Applications that are not on the same platform version as your Deployment Manager orchestrator system, see Configuring an application pipeline in 5.1.x.

Can cloud customers download new Deployment Manager releases directly from Pega Marketplace?

It is strongly recommended that Pega cloud customers request new versions of Deployment Manager through Pega Support. The newest versions of Deployment Manager are available simultaneously on both Pega cloud and Pega Marketplace.

Provisioning releases through Pega support also ensures that the Deployment Manager orchestrator environment is configured correctly and makes support and future management of orchestrator instance easier. To get started with Deployment Manager on Pega cloud, see Quick-start guide for Deployment Manager on Pega Cloud Services.

Where can I get older versions of Deployment Manager?

Supported versions of Deployment Manager are always available on Deployment Manager marketplace. If a version cannot be found, it is no longer supported.

The oldest supported version of Deployment Manager v3.4 for Pega platform 7.4, which can be downloaded from the Marketplace. We recommend updating the latest version of Deployment Manager for Pega Infinity. Deployment Manager supports v4.8.4 for Pega Platform 8.1 and later.

What is the preferred configuration for installation?

The ideal configuration for Deployment Manager is to install a separate Pega environment, known as an orchestrator.

Install the Deployment Manager application in a separate environment to:

  • Ensure that the orchestrator environment is stable and is not impacted by development and testing activities that happen as part of standard development and release practices.
  • A single orchestrator environment can be used to manage multiple application pipelines across many different Pega environments.
  • It can connect to all different target environments safely. There are often policies in place to prevent lower environments from being able to connect to higher environments and this way you can authorize just the orchestrator to connect to all the target environments and lock down access to the orchestrator. This is the model that matches other tools such as Jenkins, XLDeploy, and so on.
  • The orchestrator environment can be a standard Pega environment configuration typically used for a development environment.
  • This orchestrator environment connects to all the other candidate environments that make up the application pipeline. The orchestrator communicates to the other environments through http or https on port 443.
  • The candidate environments also need to connect to the orchestrator environment to send updates and responses using http or https via port 443.
  • The orchestrator environment also connects to Jenkins if Jenkins tasks are used as part of the pipeline.
  • There are also artifact repositories (Development Repository and Production Repository) that are used to store the application artifacts (such as product rule export archives). All environments connect to the repositories as that is how the development environment publishes and shares the archives to the higher environments.

For more information about the overall Deployment Manager architecture and workflows, see Getting to know the systems and components.

Can my candidate environment exist in different VPCs?

There are two key requirements to make Deployment Manager work across VPCs. The DevOps orchestrator environments must be able to connect through https to all environments (development, QA, production), and all environments must have a shared artifact store such as S3.

The S3 folders are specific to a VPC and are not accessible across to other VPCs. It is necessary to procure and create a repository that can be accessed across all the environments. This includes leveraging any corporate repositories that are already available such as JFrog Artifactory, Azure, S3 or even a network file share, all of which are supported by Deployment Manager.

You also have the option of creating a custom repository for any artifact repositories that are not supported out of the box (see Creating and using custom repository types for Deployment Manager for more information).

If you would like to continue using the Pega provided S3 solution, work with Pega support to provision a cross-VPC compatible S3 bucket.

Can a single system serve as both a development system and an orchestrator?

For on-premises customers, it is recommended to always have a separate environment to the Deployment Manager orchestrator. This is the deployment procedure for Pega cloud customers and provides many benefits to your application.

  • Security- Companies often have policies that prevent development environments, or lower environments in general, from being able to connect directly to higher environments. The Deployment Manager orchestrator can be setup to be the only authorized entity that can connect between the different environments with all the appropriate security privileges enforced, which satisfies this policy.
  • Stability- If a development environment needs to restart or is impacted in any significant way, then the DevOps pipelines running in the orchestrator are not affected. Rolling back an application on the same system as the orchestrator could cause significant issues.
  • Scale- A single Deployment Manager orchestrator instance can manage multiple applications, each of which have their own environment stacks. Keeping the orchestrator separate ensures that all connectivity necessary between the different environments is handled only at the orchestrator and not between the development environment.

How should operators be configured on the orchestrator?

All operators using the Deployment Manager portal should be logging in using the PegaDeploymentManager:Administrators access group.

All users who interact with pipelines via merge requests or App Studio publishing should exist on the system with an appropriate email address if you intend to support email notifications.

Be sure to have each user configure proper notification preference for their needs.

Is the 5.x orchestrator supported with all 4.x candidates?

The 5.x orchestrator is only supported with all the candidates having 5.x PegaDevOpsFoundation and candidates having 4.8.4 PegaDevOpsFoundation.

The generate client secret button is not available after updating to Deployment Manager 5.x

After update to 5.x please ensure that your operator has SuperAdmin Access Group. Only users with appropriate privileges can see this option. Also ensure you are connected to a secure link (https).

How do I know if the client secret has updated?

The recent changes can be validated from Dev Studio, open the Deployment Manager client Registration rule and view history.

Which email account should be configured after updating to Deployment Manager 5.1 for email notifications?

Deployment Manager 5 uses the default email account for sending email notification and email approval please ensure that test connection is successful for default Account.

OAuth configuration

See the following topics for answers to frequently asked questions about OAuth configuration.

Why do I receive a caught exception error when creating OAuth2 clients?

When you configure Deployment Manager version 5.x for the first time, you might receive an error when you create OAuth2 clients.

Perform this procedure if you receive the following error:
ERROR X.X.X.X | X.X.X.X H0ME8A3S0E9LOLZ2TIZY4L0PX2HBLLSXDA DMReleaseAdmin - Unable to complete interaction with remote resource: Caught Exception while creating OAuth2 client Caught Exception while creating OAuth2 client
  1. In Deployment Manager, click SettingsGeneral settings and then, in the Generate client secret section, check the last time that the client secret field was updated.
    If the date in the Generate client secret section is older than the time that you installed Deployment Manager, configure the orchestration server to use OAuth authentication.
  2. Validate the client secret, access token endpoint, and then revoke the token endpoint for the following authentication profiles:
    • DMAgentUser
    • DMStudioUser
    • DMReleaseAdmin
    • DMRelease_Admin_oAuth2 (on candidate environments).

Why do I receive an SSL configuration error?

When you configure Deployment Manager version 5.x for the first time, you might receive an SSL configuration error that the JSSE socket factory cannot be instantiated.

Perform this procedure if you receive the following error message:
ERROR BAS053O9EWPP16VB5JBVK3X08PJW1GM11A - Rule-Connect-REST: - Caught unhandled exception: SSL configuration: unable to instantiate JSSE socket factory - SSL configuration: unable to instantiate JSSE socket factory
  1. Verify that a valid truststore is configured in the Truststore dynamic system setting, that you are using a valid certificate, and that the systems are trusted.

Why do I receive an error that the execution of a job scheduler activity failed?

If you are setting up Deployment Manager 5.x for the first time, you might receive an error that a job scheduler activity failed to run.

Perform this procedure if you receive the following error message:

ERROR BOF3VWNH66ROCH8TL905IZXFP2IMW0DIFA - Exception in executing Job[DeploymentManagerAgentScheduler] com.pega.platform.executor.jobscheduler.scheduler.JobExecutionException: Job Scheduler [DeploymentManagerAgentScheduler] activity [RunDeploymentManagerAgent] execution marked as failed with message [cryptography operation failed, mode:2]. Exception message [-]
  1. Verify that the DMAgentUser authentication profile is configured with a valid client secret ID, access token endpoint, and then revoke token endpoint.
  2. Verify that the DMAgentUser operator is enabled.

Why do I receive the a PRRuntimeException error?

If you are setting up Deployment Manager version 5.x for the first time, you might receive a caught unhandled exception error.

Perform this procedure if you receive the following error message:
ERROR B1U36XYV7N43R4QQCUWASM1L6WAGEE780A - cryptography operation failed, mode:2 2021-11-30 03:08:46,024 [OBSCHEDULER_THREAD_3] [ STANDARD] [ ] [ ] ( ERROR B1U36XYV7N43R4QQCUWASM1L6WAGEE780A - Rule-Connect-REST: - Caught unhandled exception: PRRuntimeException - PRRuntimeException PRRuntimeException
To resolve the issue, verify that the DMAgentUser authentication profile is configured with a valid client secret ID, access token endpoint, and then revoke token endpoint.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us