Si vous avez déjà utilisé FIM, vous savez que la migration d'une configuration de service FIM d'un environnement à un autre peut s'avérer très difficile.
Bien que Microsoft fournisse une procédure, des scripts et des primitives PowerShell sous-jacentes pour faciliter le processus, la solution proposée part du principe que vous allez migrer une configuration entière et que vous n'avez pas besoin de gérer plusieurs configurations. Pour être honnête, ce que Microsoft fournit n'est qu'un point de départ suggéré.
Dans ce billet de blog, j'aborderai une procédure que nous avons mise au point au CSS et qui améliore le processus de migration. Nous n'avons certainement pas résolu tous les problèmes, mais nous espérons que vous trouverez ce que nous avons fait utile pour créer votre propre processus de migration du service FIM.
Si vous lisez l'article TechNet sur la migration de la configuration FIM, il est question de sauvegarder les bases de données, d'extraire la configuration du service FIM et du moteur de synchronisation, de copier le flux de travail du service FIM et les DLL d'extension du moteur de synchronisation, de comparer les configurations du service FIM et d'importer les modifications du service FIM dans le système cible. Beaucoup de ces étapes sont importantes (en particulier la sauvegarde) mais ne sont pas abordées dans ce billet. Je ne parlerai que de la migration du schéma et de la politique dans le service FIM lui-même. Prenez le temps de lire l'article de TechNet (lien ci-dessus et ci-dessous).
Pour faciliter la gestion des configurations multiples, nous avons mis à jour les scripts PowerShell afin de créer et de travailler à partir de répertoires contenant des configurations individuelles. En automatisant la création de répertoires liés à la configuration, nous réduisons les erreurs qui peuvent survenir lors de la copie et du renommage manuels des fichiers, comme cela est nécessaire lors de l'utilisation du processus de migration de la configuration de base.
La première étape consiste à obtenir les scripts et l'outil delta. Ils sont disponibles ici. Décompressez les fichiers dans un répertoire appelé "FIM Service Migration" ou similaire. Effectuez cette opération sur vos machines de développement et de production (ou sur tout autre environnement entre lequel vous effectuez la migration).
Ensuite, exécutez le script ExportConfig.ps1 dans vos deux environnements. Ce script combine les fonctions des scripts originaux ExportSchema et ExportPolicy et place les fichiers d'exportation résultants dans un sous-répertoire nommé avec la date et l'heure actuelles. Notez que, comme pour les scripts Microsoft originaux, vous devez exécuter ce script en tant que compte faisant partie de l'ensemble des "administrateurs" du service FIM. Sinon, vous n'obtiendrez pas une exportation complète de la configuration.
Comme le répertoire créé par le script ExportConfig représente une configuration du service FIM pour un environnement spécifique à un moment précis, vous voudrez renommer le répertoire en quelque chose de plus significatif pour vous. Je recommande d'inclure au moins le nom de l'environnement et un horodatage ou un numéro de version. Dans cet exemple, je renommerai l'exportation ci-dessus (à partir de la machine de développement) en "Dev-20140429" pour indiquer qu'il s'agit de la configuration de l'environnement de développement en date du 29 avril. Sur l'ordinateur de production, je ferai la même chose mais j'utiliserai le nom de répertoire "Prod-20140429". Copiez le répertoire de la machine de développement vers la machine de production de manière à ce que les deux répertoires se trouvent sur la machine de production. Sur la machine de production, vous devriez obtenir quelque chose comme :
Ensuite, exécutez le script DiffConfig.ps1. Ce script combine les fonctions des scripts originaux SyncSchema et SyncPolicy. Au lieu de vous demander de renommer les fichiers d'exportation en pilot.xml et production.xml pour chaque extrait de schéma et de politique (et de vous demander de vous souvenir de quels fichiers il s'agit), le script DiffConfig prend les noms de répertoire des étapes précédentes comme paramètres. Le paramètre SourceDirectory est la nouvelle configuration que vous souhaitez appliquer quelque part (dans notre cas, l'environnement de développement) et le paramètre TargetDirectory est la configuration sur laquelle nous souhaitons appliquer la configuration source (dans notre cas, la production). Nous voulons appliquer la source à la cible (pour que la cible ressemble à la source).
Le script calcule les modifications nécessaires sur la cible et crée un ensemble de fichiers de modifications. Ces fichiers sont placés dans un nouveau répertoire nommé "Diff-" suivi des noms des répertoires source et cible.
Le script utilise les mêmes techniques (cmdlets d'automatisation FIM PowerShell) que les scripts Microsoft standard et présente les mêmes problèmes. Si vous avez des instances d'objets dont les noms d'affichage ne sont pas uniques ou si vous avez créé des types de ressources personnalisés, vous devrez peut-être nettoyer vos données ou modifier les règles de jointure dans le script (à cet égard, le processus d'exportation précédent peut avoir des problèmes similaires s'il y a des références invalides dans votre configuration ou si vous avez des valeurs de chaîne qui "ressemblent" à des références aux cmdlets d'automatisation).
En regardant dans le répertoire résultant, nous avons maintenant :
Hormis les noms de fichiers, ces fichiers sont identiques aux fichiers changes.xml que les scripts SyncSchema et SyncPolicy auraient fournis. Si nous savions que nous voulions appliquer tous les changements calculés, nous pourrions simplement appliquer ces fichiers à l'environnement de production et en finir.
Mais que se passe-t-il si nous avons des éléments dans l'environnement de développement que nous ne voulons pas mettre en production ?
Dans notre exemple, l'environnement de développement contient des types de ressources supplémentaires qui ont été créés par inadvertance. Dans le service FIM, une fois que vous avez créé un nouveau type d'objet et que vous l'avez utilisé, vous ne pouvez pas le supprimer, ce qui peut poser problème si vous ne voulez pas de ressources supplémentaires en production. Notre configuration comprend également des ensembles dont l'appartenance est manuelle. Les personnes placées dans les ensembles de l'environnement de développement ne seront pas présentes dans la production, donc si nous ne faisons rien de spécial, le processus de migration essaiera de créer les utilisateurs de développement dans la production ou se plaindra qu'il ne peut pas trouver les utilisateurs correspondants.
Traditionnellement, pour corriger cette situation, il faut ouvrir le fichier changes.xml et supprimer les objets que l'on ne souhaite pas mettre en production. En outre, si vous vouliez simplement voir les modifications exactes qui étaient sur le point d'être envoyées à la production, vous deviez inspecter manuellement le fichier changes. L'inspection et la modification du fichier de modifications sont difficiles et sources d'erreurs, car il identifie en interne les objets par leurs identifiants de ressources de type GUID et de nombreux objets contiennent des références à d'autres objets. L'édition incorrecte d'un objet ou la rupture d'une chaîne de référence peut entraîner des échecs d'importation à un stade ultérieur du processus.
Il y a environ un an, un certain Alex Skalozub a publié sur GitHub un outil formidable appelé "FimDelta". Cet outil affiche le contenu d'un fichier de modifications dans une arborescence graphique et vous permet de supprimer les éléments que vous ne souhaitez pas mettre en production. Les modifications peuvent être exclues au niveau de l'objet ou de l'attribut. L'outil vous permet également de naviguer facilement dans les références et les relations entre les objets. Même si vous n'avez pas l'intention d'exclure des objets de votre production, il s'agit d'un excellent outil pour voir simplement quels sont les changements.
Pour une raison ou une autre, cet outil ne semble pas être très utilisé. La plupart de nos clients n'en ont pas entendu parler. Cela peut s'expliquer par le fait que l'outil est un peu difficile à lancer, car il nécessite de copier et de renommer les fichiers d'extraits source et cible, ainsi que le fichier de modifications, dans le répertoire où l'outil est installé.
Afin de faciliter son utilisation et de l'intégrer dans notre processus de migration, j'ai procédé à quelques mises à jour de l'outil. J'ai ajouté la possibilité de transmettre les noms de fichiers dont il a besoin sur la ligne command et j'ai ajouté des menus "fichiers" traditionnels pour que, à l'intérieur de l'outil, vous puissiez naviguer vers les fichiers dont vous avez besoin et les ouvrir, ainsi que spécifier le nom et l'emplacement du fichier de modifications de sortie. J'ai également ajouté la possibilité de sauvegarder et de restaurer les "exclusions" ou les éléments que vous ne souhaitez pas migrer. Cela peut vous faire gagner du temps si vous devez effectuer plusieurs migrations.
L'outil mis à jour est inclus avec les scripts de migration dans le lien ci-dessus et le code source mis à jour est disponible sur GitHub (comme pour tout ce qui est gratuit, utilisez-le à vos risques et périls, sans garantie, etc.)
Examinons l'outil et voyons comment exclure les modifications de schéma que nous avons en développement, mais que nous ne voulons pas en production. Le script LaunchFimDelta.ps1 lance l'outil et lui donne les noms de fichiers nécessaires. Vous verrez qu'il prend les mêmes paramètres que le script DiffConfig et un de plus. Cela signifie que si vous venez d'exécuter le script Diff, vous pouvez appuyer sur la flèche vers le haut, modifier le nom du script, appuyer sur la touche de fin et ajouter le paramètre de catégorie. Le paramètre de catégorie prend soit "schema", soit "policy_portal", en fonction de l'ensemble de modifications que vous examinez.
Lorsque l'outil s'ouvre, vous verrez la boîte de dialogue "Ouvrir les fichiers" prête à fonctionner, il vous suffit de cliquer sur OK. Si vous exécutez l'outil manuellement, vous devrez spécifier les fichiers d'extraction source et cible ainsi que le fichier de modifications généré par le processus de comparaison. Notez que si vous donnez à l'outil un ensemble de fichiers qui ne vont pas ensemble, il se plantera probablement.
Les détails de l'utilisation de l'outil font l'objet d'un autre article de blog, mais vous pouvez trier les modifications par opération ou par type d'objet et vous pouvez passer beaucoup de temps à examiner et à filtrer votre fichier de modifications. Pour ce récit, nous allons exclure certains types d'objets indésirables :
Vous pouvez voir que j'ai décoché cinq types de ressources (types d'objets) que nous ne voulons pas transférer à la production et que j'ai laissé coché le seul nouveau type de ressource (emplacement) que nous voulons envoyer à l'environnement de production.
Nous allons maintenant enregistrer nos modifications (Fichier, Enregistrer sous). Par défaut, l'outil ajoute "_filtered" au nom du fichier et le place dans le même répertoire que celui d'où proviennent les modifications.
Ensuite, nous allons empêcher les utilisateurs de développement d'être migrés vers la production. La capture d'écran suivante montre à quoi ressemble l'outil delta après l'exécution du script LaunchFimDelta, cette fois avec l'option policy_portal :
J'ai regroupé les modifications par type d'objet et vous pouvez voir des exemples des différents types d'objets hors schéma qui font partie de la configuration d'un service FIM. J'ai décoché tous les objets "Personne" parce que je ne veux pas déplacer d'identités du développement vers la production. Vous pouvez voir que le type d'opération est "Resolve", qui est l'opération que le processus d'importation (à venir) utilise pour aligner les références aux objets qui n'existent pas encore dans l'environnement cible. Comme nous ne déplaçons pas d'utilisateurs, nous ne voulons pas nous embêter à essayer de les rechercher.
En descendant un peu, nous pouvons voir quelques définitions :
Ici, vous pouvez voir que nous choisissons de créer un ensemble appelé "_Location Admins" mais que nous n'allons pas faire progresser l'appartenance réelle de l'ensemble. Dans le fichier de modifications, les membres de l'ensemble sont stockés en tant que références, mais l'outil delta a l'intelligence de vous montrer ce que sont les références. La capture d'écran montre que "ce2579dd-204c..." est en fait moi dans l'environnement de développement. Si j'avais voulu mettre mon compte en production, j'aurais pu laisser mon attribut ExplicitMember et l'action de résolution correspondante cochés.
Après avoir sauvegardé, nous avons ce qui suit dans notre "répertoire diff" :"
Il est maintenant temps d'importer les modifications en production. Pour ce faire, nous utilisons le script CommitChanges.ps1. Ce script combine les fonctions des scripts CommitChanges et ResumeUndoneImports.
Notez que le script CommitChanges apporte effectivement des modifications à votre configuration. Comme pour toute modification de configuration, vous devez donc vous assurer de disposer d'une bonne sauvegarde de la base de données du service FIM avant de l'exécuter.
CommitChanges prend en paramètre le fichier de modifications. Vous devriez typiquement lui passer la version "filtrée" du fichier que vous venez de créer avec l'outil delta. Voici l'importation du schéma, qui s'exécute proprement :
Il arrive que l'importation ne se déroule pas "proprement". Dans notre cas, nous avons une erreur lors de l'importation de la politique :
Dans ce cas, nous avons utilisé une fonctionnalité qui a été ajoutée dans un correctif de FIM (la possibilité de cacher le lien de recherche avancée dans le portail). Dans l'environnement de développement, nous avons ajouté manuellement le schéma nécessaire pour activer la fonctionnalité et nous avons créé la règle de politique de gestion nécessaire pour autoriser l'accès au nouveau schéma. Ces modifications n'ont pas encore été apportées à la production et, par hasard, l'option de configuration qui contient le nouveau paramètre est appliquée avant la règle de politique de gestion nécessaire qui permet de modifier le paramètre. Ce type d'erreur d'ordre est un problème courant lors des migrations de configuration. La solution consiste à réessayer pour les modifications qui n'ont pas pu être importées.
Comme le script CommitChanges original, notre script mis à jour affiche toutes les modifications qu'il n'a pas pu envoyer au système cible. Contrairement au script original, nous construisons le nom du fichier "undone" avec le nom du fichier de modification qui a été utilisé plus un horodatage. Vous disposez ainsi d'un historique de chaque série d'"annulations".
Ce qui est intéressant, c'est que le fichier "undone" est dans le même format que le fichier "changes". Cela signifie que si vous ne voulez pas examiner le XML à la main pour voir ce qui n'a pas été mis en production, vous pouvez le charger dans l'outil delta...
L'outil delta nous indique que nous essayons de mettre à jour les attributs "HideAdvancedSearchLink" (et trois autres). Le problème est que le MPR qui le permet n'a pas encore été créé.
Dans notre cas, le MPR dont nous avions besoin se trouvait dans le fichier de modifications original (juste après la mise à jour de PortalUIConfiguration) et se trouve maintenant dans la production. Cela signifie que nous pouvons simplement soumettre le fichier annulé au script CommitChanges et réussir :
Si nous jetons un dernier coup d'œil à notre répertoire diff, nous verrons que nous avons un bel historique des changements calculés pour notre "release" ; les changements que nous avons effectivement mis en production ; et les changements avec lesquels nous avons eu des difficultés :
Enfin, il ne faut pas oublier que ce processus ne doit pas être réservé à la migration de la production. Vous pouvez également l'utiliser pour suivre la progression au sein d'un environnement unique. La capture d'écran suivante montre à quoi pourrait ressembler un environnement de développement avec des exportations de configuration prises à différents moments (ignorez les temps de mise à jour des fichiers - il s'agit d'une simulation pour l'article de blog, regardez les noms des répertoires...).
Le répertoire "Base3508" contient une exportation d'une version 3508 de la base de données du service FIM, fraîchement installée et mise à jour. Les autres répertoires contiennent des exportations de la configuration aux dates indiquées dans les noms de fichiers.
Avec ces informations, nous pouvons exécuter le processus DiffConfig à deux moments quelconques :
- Si nous voulons savoir à quoi ressemble notre configuration complète : Exécuter "DiffConfig .\Base3508 .\Dev-20140429"
- Si nous voulons savoir ce qui a changé dans la configuration entre le 24 mars et le 28 mars : Exécutez "DiffConfig .\Dev-20140324 .\Dev-20140328"
Il fonctionne également à l'envers :
- Si nous voulons savoir comment annuler les changements qui se sont produits entre le 4 avril et le 28 mars : Exécutez "DiffConfig .\Dev-20140404 .\Dev-20140328"
- Si nous ne voulons annuler que quelques modifications survenues entre le 4 avril et le 28 mars, nous pouvons procéder de la même manière, mais en passant le fichier de modifications (rétrospectives) dans l'outil FIM Delta et en décochant les éléments que nous ne voulons pas annuler.
- Si nous voulons rétablir le portage de certains changements qui n'ont été effectués qu'en production : Exécuter "DiffConfig .\Prod-xxx .\Dev-xxx". Là encore, nous pouvons utiliser l'outil delta pour sélectionner uniquement les modifications que nous voulons rétablir et ne pas effacer les autres modifications dans le développement qui n'ont pas encore été transférées.
Bien que la procédure décrite ci-dessus ne soit pas parfaite, elle constitue une amélioration considérable par rapport aux opérations manuelles. J'ai trouvé les migrations beaucoup plus simples en l'utilisant. Je n'ai plus besoin de me rappeler quelle version du fichier changes.xml se trouve devant moi. Je ne m'effondre plus lorsque je dois déplacer quelques éléments de configuration d'un environnement à un autre. J'espère que le processus décrit ci-dessus et l'outil FIM Delta mis à jour vous seront utiles.
Liens utiles :
Fichier zip contenant l'outil FIM Delta mis à jour et les scripts de migration PowerShell : https://www.css-security.com/fdist/FimServiceMigration1.3.zip
Code source de l'outil FIM Delta mis à jour : https://github.com/RexWheeler/FIMDelta
Article TechNet sur la migration de la configuration du FIM : https://technet.microsoft.com/en-us/library/ff400277%28v=ws.10%29.aspx
Scripts PowerShell de migration Microsoft FIM : https://technet.microsoft.com/en-us/library/ff400275%28v=ws.10%29.aspx
Documentation pour les Cmdlets PowerShell de la FIM : https://technet.microsoft.com/en-us/library/ff394179.aspx
