Manual Migration

Restore the specific information from the files you backed up as described in the section “Preserving Files” in the chapter “Preparing the Migration” by merging the information in the backup files into the files in the relevant locations.

You only need to update the file dxi_java_home/lib/security/cacerts with the information from the relevant backup.

In older DirX Identity versions, the password and user were taken from an attribute at the ids-j object where the password was stored in clear text. Beginning with V8.7, the user and password are now taken from a specified bind profile. If you use JMS-based auditing, you need to migrate the configured user and password as follows:

In the Provisioning view, the SMTP configuration object for sending e-mail notifications and the SMS Gateway configuration object for sending SMS notifications are located in Workflows → Configuration → Services.

If the Authenticate flag is checked for these configuration objects, the password information for these objects needs to be migrated.

For each configuration object, enter the password in the relevant field and then save the object. Now the passwords are stored encrypted according to the type of encryption mode specified in the Connectivity database’s central configuration object (in Encryption Mode in the Server tab).

You can define notifications in the Connectivity view at the metacp job in the Operation tab. If you have used these notifications with a user and password, you need to migrate the referenced service object, which is usually the Mail Service (Configuration → Services → System → Mail Service).

Open the notification object (it’s usually located below the metacp job object (Connectivity view → Jobs → your_metacp_job → your_notification_object)) and then click the Service link in the Service Definition area to open the service object. Enter the password and save the object. Now the password is stored encrypted according to the encryption mode defined in the Connectivity central configuration object (Encryption Mode in the Servers tab).

We recommend upgrading to the latest version.

After installing and configuring DirX Identity, configure the services according to the section "Runtime Operation" in the chapter "SPML Provisioning Web Services" in the DirX Identity Integration Framework Guide.

After customizing the Provisioning Web Services, merge the relevant configuration information from your backup into the relevant files of the folder install_path/*provisioningWebServices/provisioningServlet-*technical_domain_name.

For selected migration paths, the files ProvisioningWebServicesChanges.txt* in the subfolder Documentation/DirXIdentity/ProvisioningWebServices of the installation media list all files and folders to be merged.

When upgrading from a version lower than V8.5, the folder install_path/provisioningServlet is obsolete. Keep a related backup outside the DirX Identity installation and then remove this folder. When you are sure that the backup is no longer needed, remove the backup, too.

Migrating the SPML Provisioning Web Services clients consists of the following steps:

If you have a customized Web Center, you must merge the changes from your backed-up customized version into the new version of Web Center which now contains the domain name:

install_path/web/webCenter-technical_domainname

The files WebCenterChanges*.txt in the subfolder Documentation/DirXIdentity/WebCenter of the installation media list all files and folders to be merged.

Note that the new URL is now

http://host:8080/webCenter-technical_domainname

You can rename the URL by renaming the related file webCenter-technical_domainname.xml in the folder tomcat_path/conf/Catalina/localhost. If you rename the URL, you must update the related URL in the Provisioning Store accordingly. (DirX Identity Manager → Provisioning → Workflows → Configuration → Services → Approval, Property Location (URL, server)).

If you have a customized Web Center for SAP NetWeaver, you must merge the changes from your backed-up customized version into the new version of Web Center which now contains the domain name:

install_path/web/webManagerForSAP-technical_domainname

The files WebCenterChanges*.txt in the subfolder Documentation/DirXIdentity/WebCenter of the installation media list all files and folders to be merged.

If you have a customized Web Center for Password Management, you must merge the changes from your backed-up customized version into the new version of Web Center which now contains the domain name:

install_path/web/pwdManagement-technical_domainname

The files WebCenterChanges.txt* in the subfolder Documentation/DirXIdentity/WebCenter of the installation media list all files and folders to be merged.

See the Business User Interface Configuration Guide for more detail information about migrating.

In some cases, the migration of the repository (file-based database kahadb) from a former ActiveMQ version to the version that comes with DirX Identity V8.10 does not work.

For this reason, we strongly recommend that you verify that all message queues in ActiveMQ are empty before upgrading (enqueuer and dequeuer counters are equal in Web Console). In rare cases, ActiveMQ doesn’t start correctly after migration because of kahadb issues (the repository). In this case, the only choice is to delete the kahadb completely.

The size limit applied to an LDAP search operation limits the number of returned entries in single searches and paged searches.

The source is:

The value in force is 3 or a smaller limit from 2 or 1 (if there is no specific limit for that user; for example, there is no DSA User Policy for that user).

Older directory versions (before release “DirX Directory V8.2B”) had a problem interpreting the size limit in search operations: they applied the size limit to every single search operation in a series of paged searches. Therefore, the size limit could easily be circumvented by specifying a page size smaller than the size limit in force.

Starting with DirX Directory 8.2B, the size limit is applied to the entire search operation regardless of whether or not it uses simple paging control.

Caution: Applications may see a changed behavior:

Please note that DirX Identity has defined user policies with a size limit of 32,768 for non-paged searches and a paged result size limit of 100,000 (for the Connectivity branch and for each domain in the Provisioning branch).

Example (including the sample domain):

Normally you should not have any size limit problems; if you do, you must increase either the size limit of 32,768 or the paged result size limit of 100,000 to some higher value.

When configuring a new customer domain, the default values for the two size limits are as described in this section.

If you upgrade to a new DirX Identity version, be aware that the schema for certain target system objects may have been extended for the purpose of provisioning new connected system attributes. The schema for the My-Company domain is updated during the Initial Configuration if the domain step with the My-Company domain is selected. If you configure your own customer domain, you must update the schema for that domain by running the appropriate agent schema scripts provided in the install_path*/schema/tools* folder. For a detailed description of this procedure, see the section “Extending the Schema for the Target System Workflows” in the DirX Identity Application Development Guide.

