This section contains information and known issues related to upgrading Identity Manager from versions 6.0, 7.0, 7.1, 7.1.1, or 8.0 to version 8.1.
The information in this section is organized as follows:
Be aware of the following information before starting the upgrade process:
See Sun Identity Manager 8.1 Upgrade for comprehensive upgrade instructions.
If you upgrade your JDK or JRE, you must use a JDK or JRE supplied by the same vendor as your previous JDK. For example, do not install a Sun JDK if previously you were using a JDK from IBM. If you mix JDKs from different vendors, data encrypted under a previous JDK cannot be read by a JDK from another vendor. (ID-17800)
Upgrade Identity Manager in the following order:
Upgrade all Identity Manager server instances and Gateway instances
Upgrade all PasswordSync instances
The 8.1 version of Identity Manager server provides limited, temporary support for older versions of PasswordSync. This support is provided so that Identity Manager can continue to run while you upgrade your PasswordSync instances. All instances of PasswordSync should be updated to the same version as the Identity Manager server as soon as possible.
When uninstalling PasswordSync, use the add/modify programs feature from the Windows Control Panel to ensure correct removal. You must reboot after uninstalling.
When installing PasswordSync, use the appropriate binary file for the operating system on which you are installing. The binary for 32-bit Windows is called IdmPwSync_x86.msi and the binary for 64-bit Windows is called IdmPwSync_x64.msi. After each PasswordSync installation you must reboot.
Be sure to use only one Identity Manager server to import update.xml.
During an upgrade, only one Identity Manager server should be running. If you start any other Identity Manager servers during the upgrade, you must stop and restart those servers before making them available. Note that changes to RepositoryConfiguration do not affect an Identity Manager server until you restart that server.
If the upgrade process fails to log in with the default configurator account and password, the log file logs the error, but does not log anything after the error. (ID-18929)
The update.xml file is imported during the upgrade process. The import attempts to log in as configurator with the default password. If the login fails, an error is displayed, and the upgrade program prompts you for the correct login information. If you provide the correct information, the upgrade continues. When looking through the log file for the upgrade process, you can see the error message when the default log in fails, but you do not see any further information about the upgrade in the log file. This issue does not affect the upgrade, only the log file.
If your current Identity Manager installation has a large amount of custom work, consider contacting Sun Professional Services for assistance with planning and executing your upgrade.
If planning a skip-level upgrade, be sure to also review the upgrade notes in the following sections. Upgrade notes for subsequent versions of Identity Manager also apply to your upgrade.
If you are upgrading from an Identity Manager version 6.x installation and you want to start using the new Identity Manager end-user pages, you must manually change the system configuration ui.web.user.showMenu to true for the horizontal navigation bar to display. (ID-14901)
Also, if you want the new end-user dashboard to display on the end-user home page, you must manually change the end-user form mapping for Form Type endUserMenu. Go to Configure > Form and Process Mapping > for Form Type ’endUserMenu’. Change the Form Name Mapped To to be End User Dashboard.
You should also update the mapping for Form Type endUserWorkItemListExt. Change the Form Name Mapped To to be End User Approvals List.
If you are upgrading from version 6.0 and using LocalFiles, you must export all of your data before upgrading and then re-import the data after doing a clean installation of 8.1. (ID-15366)
If planning a skip-level upgrade, be sure to also review the upgrade notes in the following sections. Upgrade notes for subsequent versions of Identity Manager also apply to your upgrade.
If you are upgrading from version 7.0 and using LocalFiles, you must export all of your data before upgrading and then re-import the data after doing a clean installation of 8.1. (ID-15366)
There may be ItemNotFound Exceptions in the upgrade log due to Identity Manager Service Provider Edition (SPE) objects being renamed to Identity Manager Service Provider. (ID-18860)
If your installation contains a Remedy resource, you must place Remedy API libraries in the directory where the Gateway is installed. These libraries can be found on the Remedy server.
If planning a skip-level upgrade, be sure to also review the upgrade notes in the following sections. Upgrade notes for subsequent versions of Identity Manager also apply to your upgrade.
As of version 7.1.1, Identity Manager User Extended Attributes fully support multi-valued attributes. (ID-14863)
You can add a multi-valued user extended attribute to the accounts list table, and it will render the list without error. However, attempting to sort on that column will yield the following error:
java.lang.ClassCastException: java.util.ArrayList
An attribute condition that refers to a multi-valued extended attribute will evaluate correctly for a user object only after that user object has been re-serialized. If you want such an attribute condition to evaluate correctly for all user objects, then you must re-serialize all user objects. See Refreshing User Objects in the following section for instructions.
Certain types of changes require an administrator to refresh all User objects. For example, you must refresh all User objects when you change the inline attributes for Type.USER in RepositoryConfiguration. Whenever you mark an attribute as queryable or summary in the IDMSchemaConfiguration object, you must refresh all User objects for the change to affect older, unmodified objects. The same logic applies when a new version of Identity Manager adds a new attribute, or when a new version of Identity Manager changes the values of an existing attribute— the upgrade process or an administrator must refresh all User objects for the change to affect older, unmodified objects.
There are three ways to reserialize existing users:
Modify an individual User object during normal operations.
For example, opening a user account through the user interface and saving it with or without modifications.
Disadvantage: This method is time-consuming, and the administrator must be meticulous to ensure all existing users are reserialized.
Use the lh refreshType utility to reserialize all users. The refreshType utility’s output is a refreshed list of users.
lh console
refreshType User
Disadvantage: Because the refreshType utility runs in the foreground and not the background, this process can be time-consuming. If you have a lot of users, reserializing them all takes a long time.
Use the Deferred Task Scanner.
Before running the Deferred Task Scanner process, you must edit the System Configuration object using the Sun Identity Manager Integrated Development Environment (IDE) or some other method.
Search for ’refreshOfType’ and remove the attributes for ’2005Q4M3refreshOfTypeUserIsComplete’ and ’2005Q4M3refreshOfTypeUserUpperBound’.
After editing the System Configuration object, you must import that object to repository for your changes to be present.
Disadvantage: This method causes the next Deferred Task Scanner run to take a long time because it examines and rewrites almost every User object. However, subsequent Deferred Task Scanner runs should execute at normal speed and duration.
If planning a skip-level upgrade, be sure to also review the upgrade notes in the following sections. Upgrade notes for subsequent versions of Identity Manager also apply to your upgrade.
If you are using an Oracle repository, the Identity Manager 8.0 and 8.1 repository DDL uses data types that are not properly handled by older Oracle JDBC drivers. The JDBC drivers in ojdbc14.jar do not properly read all of the columns in the log table.
You must upgrade to the ojdbc5.jar for JDK 5 drivers for Identity Manager to work properly.
Upgrading automatically converts the User Extended Attributes object and QueryableAttrNames and SummaryAttrNames elements of the UserUIConfig object into the IDM Schema Configuration object. (ID-17784)
The sample update.xml script contains an import command that invokes IDMSchemaConfigurationUpdater to convert legacy user schema configuration objects. Successful conversion of legacy user schema configuration objects performs the following:
Creates within IDM Schema Configuration an IDMObjectClassAttribute element for each extended attribute name from User Extended Attributes.
Flags as ”summary’ any IDMObjectClassAttribute that corresponds to each value from the SummaryAttrNames element within UserUIConfig.
Flags as ”queryable’ any IDMObjectClassAttribute that corresponds to each value from the QueryableAttrNames element within UserUIConfig.
Empties the SummaryAttrNames element within UserUIConfig.
Empties the QueryableAttrNames element within UserUIConfig.
Renames any extended attribute named objectClass to spml2ObjectClass. Starting in version 8.0, legacy attributes named objectClass conflict with a core attribute in the Identity Manager schema.
Identity Manager 8.0 dedicated some new tables for Roles objects. You must use the sample scripts provided in the db_scripts directory to make the schema changes, create the new table structures, and move your existing data.
Before updating the repository database table definitions, make a full backup of your repository tables.
Refer to the db_scripts/upgradeto8.0from71.DBMSName script for more information.
Be careful when you edit the super role field in the Role form because the super role itself may be a nested role. The super roles and subroles fields indicate a nesting of roles and their associated resources or resource groups. When applied to a user, the super role includes the resources associated with any designated subrole. The super role field is displayed to indicate the roles that include the displayed role.
During the upgrade process, Identity Manager analyzes all roles on the system and then updates any missing subroles and super roles links using the RoleUpdater class.
To check and upgrade roles outside of the upgrade process, you can import the new RoleUpdater configuration object that is provided in sample/forms/RoleUpdater.xml.
For example:
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Waveset PUBLIC 'waveset.dtd' 'waveset.dtd'> <Waveset> <ImportCommand class='com.waveset.session.RoleUpdater' > <Map> <MapEntry key='verbose' value='true' /> <MapEntry key='noupdate' value='false' /> <MapEntry key='nofixsubrolelinks' value='false' /> </Map> </ImportCommand> </Waveset> |
Where:
verbose: Provides verbose output when updating roles. Specify false to enable a silent update of roles.
noupdate: Determines whether the roles are updated. Specify false to get a report that only lists which roles will be updated.
nofixsubrolelinks: Determines whether super roles are updated with missing subrole links. This value is set to false by default and links will be repaired.
Administrators who need to view or edit the Identity Manager schema for Users or Roles must be in the IDM Schema Configuration AdminGroup and must have the IDM Schema Configuration capability.
The SPML 2.0 implementation in Identity Manager changed in Sun Identity Manager 8.0. In previous releases, the SPML objectclass attribute used in SPML messages was mapped directly to the objectclass attribute of Identity Manager User objects. The objectclass attribute is now mapped internally to the spml2ObjectClass attribute and is used internally for other purposes.
During the upgrade process the objectclass attribute value is automatically renamed for existing users. If your SPML 2.0 configuration contains forms that reference the objectclass attribute, you must manually change those references to spml2ObjectClass.
Identity Manager does not replace the sample spml2.xml configuration file during an upgrade. If you used the spml2.xml configuration file as a starting point, be aware that this file contains a form with references to objectclass that you must change to spml2ObjectClass. Change the objectclass attribute in forms (where it is used internally), but do not change the objectclass attribute in the target schema (where the attribute is exposed externally).
When you upgrade Identity Manager, any custom code that calls UserUIConfig#getRepoIndexAttributes() must be removed or changed to call Type.USER#getInlineAttributeNames(). (ID-18051)
Importing update.xml converts the values from the UserUIConfig RepoIndexAttrs into values of XML attributes on the TypeDataStore element for Type.USER within the RepositoryConfiguration object. The update.xml file includes the UserUIConfigUpdater.xml file, which contains an import command that invokes UserUIConfigUpdater to convert RepoIndexAttrs. Conversion also sets a flag in SystemConfiguration that inhibits reconversion.
Any future changes to the inline attributes for Type.USER should be made by editing the RepositoryConfiguration object. If you change the inline attributes for Type.USER, you generally must refresh all Type.USER objects.
Changes to RepositoryConfiguration do not affect an Identity Manager server until you restart that server.
Sun Identity Manager 8.0 changed the display method of charts and graphs in reports. Reports created prior to version 8.0 display as expected in the version 8.0 release. These reports, however, will not display properly in Sun Identity Manager 8.1. A deprecation notice regarding this issue appeared in the Sun Identity Manager Release Notes, Version 8.0 May 2008. (ID-17636)
Forms and workflows that use the SaveNoValidate action will need to be added to the new saveNoValidateAllowedFormsAndWorkflows list. (ID-19115)
Whitelist functionality added in Sun Identity Manager 8.1 checks forms and workflows that use the SaveNoValidate action against a list of IDs of form names. The saveNoValidateAllowedFormsAndWorkflows list is located in the security attribute in the System Configuration object. With this update, if the form name or owner ID is on the whitelist, the form or workflow can use the SaveNoValidate action. If the form name or the owner ID is not on the list, the form or workflow is processed using a Save action.
To obtain the IDs or form names for forms and workflows that use the SaveNoValidate action, check the system log or turn on trace level 4 for com.waveset.ui.util.GenericEditForm and submit any custom forms or workflows that use SaveNoValidate. A warning including the ID will be logged.
If you add a form name to the whitelist, be sure that the name attribute for the form is set, otherwise you will see the following error message:
SaveNoValidate on null processed as Save because it is not in the saveNoValidateAllowedFormsAndWorkflows list.