Troubleshooting

Use the information described here to troubleshoot problems.

Note: If the Server Automation Plan is slow to execute, check the refresh time of the Web Reports cache. Set its value to 5 minutes (300 seconds). For setting the cache refresh time, refer to Datasource Settings.

Problem 1: 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:

  1. Immediately after installing the plan engine, go to <BES Root Dir>\Applications\Config and rename the PlanEngine.xml file into PlanEngine.xml.stop.
  2. 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).

Problem 2: 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:
  1. Immediately after installing the plan engine, go to <BES Root Dir>\Applications\Config and rename the PlanEngine.xml file into PlanEngine.xml.stop.
  2. 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:
  1. Go to <BES Root Dir>\Applications\PlanEngine\bin\planengine.bat
  2. 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 Problem 1: 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.

Problem 3: 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:

Note: From SA REST API v9.5.73, there is no multi-node support for secure parameters.
  • 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.

Problem 4: Limitations when managing Step Actions with Non-Master Operators

There can be limitations when managing step actions with non-master operators.

Cause:

In BigFix Server Automation, plan execution and control actions (such as stop, resume, and monitoring step actions) are tightly bound to the operator used to configure the REST API. If a different type of operator attempts to control the plan (for example, to stop a step action), the operation may fail or be disabled due to internal session privilege enforcement. This behavior applies across all Plan Engine versions and is based on the current design of Server Automation and Plan Engine.

Solution:
  • Server Automation Plan Engine binds its session to the operator used to configure the REST API.
  • If a Non-Master Operator (NMO) triggers a plan via a REST API configured by a Master Operator (MO), the plan may start, but the stop and step control actions will be disabled for the NMO.
  • Similarly, if an MO triggers a plan via an NMO-configured REST API, the plan may start, but step actions fail due to privilege mismatch.
  • Full control (trigger, manage, stop) is only supported when:
    • The same operator (MO or NMO) is used for both configuration and execution, or
    • Different MOs are involved (for example, MO1 configures, MO2 triggers).
  • A Plan Engine restart is required after REST API reconfiguration to apply the new session context.