• Accueil
  • Blog
  • SCCM 2012 - Migration facilitée - Partie 2

SCCM 2012 - Migration facilitée - Partie 2

Dans la première partie de cette série de blogs, j'ai présenté une vue d'ensemble des conditions requises pour préparer une migration de Configuration Manager 2007 vers 2012. Avec ces informations en main, je pense que vous devriez avoir une compréhension générale des pré-requis nécessaires pour commencer votre processus de migration.

Objets de migration

Nous allons couvrir les types d'objets qui peuvent être migrés et comment ils sont traduits dans Configuration Manager 2012. Vous trouverez ci-dessous tous les objets qui peuvent être migrés de ConfigMgr 2007 à ConfigMgr 2012.

  • Frontières
  • Collections
  • Software Emballages
  • Paquets d'applications virtuelles
  • Software Mise à jour des paquets de déploiement
  • Software Mise à jour des modèles de déploiement
  • Software Mise à jour des listes
  • Images de démarrage du système d'exploitation
  • Paquets de pilotes du système d'exploitation
  • Pilotes du système d'exploitation
  • Images du système d'exploitation
  • Packages d'installation du système d'exploitation
  • Séquences de tâches
  • Lignes de base de la configuration du DCM
  • Éléments de configuration du DCM
  • Catalogue d'Asset Intelligence
  • Asset Intelligence Hardware Exigences
  • Asset Intelligence Software Liste
  • Software Règles de comptage

Frontières

Le processus de migration des limites permet une migration directe de chaque limite spécifiée dans un site source de ConfigMgr 2007. Comme ConfigMgr 2012 utilise des groupes de limites en conjonction avec des limites standard, le processus de migration créera chaque limite et créera automatiquement un groupe de limites (pour le site source correspondant) dont les limites migrées deviendront membres. La figure 1 montre trois périmètres qui ont été migrés à partir d'un seul site ConfigMgr 2007 et la figure 2 montre qu'un seul groupe de périmètres a été créé pour contenir trois périmètres.

Figure 1 - Frontières migrées de ConfigMgr 2012

Figure 2 - Groupe de délimitation créé automatiquement par ConfigMgr 2012

Collections

La migration des collections est de loin l'un des processus les plus utiles de l'utilitaire pour plusieurs raisons. Tout d'abord, les collections sélectionnées pour la migration sont automatiquement analysées par l'utilitaire de migration afin de déterminer s'il existe des paquets software , des publicités, des mises à jour software ou des séquences de tâches associées à la (aux) collection(s) sélectionnée(s). Si l'un ou l'ensemble de ces éléments sont identifiés, l'utilitaire offre la possibilité de migrer les éléments spécifiquement référencés avec la ou les collections.

Si vous remarquez, les "annonces" ne sont pas présentes dans la liste par défaut des objets de migration qui ont été mentionnés précédemment et qui font pourtant partie de la migration de la collection. Il ne s'agit pas d'une erreur. La migration d'une publicité n'est possible que lors de la migration d'une collection, et uniquement si une publicité est ciblée sur la collection en cours de migration. L'objectif derrière cela, qui est mon opinion et non un fait publié, est qu'une publicité ne peut pas être migrée si la collection et le paquet ciblés ne sont pas présents.

Deuxièmement, si vous avez une structure de collection qui utilise des collections vides comme supports et organisation, l'utilitaire de migration convertit ces collections en dossiers organisationnels. Bien que j'aie été méfiant au début, après avoir vu la traduction de l'objet de migration, je peux dire que le processus est très efficace. La capture d'écran de la figure 3 montre les collections sélectionnées pour la migration, et la figure 4 montre à quoi ressemblent ces collections après la migration.

Figure 3 - Assistant de migration des collections

Figure 4 - Collections migrées

Remarque importante : les collections contenant à la fois des utilisateurs et des systèmes ne peuvent pas être migrées. Il est recommandé de séparer les collections mixtes avant la migration.

Software Emballages

Software sont évidemment une évidence en termes d'objets disponibles pour la migration. Toutes les options et tous les programmes des paquets sont maintenus pendant la migration. Cependant, les paquets migrés ne sont pas traduits dans le nouveau "modèle d'application". La figure 5 montre deux paquets migrés et le nombre de programmes correspondant.

Figure 5 - Paquets migrés Software

Microsoft a conçu un gestionnaire de conversion de paquets (PCM) pour vous aider à transformer vos paquets Software migrés en applications ConfigMgr 2012. Pour plus d'informations sur le PCG, cliquez sur le lien suivant :

https://technet.microsoft.com/en-us/library/hh531519.aspx

