Planifier la migration d’objets Configuration Manager vers Configuration Manager Current Branch

S’applique à : Gestionnaire de Configuration (branche actuelle)

Avec Configuration Manager branche actuelle, vous pouvez migrer un grand nombre des différents objets associés à différentes fonctionnalités trouvées sur un site source.

Planifier la migration des mises à jour logicielles

Vous pouvez migrer des objets de mise à jour logicielle, tels que des packages de mise à jour logicielle et des déploiements de mises à jour logicielles.

Pour réussir la migration des objets de mise à jour logicielle, vous devez d’abord configurer votre hiérarchie de destination avec des configurations qui correspondent à votre environnement de hiérarchie source. Cela nécessite les actions suivantes :

  • Déployer un point de mise à jour logicielle actif dans la hiérarchie de destination

  • Configurer le catalogue de produits et de langues pour qu’il corresponde à la configuration de votre hiérarchie source

  • Synchroniser le point de mise à jour logicielle dans la hiérarchie de destination avec Windows Server Update Services (WSUS)

Lorsque vous migrez des mises à jour logicielles, tenez compte des points suivants :

  • La migration des objets de mise à jour logicielle peut échouer lorsque vous n’avez pas synchronisé les informations dans votre hiérarchie de destination pour correspondre à la configuration de votre hiérarchie source.

    Avertissement

    Configuration Manager ne prend pas en charge l’utilisation de l’outil WSUSutil pour synchroniser les données entre une hiérarchie source et une hiérarchie de destination.

  • Vous ne pouvez pas migrer les mises à jour personnalisées publiées à l’aide de System Center Mises à jour Publisher. Au lieu de cela, les mises à jour personnalisées doivent être republiées dans la hiérarchie de destination.

Lorsque vous migrez à partir d’une hiérarchie source Configuration Manager 2007, le processus de migration modifie certains objets de mise à jour logicielle au format utilisé par la hiérarchie de destination. Utilisez le tableau suivant pour vous aider à planifier la migration des objets de mise à jour logicielle à partir de Configuration Manager 2007.

objet Configuration Manager 2007 Nom de l’objet après la migration
Listes de mises à jour logicielles Les listes de mises à jour logicielles sont converties en groupes de mises à jour logicielles.
Déploiements de mises à jour logicielles Les déploiements de mises à jour logicielles sont convertis en déploiements et groupes de mises à jour.

Après avoir migré un déploiement de mises à jour logicielles à partir de Configuration Manager 2007, vous devez l’activer dans la hiérarchie de destination avant de pouvoir le déployer.
Packages de mise à jour logicielle Les packages de mise à jour logicielle restent des packages de mise à jour logicielle.
Modèles de mise à jour logicielle Les modèles de mise à jour logicielle restent des modèles de mise à jour logicielle.

La valeur Duration dans Configuration Manager modèles de déploiement 2007 ne migre pas.

Lorsque vous migrez des objets à partir d’un Configuration Manager System Center 2012 ou Configuration Manager hiérarchie source Current Branch, les objets des mises à jour logicielles ne sont pas modifiés.

Planifier la migration du contenu

Vous pouvez migrer du contenu d’une hiérarchie source prise en charge vers votre hiérarchie de destination. Pour une hiérarchie source Configuration Manager 2007, ce contenu inclut des packages et programmes de distribution de logiciels et des applications virtuelles, comme Microsoft Application Virtualization (App-V). Pour System Center 2012 Configuration Manager et Configuration Manager hiérarchies sources Current Branch, ce contenu inclut des applications et des applications virtuelles App-V. Lorsque vous migrez du contenu entre des hiérarchies, les fichiers sources compressés migrent vers la hiérarchie de destination.

Packages et programmes

Lorsque vous migrez des packages et des programmes, ils ne sont pas modifiés par la migration. Toutefois, avant de les migrer, vous devez configurer chaque package pour utiliser un chemin UNC (Universal Naming Convention) pour son emplacement du fichier source. Dans le cadre de la configuration de migration des packages et des programmes, vous devez affecter un site dans la hiérarchie de destination pour gérer ce contenu. Le contenu n’est pas migré à partir du site attribué, mais après la migration, le site affecté accède à l’emplacement du fichier source d’origine à l’aide du mappage UNC.

Une fois que vous avez migré un package et un programme vers la hiérarchie de destination et que la migration à partir de la hiérarchie source reste active, vous pouvez mettre le contenu à la disposition des clients de cette hiérarchie à l’aide d’un point de distribution partagé. Pour utiliser un point de distribution partagé, le contenu doit rester accessible sur le point de distribution sur le site source. Pour plus d’informations sur les points de distribution partagés, consultez Partager des points de distribution entre les hiérarchies source et de destination dans Planifier une stratégie de migration de déploiement de contenu.

Pour le contenu migré, si la version du contenu change dans la hiérarchie source ou la hiérarchie de destination, les clients ne peuvent plus accéder au contenu à partir du point de distribution partagé dans la hiérarchie de destination. Dans ce scénario, vous devez migrer à nouveau le contenu pour restaurer une version cohérente du package entre la hiérarchie source et la hiérarchie de destination. Ces informations sont synchronisées pendant le cycle de collecte des données.

Conseil

Pour chaque package que vous migrez, mettez à jour le package dans la hiérarchie de destination. Cette action peut éviter les problèmes liés au déploiement du package sur des points de distribution dans la hiérarchie de destination. Toutefois, lorsque vous mettez à jour un package sur le point de distribution dans la hiérarchie de destination, les clients de cette hiérarchie ne peuvent plus obtenir ce package à partir d’un point de distribution partagé. Pour mettre à jour un package dans la hiérarchie de destination, dans la console Configuration Manager, accédez à la bibliothèque de logiciels, cliquez avec le bouton droit sur le package, puis sélectionnez Mettre à jour les points de distribution. Effectuez cette action pour chaque package que vous migrez.

Conseil

Utilisez Package Conversion Manager pour convertir des packages et des programmes en applications Configuration Manager. Pour plus d’informations, consultez Package Conversion Manager.

Applications virtuelles

Lorsque vous migrez des packages App-V à partir d’un site Configuration Manager 2007 pris en charge, le processus de migration les convertit en applications dans la hiérarchie de destination. En outre, en fonction des publications existantes pour le package App-V, les types de déploiement suivants sont créés dans la hiérarchie de destination :

  • S’il n’y a pas de publication, un type de déploiement est créé qui utilise les paramètres de type de déploiement par défaut.

  • S’il existe une publication, un type de déploiement est créé et utilise les mêmes paramètres que la publication Configuration Manager 2007.

  • S’il existe plusieurs publications, un type de déploiement est créé pour chaque publication Configuration Manager 2007 à l’aide des paramètres de cette publication.

Importante

Si vous migrez un package App-V Configuration Manager 2007 précédemment migré, la migration échoue, car les packages d’applications virtuelles ne prennent pas en charge le comportement de migration de remplacement. Dans ce scénario, vous devez supprimer le package d’application virtuelle migré de la hiérarchie de destination, puis créer une tâche de migration pour migrer l’application virtuelle.

Remarque

Après avoir migré un package App-V, vous pouvez utiliser l’Assistant Mise à jour du contenu pour modifier le chemin d’accès source pour les types de déploiement App-V. Pour plus d’informations sur la mise à jour du contenu d’un type de déploiement, consultez Guide pratique pour gérer les types de déploiement dans Tâches de gestion pour les applications Configuration Manager.

Lorsque vous migrez à partir d’un Configuration Manager System Center 2012 ou Configuration Manager hiérarchie source Current Branch, vous pouvez migrer des objets pour l’environnement virtuel App-V en plus des types et applications de déploiement App-V. Pour plus d’informations sur les environnements App-V, consultez Déploiement d’applications virtuelles App-V.

Publications

Vous pouvez migrer des publicités d’un site source Configuration Manager 2007 pris en charge vers la hiérarchie de destination à l’aide de la migration basée sur la collection. Si vous mettez à niveau un client, il conserve l’historique des publicités précédemment exécutées pour empêcher le client de réexécuter les publicités migrées.

Remarque

Vous ne pouvez pas migrer de publicités pour des packages virtuels. Il s’agit d’une exception à la migration des publicités.

Applications

Vous pouvez migrer des applications d’une Configuration Manager System Center 2012 prise en charge ou Configuration Manager hiérarchie source Current Branch vers une hiérarchie de destination. Si vous réaffectez un client de la hiérarchie source à la hiérarchie de destination, le client conserve l’historique des applications précédemment installées pour empêcher le client de réexécuter une application migrée.

Planifier la migration des regroupements

Vous pouvez migrer les critères pour les regroupements à partir d’une Configuration Manager System Center 2012 prise en charge ou Configuration Manager hiérarchie source current Branch. Pour cela, vous utilisez un travail de migration basé sur un objet. Lorsque vous migrez une collection, vous migrez les règles de la collection et non les informations sur les membres de la collection ou les informations ou objets liés aux membres de la collection.

La migration de l’objet de collection n’est pas prise en charge lorsque vous migrez à partir d’une hiérarchie source Configuration Manager 2007.

Planifier la migration des déploiements de système d’exploitation

Vous pouvez migrer les objets de déploiement de système d’exploitation suivants à partir d’une hiérarchie source prise en charge :

  • Images et packages de système d’exploitation. Le chemin source des images de démarrage est mis à jour vers l’emplacement d’image par défaut pour le Kit d’installation d’administration Windows (Windows AIK) sur le site de destination. Voici les exigences et limitations de la migration des images et des packages de système d’exploitation :

    • Pour réussir la migration des fichiers image, le compte d’ordinateur du serveur du fournisseur SMS pour le site de niveau supérieur de la hiérarchie de destination doit disposer de l’autorisation Lecture et Écriture sur les fichiers sources d’image de l’emplacement Windows AIK du site source du site source.

    • Lorsque vous migrez un package d’installation de système d’exploitation, assurez-vous que la configuration du package sur le site source pointe vers le dossier contenant le fichier WIM et non vers le fichier WIM lui-même. Si le package d’installation pointe vers le fichier WIM, la migration du package d’installation échoue.

    • Lorsque vous migrez un package d’image de démarrage à partir d’un site source Configuration Manager 2007, l’ID de package du package n’est pas conservé dans le site de destination. Le résultat est que les clients de la hiérarchie de destination ne peuvent pas utiliser les packages d’images de démarrage disponibles sur des points de distribution partagés.

  • Séquences de tâches. Lorsque vous migrez une séquence de tâches qui a une référence à un package d’installation de client, cette référence est remplacée par une référence au package d’installation du client de la hiérarchie de destination.

    Remarque

    Lorsque vous migrez une séquence de tâches, Configuration Manager peuvent migrer des objets qui ne sont pas requis dans la hiérarchie de destination. Ces objets incluent des images de démarrage et Configuration Manager packages d’installation du client 2007.

  • Pilotes et packages de pilotes. Lorsque vous migrez des packages de pilotes, le compte d’ordinateur du fournisseur SMS dans la hiérarchie de destination doit disposer d’un contrôle total sur la source du package.

Planifier la migration de la gestion de la configuration souhaitée

Vous pouvez migrer des éléments de configuration et des bases de référence de configuration.

Remarque

Les éléments de configuration non interprétés des hiérarchies sources Configuration Manager 2007 ne sont pas pris en charge pour la migration. Vous ne pouvez pas migrer ou importer ces éléments de configuration dans la hiérarchie de destination.

Vous pouvez importer Configuration Manager packs de configuration 2007. Le processus d’importation convertit automatiquement les packs de configuration pour qu’ils soient compatibles avec Configuration Manager Current Branch.

Planifier la migration des limites

Vous pouvez migrer des limites entre les hiérarchies. Lorsque vous migrez des limites à partir de Configuration Manager 2007, chaque limite du site source migre en même temps et est ajoutée à un nouveau groupe de limites créé dans la hiérarchie de destination. Lorsque vous migrez des limites à partir d’un Configuration Manager System Center 2012 ou d’une hiérarchie Configuration Manager branche actuelle, chaque limite que vous sélectionnez est ajoutée à un nouveau groupe de limites dans la hiérarchie de destination.