The following sections provide an overview of the schema changes provided for all the supported connected systems. Except for RACF, no migration needs to be done manually.

A lock mechanism (preventing parallel updates for a user) has been implemented in DirX Identity V8.6 and was revised in DirX Identity V8.6-SP1 and again in DirX Identity V8.10. More details are available in the use case document DXI Java Programming.

Client-side SSL authentication is supported in realtime workflows when using one of the following connectors: ADSConnector, LDAPConnector, and RACFConnector.

The XML workflow definition needs to be adapted to support additional connection parameters.

Migration is done automatically during the first Configurator run. All workflows in the Connectivity database (using any of the connectors listed above) are processed.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/89/rtworkflows

As the Connectivity part is migrated, all arguments refer to the Connectivity configuration database.

Usage:

MigratePortForClientSSL.bat host port user password ssl logfile

or

MigratePortForClientSSL.sh host port user password ssl logfile

Example:

MigratePortForClientSSL.bat localhost 389 "cn=admin,dxmC=DirXmetahub" dirx 0 trace.txt

DirX Directory V8.6 provides improved search operation processing, especially for AND filter combinations that begin with filter items (for example, uid=b*), “greater than or equal to” filter items (for example, time>=20170716) and/or “less than or equal to” filter items (for example, time⇐20170716) - apply.

For best performance, we recommend re-building the indexes for the attributes where these search filters apply on a regular basis; for example, on a bimonthly schedule.To perform this task, for example, use the following dirxadm db attrconfig command:

dirxadm> db attrconfig uid time -index BUILD

Note that the DSA runs in the POSTINDEXING operation mode while the db attrconfig command is in progress and update operations will be rejected.

DirX Identity attributes that need to be handled this way include:

dxmStatusExpirationTime

dxrCertificationDate

dxrDeleteDate

dxrDisableEndDate

dxrDisableStartDate

dxrEndDate

dxrExpirationDate

dxrPwdExpiryNotified

dxrStartDate

Starting with DirX Identity V8.10, the Entry Lock Manager has been improved and makes use of two new LDAP controls. These LDAP controls are available with DirX Directory Server V8.9 (9.4.454 or higher) if you installed DirX from scratch. A DirX upgrade will not set the LDAP controls at the LDAP root.

The DirX Identity Configurator sets these LDAP controls.But please note that a manual migration is necessary if you decide to upgrade the DirX installation after you have already configured DirX Identity.

In this scenario, the migration procedure is as follows:

