Guide - IOM 2.12 Migration of Setup and Operations

1 All Existing Server-Types Were Replaced by New Type "Cluster"

All previously existing server-types (property OMS_SERVER_TYPE in $OMS_ETC/ became invalid and cannot be used any longer. The following server-types became invalid:

  • standalone
  • frontend
  • backend

The new server-type cluster was introduced, replacing all previously existing types. As now only one server-type remains, there is no need to have a property for configuration. Therefore the property OMS_SERVER_TYPE was removed completely. Nevertheless the variable is still available in the environment and can be accessed where needed. The fixed value cluster is now set by the script

Along with the change of server-types, the overall high availability (HA) architecture of IOM has changed. HA nodes of distributed IOM installations now require a single IOM application server only. Previously, it were two, a frontend- and a backend-server. All the details can be found in Guide - Intershop Order Management - Technical Overview.

To migrate existing installations, you have to reinstall IOM using the new server-type. Please make sure that data within the DB and on shared file-system are kept safe.

2 All Existing IOM Server-Groups in Ansible4IOM were Replaced

As IOM 2.12 has removed support for server-types standalone, frontend and backend, the according server-groups in Ansible4IOM 1.2 were removed too. Ansible4IOM 1.2 does not support server-groups oms_ha_node, oms_azure_node and oms_single_node for IOM 2.12 and newer. Instead, two new server-groups were added: oms_cluster_node and oms_azure_cluster_node. 

For migration of existing installations, please remove the old installations (please make sure that DB data and data on shared file-system are kept safe), change the server-groups in the inventory file according the following rules:

  • oms_single_node to oms_cluster_node
  • oms_ha_node to oms_cluster_node
  • oms_azure_node to oms_azure_cluster_node

If you use group-files in your config-repository, you have to rename them too. Now you can reinstall IOM with Ansible4IOM 1.2.

3 Extensions of Deployment Artifacts was Changed

The extensions of the deployment artifacts bakery.control-app-<version>.ear and bakery.impex-app-<version>.ear has changed to war.

In the

  1. Change bakery.control-app-<version>.ear to bakery.control-app-
  2. Change bakery.impex-app-<version>.ear to bakery.impex-app-

4 Default Setting of OMS_LOG was Changed

The default value of OMS_LOG in $OMS_ETC/ has changed from "$OMS_VAR/log" to "/var/opt/$OMS_USER.log".

You have to make sure to provide sufficient disk space at the new position of OMS_LOG. Advantage of this change is the separation of OMS_VAR and OMS_LOG. OMS_LOG will not be removed any longer when uninstalling IOM.

5 Deprecated Command Line Switch of

Script $OMS_HOME/bin/ command line switch --var-dir is deprecated (but still working).  Please use --share-dir instead. The change was necessary as the directory importarticle was moved from $OMS_VAR to newly introduced $OMS_SHARE.

6 Health Check of Shared File System Replaces Check of FTP-Servers

As of IOM 2.12 the previously existing mounts of shared file-systems within OMS_VAR were consolidated within OMS_SHARE. The new central shared file-system became now part of the health-check mechanism of IOM. This health-check is controlled by the newly introduced property is.oms.sharedfs.healthcheck ($OMS_ETC/

The previously existing mounts of shared file-systems were not tested by health-checks. Only the two internal FTP-servers were checked. As these FTP-servers were replaced by the new central shared file-system too, the according properties were removed: and is.oms.pdf.healthcheck ($OMS_ETC/

The default value of is.oms.sharedfs.healthcheck is enabled. If you do not have a distributed installation, you do not need a shared file-system. In this case you have to to disable the check of the shared file-system by setting the property to disabled.

The health-check of the shared file-system requires a special directory .healthcheck in the root of $OMS_SHARE. You have to make sure, that this directory exists on the shared file-system.

7 Developer Installations Have to be Configured to Run Without Watchdog

Standalone installations of IOM (< were running without Watchdog. This setup made this installation type the ideal base for developers.

As of IOM 2.12 the server-type standalone was removed, hence a suitable setup of IOM suitable for developers was lost. To enable developers again to setup a system according their needs, a new Ansible4IOM configuation variable in roles/oms_config/defaults/main.yml was added: WATCHDOG_ACTIVATED (set to true by default).

In order to setup an IOM installation without Watchdog, the variable has to be set to false within the config-repository. When changing from an older IOM version to, this change has to be applied to all config-repositories, which are used to setup developer installations of IOM.

The deactivation of Watchdog is only supported for installations consisting of a single oms_cluster_node.


The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets