La migration de SCCM 2007 vers SCCM 2012 partie 2 : Migrons !

Nous avons dans la première partie abordé les généralités concernant la migration vers SCCM 2012 et décrit l’infrastructure SCCM 2007 qui va nous servir de sources.

Nous allons maintenant définir notre architecture SCCM cible et procéder à la migration. Nous conserverons les objets tels qu’ils sont migrés puis, dans la 3ème et dernière partie du post, nous aborderons comment tirer parti des améliorations et nouveautés de SCCM 2012.

L’architecture cible

Comme pour toute migration SCCM nous allons nous poser la question de notre architecture cible, ici nous allons nous orienter vers une architecture relativement simple à savoir :

  • Un serveur de site primaire
  • Un serveur de site secondaire (en réutilisant le serveur SCCM-SEC-R2)
  • Un point de distribution (en réutilisant le serveur LAB-SCCM-2007-SEC)

Au vu des nouveautés concernant l’architecture de SCCM et du modèle RBAC une infrastructure avec un seul serveur primaire devient une solution viable pour un très grand nombre d’entreprises, une architecture à plusieurs sites primaires sera réservée aux fanatiques de la haute disponibilité ou aux parcs de plus de 100 000 postes. Sachant que SCCM n’est pas un service critique au point de vue de l’entreprise et qu’il existe un bon nombre de solutions pour améliorer la résilience de SCCM (cluster SQL, backup, haute dispo avec la virtualisation…) les infras à plusieurs sites primaires devraient se faire plus rares.

De la même manière n’hésitez pas à revoir la répartition des vos sites secondaires, en effet dans SCCM 2012 les points de distributions permettent de faire du PXE et du Multicast, si vous n’avez pas besoin d’un point de gestion proxy ou que le routage de contenu ne vous intéresse pas, ou plus simplement si vous n’avez pas de serveur 64bits sur site. Alors les points de distribution peuvent devenir des alternatives viables aux sites secondaires.

Note importante : Si vous installez un serveur de site primaire seul, vous ne pourrez pas lui ajouter un serveur CAS parent après coup. Le nombre de sites primaires est donc figé, réfléchissez-y bien avant !

Voici donc le schéma de notre architecture cible :

La migration

Passons maintenant à l’action, j’ai au préalable installé mon site Primaire sur un serveur Windows Server 2008 RC2, je vous rappelle que j’ai dû utiliser un trigramme de site différent des trigrammes existants dans mon infra. J’ai fait preuve d’imagination et mon site primaire porte donc le trigramme PRI.

Installation des rôles

La première étape est d’installer les rôles de site dont nous allons avoir besoin. Nous allons ici installer :

  • Le point d’état de secours, un indispensable qu’on soit en SCCM 2007 ou 2012 !
  • Le point de migration de l’état
  • Le point de mise à jour logicielle (N’oubliez pas qu’il faut installer WSUS avant !)
  • Le point de Reporting Services
  • Le point de synchronisation Asset Intelligence
  • Le point Endpoint Protection
Etape

Résultat

Pour créer le connecteur, aller dans l’espace « administration » et « Configuration du site / Serveurs et rôles de système de site ».

Faites un clic droit sur le serveur primaire et cliquez sur « Ajouter des rôles de système de site » ou cliquez sur le bouton correspondant dans le ruban.

Cliquez sur suivant.

Cochez les cases correspondantes aux rôles qui nous intéressent.

Nous verrons dans des posts ultérieurs le fonctionnement du catalogue d’applications.

Paramétrez le point de migration de l’état. Je vous rappelle qu’il s’agit du ou des dossiers ou USMT va stocker les données utilisateurs lors des migrations d’OS.

SCCM nous propose d’associer le point de migration à un groupe de limite histoire d’empêcher un client à Hong Kong de stocker les données USMT à Paris.

Nous allons créer un groupe de limites.

Donnez un nom à votre groupe de limites, ici ce groupe sera aussi utilisé pour l’assignation des clients au site.

Il n’y a pour le moment aucune limite à associer vu que celles-ci seront migrées.

Voilà notre groupe de limites paramétré, décochez la case qui autorise le stockage sur un emplacement de secours, cela vous évitera des transferts de données incongrus.

Configurez les paramètres de proxy pour la synchronisation avec Microsoft Update.

Précisez la configuration de votre WSUS.

Choisissez votre mode de synchronisation des mises à jour.

Choisissez votre planning de synchronisation.

Comme nous allons utiliser Endpoint Protection il nous est nécessaire de définir un intervalle court pour être toujours à jour en termes de définitions.

Pour la même raison nous allons cocher la case qui permet de déclencher une alerte en cas d’échec de synchronisation.

Paramétrez la gestion du remplacement des mises à jour.

Choisissez les types de mises à jour que vous désirez, n’oubliez pas les définitions si vous utilisez Endpoint Protection.

Vous devez choisir au moins les mêmes classifications que celles choisies dans SCCM 2007.

Choisissez les produits pour lesquels la synchronisation sera faite, n’oubliez pas que cette liste peut être mise à jour au gré des synchronisations.

Vous devez choisir au moins les mêmes produits que ceux choisis dans SCCM 2007.

Choisissez les langues de mises à jour à prendre en charge.

Voici qui clôture la configuration du rôle de mise à jour.

Configurez votre point d’état de secours.

Cliquez sur suivant.

Configurez les paramètres de proxy pour le point Asset Intelligence.

Choisissez l’intervalle entre deux synchronisations Asset Intelligence.

Pour configurer le point Reporting Services, cliquez sur vérifier.

Puis saisissez un compte de connexion à la base, évidemment le domain admin n’est un choix valable que dans une maquette J.

Acceptez la licence de Endpoint Protection.

Choisissez vos paramètres d’adhésion à MAPS.

Validez les paramètres.

Avant de poursuivre déclenchez une synchronisation WSUS et Assez intelligence.

Le connecteur de migration

La seconde étape est donc de mettre en place un connecteur vers ma hiérarchie source. Le connecteur va permettre à SCCM 2012 de lister tous les objets migrables contenus dans mon SCCM 2007. Vous devez créer un connecteur par serveur primaire SCCM 2007, qu’ils soient ou non de la même hiérarchie n’importe pas.

Si vous comptez utiliser différentes étendues avec le modèle RBAC je vous recommande de les créer avant de procéder à la migration. Pour l’instant dans cet exemple nous n’utiliserons que l’étendue par défaut.

Etape

Résultat

Pour créer le connecteur, aller dans l’espace « administration » et dans « migration / hiérarchie source »

Cliquez sur « Spécifier une hiérarchie source »

Spécifiez le nom du serveur primaire SCCM 2007, puis entrez un compte qui dispose des droits de lectures sur tous les objets de votre site SCCM 2007.

Et non, l’admin du domain n’est toujours pas un choix sécurisé en prod J

Votre serveur SCCM 2012 commence la collecte des données

Désormais SCCM 2012 va scanner votre site SCCM 2007 toutes les 4 heures à la recherche de nouveaux paramètres à migrer.

Pour gérer la migration des sites secondaires activez la fonction de partage des points de distribution.

Cette fonction permet dans un premier temps de partager les points de distribution. Ainsi les clients SCCM 2007 et 2012 pourront indépendamment utiliser les points de distribution partagés.

Dans un second temps l’assistant nous montre les points de distribution qui pourront être mis à jour en version 2012 à la fin de la migration.

Les jobs de migration

Nous allons maintenant créer les tâches de migration qui vont nous permettre de copier les objets depuis SCCM 2007.

Etape

Résultat

Pour créer une tache, allez dans la partie « Taches de migration » dans le nœud « migration ».

Cliquez sur créer une tache de migration

Donnez un nom à votre tâche de migration et choisissez son type.

Il existe 3 types de tâches :

  • Migration du regroupement vous permet de choisir des regroupements et de ne migrer que les objets qui y sont liés.
  • Migration de l’objet vous permet de choisir des objets à migrer
  • Objets modifiés après la migration vous permet de choisir des objets qui ont été changés dans SCCM 2007 depuis votre dernière tache de migration

Nous allons ici choisir une tache de migration de l’objet.

Choisissez les objets à migrer.

Choisissez le site SCCM 2012 qui sera propriétaire des objets migrés.

Affectez les objets choisis à une étendue de sécurité. D’où l’importance de les créer avant si vous souhaitez implémenter différentes étendues.

Lisez les considérations de migration d’objets.

Choisissez les paramètres de migration.

Validez le résumé.

L’assistant est terminé.

yy

Vous pouvez désormais surveiller l’avancement de votre tâche de migration.

Vous pouvez aussi consulter le fichier de log migmctrl.log.

Attention ! N’oubliez pas que lorsque vous migrez des objets avec du contenu (packages, OS) la source du contenu n’est pas déplacée. Si les sources de vos packages se trouvent sur le serveur SCCM 2007 pensez bien à les déplacer pour que SCCM 2012 puisse toujours y avoir accès lorsque vous aurez coupé votre serveur 2007. Voici un excellent post qui vous expliquera comment déplacer les sources de vos contenus grâce à un outil dédié.

Configuration initiale du serveur

Une fois les objets migrés, préparez le serveur à accueillir des clients. Configurez vos méthodes de découvertes, vos paramètres de client, vos paramètres d’installation du client…

N’oubliez pas que vous pouvez désormais créer plusieurs paramétrages de client et les assigner à différents regroupements.

La migration des clients

Il est désormais temps de passer à la migration des clients. La meilleure approche est de procéder par site :

  • Désactivez les frontières du site SCCM 2007
  • Activez la frontière correspondante dans SCCM 2012
  • Installez le nouveau client SCCM 2012

Etape

Résultat

Commencez par vous rendre dans la console SCCM 2007 et supprimez la ou les frontières des sites que vous allez migrer.

Allez maintenant dans la console SCCM 2012, mettez les frontières que vous venez de supprimer dans des groupes de frontières.

Les groupes de frontières que vous allez choisir doivent avoir l’option d’assignation à un site activée.

Désormais dans SCCM 2012 les clients s’assignent à un site non pas grâce à des frontières mais grâce à des groupes de frontières.

Une fois les frontières transférées, poussez le client sur les postes concernés en utilisant votre méthode préférée (push, wsus, script de logon…).

Le setup du client SCCM 2012 se charge de désinstaller le client 2007.

Les serveurs secondaires

Nous allons maintenant voir comment gérer les sites secondaires en place. La première considération à avoir est qu’il est impossible de migrer les sites secondaires, comme nous allons le voir, SCCM 2012 nous permet de les transformer en point de distribution.

Vous avez donc deux choix :

  • Vous souhaitez conserver un site secondaire à tout prix
  • Vous souhaitez passer à un point de distribution

Pour vous aider à choisir, sachez que les points de distribution sous SCCM 2012 ont plus de fonctionnalités qu’auparavant, un point de distribution peut notamment gérer le PXE. Sachez aussi qu’un site secondaire SCCM 2012 vous impose d’avoir un serveur 2008 R2.

Une fois votre choix fait, si vous souhaitez conserver un site secondaire vous devrez le désinstaller manuellement via la console SCCM 2007 et le réinstaller manuellement via la console SCCM 2012. Je ne vous décris pas la procédure, il s’agit d’opérations de maintenance de hiérarchie tout à fait communes.

Si vous souhaitez transformer votre site secondaire SCCM 2007 en un point de distribution SCCM 2012 voici la procédure :

Etape

Résultat

Dans le nœud migration / hiérarchie source, cliquez sur l’onglet « points de distribution partagés ».

Choisissez le serveur à transformer et cliquez sur « Mettre à niveau ».

Choisissez le site SCCM 2012 auquel rattacher ce point de distribution.

Si votre serveur SCCM est administrateur du site secondaire laissez l’option de compte par défaut sinon spécifiez un compte qui soit administrateur du serveur.

Configurez les paramètres généraux de votre point de distribution.

Choisissez les paramètres de stockage de votre point de distribution.

Configurez les paramètres de PXE (WDS doit être installé sur le serveur).

Choisissez d’associer des groupes de limites à votre point de distribution. Si vous avez partagé le point de distribution, SCCM à dû le faire pour vous.

Validez le contenu qui va être converti.

Il ne s’agit pas d’une conversion des applications, mais d’une conversion du mode de stockage. En effet, les points de distribution SCCM 2012 stockent les données d’une manière différente que sous 2007.

Validez le résumé.

Vous avez terminé l’assistant.

Sous le nœud migration de la console rendez-vous dans le nœud « Mises à niveau de points de distribution ».

Vous retrouverez ici toutes les taches de mises à niveau de point de distribution et leur état.

Comme vous pouvez le voir SCCM 2012 se charge de désinstaller le site secondaire SCCM 2007.

Une fois le site secondaire SCCM 2007 désinstallé, SCCM 2012 transforme votre point de distribution pour qu’il corresponde au nouveau format SCCM 2012 : la bibliothèque de contenu.

Conclusion

Voilà notre infrastructure SCCM 2007 est migrée. Nous pouvons désormais mettre notre serveur SCCM 2007 à la retraite et travailler sur SCCM 2012.

Pour le moment le résultat est un peu brut de décoffrage, nous verrons dans le prochain post l’état de nos différents objets et ce que nous pouvons faire pour profiter au mieux des nouveautés de SCCM 2012.

Publicités

Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s