Chaque groupe de limites créé automatiquement est activé pour l’emplacement du contenu, mais pas pour l’attribution de site. Cela empêche le chevauchement des limites pour l’attribution de site entre les hiérarchies source et de destination. Lorsque vous migrez à partir d’un site source Configuration Manager 2007, cela permet d’empêcher les nouveaux clients Configuration Manager 2007 qui s’installent d’attribuer de manière incorrecte à la hiérarchie de destination. Par défaut, Configuration Manager clients Current Branch n’attribuent pas automatiquement aux sites Configuration Manager 2007.

Pendant la migration, si vous partagez un point de distribution avec la hiérarchie de destination, toutes les limites associées à cette distribution migrent automatiquement vers la hiérarchie de destination. Dans la hiérarchie de destination, la migration crée un groupe de limites en lecture seule pour chaque point de distribution partagé. Si vous modifiez les limites du point de distribution dans la hiérarchie source, le groupe de limites dans la hiérarchie de destination se met à jour avec ces modifications au cours du cycle de collecte de données suivant.

Planifier la migration des rapports

Configuration Manager ne prend pas en charge la migration des rapports. Utilisez plutôt SQL Server Reporting Services Report Builder pour exporter des rapports à partir de la hiérarchie source, puis importez-les dans la hiérarchie de destination.

Remarque

Étant donné qu’il y a des modifications de schéma pour les rapports entre Configuration Manager 2007 et Configuration Manager Current Branch, testez chaque rapport que vous importez à partir d’une hiérarchie Configuration Manager 2007 pour vous assurer qu’il fonctionne comme prévu.

Pour plus d’informations sur la création de rapports, consultez Présentation de la création de rapports.

Planifier la migration des dossiers d’organisation et de recherche

Vous pouvez migrer des dossiers d’organisation et des dossiers de recherche d’une hiérarchie source prise en charge vers une hiérarchie de destination. En outre, à partir d’une hiérarchie source De System Center 2012 Configuration Manager ou Configuration Manager current Branch, vous pouvez migrer les critères d’une recherche enregistrée vers une hiérarchie de destination.

Par défaut, le processus de migration gère vos structures de dossiers de recherche et d’administration pour les objets et les regroupements lors de la migration. Toutefois, dans l’Assistant Création d’un travail de migration, dans la page Paramètres , vous pouvez configurer un travail de migration pour ne pas migrer la structure organisationnelle des objets en décochant la case correspondant à cette option. Les structures organisationnelles des collections sont toujours conservées.

Une exception à ce problème est un dossier de recherche qui contient des applications virtuelles. Lorsqu’un package App-V est migré, le package App-V est transformé en application dans Configuration Manager. Après la migration du dossier de recherche, seuls les packages restants sont trouvés et le dossier de recherche ne peut pas localiser un package App-V en raison de cette conversion en application lors de la migration du package App-V.

Lorsque vous migrez une recherche enregistrée à partir d’une Configuration Manager System Center 2012 ou Configuration Manager hiérarchie source Current Branch, vous migrez les critères de la recherche, et non les informations sur les résultats de la recherche. La migration d’une recherche enregistrée n’est pas applicable à partir d’un site source Configuration Manager 2007.

Planifier la migration des personnalisations Asset Intelligence

Vous pouvez migrer des personnalisations pour Asset Intelligence d’une hiérarchie source prise en charge vers une hiérarchie de destination. Aucune modification significative n’a été apportée à la structure des personnalisations Asset Intelligence entre Configuration Manager 2007 et Configuration Manager Current Branch.

Remarque

Configuration Manager current branch ne prend pas en charge la migration d’objets Asset Intelligence à partir d’un site Configuration Manager 2007 qui utilise Asset Intelligence Service 2.0 (AIS 2.0).

Planifier la migration des personnalisations des règles de contrôle de logiciel

Entre Configuration Manager 2007 et Configuration Manager Current Branch, aucune modification significative n’a été apportée au contrôle des logiciels. Vous pouvez migrer vos règles de contrôle de logiciel d’une hiérarchie source prise en charge vers une hiérarchie de destination.

Par défaut, les règles de contrôle de logiciel que vous migrez vers une hiérarchie de destination ne sont pas associées à un site spécifique dans la hiérarchie de destination et s’appliquent à tous les clients de la hiérarchie. Pour appliquer une règle de contrôle de logiciel aux clients d’un site spécifique, vous devez modifier la règle de contrôle après sa migration.