Bonjour à tous !

Nous allons nous pencher aujourd'hui plus profondément dans les entrailles du produit Quest Migration Manager for Active Directory, notamment avec l'étude d'un cas problématique et de sa résolution.

Le cas que nous allons étudier ci-dessous est susceptible d'être peu rencontré, mais il n'en est pas moins "vicieux". J'espère donc que ce billet n'en sera que d'autant plus utile.

Les symptômes

• Vous avez migré un ensemble d'utilisateurs à l'aide de QMM.
• Vous avez lancé des processings avec RUM sur un ensemble de postes.
• Sur certains postes, le processing se passe correctement, sur d'autres non.
• Aucune erreur particulière n'est rapportée dans la console RUM, le seul signe visible est qu'aucun élément n'est mis à jour lors du processing (Aucun fichier, aucune clé registre, ...).
• Si vous remigrez les utilisateurs à l'aide d'un autre serveur Quest, et si vous effectuez de nouveau des processings sur les précédents postes avec ce nouveau serveur, vous pourrez constater que certains postes sont correctement processés cette fois-ci, et que d'autres ne le sont plus.

Analyse du problème

La console RUM de Quest ne nous indiquant aucune erreur particulière lors des processings sur les postes en question, c'est donc vers les fichiers de logs que nous allons devoir nous tourner.

Le premier fichier de log nous intéressant va être celui qui remonte les détails du processing d'un poste.

Vous pourrez trouver, pour une instance RUM, tous les fichiers de processing de l'ensemble des postes dans le dossier suivant :

C:\Program Files (x86)\Common Files\Aelita Shared\Migration Tools\Resource Updating\Logs\

Allez dans le dossier correspondant au poste voulu et ouvrez le fichier de log correspondant au processing "en échec".

A première vue, il n'y a rien d'inhabituel dans le fichier de log, à part que l'on remarque bien qu'il n'y a aucun élément mis à jour lors de processing. Cependant, il faut bien regarder le Warning présent à la deuxième ligne.

Nous y trouvons l'avertissement suivant, à savoir que Le fichier INI contient une ligne invalide :

INI file contains invalid line '9;User_XXX;106572;;User;XXX@sourcedomain.local;User;XXX@targetdomain.local;1'. Escape to next domain pair

Avant de pouvoir analyser la ligne en question, il nous faut donc parcourir le fichier INI en question. Ce fichier correspond en fait au fichier de mappage des utilisateurs que RUM utilise lors de ces processings. A chaque processing, un nouveau fichier de mappage est généré selon les utilisateurs migrés par l'instance QMM. Tous les fichiers de mappage générés se trouvent à l'intérieur du dossier suivant :

C:\Program Files (x86)\Common Files\Aelita Shared\Migration Tools\Resource Updating\Configs\

Si l'on prend le fichier INI cité précédemment, voici ce que l'on trouve à l'intérieur de celui-ci :

La 1ère ligne représente une ligne correctement formée, à savoir que tous les champs du fichier de mappage sont séparés par un point-virgule.

La 2ème ligne surlignée correspond à la ligne citée en erreur. Quand on effectue une analyse de celle-ci, on remarque qu'elle contient plus de point-virgule que pour une ligne correctement formée. Je vous remets le message d'erreur avec le surlignage pour bien mettre en évidence les anomalies :

INI file contains invalid line '9;User_XXX;106572;;User;XXX@sourcedomain.local;User;XXX@targetdomain.local;1'. Escape to next domain pair

En l'occurrence, après une vérification dans les propriétés de l'utilisateur dans l'AD Source, il s'avère que le SamAccountName de l'utilisateur en question est bien "User_XXX" mais que l'UPN de celui-ci est "User;XXX" !

Le fichier de mappage va donc inclure d'office ces points virgules supplémentaires ce qui va causer l'erreur citée précédemment, qui n'est donc pour le moment pas explicitement gérée par Quest dans le sens ou, précédemment, la migration de cette utilisateur via QMM n'a donné lieu à aucun avertissement.

La conséquence de cette erreur nous est donnée dans le message d'avertissement, à savoir Escape to next domain pair.

Une domain pair dans le jargon de Quest correspond à une paire domaine source - domaine cible déclarée dans Quest. Si vous avez plusieurs domaines distincts à migrer avec QMM, vous devez déclarer une domain pair pour chacun d'entre eux. Ce qu'indique le message d'erreur, c"est que toute la partie du fichier de mappage qui est après la ligne en erreur est ignorée, jusqu'à la prochaine domain pair rencontrée comme schématisé dans l'image ci-dessous :

C'est ce fait qui explique pourquoi certains postes n"étaient pas procéssés, tandis que d'autres l'étaient correctement. C'est également ce fait qui explique les disparités observées dans les processings effectués à l'aide d'une autre instance de Quest RUM. En effet, comme le fichier de mappage des comptes est re-généré à chaque processing, l'ordre des comptes à l'interieur de celui-ci diffère suivant les instances, c'est donc pourquoi le processing était de nouveau fonctionnel pour certains postes, et pour d'autres non avec une nouvelle instance.

Solution

La résolution du problème se présente sous la forme suivante :

• Modifiez l'utilisateur en erreur dans l'AD source et dans l'AD cible afin de retirer le caractère point-virgule du nom d'utilisateur
• Effectuez une nouvelle migration de l'utilisateur (un merge dans le cas présent car l'utilisateur est déjà existant dans l'AD cible) avec QMM car RUM se base sur les utilisateurs migrés avec QMM pour construire son fichier de mappage des utilisateurs (voir la section Addendum pour les exceptions)
• Effectuez de nouveau un processing des postes en erreurs, celui-ci devrait être désormais fonctionnel, avec notamment le message suivant dans le fichier de log des postes procéssés :

Addendum

Il nous faut ajouter une petite précision, car nous avons précisé au paragraphe précédent que RUM se basait sur la liste des utilisateurs migrés avec QMM pour construire son fichier de mappage des utilisateurs.

Ce n'est plus systématiquement vrai avec la version 8.13 de QMM et RUM, car nous pouvons indiquer à RUM lors des processings de se baser directement sur le SIDHistory de l'utilisateur cible (SID de l'utilisateur source) dans l'AD cible pour effectuer la correspondance des comptes utilisateurs sur les machines migrées.

Vous trouverez l'option lors de l'étape suivante du processing :