Troubleshooting / Debugging


Problems with AD-Plugin for vCO? Uninstall all old Microsoft-Plugin-Stuff!

Some problems came up getting the ActiveDirectory-Plugin for Orchestrator run. Mostly the problems are related to wrong credential settings in the configuration:

If you had the (old) Micrsoft-Plugin installed, you have to uninstall it completely. For details about how to do this, and some explanation, follow this discussion on the forums:

The new AD-Plugin has no WMI-support. Powershell has a good WMI-support. So the PowerSShell-Plugin might fit into the gap? Surely worth to figure out more and draft some ideas for the Roadmap…;-)   Stay tuned!


Fix missing Schema Chart in weboperator-Webview

When using the bundled weboperator-Webview for vCO, current 4.x-versions have a known issue not showing the workflow chart in the schema tab of the webview:

The reason for this is that the installer of the Orchestrator miss to copy some library-files to the proper folder. I first ran into this issue a year ago, and got the solution from VMware support, in the meantime there is an KB article 1029685 about it:

The solution is to copy two library jars from the client installation to the server’s lib folder:

As a workaround, copy 2 .jar files from the Client installation to the server installation.
If you have performed a Client/Server installation:
1. Copy o11n-application.jar and o11n-gui.jar from the directory $INSTALL_DIR/apps/lib/ to the $INSTALL_DIR/app-server/server/vmo/lib/o11n/ directory
2. Restart the VMware vCenter Orchestrator Server.
Note: If you have the VMware vCenter Orchestrator Client installed on a different machine than the Orchestrator Server, you have to copy the same files from the client installation machine to the server machine using the above steps.

The default lib-directory of the vCO-client is C:\Program Files\VMware\Orchestrator\apps\lib, so after copying the files it should look like:

After a restart of the Orchestrator server you should see your Workflow Schema as a chart:


Troubleshooting LDAP-Erros in vCO

VMware vCenter Orchestrator uses LDAP in different flavors:

  • For its own User Authentication (configured in the webbased configuration utility)
  • inside Workflows, e.g. when getting information about the user who started the workflow via Server.getCurrentLdapUser()
  • in Plugins (e.g. the vCO-Plugin fo Microsoft Active Directory)

Since the Workflow engine runs on a Java-Plattform, even the LDAP-calls are done using Java-Libraries. So if something goes wrong, you will get an JNDI-exception. To troubleshoot such errors, you can do following process:

  1. Get the error code:
    In the “Validation results”-area in the configuration tool, in the Events of your workflow or in the logfiles of vCO
  2. Translate error code to the JNDI-Exception to get a better description:
  3. (Gooogle to find other cases 🙂 )
  4. Fix it!

The common issues are:

  • wrong username / password
  • wrong Distinguished Name
  • vs. Domain\user specification
  • Active Directory password restrcition policy when using the AD plugin

If you cannot find the reason for the error, you can do troubleshooting the hard way: Use another Java-based LDAP-Utility (like Apache LDAP Studio), and try to do the things you expect your workflow to do manually. You should get the same errors…

Good luck! 😉

BTW: If you want to access some LDAP-information which are not exposed via the LdapUser/LdapGroup in JavaScript, you can do as workaround: Use an external commandline-tool like adfind, and call it via Command.execute() in a scripting element.
Download adfind:
Examples for calling external scripts (here powercli, but works with adfind in the same way):


Orchestrator Logfiles

Orchestrator uses the log4j-mechanism (Version 1.2) for logging. The core-platform, custom scripting elements (via System.log()) and the Plugins log to the targets configured in the log4j.xml in %INSTALLDIR%\app-server\server\vmo\conf.


For a description of the possible log-targets view the original log4j-documentation:
Nice examples for the configuration log4j.xml you can find on
Additional there is a snmp-appender for log4j. So you can send snmp-traps for log-events as well. An example configuration:
Page 2 of 212