Troubleshooting

When the automation plan engines are installed on one or more DSA servers

When the automation plan engines are installed on one or more DSA servers in your environment, each step of the automation plan execution is created several times instead of once. The number of times each step is created is equal to the number of DSA servers, with the automation plan engine installed, present in your environment.

Cause:

In a DSA environment, you can install the Server Automation components on both the servers (primary and secondary), but you must ensure that only one instance is active at any given time. Otherwise, multiple actions are created for each step in the plan, and both plan engine instances process the same plan.

Solution:

To disable the plan engine on a DSA server, perform these steps:

Immediately after installing the plan engine, go to <BES Root Dir>\Applications\Config and rename the PlanEngine.xml file into PlanEngine.xml.stop.
To ensure that it is stopped, check the <BES Root Dir>\Applications\Logs\pe_console.log file. When stopped, no new message is posted on this log file.

Important: In the event of a primary root server failure:

On the secondary DSA server, rename the PlanEngine.xml.stop file back to PlanEngine.xml .
On the primary server, disable the plan engine instance by adding the .stop extension to the PlanEngine.xml file).

Delay in starting the scheduled plans

In a DSA enviroment setup, there can be a delay in starting the scheduled plans.

Cause:

In a DSA environment, the plan engine checks if any plan engine instances exist on the secondary server, regardless of an actual instance running or not. This check is done while the current plan is being processed. This tries to stop the current running instance, which delays the processing of the scheduled plans.

Solution:

Step 1:

Keep only one instance up and running and disable/uninstall the plan engine on the other (secondary) DSA servers. Perform these steps to disable the plan engine:

Immediately after installing the plan engine, go to <BES Root Dir>\Applications\Config and rename the PlanEngine.xml file into PlanEngine.xml.stop.
To ensure that the plan engine is stopped, check the <BES Root Dir>\Applications\Logs\pe_console.log file. When stopped, no new message is posted on this log file.

Step 2:

Perform these steps to use the DSA flag to disable the DSA checks:

Go to <BES Root Dir>\Applications\PlanEngine\bin\planengine.bat
Set VM_ARGS=%VM_ARGS% -Denable.dsa=0 (by default its set to 0 since 9.5.65)

Important: In the event of a primary root server failure:

On the secondary DSA server, rename the PlanEngine.xml.stop file back to PlanEngine.xml .
On the primary server, disable the plan engine instance by adding the .stop extension to the PlanEngine.xml file).

Note:

This solution works only if the plan engine version is 9.5.64 or later.
If you diable the DSA flag but keep more than one instance of Plan engine up and running, then it results in When the automation plan engines are installed on one or more DSA servers.
If the Plan engine version is in between 9.5.53 and 9.5.63, there is no option to disable the DSA checks. In this case, you need to upgrade to the latest version to use the above solution.

Creating an automation plan using Secure parameter Fixlet fails

ActionID is not created and Bad Request error is thrown when an API request is sent to create an automation plan from SA REST API for Secure parameter Fixlet.

Cause:

The current workflow to create an automation plan from SA REST API does not parse for secure parameter fixlet, if Username, Password, and Confirm Password fields are missing when the request is sent from Postman or Swagger.

Solution:

When sending the API request from Postman or Swagger, make sure that the necessary fields for the secure parameter fixlet (Username, Password, and Confirm Password) are included and properly formatted within the request payload.
Follow the steps at Creating an Automation Plan.