Une mise en garde s'impose concernant l'emplacement du contenu source. Afin de faciliter une migration transparente pour les paquets software , tous les emplacements de fichiers source doivent utiliser un chemin UNC. Tout paquet qui utilise un chemin d'accès local comme emplacement source lors de la migration ne sera pas distribué à moins que le chemin spécifié et le contenu source correspondant ne soient tous deux présents sur le serveur ConfigMgr 2012.

Software Mises à jour

Comme mentionné dans la partie 1 de ce blog, il est nécessaire d'avoir l'infrastructure ConfigMgr 2012 souhaitée installée et configurée pour exécuter correctement une migration. Je dois souligner l'importance de ce point en ce qui concerne la migration des mises à jour software . Bien qu'il soit probablement évident que les points de mise à jour Software sont nécessaires avant la migration des mises à jour Software , ce qui doit être souligné est que le catalogue de produits et les langues de mise à jour doivent correspondre parfaitement à la configuration de ConfigMgr 2007 et être synchronisés avec succès. Si une seule mise à jour est manquante dans un ensemble de mises à jour, la migration de cet ensemble échouera.

Note importante : Toutes les mises à jour personnalisées, les mises à jour SCUP publiées localement, devront être republiées car elles ne peuvent pas être migrées.

Software Les paquets de mise à jour ainsi que les modèles de mise à jour existent toujours dans ConfigMgr 2012. Les paramètres de durée des modèles de mise à jour devront être reconfigurés car ils ne migrent pas. Le processus de migration convertira les listes de mise à jour Software en groupes de mise à jour Software et un déploiement de mise à jour Software sera converti en un déploiement et un groupe de mise à jour correspondant.

Objets de déploiement du système d'exploitation

Pendant la migration des objets OSD, les pilotes, les paquets de pilotes, les images d'OS et les paquets d'installation d'OS (maintenant appelés installateurs d'OS) sont migrés exactement comme ils l'étaient dans ConfigMgr 2007. Les seules exceptions à la règle sont les images de démarrage. Bien qu'elles soient listées comme des objets pouvant être migrés, certains détails doivent être identifiés.

Le premier point, et le plus important, est que les personnalisations apportées aux images de démarrage dans ConfigMgr 2007 ne peuvent pas être migrées. Maintenant que certains d'entre vous sont en train de crier à l'intérieur, laissez-moi vous expliquer pourquoi. Le fichier WIM de l'image de démarrage n'est pas ce qui est migré. Les pilotes qui ont été injectés dans les images de démarrage de ConfigMgr 2007 sont automatiquement injectés dans des images de démarrage de nom similaire créées à partir des fichiers WIM de démarrage de l'AIK sur le serveur ConfigMgr 2012. Sur une note positive, un bon nombre de personnalisations peuvent être apportées aux images de démarrage via la nouvelle interface graphique de ConfigMgr 2012, telles que les crochets de pré-exécution et les fichiers associés.

Les séquences de tâches sont migrées de manière presque identique. Le seul changement qui sera fait automatiquement est lorsqu'un paquet d'installation client est utilisé ; il sera remplacé par une référence au paquet ConfigMgr 2012 Client pré-créé.

Objets DCM

Deux points méritent d'être brièvement décrits en termes de migration d'objets DCM. Premièrement, les packs de configuration de ConfigMgr 2007 peuvent être importés dans ConfigMgr 2012. Le pack de configuration est automatiquement converti pour être compatible. Deuxièmement, tout élément de configuration non interprété NE SERA PAS migré et ne pourra pas être importé.

Asset Intelligence & Software Metering

Il n'y a pas de changements significatifs pour Asset Intelligence ou Software Metering. Par conséquent, la migration de ces deux catégories est pratiquement transparente et apparaîtra dans ConfigMgr 2012 comme elle l'était en 2007.

Objets non migratoires

Les objets suivants ne peuvent pas être migrés...

  • Requêtes SCCM
  • Sécurité du site et droits d'instance
  • Sécurité des objets et droits d'instance
  • Rapports SCCM
  • Inventaire des clients
  • Données sur l'historique du client
  • Données d'approvisionnement AMT
  • Fichiers cache du client
  • Personnalisation de l'image de démarrage
  • Site secondaire

Revenez nous voir pour la troisième partie qui couvrira le processus de migration proprement dit, y compris la création de tâches de migration, ce à quoi ressemblent les éléments migrés dans la nouvelle console, et quelques points concernant le nettoyage de la migration. Comme toujours, j'espère que ces informations seront utiles à tous ceux qui s'intéressent à Configuration Manager 2012.