Introduction

Renaming of objects in the Provisioning configuration database requires deletion of the old objects after adding the new ones. This comes from the fact that the cn, which is part of the DN, is used as a display attribute. Procedures exist that handle the deletion task automatically.

In the UserCommon.xml, this flag was not correctly written.

The Identity API has changed. For details, see the DirX Identity API documentation delivered with Web Center.

The object description names for password policies and provisioning rules had to be changed.

Subscription IDs of the C++-based Server were unified. The structure of the subscription IDs is now identical for Windows and UNIX systems. Statustracker subscription IDs no longer include the hostname of the system where it runs, because it may move to another host.

The new format for subscription ID is:

host.jms.module.topic

For statustracker:

jms.module.topic

The old format is:

host.jms.module.host.topic

For statustracker:

jms.module.host.topic

host.libmqjms_dxm.host.topic

For statustracker:

libmqjms_dxm.module.host.topic

An automatic migration routine performs this task during the upgrade configuration when you start the C++-based Server hosting ATS the first time.

Request workflows started with older versions may include an activation date (the workflow creation date) in the order. This causes a ticket creation during processing of the order. Migration eliminates these activation dates.

In older versions, a lot of attributes were managed by an XML structure in the dxmContent LDAP attribute. For performance reasons, these attributes are now represented by LDAP attributes. Without a migration Request Workflow/Activity instances cannot be displayed correctly in the Identity Manager (especially the graphic). Therefore Request Workflow/Activity instances created by older versions are migrated.

DirX Identity V8.3 supports delta handling in realtime workflows. This new feature requires an extension in the XML definition of the realtime channels. (LDAP attribute “dxmContent”).

An automatic migration routine performs this task during the upgrade configuration.

You can run this routine by hand at any time.

The realtime workflows can send JMS events for the event-based workflows. Internally the workflows have an event port integrated that starts a JMS connector. The XML definition for this JMS connector (LDAP attribute “dxmContent”) had some connection parameters defined that were not used by the workflow at runtime. With the integration of ActiveMQ as the JMS messaging system, these parameters were even invalid due to broken links to LDAP objects that no longer existed. Therefore, the XML definition of the JMS connector will now be updated by the migration routine.

An automatic migration routine performs this task during the upgrade configuration.

You can run this routine by hand at any time.

The Certificate Handler is automatically deleted during the upgrade configuration.

It was used in the pre V8.2C versions for the Windows Password Listener. In V8.2C, the feature to distribute certificates and the message server list was assumed by the Configuration Handler adaptor. Therefore, in V8.3, this adaptor is no longer necessary.

This section comprises all issues relevant for V8.3 or V8.3 R2 only.

The JMS-Audit handler is neither configured nor updated automatically as part of the normal installation and configuration. See the chapter in the Installation Guide to upgrade the JMS audit handler.

There are two new special adaptors responsible for the consumption of scheduler and Identity Manager messages:

The Entry Change Start Workflow Listener (or Provisioning Request Start Workflow Listener) is always co-located with the Entry Change Listener adaptor (or Provisioning Request Listener adaptor) and starts event-based processing (or provisioning) workflows.

These new adaptors replace the legacy adaptor Start Realtime Workflow Listener. There are no manual steps necessary.

In V8.6, SSL handling has been extended. For ActiveMQ, only client-side SSL is now supported. As a result, you need to perform the manual steps described in the chapter “Manual Migration” to migrate Windows Password Listeners that connect with SSL to ActiveMQ to connect with client-side SSL.

In V8.7, the use of clear text passwords has been minimized. In older versions, the following features stored clear text passwords in LDAP:

Now these passwords are stored encrypted. See the relevant sections in the chapter “Manual Migration” for details on how to migrate the passwords formerly stored as clear text passwords.

In V8.9, target system-specific adaptors were introduced. In this context, the topic prefix name of the following listeners was changed:

If you upgrade from an older version, for example, V8.5, these changes were not made in all cases automatically. So, you must make the canges manually with Web Admin.

In V8.10, client-side SSL for realtime workflows using either an ADS Connector or LDAP Connector or RACF Connector is supported. Additional connection parameters for this feature need to be put into the XML workflow definition. There are no manual steps necessary.

In V8.10, the LDAP lock mechanism has been revised and improved. For better performance, two new LDAP controls are implemented by the DirX Directory server V8.9 (9.4.454 or higher). These controls are set at the LDAP root in the LDAP attribute supportedControl (DAP attribute name: SCON) if you installed DirX Directory from scratch. If you just do a DirX Directory upgrade installation, these LDAP controls are not set at the LDAP root.

DirX Identity checks at configuration time whether the current DirX Directory version supports these controls. If the LDAP controls are supported, then it updates the LDAP-root automatically if missing. But keep in mind that manual migration is necessary if you decide to upgrade the DirX installation later.

In V8.9, target system-specific adaptors were introduced. In this context, the topic prefix name of the following listener is automatically changed in V8.10: