System Center 2012 R2 Configuration Manager est disponible depuis le 18 octobre. Avec le SP1, j’avais fait une migration chez un client qui m’avait posé de nombreux problèmes. J’ai souhaité sans tarder tester le processus de migration pour valider la procédure et les éventuels problèmes rencontrés. Aujourd’hui, je vous propose de partager cette expérience sur mon lab créé pour l’écriture du livre System Center 2012 Configuration Manager (SCCM) : Concepts, Utilisation, et Administration. J’ai choisi celui avec un site primaire autonome pour commencer. Voici les rôles :
- Un serveur Active Directory avec niveau fonctionnel de forêt Active Directory 2012. Ce dernier héberge aussi le rôle de système de site System Health Validator Point.
- Un serveur de site primaire autonome hébergeant :
- La base de données de site
- Asset Intelligence Proxy Point
- Application Catalog Website Point
- Application Catalog Web Service Point
- Distribution Point (PXE activé)
- Endpoint Protection Point
- Enrollment Point
- Enrollment Proxy Point
- Fallback Status Point
- Management Point (avec Device Management Point)
- Out of Band Service Point
- Reporting Service Point
- Software Update Point
- State Migration Point
- SMS Provider
- Windows Intune Connector
- Deux Cloud Distribution Points
Comme vous pouvez le voir, on retrouve toutes les fonctionnalités proposées par le produit excepté la partie Multicast.
Quelle est le processus à adopter ? Vous devez commencer votre migration par les éléments au plus haut dans la hiérarchie. Commencez par migrer votre CAS (ou votre site primaire autonome) puis les sites primaires, les sites secondaires et les clients :
1. Site d'administration central (CAS) si vous avez choisi d'en installer un.
2. Sites primaires
3. Sites secondaires
4. Clients
Lorsque la hiérarchie entre en mode de compatibilité, il existe des limitations qui s’appliquent à ce scénario SP1 vers R2 :
Les comptes d’accès réseau :
- Quand vous utilisez une console connectée sur un CAS migré vers la R2, la console n’affiche pas le détail des comptes configurés sur les sites primaires encore sur ConfigMgr 2012 SP1.
- Lorsque ce sont des clients SCCM 2012 Sans Service Pack ou avec Service Pack 1, ils utilisent le premier compte d’accès réseau de la liste. Ce comportement permet d’assurer la retro compatibilité pour les clients qui n’ont pas encore été mis à jour. Veillez à placer le compte de référence comme premier de la liste.
- Lorsque vous gérez des ressources en mode Workgroup, ces dernières doivent avoir le client ConfigMgr 2012 R2 pour bénéficier de la prise en charge des multiples comptes d’accès réseau.
- Lorsque vous déployez des systèmes d’exploitation, vous devez utiliser les images de démarrage Windows PE 4.0 générées par ConfigMgr 2012 R2 pour permettre la prise en charge des multiples comptes d’accès réseau.
Lorsque vous commencez la mise à niveau de votre infrastructure, Microsoft recommande de retarder les déploiements de système d'exploitation jusqu'à que toute la hiérarchie de sites soit à jour. Dans le cas contraire, voici quelques considérations à prendre en compte :
- La mise à niveau du site le plus haut dans la hiérarchie engendre la mise à jour du package d'installation du client sur tous les points de distribution de la hiérarchie.
- Un client ConfigMgr avec un niveau de Service Pack ne peut dialoguer avec un site ayant un niveau de version inférieur.
- Lorsque vous mettez à jour le site le plus haut dans la hiérarchie, les images de démarrage par défaut sont mises à jour.
- Pour écarter l'échec d'une séquence de tâches, vous devez valider que l'image de démarrage utilisée correspond à la version du client ConfigMgr installée durant le déploiement de système d'exploitation.
- Evitez l'utilisation des médias dynamiques tant que la hiérarchie est dans un mode d'intéropérabilité.
Plus d’informations sur : http://technet.microsoft.com/en-US/library/jj822985.aspx
La première des choses à faire est la lecture de la note de publication concernant la R2 que vous allez appliquer. Commençons par les prérequis et considérations :
- Tous vos sites doivent avoir été migrés vers ConfigMgr 2012 SP1. Si ce n’est pas le cas votre hiérarchie est toujours en mode de compatibilité.
- Habituellement les versions majeures incluent tous les correctifs apportées par les Cumulative Update. Néanmoins, un correctif concernant le multicast n’est pas inclus dans la R2. Microsoft recommande dans ce cas l’application du Cumulative Update 3 sur l’infrastructure.
- Validez que votre environnement supporte la configuration matérielle et logicielle requise par la R2. Ceci s'applique à l'ensemble des composants constituant l'infrastructure (Serveurs de site et Systèmes de site) mais aussi les clients. Par exemple le Service Pack 1 de ConfigMgr 2012 requiert l'installation de Windows ADK sur les serveurs de site et les SMS Provider. Voici la liste des configurations supportées : http://technet.microsoft.com/library/gg682077.aspx
- Microsoft recommande l'application de toutes les mises à jour critiques applicables aux serveurs de site et systèmes de site.
- Microsoft recommande la mise à jour des bases de données des sites secondaires vers SQL Server 2012. Ceci ne constitue pas une étape obligatoire.
- Validez l'état des sites, des systèmes de site et de la hiérarchie. Ceci a pour but d'éviter d'impacter la mise à jour si un problème est persistant sur l'infrastructure. Vous pouvez pour cela, utiliser la vue Monitoring - System Status.
- Vous devez désactiver les réplicas de base de données pour les Management Points et les réactiver après installation du Service Pack.
- Lorsque vous utilisez le rôle Software Update Point dans une configuration avec un cluster NLB, vous devez désinstaller cette fonctionnalité pour que le produit puisse mettre à jour le site concerné.
- Il est primordial de sauvegarder la base de données des sites prenant part à la hiérarchie (CAS + Sites primaires). Ceci permettra une restauration si la mise à jour aboutie à un échec.
- Vous devez désactiver la tâche de maintenance Delete Aged Client Operations sur l'ensemble des sites primaires. Lorsque la migration est complète, vous pouvez la réactiver sur l'ensemble des sites.
- Désactivez les tâches de maintenance suivantes Backup Site Server et Delete Aged Discovery Data sur tous les sites
- Lancer l'assistant de vérification des prérequis pour valider que votre site est prêt à être migré.
- Si votre site ne dispose pas d'un accès à Internet, téléchargez les fichiers de prérequis à partir du média d'installation sur une autre machine.
- Lorsque vous opérez la mise à jour du site, l'assistant vous propose de faire une revue des packs de langue déjà installés. Le Service Pack propose un niveau équivalent et apporte même le support de langues supplémentaires.
- Planifier les nouveaux prérequis nécessaires pour les systèmes de site déjà installés. Lorsque vous procédez à la mise à jour d'un site, le gestionnaire de composants de site procède à la réinstallation des rôles de systèmes de site pour les mettre à jour. L'application du Service Pack peut changer le niveau de prérequis nécessaire.
- Testez la mise à jour sur une copie de la base de données sur un serveur de site de test. Cette opération visera à valider l'intégrité de la base de données vis-à-vis d'une opération de mise à jour. Vous pouvez pour cela, copier la base de données sur un serveur SQL de test qui dispose du même niveau de version que le serveur de production. Utilisez ensuite le média d'installation (Setup.exe dans SMSSETUP\BIN\X64) du Service Pack et le paramètre de ligne de commande /TESTDBUPGRADE <Nom d'instance>\<Nom de la base de données> pour valider le processus. Vous devez valider cette opération pour toutes les bases de données de tous les sites de la hiérarchie (CAS + Primaires).
- L'assistant de vérification des prérequis valide qu'aucun système de site attaché au serveur de site n'a de redémarrage en attente. Il est ainsi recommandé de redémarrer le serveur de site et les systèmes de site associés. Notez que cette opération peut prendre un temps certain compte tenu du nombre de systèmes de site installés (notamment pour les Distribution Points) et de la latence engendrée par leur localisation.
- Validez les exceptions de l'antivirus installé sur le serveur de site. Certains antivirus provoquent des effets indésirables sur la mise à jour du site. Ceci est particulièrement valable avec McAfee et l'étape de régénération des nouvelles images de démarrage avec Windows ADK. Vous pouvez aller jusqu'à désactiver temporairement l'antivirus.
- L'utilisateur qui procède à la mise à jour doit être administrateur local du serveur hébergeant le site secondaire et disposer des droits System Administrator (SA) sur la base de données de site. Il doit aussi disposer des rôles de sécurité Infrastructure Administrator ou Full Administrator sur le site primaire parent.
- Vous devez désinstaller la version de Windows ADK pour Windows 8 et installer la nouvelle version pour Windows 8.1.
- Les clients ConfigMgr 2012 R2 ne peuvent bénéficier des nouvelles fonctionnalités lorsqu’il dialogue avec un site ConfigMgr 2012 d'une version précédente.
Il existe plusieurs actions réalisées automatiquement par la mise à niveau d'une infrastructure System Center 2012 R2 Configuration Manager :
- Le site opère une réinitialisation de site qui a pour effet de réappliquer les fichiers par défaut et les permissions de registre sur le serveur de site. De plus, cela enclenche la réinstallation de tous les rôles de systèmes de site.
- La mise à jour du package d'installation est lancée pour tous les points de distribution de la hiérarchie. Ceci est à prendre en compte pour éviter les effets de bord liés au niveau de version entre le client et les serveurs de site.
- Si l'installation est exécutée sur un site primaire, elle procède à la mise à niveau du package de mise à jour du client pour ce site.
Passons dans le vif du sujet ! Vous avez relus l’ensemble des prérequis. Désactivez les trois tâches de maintenance Delete Aged Client Operations, Backup Site Server et Delete Aged Discovery Data :
Désinstallez Windows Assessment and Deployment Kit du site primaire :
Téléchargez et installez la nouvelle version pour Windows 8.1 en cochant les composants Deployment Tools, Windows Presinstallation Environment (Windows PE) et User State Migration Tool (USMT) :
Chargez les sources de ConfigMgr 2012 R2 et lancez le SplashScreen. Cliquez sur Install :
Note : Au préalable, vous pouvez lancer le vérificateur de prérequis.
Passez l’écran de bienvenue.
Sélectionnez Upgrade this Configuration Manager site et cliquez sur Next :
Entrez ensuite la clé produit et passez à l’étape pour accepter le contrat de licence du produit.
Acceptez aussi les termes de licence de SQL Server 2012 et Silverlight 5.
Téléchargez ou cibler le dossier contenant les fichiers de prérequis :
Sur les deux écrans qui suivent, sélectionnez les langues d’interface serveur et client à télécharger et installer.
Sur la page Settings Summary, cliquez sur Next pour lancer l’assistant de vérification des prérequis.
Validez l’ensemble des prérequis. Ceux en erreur vous empêcheront de démarrer la mise à jour.
Une fois la mise à jour terminée, cliquez sur View Log pour relire les journaux d’installation pour traquer les éventuelles erreurs et faites Close.
Voici mon résultat pour la mise à jour de ce lab :
- J’ai essuyé un premier échec. Avant même de démarrer l’installation, le processus d’installation SetupWpf.exe n’a pas pu être créé.
- Une fois le serveur redémarré, j’ai lancé une deuxième tentative qui s’est arrêtée sur une erreur : Setup failed to configure SQL Server Broker. Possible Cause : Each Configuration Manager site must have its own SQL Server Instance. Verify that the selected SQL Server instance it not in use by another Configuration Manager Site. En vérifiant le fichier de journalisation, j’observe les erreurs suivantes :
INFO: If top most site we will execute spDRSInvalidateAllReplicationConfigurationGroups
*** IF (dbo.fnIsCasOrStandalonePrimary() = 1) EXEC dbo.spDRSInvalidateAllReplicationConfigurationGroups
*** [42000][50000][Microsoft][SQL Server Native Client 11.0][SQL Server]ERROR 50000, Level 16, State 1, Procedure spRethrowError, Line 42, Message: ERROR 50000, Level 16, State 1, Procedure spGetSSBDialogHandle, Line 58, Message: Route is not defined for target site with service name ConfigMgrRCM_SiteSE4. : spRethrowError
ERROR: SQL Server error: [42000][50000][Microsoft][SQL Server Native Client 11.0][SQL Server]ERROR 50000, Level 16, State 1, Procedure spRethrowError, Line 42, Message: ERROR 50000, Level 16, State 1, Procedure spGetSSBDialogHandle, Line 58, Message: Route is not defined for target site with service name ConfigMgrRCM_SiteSE4. : spRethrowError
Failed to execute sql command IF (dbo.fnIsCasOrStandalonePrimary() = 1) EXEC dbo.spDRSInvalidateAllReplicationConfigurationGroups~
ERROR: Failed to execute spDRSInvalidateAllReplicationConfigurationGroups
ERROR: Failed to update global table schema record. $$<Configuration Manager Setup><10-21-2013 12:13:38.081-120><thread=7088 (0x1BB0)>
Il s’avère que j’avais un site secondaire orphelin (SE4) depuis quelques temps. J’ai donc procédé à sa suppression puis relancé la mise à jour qui s’est déroulée avec succès.
Ce qu’il faut retenir ? Assez-vous de valider l’ensemble des prérequis ! Sauvegardez bien vos sites avant de procéder à la mise à jour de ces derniers.
Une fois le site primaire à jour, vous pouvez mettre à jour les sites secondaires avec la procédure suivante :
- Ouvrez la console d'administration et naviguez dans Administration - Site Configuration - Sites.
- Sélectionnez le site secondaire souhaité, et cliquez sur Upgrade. Confirmez l'opération pour lancer la mise à jour.
Mettez à jour toutes les consoles d'administration distantes. Ce processus est nécessaire afin d'offrir l'accès à toutes les nouvelles fonctionnalités offertes par la R2. Vous pouvez utiliser toutes les méthodes d'installation supportées par la console d'administration : Manuelle, Déploiement de packages etc…
Une fois l'installation du site primaire achevée, vous pouvez reconfigurer les réplicas de bases de données pour les Management Points.
Mettez à jour les clients en utilisant une des méthodes proposée par Microsoft : Déploiement du package, fonction intégrée de mise à jour du client …
Notez que quelques retours sont signalés sur les forums, voici les plus communs :
- La mise à jour de l’infrastructure semble avoir un impact négatif sur les points de distribution avec la fonction PXE/WDS. Rien n’est confirmé à ce jour par Microsoft.
- Les performances du déploiement de système d’exploitation semblent être impactées lors de l’utilisation des images Windows PE 5.0. L'impact est confirmé par Microsoft. Voir : http://social.technet.microsoft.com/Forums/en-US/4c72ae27-198f-4751-b0d6-340a11b52bd4/insanely-slow-os-download-in-2012-r2-winpe?forum=configmanagerosd
- La mise à niveau peut échouer si des Pull DPs sont présents dans l'environnement. Voir : http://blogs.technet.com/b/umairkhan/archive/2013/10/29/the-configmgr-2012-r2-upgrade-from-configmgr-2012-sp1-cu3-will-fail-if-you-have-pull-dps-in-your-environment.aspx
Vous pouvez aussi obtenir plus d'information dans mon livre sur System Center 2012 Configuration Manager :
