The installer migrates certain files automatically during upgrade to a newer version. Note that the installer considers only the installation folder of the Directory Integrator.
All solution folders that are different than the installation folder must be migrated manually (or using some of the tools described in section Tool-assisted migration).
Which files does the installer migrate automatically?
Which files need to be migrated manually?
Everything mentioned in section Manual migration, except those mentioned in its first subsection, Property Files.
These tool are used by the installer for the installer-assisted migration. We can use them for manual migration.
Property files migration
Use the "tdimiggbl" tool from TDI_install_dir/bin; see section Migrating global and solution.properties files using migration tool.
Use the "tdimigamc" tool from TDI_install_dir/bin/amc; see AMC and AM Command line utilities.
Use the "tdimigam" tool from TDI_install_dir/bin/amc; see AMC and AM Command line utilities.
Use the "migpwsync" tool from TDI_install_dir/pwd_plugins/bin; see Migrating Password plug-ins properties files using migration tool.
AMC database migration
Use the "backupamcdb"/"restoreamcdb" tools from TDI_install_dir/bin/amc; see AMC and AM Command line utilities.
Cloudscape System Store migration (only for 6.0)
See the more detailed instructions in section Migrating Cloudscape database to Derby.
Copy your Config files and any other custom files, including Derby databases from the old installation directory to the new installation directory. TDI 7.1 supports a Solution Directory, and we recommend you copy the Config files, property files, Derby databases, and so on, to such a solution directory instead of to the installation directory of TDI version.
Once we have copied the objects referenced above to a new location, we can set out to manually migrate their contents to adapt them for use with IBM TDI 7.1 as described in the sections below:
Sandbox data is version-specific; data recorded under any previous version does not play in version 7.1.
Property files
The table below lists which properties have been deleted or changed in TDI 7.1:
Old property (pre-v7.0) | New property | Remarks |
---|---|---|
## Active Correlation Technology engine settings # act.engine.rule.set.file=myrules.acts | *DELETED* | Remove ACT Engine and ACT Connector |
# Location of directory where the JRE TDI will use is installed com.ibm.di.jvmdir=$jvmRoot$ | *DELETED* | No longer possible to specify. |
com.ibm.di.scriptengine.precompile=true | *DELETED* | No longer possible to specify; the current script engine does not have this functionality. |
com.ibm.di.scriptengine.regex=java | *DELETED* | No longer possible to specify - Java syntax is always followed. |
ibmjs.options=com.ibm.di.script.ScriptEngineOptions | *DELETED* | Related to previous property; this is no longer a valid option. |
com.ibm.di.store.create.checkpoint.store=<multiple statements> | *DELETED* | Checkpoint/Restart functionality is removed; any System Store create table statements related to this should be removed too. |
com.ibm.di.admin.library.dir= | *DELETED* | The current Config Editor does not use this, so no longer possible to specify. |
api.remote.on=false | api.remote.on=true | RMI enabled by default in TDI Server - Setting to true since it is enabled by default. |
javax.net.ssl.trustStore= {protect}-javax.net.ssl.trustStorePassword= javax.net.ssl.trustStoreType= |
javax.net.ssl.trustStore=serverapi\testadmin.jks {protect}-javax.net.ssl.trustStorePassword=administrator javax.net.ssl.trustStoreType=jks | RMI enabled by default in TDI Server - empty values replaced by the default truststore. |
javax.net.ssl.keyStore= {protect}-javax.net.ssl.keyStorePassword= javax.net.ssl.keyStoreType= |
javax.net.ssl.keyStore=serverapi\testadmin.jks {protect}-javax.net.ssl.keyStorePassword=administrator javax.net.ssl.keyStoreType=jks | RMI enabled by default in TDI Server - empty values replaced by the default keystore. |
com.metamerge.securityTransformation=DES/ECB/NoPadding |
com.ibm.di.securityTransformation=DES/ECB/NoPadding | FIPS 140-2 Certification - property name changed. |
com.ibm.di.server.keystore=myKeyStore.jks com.ibm.di.server.key.alias=myKeyAlias |
api.keystore=myKeyStore.jks api.key.alias=myKeyAlias | Server API keystore properties renamed. |
com.ibm.di.store.database=TDISysStore com.ibm.di.store.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver com.ibm.di.store.jdbc.urlprefix=jdbc:derby: com.ibm.di.store.jdbc.user=APP |
#com.ibm.di.store.database=TDISysStore #com.ibm.di.store.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver #com.ibm.di.store.jdbc.urlprefix=jdbc:derby: #com.ibm.di.store.jdbc.user=APP | The EMBEDDED MODE properties for the System Store have been commented out, since the System Store now runs in Network mode by default. The Installer never makes this change; if we have previously used Cloudscape/Derby in embedded mode we will need to make this change manually. |
#com.ibm.di.store.database=jdbc:derby://localhost:1527/TDISysStore;create=true #com.ibm.di.store.jdbc.driver=org.apache.derby.jdbc.ClientDriver #com.ibm.di.store.jdbc.urlprefix=jdbc:derby: #com.ibm.di.store.jdbc.user=APP #com.ibm.di.store.jdbc.password=APP #com.ibm.di.store.jdbc.start.mode=automatic #com.ibm.di.store.jdbc.host=localhost #com.ibm.di.store.jdbc.port=1527 #com.ibm.di.store.jdbc.sysibm=true |
com.ibm.di.store.database=jdbc:derby://localhost:1527/TDISysStore;create=true com.ibm.di.store.jdbc.driver=org.apache.derby.jdbc.ClientDriver com.ibm.di.store.jdbc.urlprefix= jdbc:derby://localhost:1527/ com.ibm.di.store.jdbc.user=APP com.ibm.di.store.jdbc.password=APP com.ibm.di.store.jdbc.start.mode=automatic com.ibm.di.store.jdbc.host=localhost com.ibm.di.store.jdbc.port=1527 com.ibm.di.store.jdbc.sysibm=true | These are the new, default properties for the
System Store in TDI 7.1. If we have migrated your installation, we will need to make these changes to our global.properties file
as well, if you wish to run the System Store in Networked mode.
The new architecture of the Configuration Editor in conjunction with other changes to the development process make that running System Store in embedded mode is very cumbersome. Therefore, we highly recommend that we run in Networked mode. |
api.config.folder=$change$/configs | api.config.folder=configs | The configs folder is now always local to the Solution Directory. |
##---------------------- ## System Queue settings ##---------------------- ## If set to "true" the System Queue is initialized on startup and can be used; ## otherwise the System Queue is not initialized and cannot be used. systemqueue.on=false ### MQe JMS driver initialization properties ## Specifies the location of the MQe initialization file. ## This file is used to initialize MQe on TDI server startup. systemqueue.jmsdriver.param.mqe.file.ini=$change$/MQePWStore/pwstore_server.ini |
##---------------------- ## System Queue settings ##---------------------- ## If set to "true" the System Queue is initialized on startup and can be used; ## otherwise the System Queue is not initialized and cannot be used. systemqueue.on=true ### MQe JMS driver initialization properties ## Specifies the location of the MQe initialization file. ## This file is used to initialize MQe on TDI server startup. systemqueue.jmsdriver.param.mqe.file.ini=MQePWStore/pwstore_server.ini | The System Queue is now enabled by default in TDI 7.1 (except on z/OS). Also, the MQe initialization file is now located in a directory subordinate to the Solution Directory. |
The table below lists which properties have been added in TDI 7.1:
Property | Remarks |
---|---|
com.ibm.di.server.fipsmode.on=false | New property for enabling/disabling FIPS mode was added. |
## To enable the built-in JAAS Authentication mechanism, ## set this property to "[jaas]". api.custom.authentication ## JAAS Authentication properties ## --------------------- ## java.security.auth.login.config= | Provide support for JAAS as a Server API Authentication provider; empty property is provided in which we can specify the JAAS Configuration file. |
## Encryption certificate properties com.ibm.di.server.encryption.keystore = <<value of com.ibm.di.server.keystore from 6.1.1 global.properties>> com.ibm.di.server.encryption.key.alias = <<value of com.ibm.di.server.key.alias from 6.1.1 global.properties >> ## Server API keystore passwords {protect}-api.keystore.password= << keystore password from idisrv.sth>> {protect}-api.key.password= << key password from idisrv.sth if present>> | Provide separate configuration options for certificate to be used for PKI Encryption and SSL. |
## TDI Logging com.ibm.di.logging.enabled=true | Provide mechanisms to completely disable logging - set to "false" if we want to disable all logging. |
derby.connection.requireAuthentication=true derby.authentication.provider=BUILTIN derby.database.defaultConnectionMode=fullAccess | Additional parameters for the System Store (in Derby) in Networked mode. |
##PKCS11 options ##Set the value of following properties to use PKCS11 enabled ## devices to store TDI servers private key / certificate. com.ibm.di.pkcs11cfg=etc\pkcs11.cfg com.ibm.di.server.pkcs11=false com.ibm.di.server.pkcs11.library= com.ibm.di.server.pkcs11.slot= {protect}-com.ibm.di.server.pkcs11.password=PASSWORD | Support TDI Server's private key/certificate on PKCS 11 compliant crypto devices. |
## Specify the unique ID for the TDI Server ## ---------------------------------------- ## This property helps a client connecting to the TDI server to identify different servers ## running on the same IP and the same port in different time. (Default is blank) com.ibm.di.server.id= | TDI Server must provide a unique server ID available to remote server clients to detect the server being talked to. |
## Timeout in minutes for loading configuration. api.config.load.timeout=2 | Config initialization and Server API initialization need to be synchronized. |
com.ibm.di.server.encryption.keystoretype = jks com.ibm.di.server.encryption.transformation = RSA | Symmetric Cipher Support (FIPS 140-2 compliance). |
## Specifies a list of Server notification types, which will be suppressed. ## Notifications of suppressed types will not be propagated by the notifications framework. ## The notification types in the list are separated by spaces. Wildcards may be included. ## Example: ## api.notification.suppress=di.al.* di.ci.start ## The above example will suppress all AssemblyLine related notifications as well as ## notifications for starting a configuration instance. ## If the property is missing or is empty, no notifications will be suppressed. api.notification.suppress=di.server.api.authenticate di.server.api.authorize.* | Provide TDI Audit Capabilities - Server notification suppression. |
api.audit.on=false | Provide TDI Audit Capabilities. |
## This property specifies whether LDAP Group authentication is turned on. ## If it is set to 'true', the group membership of the authenticating user ## will be resolved and will be taken into account during authorization. ## If it is missing, the default value 'false' is used. api.custom.authentication.ldap.groupsupport=false ## Specifies the name of the attribute of a user in LDAP that contains a list of the groups of which the user is a member. ## It is taken into account only if 'api.custom.authentication.ldap.groupsupport' is set to true. api.custom.authentication.ldap.usermembershipattribute= ## Specifies how groups are named in the membership attribute of a user. ## For example, if the user's membership attribute contains values, ## which correspond to the 'objectSID' attributes of groups, set this property to 'objectSID'. ## If the user's membership attribute contains distinguished names of groups, then set this property to 'dn'. ## The property is required in case 'api.custom.authentication.ldap.groupsupport' is set to true. api.custom.authentication.ldap.usermembershipattributecontent= ## Specifies the name of a group's attribute in LDAP which corresponds to the way the group is named in the TDI User Registry. ## For example, if LDAP groups are addressed in the TDI registry by their common name, then set this property to 'cn'. ## If the User Registry contains the distinguished names of the groups, then set this property to 'dn'. api.custom.authentication.ldap.groupnameattribute= ## Represents the LDAP directory context, where groups will be searched. ## It is required only when LDAP group support is enabled api.custom.authentication.ldap.groupsearchbase= ## Optional property, which represents a list of space-separated attribute names. ## Specifies attributes which have non-string syntax. ## api.custom.authentication.ldap.binaryattributes= | Enhance Authorization to support LDAP groups. |
Property | Remarks |
---|---|
# api.remote.server.ports=8700-8900 | Commented out by default; this property is used
to configure RMI ports. This is useful in case the default ports conflict
with your firewall.
The server will use these ports to listen for incoming RMI service requests, in addition to listening on the ports defined by other properties. For outgoing RMI service requests, random port numbers may be used. |
## The properties determine the default bind address and the remote bind address for the Server API. ## * means bind to all network interfaces. The Remote Bind Address overrides the Default one. ## Only one IP address should be set. No hostnames are accepted. ## Mind that the java.rmi.server.hostname property is set implicitly to equal the Remote Bind Address property when used. This will cause the client stubs to create sockets on the specified Remote Bind Address. # com.ibm.di.default.bind.address=* # api.remote.bind.address=* | Commented out by default; these two properties are used to configure the network interface (hostname or IP address) that the Remote API listens on. |
## Touchpoint Server properties tp.server.on=false tp.server.port=1098 tp.server.config=etc/tp.xml tp.server.auth=false tp.server.auth.realm=TDI Touchpoint Server | These properties configure the REST interface to TDI connectors using a Service Control Management Protocol (SCMP) based Service. |
## ## Server API client properties ## api.client.ssl.custom.properties.on=true api.client.keystore=serverapi/testadmin.jks {protect}-api.client.keystore.pass=administrator api.client.keystore.type=jks {protect}-api.client.key.pass=administrator api.client.truststore=serverapi/testadmin.jks {protect}-api.client.truststore.pass=administrator api.client.truststore.type=jks | These properties enable custom SSL properties for Server API clients. If api.client.ssl.custom.properties.on=true, then the api.client.* properties will be used by Server API clients. Otherwise the default javax.net.ssl.* properties will be used. |
The table below lists which properties have been deleted or changed in TDI 7.1:
Old property (pre-v7.0) | New property | Remarks | |
---|---|---|---|
AMC.auth | *DELETED* | ||
monitor.refresh.rate | *DELETED* | The refresh rate for the Monitor Status panel. The rate was specified in minutes. | |
monitor.startup | *DELETED* | To set the Monitor Status panel as the first panel to be seen by the user when (s)he logs in. | |
LDAPHostName LDAPPort LDAPAdminUId LDAPAdminPwd LDAPServerType LDAPBindID LDAPBindPassword LDAPSuffix LdapUserPrefix LDAPUserSuffix LdapGroupPrefix LDAPGroupSuffix LDAPUserObjectClass LDAPGroupObjectClass LDAPGroupMember LDAPUserFilter LDAPGroupFilter LDAPsearchTimeout LDAPsslEnabled LDAPIgnoreCase | *DELETED* | LDAP Details. | |
com.ibm.di.amc.jdbc.start.mode | New default value: Automatic | ||
com.ibm.di.amc.jdbc.host | New default value: Localhost | ||
com.ibm.di.amc.jdbc.port | New default value: 1528 | ||
com.ibm.di.amc.jdbc.sysibm | New default value: True |
The table below lists which properties have been added in TDI v7.0:
New property (default) | Remarks |
---|---|
al.workEntries.cacheSize (100) | This property is used by AMC when the AssemblyLine is started in Synchronous mode. The cache size specified here is used for determining the size of the work entries cache. |
amc.db.type (derby) | Specifies the database being used by the AMC. |
am.api.host (localhost) | Action Manager RMI Details. |
am.api.port (13104) | Action Manager RMI Details. |
com.ibm.di.server.port.default (1099) | Default port for TDI server. (Added in v7.1.)
This property can be modified by the TDI installer to have a value different from 1099. When AMC is started for the first time (or if its database was lost), this property is read and its value saved in the newly created AMC database. Later it will be used when AMC connects to the default TDI server instance. |
The table below lists which properties have been deleted or changed in TDI 7.1:
Old property (pre-v7.0) | New property | Remarks |
---|---|---|
com.ibm.di.amc.am.serverapi.fail.interval.time=120 com.ibm.di.amc.am.queryProperty.interval.time=600 com.ibm.di.amc.am.healthAL.interval.time=5 | *DELETED* | These properties should be commented out as the values for these properties will be configured by the user from AMC while creating each Server API Failure Trigger, On Property trigger and Configuring a Health AssemblyLine respectively. Hence the properties mentioned in the am-config.properties file will not be used. |
com.ibm.di.amc.am.queryAL.interval.time | *DELETED* | |
javax.net.ssl.trustStore=$change$/bin/amc/ActionManager/testadmin.jks javax.net.ssl.keyStore=$change$/bin/amc/ActionManager/testadmin.jks |
javax.net.ssl.trustStore=bin/amc/ActionManager/testadmin.jks javax.net.ssl.keyStore=bin/amc/ActionManager/testadmin.jks | Truststore files are now local to Solution Directory. |
The table below lists which properties have been added in TDI 7.1:
New property (default) | Remarks |
---|---|
smtp.host= smtp.port= smtp.user= {protect}-smtp.password= | SMTP server details, added in TDI 7.0. |
javax.net.ssl.trustStore=TDI_Install_dir/serverapi/testadmin.jks {protect}-javax.net.ssl.trustStorePassword=administrator javax.net.ssl.trustStoreType=jks javax.net.ssl.keyStore=TDI_Install_dir/serverapi/testadmin.jks {protect}-javax.net.ssl.keyStorePassword=administrator javax.net.ssl.keyStoreType=jks | Action Manager SSL Properties, added in TDI 7.1. |
com.ibm.di.amc.am.encryption.keystore = TDI_Install_dir/testserver.jks com.ibm.di.amc.am.encryption.key.alias = server com.ibm.di.amc.am.encryption.keystoretype = jks com.ibm.di.amc.am.encryption.transformation = RSA com.ibm.di.amc.am.stash.file = TDI_Install_dir/idisrv.sth | Action Manager encryption properties, added
in TDI 7.1.
These properties are similar to the encryption properties used by the server. For convenience the location of the stash file has been added as a property: com.ibm.di.amc.am.stash.file. By default the AM will reuse the server's keystore and stash file encryption/decryption of AM protected properties. |
Configurations
Certain Directory Integrator components/features have been modified or removed. Configurations that reference these need to be migrated manually. Here is a list of affected components/features:
This functionality is removed in 7.0. This leaves Connectors that support Iterator mode with only the default ability to do a simple reconnect and automatically skip forward as many times as the number of successful reads. The assumption is that skipping forward this number of entries would get you back to where you last left off. Most TDI Connectors will not automatically attempt to do this, because the behavior can be indeterminate or not appropriate. However, the default behavior is specific per Connector. The ability to automatically skip forward as many times as the number of successful reads is a new reconnect option available to each Connector and is configured in the Connection Errors panel, see The Configuration Editor -> The Connector Editor -> Connection Errors in the IBM TDI V7.1 Users Guide. If you require more than the ability to automatically skip entries processed. we need to use one of the following options in the solutions:
Default and recommended behavior in TDI 7.1 is running Derby in networked mode. If you continue to use Derby in embedded mode, considerations regarding multiple JVMs attempting to use the same database simultaneously still apply; see Using Derby to hold your System Store. For migrating databases, see Migrating Cloudscape database to Derby.
This Connector is removed in v7.0. You may consider using the unsupported Exchange Changelog Connector that is now provided as an "example" in TDI_install_dir/examples/ExchangeChangelogConnector.
This Connector is removed from the default installation in v7.0. Use the System Store Connector instead as described in section Migrating BTree tables and BTree Connector to System Store; alternatively, use the (unsupported) Btree connector that is now provided as an "example" in TDI_install_dir/examples/BTreeDBConnector.
This applies to 6.0 and 6.1 only.
The Delivery Mode parameter is removed and State Key Persistence will be used instead. The behavior of old configurations which use this parameter will be as follows:
The CRAM-MD5 option is no longer available in 7.0; manually choose another authentication mechanism.
In version 6.2 of Tivoli Directory Server the BEREncoder and BERDecoder classes have been moved from the com.ibm.asn1 package to the com.ibm.ldap.bp.asn1 package. Starting from TDI v7.0 custom user solutions that directly use the old classes (com.ibm.asn1.BEREncoder and com.ibm.asn1.BERDecoder) need be updated to reflect this change.
These are deprecated in 7.0. Consider other functionality in the future.
This applies only to 6.0.
The "dsml.request" and "dsml.response" attributes have been removed. These attributes used to provide the raw request and response objects from the ITIM DSMLv2 library. If we have old configurations using any of these Attributes, you to edit your old configurations so that these Attributes are no longer used. All the data available through the raw request and response objects is also available through the other Attributes delivered by the DSMLv2 Parser.
If we have used the ITIM Agent Connector in a previous version of TDI, you may have to change the way you configure SSL connections. The ITIM Agent Connector in IBM TDI 7.1 uses JSSE (Java based keystore or truststore) for SSL authentication, and this requires that you configure the SSL related certificate details in the global.properties or solution.properties file; instead of mentioning the certificate name in the old ITIM Agent Connector's "CA Certificate File" Parameter. These are the steps involved:
keytool -import -file servercertificate.der -keystore tim.jksIn this example the truststore is stored in the file tim.jks.
## server authentication javax.net.ssl.trustStore=serverapi\tim.jks {protect}-javax.net.ssl.trustStorePassword=administrator javax.net.ssl.trustStoreType=jks
Now, the ITIM Agent Connector uses the same JSSE-based secure communications architecture as the rest of TDI.
If you already have a truststore file configured in global.properties or solution.properties, then import the certificate into that store instead of creating a new one.
The pre-v7.0 XML Parser has been renamed and is now called the Simple XML Parser; the current XML Parser is a new parser with more functionality, especially regarding hierarchical objects. Config files created under earlier versions of TDI referring to the XML Parser will, when imported into v7.1, refer to the Simple XML Parser (as the class name has not changed). If we want to use the new XML Parser instead, we will need to change that in your AssemblyLines and/or Connectors. In order to have the new XML Parser behave like the old one did set the both Entry Tag and Value Tag parameters to the values used in the Simple XML Parser.
The Simple XML Parser exports a script variable named "xmldom", which is not exported by the new XML Parser. The new XML Parser represents the deeper hierarchy with the Entry itself. Any logic that relies on the "xmldom" variable and cannot be reworked to make use of the hierarchical structure provided by the Entry class, must not migrate to the new XML Parser.
In TDI v7.1, the location of the Castor mapping file has changed, from TDI_install_dir/jars/functions/di_castor_mapping.xml to TDI_install_dir/etc/di_castor_mapping.xml.
Consequently, the default value for the Castor Mapping File parameter now reflects the new location.
InTDI v7.1 the HTTP Client Connector has been modified to automatically send an HTTP "Connection" header with value "close" when it does not intend to reuse the TCP connection for more HTTP requests. The reason for this modification is to comply with HTTP 1.1 recommendation (http://tools.ietf.org/html/rfc2616#section-14.10).
This behavior is mandatory according to the HTTP 1.1 spec and previously we needed to code this yourself in the AssemblyLine.
InTDI v7.1 HTTP Server Connector has been modified to use persistent HTTP connections by default. This means that one TCP connection can be used by the same HTTP client for multiple HTTP requests (http://tools.ietf.org/html/rfc2616#section-8.1). HTTP clients may still send a "Connection" header with value "Keep-Alive", but it is no longer required in order to use a persistent connection. Idle TCP connections will be closed automatically after 20 seconds of inactivity.
Customized scripts
If we have customized any of the Directory Integrator scripts (for example, adding items to the PATH or the LD_LIBRARY_PATH environment variables in the startup scripts - ibmdisrv, ibmditk), we should apply these customizations to the corresponding scripts of the new version.
Previous versions of TDI used the (MY)CLASSPATH variable in these scripts; the current version has the required path information built in and does not require this variable anymore. If you had tailored the aforementioned scripts before to include some libraries of the own, we do not have to do anything with the CLASSPATH variable; just make sure your library is in the correct place (typically in the jars/ directory) so it is found by TDI. Alternatively, use the com.ibm.di.loader.userjars property in global.properties to point to our own directory to be included in the loader path. In TDI 7.1, the property may specify several directories or jar files, separated by the Java Property "path.separator", which is ":" on Linux and ";" on Windows. The TDILoader for jar files searches directories recursively for files that contain classes and resources. Only files with a ".zip" or ".jar" extension are searched.
Added or replaced JAR files in the installation
If we have added JAR files to the installation, we should copy them to the new version too.
IBM TDI now requires and includes a Java 6 compliant JVM (J2SE version 1.6 SR7). If we have developed our own code in Java™, linked this code against the JVM libraries and integrated this with your IBM TDI solution, you might have to recompile and re-link your code.
If we have overwritten any of the original JAR files of the installation (for example, putting any required MQ jars in TDI_install_dir/jars/3rdparty/IBM), we should do the same with the new version.
A 64-bit Java Runtime Environment (JRE) is used now on Windows x86-64, Linux x86-64 and Linux s390. Compared to a 32-bit JRE, some performance degradation has been observed in some scenarios; we can still use the Windows x86-32 or Linux x86-32 installer for non-password plugin activities if you believe we will have potential issues with performance degradation.
If we do use the 64-bit JRE, we need to be aware that 64-bit shared libraries will be needed for any custom component (connector, parser, FC) that depends on JNI.
Password Synchronizer configurations
Follow the steps described in "Migration from previous installations" in the Windows Password Synchronizer section of the IBM TDI V7.1 Password Synchronization Plug-ins Guide.
There are no specific migration steps. Uninstall the old version, install v7.1 and configure it to suit your needs.
It makes sense to backup each of the files of the original installation that we have modified in some way: property files, keystores, scripts, jars, and so forth.
Generally it is up to you to decide which items are important and have to be backed up. Here is an overview:
If the Server feature is being upgraded the following files will be backed up:
TDI_install_dir\global.properties to TDI_install_dir\etc\global.properties.v60
TDI_install_dir\serverapi\testadmin.jks to TDI_install_dir\serverapi\testadmin.jks.v60
TDI_install_dir\serverapi\testadmin.der to TDI_install_dir\serverapi\testadmin.der.v60
TDI_install_dir\serverapi\registry.enc to TDI_install_dir\serverapi\registry.enc.v60
TDI_install_dir\serverapi\registry.txt to TDI_install_dir\serverapi\registry.txt.v60
TDI_install_dir\idisrv.sth to TDI_install_dir\idisrv.sth.v60
TDI_install_dir\testserver.jks to TDI_install_dir\testserver.jks.v60
TDI_install_dir\testserver.der to TDI_install_dir\testserver.der.v60
In addition, configuration files and solution.properties will be backed up.
If the Server feature is being migrated, the following files will be backed up: (The new suffix will be .v61 or .v611 depending on the previous version.)
TDI_install_dir\etc\global.properties to TDI_install_dir\etc\global.properties.v61x
TDI_install_dir\serverapi\testadmin.jks to TDI_install_dir\serverapi\testadmin.jks.v61x
TDI_install_dir\serverapi\testadmin.der to TDI_install_dir\serverapi\testadmin.der.v61x
TDI_install_dir\serverapi\registry.enc to TDI_install_dir\serverapi\registry.enc.v61x
TDI_install_dir\serverapi\registry.txt to TDI_install_dir\serverapi\registry.txt.v61x
TDI_install_dir\idisrv.sth to TDI_install_dir\idisrv.sth.v61x
TDI_install_dir\testserver.jks to TDI_install_dir\testserver.jks.v61x
TDI_install_dir\testserver.der to TDI_install_dir\testserver.der.v61x
TDI_install_dir\etc\reconnect.rules to TDI_install_dir\etc\reconnect.rules.v61x
TDI_install_dir\etc\derby.properties to TDI_install_dir\etc\derby.properties.v61x
TDI_install_dir\etc\jlog.properties to TDI_install_dir\etc\jlog.properties.v61x
TDI_install_dir\etc\log4j.properties to TDI_install_dir\etc\log4j.properties.v61x
TDI_install_dir\etc\tdisrvctl-log4j.properties to TDI_install_dir\etc\tdisrvctl-log4j.properties.v61x
TDI_install_dir\etc\act-jlog.properties to TDI_install_dir\etc\act-jlog.properties.v611 (TDI 6.1.1 only)
In addition, configuration files and solution.properties will be backed up.
If the Server feature is being upgraded the following files will be backed up:
TDI_install_dir\etc\global.properties to TDI_install_dir\etc\global.properties.v70
TDI_install_dir\serverapi\testadmin.jks to TDI_install_dir\serverapi\testadmin.jks.v70
TDI_install_dir\serverapi\testadmin.der to TDI_install_dir\serverapi\testadmin.der.v70
TDI_install_dir\serverapi\registry.enc to TDI_install_dir\serverapi\registry.enc.v70
TDI_install_dir\serverapi\registry.txt to TDI_install_dir\serverapi\registry.txt.v70
TDI_install_dir\idisrv.sth to TDI_install_dir\idisrv.sth.v70
TDI_install_dir\testserver.jks to TDI_install_dir\testserver.jks.v70
TDI_install_dir\testserver.der to TDI_install_dir\testserver.der.v70
TDI_install_dir\etc\reconnect.rules to TDI_install_dir\etc\reconnect.rules.v70
TDI_install_dir\etc\derby.properties to TDI_install_dir\etc\derby.properties.v70
TDI_install_dir\etc\jlog.properties to TDI_install_dir\etc\jlog.properties.v70
TDI_install_dir\etc\log4j.properties to TDI_install_dir\etc\log4j.properties.v70
TDI_install_dir\etc\tdisrvctl-log4j.properties to TDI_install_dir\etc\tdisrvctl-log4j.properties.v70
TDI_install_dir\etc\act-jlog.properties to TDI_install_dir\etc\act-jlog.properties.v70
In addition, configuration files, the workspace and solution.properties will be backed up.
These tools are used for backup/restore by the installer. They can also be used for manual migration.
See AMC and AM Command line utilities for more details.
Manual backup means copy the file to some dedicated backup folder. Conversely, restore means copy the file from the dedicated backup folder to its original location.
Note that in some cases we have to consider dependencies between files. We need to backup a group of interdependent files as a whole. Such groups of files are: