SCCM 2012 - Une migration facilitée - Partie 3

Dans la première partie, nous avons abordé les exigences relatives à la préparation d'une migration et dans la deuxième partie, nous avons abordé les types d'objets disponibles pour la migration et les exclusions. Dans ce dernier article de la série, nous allons passer en revue le processus en utilisant l'utilitaire de migration qui a été mis en avant par Microsoft dans Configuration Manager 2012.

La première étape de la configuration du processus de migration consiste à "spécifier la hiérarchie des sources". Cette étape est à la fois cruciale et nécessaire pour avancer dans les plans de migration. La spécification de la hiérarchie source permet à ConfigMgr 2012 de rassembler toutes les données nécessaires de SCCM 2007 afin d'identifier les objets qui peuvent être migrés.

Passons maintenant à l'étape suivante. Tous les outils de migration se trouvent dans la section d'administration de la console.

Développez le dossier Migration pour faire apparaître trois options.

• Hiérarchie des sources
• Emplois dans le domaine de la migration
• Amélioration des points de distribution

Cliquez avec le bouton droit de la souris sur "Hiérarchie des sources" ou, à partir du ruban, sélectionnez "Spécifier la hiérarchie des sources".

La première page de l'assistant Hiérarchie des sources est maintenant présentée et il y a un certain nombre de choses à configurer. Afin d'acquérir correctement toutes les informations de l'environnement SCCM 2007, il est nécessaire de commencer par spécifier le site primaire de premier niveau. Dans la plupart des cas, le site primaire de premier niveau dans une hiérarchie SCCM 2007 est un site primaire central.

Une fois le serveur de site Configuration Manager 2007 de premier niveau spécifié, les comptes d'accès doivent être configurés. Comme le montrent les captures d'écran, les autorisations nécessaires ont déjà été définies.

• Accès en lecture au fournisseur de SMS.
• Lecture et exécution sur le site source SQL Server

Comme pour la plupart des fournisseurs de SMS, l'accès au compte spécifié nécessite des autorisations pour les utilisateurs COM distribués dans AD. Microsoft indique sur TechNet que cette autorisation est requise lors de la spécification d'un compte d'ordinateur, mais je vous recommande de valider cet accès même si vous utilisez un compte d'utilisateur de domaine.

Une fois que tous les comptes ont été saisis et que "OK" a été sélectionné, le processus de collecte des données démarre immédiatement. Une fenêtre de progression s'affiche, indiquant les étapes de la collecte des données.

Si une erreur survient au cours du processus de collecte des données, neuf fois sur dix, elle est liée à une autorisation. Le ratio peut être encore plus élevé, mais nous nous contenterons de 90 % pour l'instant. Une fois le processus initial de collecte des données terminé, l'état de la hiérarchie des sources indiquera "Prêt pour le prochain processus de collecte".

La collecte des données de la hiérarchie des sources étant terminée, il est maintenant possible de passer à la migration proprement dite des objets. Pour commencer à migrer des données de SCCM 2007, nous devons d'abord créer une tâche de migration. Dans la section Migration, cliquez avec le bouton droit de la souris ou utilisez le ruban et sélectionnez "Créer une tâche de migration". L'assistant de migration démarre alors.

Il existe trois types d'emplois dans le domaine de la migration...

• L'option de migration des collections est la plus complète. Ce type de migration permet de sélectionner les éléments associés, tels que les paquets et les publicités, qui sont destinés aux collections en question. Les publicités ne peuvent pas être migrées en dehors de la tâche de migration de collection. En outre, lors de la migration des collections, les fenêtres de maintenance et les variables de collection sont transférées. Cependant, les données de provisionnement du client AMT ne peuvent pas être migrées.
• La migration d'objets permet de migrer tous les éléments en dehors des collections. Veuillez vous référer à la partie 1 de cette série de blogs pour une liste des objets disponibles pour la migration.
• La dernière option, Objets modifiés après la migration, a un objectif assez spécifique. Comme la migration de toutes les données de SCCM 2007 peut être longue, en fonction de la complexité de l'environnement d'origine, il est possible que les données du côté 2007 soient modifiées au cours de la migration. Cette option permet de mettre à jour ces données sans avoir à supprimer manuellement les objets précédemment migrés.

L'étape suivante du processus consiste à sélectionner la ou les collections qui seront migrées. Il n'est pas nécessaire de migrer "toutes" les collections à la fois, car plusieurs tâches de tous types peuvent être configurées. Le nombre de tâches augmentera, par défaut, avec la complexité de l'environnement SCCM 2007 ainsi qu'avec le nombre de sites et d'étendues de sécurité dans ConfigMgr 2012.

Comme vous pouvez le voir ci-dessus, toutes les collections seront affichées telles qu'elles sont présentées dans SCCM 2007. Il suffit de sélectionner toutes les collections à migrer. Si l'environnement source comporte un très grand nombre de collections, cliquez sur le bouton de recherche pour afficher une liste complète qui peut être triée et restreinte afin de localiser plus efficacement la collection souhaitée. Si la migration des données associées à la collection n'est pas nécessaire, décochez l'option Migrer les objets associés à la collection spécifiée en bas de la page de l'assistant.

Au cours de votre navigation, il est possible que la collection souhaitée apparaisse dans la liste par défaut ou dans la zone de recherche. Dans ce cas, sélectionnez Afficher les collections qui ne peuvent pas migrer. Il existe 4 scénarios dans lesquels une collection ne sera pas disponible pour la migration, qui sont décrits ci-dessous.

• Collections de requêtes mixtes - collections contenant des utilisateurs et des ordinateurs - Ceci peut être éliminé en séparant les collections mixtes du côté de SCCM 2007 avant la migration (ce qui est recommandé par Microsoft).
• Hiérarchie de collections mixtes - collections dont les collections parentales et enfantines appartiennent à des sites différents.
• Limitation de collection multiple - collection limitée par plus d'une autre collection
• Limitée à une collection bloquée - collection limitée par une collection qui ne peut pas être migrée.

Une fois que toutes les collections ont été sélectionnées pour ce travail de migration particulier, la page suivante de l'assistant nous guidera dans la sélection des objets (en supposant qu'il ait été choisi de le faire). Cette page n'affichera que les objets directement liés aux collections sélectionnées.

Cette page est très explicite dans la mesure où, s'il existe des objets associés aux collections, ils peuvent être migrés dans le cadre du même travail. Quelques remarques supplémentaires...