Starting with V8.10, images, styles, and nationalized texts (i18n) for Jaspersoft-based reports are stored in LDAP.Therefore, the configuration for the reports must be extended.This can be done manually, report per report, or automatically with a migration script.

For details, see the chapter "Upgrading" in the use case document DXI Jaspersoft Reports.

This version runs with Java 11 (JRE or JDK) and Apache Tomcat 9 only.

This version runs with Java SE 11 only.Note that the Identity installation no longer offers the use of an embedded Java JRE runtime.The Java environment must be externally provided.

For customer-specific code that is written in Java, the customer should verify if the code is running with Java SE 11 without rebuilding it.Note that Java SE 11 no longer contains some web service APIs that were included in Java JRE 8. A rebuild with Java 11 and some additional third-party jar files may therefore be necessary.

See the Oracle’s documentation of removed APIs, features and options under https://www.oracle.com/technetwork/java/javase/9-removed-features-3745614.html and https://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html#Removed.

See also the section about Class Loading in IdS-J server in this guide.

This version supports Apache Tomcat 9 only. Additionally, for the DirX Identity Web services that are deployed in Tomcat, the Tomcat server must run with Java SE 11.

In typical datacenter scenarios, DirX Identity’s Web Center or Business User Interface is used behind a reverse proxy; for example, a firewall or load balancer. To configure the Tomcat container as a reverse proxy target, see the Tomcat documentation under https://tomcat.apache.org/tomcat-9.0-doc/proxy-howto.html.

In this version, the JMX access of the IdS-J server and the Apache ActiveMQ server have been pre-configured so that user credentials are always needed.

See the relevant sections “JMX Access to the Java-based Server” and “JMX Access to the Message Broker” in the DirX Identity Connectivity Administration Guide.

The Java class loading in the IdS-J server has been simplified. In previous releases, when deploying a customer-specific request workflow job implementation (in the folder “install_path/ids-j-…/confdb/jobs/…​”) you had to supply the jar file of your job implementation and several other jar files, such as dxrOrder.jar, dxrPolicies.jar, dxrServices.jar, and so on.

This approach could cause runtime problems (class loading problems) as these additional jar files existed at different locations in the installation, too. Very often there were conflicts with the Jar files loaded from install_path*/ids-…/extensions/com.siemens.idm.domcfg/lib*).

Therefore the whole environment was simplified:

Now the request workflow job implementation folders (install_path/ids-j-…*/confdb/jobs/…​) must only contain the jar file of the job implementation (and optionally some other jar files that only that job requires; for example, third-party jar files).

The job folders provided with the installation now look as follows:

Your tasks are to:

In former versions, sometimes you ran into trouble if you wanted to create a filter with special characters in the condition; for example, description=a(b)c,. Therefore, the internal handling of this filter was changed. Provisioning rule filters are now stored escaped in LDAP except for the time constructs. Asterisks * in conditions are stored as . This means they are used as wildcards. If you want to check for an asterisk, use *\2a (insert \2a in the LDAP tab of the filter editor).

Automatic migration does not take place because it’s not always clear what the filter should represent. DirX Identity provides a standalone tool that searches for rules that might cause trouble in the new version. Run the tool and then check the output and look at the rules that are reported. Change the rule using DirX Identity Manager if necessary. But in every case, do a save for this rule to be sure the rule is stored correctly. The example given here is stored in the following way: (description=a\28b\29c).

On Windows, call:

install_path\GUI\tools\provrulechecker\CheckProvisioningRules.bat

First specify the bind credentials and the root for the Provisioning rules to be checked in CheckProvisioningRulesConfig.xml.

For details, see README.txt in the aforementioned directory.

As of version 8.9, DirX Identity supports a new type of delegations which are easier to understand and to use than the old delegations. You can either continue to use the old delegations or switch to the new ones, but you cannot use them both in parallel. This section gives an overview of the differences between the old and new delegations and describes what to pay attention to when switching from the old to the new delegations (or vice versa).

The REST Approval Service has been replaced with the new DirX Identity REST service which includes more functionality.Web applications must be adapted.You’ll find the new service in the installation under install_path*/restServices.*

The HTML5-based Approval App has been replaced with the new DirX Identity Business User Interface which includes more functionality.As before, the new interface is configured with the Configuration Wizard.

In V8.6, the setup and handling of SSL connections have changed slightly and includes the distribution of key material. This section describes the necessary steps to migrate existing SSL key material when upgrading from V8.3 and newer. Note that if you migrate from a version older than V8.3 and want to reuse existing key material, you must upgrade to V8.3 first and then perform the manual steps described in the section “Migrating Identity SSL Configurations” in the section “Aspects Relevant for Upgrade from V8.2”.

Note that we recommend setting up new key material as it is described in the chapter “Securing Identity Server Connections with SSL” in the DirX Identity Connectivity Administration Guide.

With DirX Identity V8.6, ActiveMQ clients like Java-based and C++-based Servers, Web clients or Password Listener use client-side SSL when connecting to the ActiveMQ Message Broker if system-wide SSL is selected in the Configuration Wizard. Before this configuration is selected, the certificate-generating scripts must be executed as described in the chapter “Setting up the X.509 Certificates” in the Connectivity Administration Guide.

If you upgrade from a DirX Identity V8.3, V8.4 or V8.5 version and you have Windows Password Listeners running using SSL to the Message Broker, you can migrate them one after another to use client-side SSL while the ones that haven’t been migrated yet are still running and connecting with server-side SSL by performing the following actions in the given order:

In V8.6, the passwords for the pre-defined admin account are stored hashed in files. If you then upgrade the relevant files, install_path/ids-j-domain-Sn/tomcat/conf/tomcat-users.xml and install_path/messagebroker/conf/jetty-realm.properties are not overwritten. So you need to hash the passwords yourself.

Web Admin Password

Go to install_path/ids-j-domain-Sn/bin and open a Windows command shell or a UNIX shell:

Usage:

dxidigest.bat/sh password

Example:

Copy the part after the colon and then insert it into the tomcat-users.xml file as the value for password.

ActiveMQ Web Console Password

Go to install_path/messagebroker/bin and open a Windows command shell or a UNIX shell:

Usage:

Copy the line with MD5 and insert it into the jetty-realm.properties file as

Existing instances of the External Workflow Starter and the Eventing tool from releases older than than this release are obsolete.Instances of these tools from service packs or hot fixes related to releases older than this one are obsolete, too.To continue using these tools, use the tools from this release by extracting and configuring the tools shipped with this release by hand.

If you have enabled the sending of audit records of DirX Identity Java-based Servers via JMS, you need to replace the deployment folder of the JMS Audit Handler with the new jar file(s).

The handler must be deployed into each IdS-J server into the following folder: install_path/ids-j-domain-S*n/extensions/com.siemens.idm.audit.jms*.

Replace the sub-folder lib with the one that is provided in the folder Additions/jmsAuditHandler/com.siemens.idm.audit.jms.zip/lib of the installation medium. The only required jar file is: com.siemens.idm.audit.jms.JmsAuditLogHandler.jar.

Privileges can be assigned (direct, by rule or BO inheritance), inherited from other privileges by privilege resolution, or both. As a new feature, privileges that are inherited are stored in the user’s dxrResolvedPrivilegesLink. In the Identity Manager’s “Assigned by” column (and in WebCenter’s “Mode” column), this is shown by the mode inherited. Note that this mode can be mixed with other modes that indicate the different types of sources for this privilege.

To populate the dxrResolvedPrivilegesLink once for all users, you need to run the privilege pesolution process for all users. To perform this task, change the subject filter to ‘(objectClass=dxrUser)’ before the run.

The Identity API contains a method listObjects in the Objects interface.

If assigned objects are requested (assignedRoles, assignedPermissions, assignedGroups, or assignedAccounts), the filter and base parameters are now considered. The intent of this step is to speed up the display of assignments to selected privileges in situations where users possess many privileges.

The following hints must be considered:

If a display attribute is defined for a role parameter (for example, cn), the value and the display value are stored and are also present in a request workflow.

The new role parameter format stores the value within the value tag. Thus, the extension is backward compatible to the old solution. If a special display value exists, it is stored in the key attribute of the value element, for example:

