Vous le savez depuis quelques mois, Microsoft a publié la Bêta 1 de sa prochaine version (2011) de SCCM surnommée : System Center Configuration Manager v.Next.
La partie gestion des mises à jour a subit d’important changements et la Bêta 2 promet encore de belles surprises. Néanmoins, Microsoft répond déjà à une attente prononcée de ses clients dans la Bêta 1 avec la fonctionnalité Automatic Grouping Rules (AGR) ou Règles de groupement automatique.
Cette fonctionnalité permet de définir des règles qui regroupent les mises à jour, les téléchargent automatiquement et les déploient automatiquement sur les collections choisies.
Imaginez le scénario suivant :
Vous êtes administrateur dans une grande entreprise. Vous utilisez System Center Configuration Manager pour déployer les mises à jour. Vous utilisez aussi l’antivirus de Microsoft Forefront Client Security (FCS) ou Forefront EndPoint Protection (FEP) 2010. Vous devez donc mettre à jour quotidiennement les définitions antivirus sur chacun des clients. Avec SCCM 2007, vous deviez synchroniser le serveur tous les jours, ajouter la mise à jour à un package, et ajouter la mise à jour à un déploiement. Une opération quotidienne lourde qui a le mérite d’être automatisée avec WSUS 3.0.
Avec System Center Configuration Manager v.Next (2011), Microsoft introduit cette fonctionnalité de groupement automatique permettant d’économiser du temps d’administration. Avec cette fonctionnalité, l’administrateur peut configurer les règles et prendre 5 mois de vacances sans se soucier du déploiement des mises à jour…
Ces règles seront évaluées périodiquement et ajouteront les mises à jour répondant à certains critères à un groupe de mises à jour. Les mises à jour seront aussi ajoutées à un package qui sera redéployé automatiquement sur les points de distribution. Enfin un déploiement sera créé pour introduire les mises à jour dans le cycle de vie du poste de travail.
Dans la suite de ce post, vous verrez le fonctionnement et les différentes options disponibles au travers de cette fonctionnalité.
Veuillez noter que l’article se base sur la Bêta 1 du produit et que l’interface et certaines options sont susceptibles de changer au travers du processus de développement.
Commençons par la console. Oui ! Elle a bien changée. La gestion des mises à jour se trouve dans la partie Software Library => Overview => Software Updates.
Premier changement apparent, les listes de mises à jour n’existent plus. Elles sont remplacées par la notion de groupes de mises à jour.
Ouvrez ensuite la partie Automatic Grouping Rules et sélectionnez Create Automatic Grouping Rules.
L’assistant de création d’une règle de groupement automatique s’ouvre.
Vous pouvez sélectionner un modèle de déploiement à l’aide de la fonction Select Template.
Entrez ensuite un nom de règle et la collection cible du déploiement.
Vous devez ensuite choisir l’action qui sera exécutée par la règle. Vous pouvez soit systématiquement ajouter les mises à jour au même groupe qui sera créé lors de la première exécution de la règle ou recréer un groupe à chaque nouvelle évaluation de la règle.
Enfin l’option Enable Deployment on successful execution of rule permet d’activer l’ordre de déploiement si la règle s’est exécuté avec succès.
L’écran Deployment Settings permet de spécifier le niveau de verbosité du déploiement. Il permet aussi de spécifier si un ordre de réveil (Wake On Lan) doit être envoyé au poste client. Cette option n’est disponible que si vous activé le déploiement sur des périphériques.
L’étape Updates permet de spécifier les critères de filtre qui permettront la sélection des mises à jour lors de l’exécution de la règle de groupement automatique. Vous pouvez sélectionner des paramètres comme la langue, le produit, la sévérité, la date de sortie, ou la date de modification. On peut ainsi imaginer une règle revenant à rassembler toutes les mises à jour d’un produit donné pour les 28 derniers jours, qui serait exécutée chaque mois pour le Patch Tuesday.
La page Scheduling permet de spécifier si le client doit utiliser le temps universel ou le temps local du client.
Enfin, vous devez spécifier une durée qui déterminera la date de fin (deadline) du déploiement en fonction de la date de disponibilité.
Avis Personnel : A mon grand regret, il n’est pas possible de créer une règle de déploiement automatique qui ne force pas le déploiement des mises à jour par une date de fin. La Bêta 1 ne propose pas la possibilité de créer des règles proposant des déploiements optionnels.
L’écran User Experience permet de spécifier les paramètres de notification. Vous pouvez choisir un mode de notification totalement silencieux, en accord avec les préférences d e l’utilisateur ou afficher l’ensemble des notifications.
Vous pouvez spécifier les options concernant le comportement des dates de fin et des fenêtres de maintenance lorsque la date de fin a été atteinte. Il est ainsi possible de forcer l’installation des mises à jour et le redémarrage du système (si nécessaire).
Enfin vous pouvez spécifier le comportement du poste de travail si un redémarrage est nécessaire. Il est ainsi possible de supprimer le redémarrage pour les serveurs et les postes de travail.
La page Operations Manager permet de spécifier les options concernant la génération des alertes. Vous pouvez tout comme dans SCCM 2007 désactiver les alertes ou générer des alertes si l’installation échoue.
L’étape Download Settings régit le comportement du téléchargement des mises à jour lorsque le client est sur une limites lente et non fiable ou quand le package n’est pas disponible sur le point de distribution protégé attribué à la limite. Vous pouvez ainsi faire rabattre le client sur un point de distribution non protégé.
L’écran Evaluation permet de spécifier les options d’évaluation de la règle. Ainsi elle est évaluée dès lors qu’une synchronisation du Software Update Point sur les serveurs de Microsoft a lieu.
Cette page permet aussi de spécifier le comportement pour les mises à jour nécessitant l’acceptation d’un accord de licence. Par défaut, elles ne sont pas déployées automatiquement.
La page Deployment Package permet de sélectionner ou créer un package qui servira à l’ajout des mises à jour lors de l’évaluation de la règle.
Avis Personnel : Deuxième regret, l’équipe SCCM n’a pas encore intégré la notion de création automatique de package. Certains clients ont un Workflow revenant à créer un package par Patch Tuesday.
L’étape Download Location permet de spécifier où vous souhaitez télécharger les mises à jour. Soit par Internet, soit en spécifiant un chemin réseau contenant l’ensemble des mises à jour.
L’écran Language Selection permet de spécifier les différentes langues de mises à jour à télécharger.
La page Nap Settings permet d’activer la mise en application du NAP pour ces mises à jour et l’intervalle entre la mise en déploiement et l’activation effective. Une fois l’intervalle atteint, si le client ne dispose pas des mises à jour, il sera mis en zone de quarantaine et devra se procurer les mises à jour pour redevenir conforme à la politique.
Enfin, validez l’écran de résumé pour lancer la création.
Une fois la règle créée, on initie une synchronisation. Nous avons procédé à cette étape lors de la publication du Patch Tuesday du mois d’août.
Pour voir l’avancement de l’évaluation de la règle, on peut consulter le fichier de log : rulesengine.log. On peut ainsi y voir qu’il évalue la règle, définit la liste des mises à jour à déployer et télécharge le contenu.
On peut ainsi voir que le package a subit l’ajout des mises à jour :
Le package a été automatiquement déployé sur les points de distribution sélectionné :
Un groupe de mises à jour spécifique a été créé avec l’ensemble des mises à jour évalué par la règle et validant les différents critères. Un déploiement a aussi été créé mais conformément à mes paramétrages, il n’a pas été activé par défaut :
Nous venons de voir le mécanisme de la nouvelle fonctionnalité Automatic Grouping Rules.
Cette fonctionnalité tant attendu répondra à bien des besoins de facilité d’administration. On peut néanmoins regretter certains choix comme le fait de forcer l’ajout d’une date de fin au déploiement, ne permettant pas la création de déploiement optionnel.
