Troubleshooting Ivanti Automation integration with Ivanti Neurons for ITSM

With Ivanti Automation used for most integration between the Ivanti products, it’s time to discuss troubleshooting.

This blog will discuss troubleshooting Ivanti Automation and Ivanti Neurons for ITSM (Ivanti ISM). This blog can be used for the On-prem and Cloud solution of Ivanti Neurons for ITSM.

Ivanti Automation troubleshooting

The first step is checking the Job History in Ivanti Automation.

Open the Ivanti Automation Console.

Go to Jobs – Job History

When a job fails, a red cross appears in front of the executed job. In the screenshot above, you see failed and succeeded ISM integrated jobs.

Double-click a job for troubleshooting. The tab Jobs is shown.

In the example above, all modules with tasks are successful. But let’s see if we can find some logging.

The first module executes configurations (e.g., creating a user, disabling a user, etc.). The last module in the Runbook should always return to ISM. Depending on the executed modules, this can be completed or failed.

As we have seen before, all modules in the Runbook for the ISM Return (as I normally name the module) are configured with Continue on error.

With the option Continue on error the Runbook will continue the process. But when the job fails, the ISM Return module executes a Condition and sets the parameter p_status.

Either Completed or Failed is added to the Ivanti Parameter.

The screenshots below show an example of a job that fails but returns data to Ivanti Neurons for ITSM (Ivanti ISM).

The Password Reset module failed but the Return to ISM is executed because of the option set to Continue on error.

The Ivanti Neurons for ITSM will stop with the Request Offer workflow and report this to the requester or administrator (based on how the Request Offer workflow is configured).

When a module fails, every single task has different options to troubleshoot. For example, the Execute PowerShell tasks have tabs that show Output and Errors. All Active Directory-related tasks show a Log tab.

But in the Properties, there is also a Result available.

In the screenshot above the result shows the specific account used to reset the password doesn’t exist.

But how do we get here.

Double-click the failed job.
Open the failed module or project.

Select the failed job and select Details or double-click the failed job.
Select tab Agents
Double-click the agent or select the agent and select Details.
Select the failed job, double-click, or select the failed job and Details.
In this example the Result under Properties shows the Account does not exist.
Every task has its own tabs available. The log tab shows more information.

PowerShell tasks show two tabs: Console Output (if a Write-Host is added to the script) and Console Error, which shows the error in the PS Script.

The above actions are the first steps to troubleshoot failed Modules/Projects/Runbooks.

When using the ISM Utility Connector and the job fails check the steps below identifying the issue.

Follow the steps above again to open the Update Record Ivanti Service Manager General job.

Select the tab Logs.

The log should show 6 lines.

The first line tries to create a connection to the ISM server.

The second line shows if the connection is successful or failed.

The third line searches for the Transaction ID set in the ISM_TransactionID parameter.

The fourth line shows if the Transaction ID was found.

The fifth line shows updating the transaction

The sixth line shows if the update is successful or failed.

The most common error we notice is the first line failing. The account used to connect to the ISM server is not correct. It must be a full Administrator account in ISM.

In Ivanti Neurons for ITSM (Ivanti ISM) there are a couple of places to investigate.

When Runbooks are not imported into ISM this could be an API issue.

Check in a web browser to see if the Dispatcher WebAPI is configured correctly and operates.

Execute the following link:

htt(s)://<fqdn or ip address>/Dispatcher/SchedulingService/Help

After a successful login the page below is shown:

Test this action from the Onprem ISM server and check if the connection is successful.

ISM should have the correct connection if the Dispatcher website is available from the Onprem server.

Ensure the credentials and host in the ISM Ivanti Automation Configuration are configured correctly. Check an example of the settings in the screenshot below.

The next step is checking the Integration log to see if Runbooks are imported correctly.

Select the wrench icon for the AdminUI.

Select Integration Log from the Extend – Integration Tools.

Filter Name on IVNT_Automation_Runbooks

The screenshot below shows a successful and failed import of the Automation Runbooks.

Error messages are very vague and will not give the reason of the issue.

Most of the time, it’s either the Ivanti Automation Configuration (host or credentials) or the Ivanti Automation Dispatcher WebAPI that is not configured correctly.

The logs showed when the import succeeded, as shown in the screenshot below.

When the Runbooks are imported successfully, the next action that could fail is the execution of Service Request workflows with Ivanti Automation actions.

Open the Ivanti Automation Transactions.

The transactions can have different statuses (Failed, Completed, Queued or Empty).

When the status shows failed, the Automation Job returned failed because of a failed task in the Runbook.

When the status is empty, there could be multiple issues.

Ivanti Automation Dispatcher WebAPI cannot be reached by ISM.
ISM Connector (ISM Return job) is not working correctly)

When the status is Queued, the ISM return job is not executed. This could be, for example, when jobs in the Runbook don’t have the option Continue on error configured.

This will stop the Automation job; the last job in the Runbook (Return to ISM) wasn’t executed.

Completed shows a successful execution of the Service Request, the execution of the Automation Runbook, and a successful return from Automation to ISM.

Log when the status is empty:

Log when the status is Queued:

Log when the status is failed:

Log when the status is completed:

The failed transactions are investigated mostly in the Ivanti Automation Console. Check the Job History for the failed Runbook and troubleshoot it as described earlier.

For queued transactions, ensure the Continue on error is configured for the tasks before the ISM Return task.

Empty transactions need an investigation of the Ivanti Automation Dispatcher WebAPI and the connection from the ISM server. When Onprem this can be easily tested as described earlier. When using ISM in the Cloud please contact Ivanti Support.

The last option for troubleshooting is enabling DEBUG on the script level. Open the ISM AdminUI by selecting the wrench and select Logging Configuration from Monitor – Applications Logs.