• Afin de migrer les publicités, les paquets qui leur sont associés doivent également être migrés.
• Les publicités migrées ne sont pas activées par défaut (une option d'activation est disponible, mais il ne s'agit pas d'une meilleure pratique).

Lors de la migration d'objets de SCCM 2007, il est nécessaire de spécifier le propriétaire du contenu de ConfigMgr 2012. Le propriétaire du contenu, faute d'une meilleure description, est le site d'où vous voulez que les données proviennent. Si la migration ne concerne qu'un seul site, cette section ne nécessite aucune discussion supplémentaire. Cependant, si plusieurs hiérarchies sont utilisées en 2012, le propriétaire de contenu souhaité devra être spécifié pour permettre une affectation correcte des données.

L'option suivante est l'attribution d'un périmètre de sécurité. L'étendue de sécurité fait partie du nouveau modèle d'administration basé sur les rôles qui permet d'attribuer les droits appropriés aux objets migrés sur la base des étendues définies. Comme nous n'entrerons pas dans le détail de l'administration basée sur les rôles, nous nous contenterons d'avancer et de supposer que l'étendue par défaut sera sélectionnée.

Cette étape du processus est conçue pour vous donner la possibilité de limiter les collections qui peuvent être incluses dans le champ d'application après la migration. Permettez-moi d'expliquer un peu plus en détail. Dans ConfigMgr 2012, toutes les collections sont globales. Cela signifie qu'une collection créée à partir de n'importe quelle partie de la hiérarchie est disponible pour tous les sites. Ainsi, par exemple, si vous migrez une collection d'un site primaire enfant qui contient "Tous les systèmes Windows 7" de ce site, lorsqu'elle est introduite dans l'environnement ConfigMgr 2012, cette collection contiendra désormais tous les systèmes Windows 7 de l'ensemble de la hiérarchie. L'outil de migration reconnaît ces problèmes et vous permet de fournir la limitation de collection correcte (la limitation est requise en 2012).

Cette étape est assez simple. Si vous avez des collections qui contiennent des requêtes utilisant le code de site de l'environnement SCCM 2007, elles seront remplacées par le code de site correct de l'environnement ConfigMgr 2012. Il s'agit d'un processus automatique qui ne nécessite aucune configuration.

Maintenant que vous avez parcouru la majeure partie de l'assistant de migration, une fenêtre s'affiche pour vous permettre de passer en revue les configurations et vous fournir des informations sur les objets qui ont été choisis pour la migration. Elle fournit également des informations sur les actions qui pourraient ou devraient être entreprises avant l'initialisation du travail de migration.

Une nouvelle fonction utile de la page de révision est la possibilité d'enregistrer les informations présentées dans un fichier. Cela permettra évidemment de suivre correctement les tâches et les processus de migration à des fins d'examen, tout en fournissant un enregistrement des recommandations préalables à la migration. Je recommande de sauvegarder tous les fichiers pendant votre processus de migration, car trop d'informations n'est jamais une mauvaise chose.

La page des paramètres de l'assistant permet de configurer la planification de la tâche de migration et de définir les actions qui se produiront pendant l'exécution de la tâche de migration.

La première section de cette page est consacrée à la planification du travail de migration. Il y a trois options et elles sont toutes explicites...

• Ne pas exécuter le travail de migration
• Exécuter le travail de migration maintenant
• Planifier le travail de migration

La deuxième section explique comment traiter les objets qui ont déjà été migrés. La sélection par défaut est Ne pas migrer les options mises à jour, ce qui serait ma recommandation générale. Lors de la sélection des collections ou des objets à migrer, l'état de ces éléments est indiqué (migré | non migré), et ceux qui ont été migrés doivent être ignorés. Si des éléments ont été mis à jour depuis l'exécution d'un précédent travail de migration, il convient d'utiliser le travail Objets modifiés après la migration pour les mettre à jour.

Dans les paramètres supplémentaires, la case Transférer la structure des dossiers d'organisation des objets de Configuration Manager 2007 vers le site de destination a été présélectionnée. Si vous ne souhaitez pas que les structures de dossiers soient transférées lors de la migration, il vous suffit de décocher cette case. Certaines organisations peuvent utiliser cette migration comme une raison de réorganiser les données et la façon dont les éléments de l'environnement ConfigMgr sont structurés, de sorte qu'elles choisissent de ne pas migrer la structure des dossiers. Pour ma part, je trouve cela très utile.

La dernière option est celle que nous avons brièvement évoquée précédemment et qui permet de déployer les programmes une fois qu'ils ont été migrés. Cette option doit être évaluée avec soin car l'environnement ConfigMgr 2012 doit être complètement configuré avant de l'utiliser. Je fais cette déclaration en toute confiance, car dans le cas où une publicité et un programme sont activés lors de la migration et qu'ils sont destinés à une collection dont la portée a augmenté, un certain nombre de systèmes qui n'étaient pas prévus à l'origine pour exécuter ce programme peuvent le faire. Il n'est pas difficile de passer en revue et d'activer les programmes après la migration, ce qui donne également le temps de revoir les systèmes/utilisateurs qui seront ciblés.

Les dernières pages de l'assistant sont celles que les administrateurs de gestionnaires de configuration connaissent bien : résumé, progression, achèvement. C'est pourquoi je ne pense pas que nous ayons tous besoin de les passer en revue.

Nous sommes arrivés à la conclusion de la série de blogs "Migration Made Easy". Comme toujours, j'espère sincèrement que les informations que j'ai incluses ici ont été utiles, au moins en partie, pour vous aider dans votre prochaine migration.

Si vous avez trouvé cette page et que vous n'avez pas consulté les parties 1 et 2, cliquez ici pour consulter la liste de mes blogs.