The init.metacp file includes the new Tcl variable _md_req_attr_limit, which was introduced to avoid passing huge attribute lists to the LDAP server. If more attributes than the given limit are defined, metacp internally requests all of the attributes from the LDAP server using the -allattributes switch in the obj search command. The default value for this variable is 64.

The following problems may occur if the LDAP server requests all attributes:

Be aware of this behavior when you are running Tcl-based workflows and you find that some of the attributes are no longer synchronized. To solve the problem, you need to set the value of the Tcl variable md_req_attr_limit to -1. For more information, see the _DirX Identity Troubleshooting Guide and the DirX Identity Meta Controller Reference.

The Join section of the Group channel of the default LDAP realtime workflow has been changed and now looks as follows:

So, if you copied the default workflow with older versions of DirX Identity, the new join item using “${source.dxrPrimaryKeyOld}” is missing in your LDAP realtime workflow. Thus, if you want group renaming to work in your environment, you should extend your LDAP workflow manually in the same way as the default LDAP realtime workflow. If you are sure that groups are never renamed in your environment, there is no need to extend the join criteria.

The DirX Identity installation provides a few (default) Tcl and realtime workflows that synchronize user objects. Up to now, these objects have been synchronized by either selecting the LDAP object class dxrUser or by using any other attribute (for example, employeeNumber) supposing that with such a filter a user object will match.

With DirX Identity V8.3A, you can use the new LDAP object classes dxrPersona (if you are interested in alternative representations for a user) and/or dxrFunctionalUser (if you are interested in resources that are assigned to a user). With DirX Identity V8.5, the new LDAP object class dxrUserFacet is available.

These new LDAP object classes are auxiliary object classes and are used in combination with the LDAP object class dxrUser. Therefore, when searching for dxrUser, you will also find objects with the LDAP object class dxrUser and dxrPersona, dxrUser and dxrFunctionalUser or dxrUser and dxrUserFacet (as long as the other filter attributes also match; but for the object class dxrPersona, the same set of attributes applies).

An update of the Tcl and realtime workflows is thus required, because when the join criteria results in a multiple match, none of the objects are synchronized. For export workflows, objects other than users would be exported, too.

The migration process extracts JMS Audit configuration values (user, password, url, queue name and logpath) that were hard-coded in XML server configuration (the old way up to V8.3) and stores them in specific attributes (the new way since V8.4).

Migration is done automatically during the first Configurator run. All workflows in the Connectivity database are processed.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/83

As the Connectivity part is migrated, all arguments refer to the Connectivity configuration database.

Usage:

MigrateJMSauditConf.bat host port user password ssl logfile

Example:

MigrateJMSauditConf.bat localhost 389 "cn=admin,dxmC=DirXmetahub" dirx 0 trace.txt

In V8.3, the setup and handling of SSL connections changed, including the distribution and location of key material.This section describes the necessary steps to migrate existing SSL key material.

Note that we strongly recommend setting up new key material, as the process has been enhanced to use a CA certificate, which makes distribution of key material much easier.It also has been decided to support only server-side SSL.Finally, you can only secure all Identity server connections at once, not separately.

If you want to use your previously created SSL key material, you need to decide if you’ll use the key material from the former Java-based Server, from the secured SOAP port or from the messaging service from the C++-based Server.

DirX Identity Java-based worker containers have been supported since DirX Identity V8.2, but they are no longer supported with this version.

If your installation is an upgrade installation of one of these DirX Identity versions, you need to perform the manual cleanup steps regarding worker containers described in this section. These steps are platform-dependent and include:

During Web Center deployment, Web Center for Password Management, Web Center for SAP NetWeaver, Provisioning Web Services of DirX Identity V8.2, the following files are created in tomcat_install_path*/endorsed*:

These files are obsolete because the implementation of these standards is now part of Java Runtime >= 1.8. Remove these files if you can ensure that they are related to one of the deployments listed above and if you can exclude negative side effects for any other application you deployed into that Tomcat.

If you do not have any custom scripts that use java or keytool and which originate from DirX Identity V8.2, you can skip this section. Otherwise, you need to adapt these scripts as described in this section.

DirX Identity scripts that use java or keytool have been modified so that they are correct regarding the following issues:

