Search Engine: Elastic

Article ID: 115694, created on Mar 11, 2013, last review on Jul 14, 2018

  • Applies to:
  • Operations Automation

How to troubleshoot failed 'Executing configuration script' APS tasks

1. Look at the failed task parameters in POA Task Manager to see what exactly task tries to do – configure, install, uninstall, upgrade. The exact command may be found in the task parameters:


2. Look at the arguments passed to APS provisioning script (they are listed in the failed task properties in POA Task Manager) and check if you see something wrong in them (like email address is set to jdoe@costomer which is a malformed address). The parameters passed to APS provisioning have the following format
env_var<ID>_value  PARAMETER_VALUE

where <ID> is the ID of a parameter, or
See the example of parameters passed to APS provisioning script:

3. If you need to change parameters passed to APS provisioning script by task – use the KB article How to change parameters of existing POA task.

4. Look at the failed task output carefully – find the exact error message returned by script during execution and analyze it.

5. If POA is trying execute APS provisioning script for application of the 'External System' provisioning type and communication with external system is done not via HTTPS, login to Provisioning Gateway Host and use the tcpdump utility (or its analogue, e.g Windows Network Monitor or Wireshark) to collect packets sent by POA to an external system. IP address/hostname of external system can be seen in task parameters list.

6. Some application scripts also write log file during execution, so login to a Provisioning Gateway Host and check if there is any log file in the POA_ROOT/APS/instances/INSTANCE_ID/scripts folder, where INSTANCE_ID is the ID of the APS application instance installed in the customer subscription, POA_ROOT by default is /usr/local/pem/ on Linux and C:\Program Files (x86)\SWsoft\PEM on Windows.

7. Some application scripts (for example those of Open-Xchange) have debug parameter, which, if enabled makes script to produce more output. How to understand whether application scripts support debug mode or no – just run the grep utility against the scripts on a Provisioning Gateway Host:
grep -irl SETTINGS_debug /usr/local/pem/APS/instances/INSTANCE_ID/scripts/*
Replace INSTANCE_ID with the actual ID of the APS application instance installed in the customer subscription. If script supports debug mode – edit the script located at /usr/local/pem/APS/instances/APP_INSTANCE_ID and add/set the SETTINGS_debug=on parameter and then try to re-execute provisioning script.

8. You have access to all provisioning scripts in an APS package, they are not encrypted so you can actually open script file and see what it does or even add some debug diagnostics ('print' or 'echo' statement) in some functions to see values of variables, script execution logic and so on.

9. If you see that script sent correct request to an external system and external system replied with error – contact support of an external system and ask why it returned a particular error (collect and provide the exact request and response).

10. Check whether the latest available version of APS package is used in POA - if there is a newer version available, look at release notes/changelog of this new version, perhaps the error you are getting was already fixed in this newer version of package. In this case import the newer version of APS application in question to POA and upgrade application instances to it.

See the main KB article #115664 APS: General information, Best Practices and Troubleshooting for more information.

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF