Examinez les considérations suivantes avant de commencer à mettre à niveau les composants OpenText Identity Manager :
Veillez à mettre à jour tous les composants OpenText Identity Manager vers la dernière version s'ils sont en cours d'exécution sur le même serveur.
Vous pouvez mettre à niveau les composants uniquement en mode console. La mise à niveau silencieuse n'est pas prise en charge.
Vous devez mettre à niveau un seul composant à la fois.
Le coffre-fort d'identité doit être mis à niveau séparément. Cette version prend en charge OpenText eDirectory 9.3.
Si OpenText Identity Console et OpenText eDirectory coexistent, veillez à mettre à niveau OpenText Identity Console vers la dernière version 1.9 avant de mettre à niveau OpenText eDirectory vers la version 9.3. Pour plus d'informations sur la mise à niveau d'OpenText Identity Console, voir Upgrading OpenText Identity Console (Mise à niveau d'OpenText Identity Console).
Si le coffre-fort d'identité est configuré sur le système de fichiers BTRFS, le processus de mise à niveau échouera. Cette version ne prend en charge que les systèmes de fichiers Ext3, Ext4 et XFS.
Assurez-vous que le fichier de cache ne contienne aucun événement avant d'entamer la mise à niveau du moteur OpenText Identity Manager. Si votre pilote utilise MapDB, assurez-vous que votre pilote mis à niveau fonctionne correctement avec le moteur mis à niveau. Pour plus d'informations, reportez-vous à la section Utilisation de MapDB 3.0.9.
Vous devez vérifier la configuration de serveur recommandée avant de mettre à niveau les composants. OpenText Identity Manager exige qu'Identity Applications et OSP soient installés sur le même ordinateur. Par contre, Identity Reporting prend en charge une instance OSP installée localement ou à distance.
Il est recommandé de configurer les applications et les bases de données et Identity Applications avec le nom de domaine complet (FQDN). Toutefois, pour Identity Reporting, les noms d'hôte seuls sont également pris en charge.
Si vous utilisez une version prise en charge de la base de données Oracle ou Microsoft SQL Server, vous devez configurer deux instances de base de données pour qu'Identity Applications fonctionne correctement : une base de données Identity Applications (idmuserappdb) et une base de données de workflow (igaworkflowdb). Veillez à configurer les instances de base de données sur le même serveur.
Si vous utilisez la configuration proxy inverse NAM avec Identity Applications pour charger des formulaires, vous devez utiliser une version 5.x de NAM.
À partir d'Identity Manager 4.9, SecretStore n'est plus pris en charge. Après la mise à niveau vers le dernier paquetage UAD et le redémarrage de Tomcat, tous les mots de passe de compte de messagerie électronique existants dans le dépôt SecretStore migrent automatiquement vers l'attribut notfSMTPMailPassword. Ce processus de migration de mot de passe est contrôlé par la propriété com.netiq.idm.migrate.secretstore, disponible dans le fichier ism-configuration.properties. Par défaut, cette propriété est définie sur true (vrai). Une fois la migration terminée, la propriété est automatiquement redéfinie sur false (faux) et reste dans cet état.
Lors de la mise à niveau de la 4.9 vers la 4.10, l'utilisateur n'est pas invité à saisir le mot de passe Keystore maître. Il utilise le mot de passe précédemment stocké dans le fichier ism-sensitive.properties. Toutefois, lors de la mise à niveau des versions 4.7.5 et 4.8.x vers la version 4.10, l'utilisateur est invité à saisir le mot de passe Keystore maître (encrypt-keys.pkcs12). Si vous souhaitez modifier ou coder à nouveau le mot de passe, consultez Storing Configupdate Ultity Password (Stockage du mot de passe Configupdate Ultity).
Les considérations suivantes s'appliquent à la réinitialisation de mot de passe en self-service (SSPR) :
Si la fonction d'audit est activée sur un serveur SSPR avec le type de format de sortie syslog CEF, vous devez désinstaller le collecteur SSPR du serveur Sentinel Syslog, sinon le serveur Syslog ne sera pas en mesure d'analyser les événements d'audit SSPR.
SSPR prend en charge les types de format de sortie CEF et JSON pour les événements d'audit. SSPR 4.8.0.1 continuera à prendre en charge le collecteur SSPR pour le type de format de sortie JSON. Si plusieurs serveurs SSPR sont connectés à un seul serveur Sentinel Syslog, vous ne devez sélectionner qu'un seul type de format pour les événements d'audit sur l'ensemble des serveurs.
Si la SSPR est installée sur un serveur distinct, mettez à niveau le composant vers la dernière version livrée avec OpenText Identity Manager 4.10.
Après avoir mis à jour OpenText Identity Manager vers la version 4.10, SSPR est mis à niveau vers la version 4.8.0.1 qui nécessite le collecteur Universal CEF pour collecter les événements d'audit au type de format CEF.
REMARQUE :si vous activez l'audit SSPR au type de format de sortie CEF pour la première fois, assurez-vous que le collecteur SSPR n'est pas configuré sur le serveur Sentinel Syslog.