The jms.jar file is no longer provided with the installation.JMS messaging is now provided by geronimo-jms_1.1_spec.jar (which is packaged with ActiveMQ and integrated into the DirX Identity installation).

As a result, if you made an upgrade installation, you must delete jms.jar in your installation directory manually.The following file needs to be deleted:

install_path/web/webCenter-domain/webCenter/WEB-INF/lib/jms.jar

The channel’s XML definition (LDAP attribute dxmContent) needs to be updated to support the realtime delta workflow feature.

The Configurator performs this migration automatically when it is run for the first time and processes all workflows in the Connectivity database.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/82C/rtworkflows

As the Connectivity part is migrated, all arguments refer to the Connectivity configuration database.

Usage:

MigrateDeltaWorkflow.bat host port user password ssl logfile

Example:

MigrateDeltaWorkflow.bat localhost 389 "cn=admin,dxmc=dirxmetahub" dirx 0 log.txt

The XML definition of the event port in realtime workflows (LDAP attribute dxmContent) contains a “Connection” section that uses invalid references to non-existing LDAP objects. As this section is not evaluated by the realtime workflows, a migration procedure will remove it.

The Configurator performs this migration step automatically when it is run for the first time and processes all workflows in the Connectivity database.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/82C/rtworkflows

As the Connectivity part is migrated, all arguments refer to the Connectivity configuration database.

Usage:

MigratePubConnector.bat host port user password ssl logfile

Example:

MigratePubConnector.bat localhost 389 "cn=admin,dxmc=dirxmetahub" dirx 0 log.txt

No migration for this parameter is required. This section is just to inform you about some minor changes:

The “Minimum Source Entries” parameter is now also evaluated if paging mode is turned on. The parameter is evaluated both for export and import synchronization. In addition, new entries were added and existing ones were modified in any case in old releases (without paging). The minimum number of entries was checked only when entries needed to be deleted, and deletions were not made if the minimum number of source entries was too small. With the new release, the minimum number of source entries is checked first, and synchronization starts only if the minimum number is OK.

For audit purposes, almost all objects in the Provisioning tree are required to hold the attribute dxrUid. Consequently, a migration tool checks the Provisioning tree and creates the attribute dxrUid where missing.

The migration tool creates the dxrUid attribute (if missing) under the following conditions:

Objects that have different object classes than the ones listed above are not updated (because the dxrUid attribute is not defined for these object classes).

The Configurator performs this migration step automatically during its first run.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/82C/database

As the Provisioning part is migrated, all arguments refer to the Provisioning configuration database.

Usage:

MigrateUid.bat host port user password ssl domain-DN logfile

Example:

MigrateUid.bat localhost 389 "cn=DomainAdmin,cn=My-Company" dirx 0 "cn=My-Company" log.txt

Note: due to the new paging features in DirX V8.2, a sizelimit error may occur and the tool might not be able to read all requested entries. In this case, simply start the tool again until only those entries remain whose object class does not allow setting a dxrUid (for example, dxmObjectCollection).

If the feature Reduce Runtime Activities is set in Approval activities, there are many approvers assigned to one activity.

Consequently, when using the token ${activity.participantEntries} in the e-mail body, all approvers are shown as the ones that rejected. Thus, a new token must be used that shows only the one(s) that really rejected.

Note that there is no automatic migration of the e-mail body. Therefore the following change needs to be made manually; for example, in the “Notification If Rejected” part of the 4-Eye Approval workflow of My-Company domain:

Here is the old e-mail body:

Here is the new e-mail body:

The URL of the Source Ticketing sample Web Service shipped with the new product release has changed. Therefore, applications which use the Web Service of the new product release must be changed so that they use a URL of the form http://host:port/sourceTicketing/sourceTicketingService (instead of http://host:port/spmlsoapservice/services/SpmlSoapService). For details about this topic, see the subsection "Preparing the Web Service Environment" in the section "Working with Source Tickets" of the chapter "Follow-up Tutorials" in the DirX Identity Tutorial.

The conversion of an SPML filter expression containing a wildcard (*) character to an LDAP filter expression by the LDAP connector has changed with product versions newer than V8.2C.

This kind of filter is now converted according to the standard OASIS SPML filter specification. This change means that a wildcard contained in a value of an SPML filter expression, like

is now interpreted as part of the value and not as a wildcard. As a result, it is escaped in the converted LDAP filter (“sn=a/”) passed to the LDAP server with the consequence that users with a surname equal to *a* are searched for, not the users with a surname beginning with a.

If wildcard searches are intended, the SPML filter element substring together with the elements initial, any or final must be used. The following snippet defines the SPML filter to handle the example of searching for all users with surname beginning with a:

If customers, for example, use their own workflow definitions with wildcards specified in, for example, channel search filters, they must adapt their definitions accordingly.

In V8.2B, the display of Data View search result entries was wrong (like the Provisioning View and not the Data View) when you used server=”DirXmetaRole” for the quick search panel.The workaround was to delete/rename the server attribute from the ldapquicksearchpanel definition.If you want to use the server=”DirXmetaRole” (you don’t have to select a server during Data View search):

Subscriptions for C++-based Server were migrated automatically during upgrade installation and configuration. After you complete the upgrade, check that only subscriptions in the new format exist. This format is described in the section “Issues Relevant for Upgrade from 8.2B” → “Migration of JMS Subscriptions” in the “Introduction” chapter. If you find subscriptions in the old format, delete them.

Hint: On the host of the C++-based Server, you’ll find migration.ini or migration.tmp.ini in install_path/ats/msgstore. In this file, you’ll find the old subscriptions (on the right side and the new subscriptions on the left side of the equals sign).

See the subsection "Migrating the URL of the Source Ticketing Sample Web Service" in the section "Aspects Relevant for Upgrade from 8.2C".

Many request workflow parameters were stored in the attribute “dxmContent” (in XML format). For better performance and to be able to search for these parameters, these parameters are now stored in the attribute “dxmSpecifiAttriibutes”. For example:

dxmSpecificAttributes=escalationLevel 1

The Configurator performs this migration step automatically when it runs for the first time and processes all workflows in the Provisioning database.

You can start this migration step by hand at any time. It is located in:

install_path/tools/migration/82B/reqworkflows

As the Provisioning part is migrated, all arguments refer to the Provisioning configuration database.

Usage:

MigrateReqWFldapAttrs.bat host port user password ssl logfile

Example:

MigrateReqWFldapAttrs.bat localhost 389

"cn=DomainAdmin,cn=My-Company" dirx 0 "cn=My-Company" trace.txt

The behavior of properties of type “siemens.dxm.util.GeneralizedTime” without an explicit editor definition has changed.In earlier versions, only the date part of these properties was displayed.Now both the date and time part are shown.If only the date should be displayed, you need to insert an explicit editor definition.The relevant value is:

“siemens.DirXjdiscover.api.ldap.beans.JnbLdapGeneralizedDate”

The SSL flag for messaging is no longer located at the Configuration → Messaging Services → Message Server object. It has been shifted to the corresponding service object.

If you used SSL for messaging, perform the following steps:

In previous releases of DirX Identity, the default location for customer-specific jar files concerning

was

install_path/ids-j-domain-Sn/confdb/jobs/framework/lib

This location has changed and now the jar files are located in the following folder:

install_path/ids-j-domain-Sn/confdb/common/lib

Make sure that the jar files are removed from the old location.

SAP R3 UM agent/connector: A new flag directlyAssignedRolesOnly (set to true) allows export of only directly assigned roles. The default value is false. If you want to adjust your existing workflows perform the following steps:

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

For each domain, navigate to Provisioning view group → Domain Configuration → Customer Extensions → Object Descriptions → UserCommon.xml

Replace each occurrence of the string ClearOnMasterRemova=" with ClearOnMasterRemoval=".

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

The object description name for a Provisioning rule had to be changed from ProvisionRule to dxrProvisionRule and the object description name for password policies had to be changed from dxrPwdPolicyCheck to dxrPwdPolicy.

If attribute polices, event policies or delete policies for these types exist in your environment, adapt these policies accordingly, or they will no longer work.

See the subsection "Migrating the URL of the Source Ticketing Sample Web Service" in the section "Aspects Relevant for Upgrade from 8.2C".