Exporter (0) Imprimer
Développer tout

Processus de gestion des correctifs

Phase 3 - Évaluation et planification

Dernière mise à jour le 01 juin 2007

Sur cette page

Dans ce module
Objectifs
S'applique à
Comment utiliser ce module
Présentation
Identification des actions appropriées
Planification de la diffusion
Génération de la version
Tests d’acceptation
Synthèse
Passage à la phase de déploiement

Dans ce module

Ce module décrit la troisième des quatre phases du processus de gestion des mises à jour : l'évaluation et la planification. Cette phase consiste à décider si une mise à jour doit être ou non déployée, à déterminer ce qui est nécessaire pour son déploiement et à la tester dans un environnement semblable à celui de la production afin de vérifier qu’elle ne compromet pas la sécurité des applications et des systèmes fondamentaux de l’entreprise.

Ce module a pour objectif de décrire les principes de la phase d’évaluation et de planification du processus de gestion des mises à jour et de vous présenter les types de tâches qui vous permettront d’effectuer l’évaluation et la planification avec Microsoft Windows Server Update Service (WSUS) et Microsoft Systems Management Server (SMS).

Remarque : Vous pouvez télécharger la version bêta 2 de la prochaine version de SMS, appelée System Center Configuration Manager 2007, à l'adresse http://www.microsoft.com/technet/sms/2007/evaluate/download.mspx. Grâce à des améliorations au niveau de la simplicité, de la configuration, du déploiement et de la sécurité, Configuration Manager 2007 simplifie considérablement le déploiement des systèmes, l'automatisation des tâches, la gestion des conformités et la gestion de la sécurité basée sur les stratégies, améliorant ainsi la souplesse de l'entreprise.

Sans processus d’évaluation et de planification, vous ne pouvez pas disposer d’un ensemble de critères clairs vous permettant de décider si une mise à jour doit être ou non déployée. Vous ne saurez donc pas ce qui est nécessaire pour le déploiement et les procédures ne seront pas en place pour générer une version logicielle fiable et parfaitement testée.

Objectifs

Ce module vous permettra d'effectuer les opérations suivantes :

  • déterminer si un déploiement de mise à jour est véritablement nécessaire ;

  • planifier la diffusion de la mise à jour de logiciel ;

  • générer la version ;

  • mener les tests d’acceptation de la version.


S'applique à

Ce module s’applique à l’ensemble des produits et technologies Microsoft.

Comment utiliser ce module

Les étapes de base nécessaires à l’exécution des tâches d’évaluation et de planification à l’aide de WSUS et SMS sont décrites dans ce module. Toutefois, des instructions plus détaillées sont disponibles dans les bibliothèques techniques dont vous trouverez la liste ci-dessous.

Afin de tirer le meilleur parti possible de ce module :

  • Lisez la section Introduction du module « Processus de gestion des mises à jour ». Elle présente les quatre phases du processus de gestion des mises à jour et propose une introduction aux outils permettant la prise en charge de la gestion des mises à jour dans les environnements basés sur un système d’exploitation Microsoft Windows.

  • Vous trouverez des supports de référence détaillés dans les bibliothèques techniques WSUS et SMS. Ces bibliothèques sont disponibles aux adresses suivantes :


Présentation

La phase d’évaluation et de planification est la troisième phase du processus de gestion des mises à jour illustré à la figure 1.

Figure 1 Processus de gestion des correctifs

Figure 1 Processus de gestion des mises à jour

Au cours de cette troisième phase, vous allez évaluer la mise à jour de logiciel et, si son déploiement est approuvé, vous allez le planifier dans l’environnement de production.

Le début de la phase d'évaluation et de planification correspond au moment où une requête de modification (RFC) pour une mise à jour de logiciel a été identifiée comme appropriée à votre environnement de production.

À la fin de la phase d’évaluation et de planification, vous devez avoir déterminé si la demande de modification doit être considérée comme urgente, avoir révisé et approuvé la requête et déterminé les tâches nécessaires pour le déploiement des modifications approuvées en production. Vous devez également avoir testé la mise à jour de logiciel dans un environnement semblable à celui de la production pour vérifier qu’elle ne compromet pas la sécurité des applications et des systèmes fondamentaux de l’entreprise.

Ce module met l’accent sur les conditions requises pour l’évaluation et la planification, à savoir :

  • déterminer les actions appropriées ;

  • planifier la diffusion de la mise à jour de logiciel ;

  • générer la version ;

  • mener les tests d’acceptation de la version.


Identification des actions appropriées

La requête de modification (RFC) détermine le type de changement requis dans l’environnement de production, comme le déploiement d’une mise à jour de logiciel, l’application de contre-mesures qui visent à réduire la vulnérabilité, ou les deux. Elle décrit également la modification requise de sorte que des actions puissent être entreprises.

La première étape de cette phase d’évaluation et de planification consiste à réviser le RFC et à déterminer la réponse la plus appropriée à une menace ou à une faille logicielle. Ceci implique les opérations suivantes :

  • attribution de priorité et classification de la requête ;

  • obtention de l’autorisation de déploiement de la mise à jour de logiciel.

Attribution de priorité et classification d’une requête de mise à jour de logiciel

Pour qu’une requête de mise à jour de logiciel soit autorisée, sa priorité et sa catégorie doivent être déterminées. Bien que la priorité et la catégorie soient à l’origine attribuées par l’initiateur de la requête et incluses dans le RFC, celles-ci peuvent être révisées, puis approuvées ou modifiées avant que la demande de modification ne soit autorisée.

Attribution de la priorité d’une mise à jour de logiciel

Le niveau de priorité est particulièrement important du fait qu’il détermine la rapidité avec laquelle une mise à jour de logiciel est transmise via le processus de modification. Les remarques suivantes peuvent vous permettre de déterminer le niveau de priorité d’une mise à jour de logiciel :

  • Quelles sont les principales ressources de l’entreprise ? Seront-elles exposées à une faille de sécurité potentielle ou à l’instabilité du système tant que la mise à jour du logiciel ne sera pas installée ? Vous devez attribuer une priorité aux demandes de modification en fonction de l’impact de la mise à jour ou de l'absence de mise à jour des ressources à haute valeur.

  • La mise à jour de logiciel va-t-elle s’appliquer à un système exécutant un service important de l’entreprise, une application métier ayant fait l’objet d’attaques par le passé ? Ceci peut être une bonne raison d’augmenter la priorité d’une demande de modification.

  • Avez-vous déployé des contre-mesures devant réduire l’exposition à une faille de sécurité particulière ? Ceci peut réduire la priorité de la demande de modification, bien que le déploiement de la mise à jour de logiciel demeure peut-être nécessaire pour éliminer la vulnérabilité.

  • Quelle est la menace de la vulnérabilité en question sur l’environnement de production ? Il se peut que de nombreux bulletins de sécurité et mises à jour de logiciels connexes ne s’appliquent qu’à quelques ordinateurs de votre environnement. Si la menace de la vulnérabilité est faible, le niveau de priorité de la requête peut être réduit.

Les tableaux ci-dessous peuvent vous aider à estimer la priorité de la requête par rapport aux autres requêtes. Le tableau 1 associe les niveaux de priorité aux délais d’exécution recommandés et aux délais d’exécution maximaux recommandés.

Tableau 1 : Priorités des mises à jour et délais d’exécution recommandés

Priorité

Délai d’exécution recommandé

Délai d’exécution maximal recommandé

Urgente

Dans les 24 heures

Dans les 2 semaines

Haut

D’ici 1 mois

D’ici 2 mois

Moyen

Selon la disponibilité, déploiement d’un nouveau Service Pack ou d’une mise à jour cumulée incluant un correctif de vulnérabilité dans les 4 mois.

Déploiement de la mise à jour de logiciel dans les 6 mois.

Faible

Selon la disponibilité, déploiement d’un nouveau Service Pack ou d’une mise à jour cumulée incluant un correctif de vulnérabilité dans les 12 mois.

Déploiement de la mise à jour de logiciel dans les 12 mois. Vous pouvez également décider de ne pas la déployer du tout.


Le tableau 2 fournit des exemples de facteurs qui peuvent augmenter ou réduire la priorité.

Tableau 2 : Facteurs affectant les priorités des mises à jour

Facteur environnemental/organisationnel

Ajustement de la priorité

Ressources à haute valeur et à haut risque affectées.

Augmentation

Ressources identifiées comme cibles coutumières d’attaques.

Augmentation

Facteurs de réduction en place, par exemple des contre-mesures réduisant la menace.

Réduction

Ressources à faible valeur et faiblement exposées affectées.

Réduction


Demande de modification urgente

Si la vulnérabilité à laquelle répond la mise à jour de sécurité est déjà exploitée ou est sur le point de l’être, ou si la mise à jour corrige une instabilité du système rencontrée dans l’environnement de production, il se peut que vous deviez classer la requête comme « urgente », lui donnant la priorité sur toutes les autres modifications appliquées à l’environnement de production.

Classification d’une mise à jour de logiciel

La catégorie d’une mise à jour de logiciel est importante car elle aide les personnes révisant la modification à comprendre l’impact qu’elle aura sur les systèmes et services dans l’environnement de production. Pour définir la catégorie (ou l’impact) de la demande de modification, vous devez déterminer :

  • Sur quelles machines la mise à jour de logiciel doit être installée et les rôles (gravité applicative) de ces machines.

    Une mise à jour de logiciel nécessitant, par exemple, qu’un ordinateur fondamental pour l’entreprise soit redémarré, aura un impact plus grand que celle ne le nécessitant pas.

  • Si des modifications supplémentaires sont nécessaires pour prendre en charge le déploiement de la mise à jour de logiciel.

    Si, par exemple, la mise à jour de logiciel s’applique uniquement au Service Pack actuel et que celui-ci n’est pas installé sur certains systèmes de production, il se peut qu’il ne soit pas possible de protéger ces systèmes contre une faille de sécurité particulière. Dans ce cas, l’impact et donc la catégorie de la demande de modification seront plus élevés, car le Service Pack et la mise à jour de logiciel doivent être tous deux déployés.

  • Si la mise à jour de logiciel peut être désinstallée une fois qu’elle a été installée.

    Dans le cas contraire, elle présente un plus grand risque pour l’environnement de production qu’une mise à jour pouvant être supprimée. Malgré la nécessité de déployer de telles mises à jour de logiciels pour fournir une protection contre une faille de sécurité spécifique ou pour répondre à une instabilité particulière du système, la catégorie de la demande doit en faire état.

  • L’impact présumé sur l’infrastructure du réseau.

    Le déploiement simultané d’une mise à jour de logiciel de taille importante sur plusieurs ordinateurs risque de réduire les performances du réseau et de nuire au bon fonctionnement de l'ensemble de votre environnement. Vous devez revoir minutieusement la totalité de la documentation relative à la mise à jour de logiciel et connaître la taille de la mise à jour et le nombre d’ordinateurs concernés par celle-ci. Ces informations peuvent aider à planifier correctement la diffusion.

  • Si certains services doivent être arrêtés, suspendus ou fermés pendant l’installation.

    Ceci risque d’affecter les services fondamentaux d’une entreprise ou d’empêcher un utilisateur final de travailler sur l’ordinateur pendant l’installation.

Des informations supplémentaires sur la définition de la priorité et de la catégorie d’une demande de modification figurent à la section relative à la fonction de gestion des services (SMF) de gestion des modifications à l’adresse http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx.

Obtention de l’autorisation de déploiement de la mise à jour de logiciel

Une fois la priorité et la catégorie de la demande de modification définies, celle-ci doit être révisée et autorisée pour que la mise à jour de logiciel soit déployée en production. Pour que la demande de modification soit autorisée, vous devez :

  • déterminer qui sera impliqué dans le processus de prise de décision ;

  • réviser la demande de modification, estimer les risques et les conséquences du déploiement de la mise à jour de logiciel et sélectionner l’action la plus appropriée ;

  • identifier qui sera responsable du déploiement de la mise à jour de logiciel sur tous les systèmes concernés.

Identification des personnes impliquées

Il est important de déterminer qui sera impliqué dans la révision et l’autorisation d’une mise à jour de logiciel en vue de son déploiement en production. Pour des mises à jour à caractère non urgent, la révision et l’autorisation doivent être effectuées par un conseil décidant des modifications, constitué de représentants de tous les secteurs de l’entreprise qui seront affectés.

Les membres de ce conseil doivent être des individus dotés d’une expérience dans les technologies et services spécifiques qui seront utilisés pour déployer la mise à jour. Des représentants des équipes métier, réseau, sécurité, services et support technique doivent également faire partie de ce groupe.

Des informations supplémentaires sur ce conseil et sa formation figurent à la section SMF de gestion des modifications, pouvant être téléchargée à l’adresse http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx.

Demande de modification urgente

Lorsqu’une décision rapide doit être prise à propos d’une requête sensible, conçue pour résoudre une faille de sécurité ou éviter une panne importante du système, l’autorisation doit être accordée par le comité d’urgence du conseil (CAB/EC).

Ce comité doit être composé de personnes disposant de droits leur permettant d’approuver des modifications d’urgence et qui seront disponibles pour prendre des décisions rapides. Des informations supplémentaires sur ce comité figurent à la section SMF de gestion des modifications qui peut être téléchargée à l’adresse suivante : http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx.

Révision de la demande de modification

Une fois les personnes requises rassemblées, vous devez évaluer les risques et l’impact de la mise à jour de logiciel sur l’environnement de production et déterminer si elle doit être ou non déployée. En prenant cette décision, vous devrez aborder les questions suivantes :

  • Que se passe-t-il d’autre dans l’environnement de production ?

  • Quel est l’impact de l’application ou non de la mise à jour de logiciel ?

  • Quel est le coût estimé du déploiement ou non de la mise à jour de logiciel ?

  • Quelles actions peuvent être entreprises, le cas échéant, pour réduire l’exposition à une faille de sécurité ou le risque d’une instabilité du système, pendant le déploiement de la mise à jour de logiciel ?

  • Quel est l’impact de l’inactivité de l’ordinateur ? Il est nécessaire de comparer et de prendre en considération les risques de report du déploiement d’une mise à jour de logiciel en fonction des risques encourus du fait de l’inactivité de l’ordinateur lors du déploiement de la mise à jour dans votre environnement.

  • Quel sera le meilleur mécanisme et le plus efficace pour le déploiement de la mise à jour de logiciel ?

  • Existe-t-il des problèmes ou des effets secondaires connus dus à la mise à jour de logiciel ? Nécessite-t-elle le redémarrage du système ?

  • Les ressources disponibles sont-elles suffisantes pour déployer la mise à jour de logiciel ou traiter les éventuels problèmes rencontrés au cours du déploiement ?

  • Comment allez-vous préparer les dépendances et la configuration requise avant que la mise à jour de logiciel ne soit déployée ?

Bien que la meilleure façon de faire face à une faille logicielle soit de déployer la mise à jour qui vise à résoudre le problème, il est parfois préférable de mettre en place une contre-mesure à court terme, comme par exemple la fermeture des ports réseau ou l’arrêt de l’accès externe aux systèmes, pendant que la mise à jour de logiciel est déployée sur les systèmes de l’environnement de production. L’application de contre-mesures peut présenter plusieurs avantages :

  • La majorité des mises à jour de logiciels requiert le redémarrage des ordinateurs cibles pour que l’installation soit terminée et que l’ordinateur soit protégé. Si vous ne pouvez pas déployer immédiatement une mise à jour de logiciel dans votre environnement car les ordinateurs ne peuvent être redémarrés que lors de certaines plages de maintenance spécifiques, la mise en œuvre des contre-mesures recommandées peut effectivement protéger vos ordinateurs jusqu’à ce que la mise à jour de logiciel soit déployée. Parfois, des mises à jour de sécurité peuvent être également déployées et le redémarrage automatique supprimé. Dans ce cas, la mise à jour de sécurité peut être installée pendant les heures normales et l’ordinateur redémarré à un moment opportun au cours d’une plage de maintenance.

  • Des contre-mesures peuvent présenter un moindre risque et être appliquées plus rapidement et avec moins de tests que la mise à jour de logiciel elle-même. Il peut être bien plus simple, par exemple, de désactiver les ports réseau ou d’arrêter des services ou des systèmes qui sont exposés à une faille de sécurité particulière et d’appliquer la mise à jour de logiciel ultérieurement.

L’implémentation de contre-mesures renforçant les ordinateurs peut souvent protéger les ordinateurs contre de nombreuses failles de sécurité. Le blocage de certains ports réseau et la désactivation des services inutilisés ne sont que deux des contre-mesures qui, si elles sont mises en œuvre, peuvent effectivement protéger vos ordinateurs.

Pour plus d’informations sur les contre-mesures renforçant les ordinateurs, reportez-vous au guide « Menaces et contre-mesures » à l'adresse http://www.microsoft.com/france/technet/security/guidance/serversecurity/tcg/tcgch00.mspx

Remarque : Même si des contre-mesures sont déployées pour réduire l’exposition à une faille de sécurité, le déploiement de la mise à jour de sécurité doit tout de même être planifié.

Par exemple, si certains systèmes ne sont pas mis à jour et qu’un ordinateur est infecté par un ver ou qu’un virus est introduit dans le réseau, l’infection s’étendra rapidement à tous les systèmes non protégés. Le déploiement de contre-mesures doit simplement réduire la priorité de la demande de modification, et non supprimer la nécessité de la mise à jour de logiciel.

Attribution de la propriété du déploiement de la mise à jour de logiciel

Une fois l’accord obtenu de déployer la mise à jour de logiciel et, le cas échéant, d’utiliser des contre-mesures, vous devez identifier qui devra s’assurer que les modifications sont appliquées. Cette personne devra :

  • développer un plan d’exécution des modifications requises ;

  • déterminer et obtenir les ressources requises ;

  • préparer le développement des scripts, des outils et de la documentation nécessaires pour le déploiement des modifications ;

  • s’assurer que les tests adéquats sont effectués ;

  • s’assurer que les modifications sont déployées en production ;

  • évaluer le succès ou l’échec du déploiement.

Sans propriétaire désigné pour superviser les activités mentionnées ci-dessus, le déploiement de la mise à jour de logiciel risque d’échouer. Le propriétaire désigné est généralement le responsable des versions, appelé « Release Management SMF » sur le site suivant : http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx.

Planification de la diffusion

Le planning de diffusion est le processus qui consiste à déterminer comment diffuser la mise à jour de logiciel dans l’environnement de production.

La diffusion d’une nouvelle mise à jour de logiciel comporte essentiellement trois étapes :

  • définir les éléments devant être mis à jour ;

  • identifier les problèmes et les contraintes majeurs ;

  • établir le plan de diffusion.

Identification des éléments à mettre à jour

Décider des éléments devant être mis à jour requiert une connaissance précise et à jour des éléments présents dans l’environnement.

Dans un environnement WSUS, il se peut que les administrateurs doivent effectuer une nouvelle analyse à l’aide de MBSA (Microsoft Baseline Security Analyzer) afin d’identifier les systèmes nécessitant la mise à jour de logiciel. Si SMS est déployé, les informations extraites par les outils d’inventaire et les agents client peuvent être utilisées pour identifier les machines sur lesquelles la mise à jour doit être installée.

Pour plus d’informations sur ces outils, reportez-vous à la bibliothèque technique WSUS (Windows Server Update Services) et à la bibliothèque technique pour Systems Management Server 2003.

Identification des problèmes et des contraintes majeurs

Il se peut qu’un certain nombre de problèmes et de contraintes dicte les étapes nécessaires pour déployer totalement la mise à jour de logiciel en production. Par exemple, si la tâche vous incombe de déployer la mise à jour de logiciel, vous devez prendre en considération les points suivants :

  • Combien de temps devez-vous accorder aux utilisateurs avant que la mise à jour de logiciel ne soit installée automatiquement ? La durée autorisée dépendra d’un certain nombre de facteurs, y compris des rôles et des responsabilités des utilisateurs et de la nature de l’instabilité du système ou de la faille de sécurité que la mise à jour de logiciel doit corriger.

  • La figure 2 est un exemple de planning de déploiement d’une mise à jour de logiciel (contrat de niveau de service [SLA]) qui montre que la mise à jour doit être appliquée aux serveurs dans les sept jours qui suivent l’arrivée de la mise à jour de logiciel ne présentant pas un caractère crucial pour l’entreprise. L'autorisation de lancer l’application de la mise à jour dans les sept jours a été accordée aux administrateurs, mais ils doivent être conscients du fait que l’application de la mise à jour sera forcée sur les ordinateurs ou que ceux-ci seront déconnectés du réseau une fois le délai expiré.

    Cc700840.secmod196figure2-0-1(fr-fr,TechNet.10).gif

    Figure 2 Exemple de contrat de niveau de service (SLA) pour le déploiement d’une mise à jour sur des serveurs

Un planning de conformité similaire peut être appliqué aux stations de travail de votre environnement, mais les temps de réponses et les actions seront différents.

  • Certaines mises à jour de logiciels requièrent des droits d’administrateur sur l’ordinateur sur lequel elles vont être installées. La plupart des utilisateurs finaux ne disposent pas des droits d’administrateur locaux ; l’outil utilisé pour installer la mise à jour de logiciel doit donc être capable d’acquérir des droits et des privilèges élevés pour installer la mise à jour sur les ordinateurs client.

  • Si l’installation de la mise à jour de logiciel requiert une certaine quantité d’espace ou si elle est placée en mémoire cache locale avant d’être installée, la quantité d’espace libre sur chaque ordinateur client doit être vérifiée.

  • Si la mise à jour de logiciel est volumineuse, plusieurs millions d’octets par exemple, le téléchargement risque de prendre du temps pour les clients mobiles. Si la mise à jour de logiciel n’est pas considérée comme urgente, il peut être préférable de remettre l’installation à plus tard sur ces clients, jusqu’à ce qu’ils soient physiquement connectés au réseau.

  • Il se peut que les ordinateurs fondamentaux de l’entreprise aient des heures auxquelles les modifications et les redémarrages sont autorisés (plages d’inactivité). Le déploiement d’une mise à jour de logiciel et les redémarrages du système qui en résultent doivent être planifiés pendant ces plages d’inactivité.

  • Si des ordinateurs client sont verrouillés par l’utilisation de certains paramètres de la stratégie de groupe, ceci risque d’empêcher l'installation correcte de la mise à jour de logiciel.

  • Si le produit à mettre à jour a été déployé à l’aide de Windows Installer, ce dernier peut requérir l’accès aux fichiers d’installation d’origine. Si vous effectuez une installation sans surveillance de la mise à jour du logiciel, ces fichiers doivent se trouver au même emplacement que lors de l’installation initiale du produit. Si à l’origine, le produit a été installé à partir d’un support physique, un lecteur CD par exemple, Windows Installer tentera de trouver les fichiers originaux sur le CD inséré.

  • Si une image administrative a été utilisée pour l’installation initiale d’un produit Microsoft Office, par exemple, vous devrez effectuer une installation administrative de la mise à jour de logiciel sur l’image plutôt que de l’appliquer directement sur le client. Des informations supplémentaires sur les questions concernant la mise à jour d'une image administrative sont disponibles à l’adresse /technet/prodtechnol/sms/sms2/depopt/smsoffxp.mspx.

  • Si des applications ont été installées au niveau de chaque utilisateur, et non au niveau de chaque ordinateur pour tous les utilisateurs, vous devez réinstaller l’application au niveau de chaque ordinateur, puis appliquer la mise à jour de logiciel à la nouvelle installation.

Si vous utilisez SUS et souhaitez éviter un déploiement en dehors des plages d’inactivité, vous devrez utiliser des objets Stratégie de groupe pour indiquer que les mises à jour doivent être téléchargées, mais pas installées. Dès que vous savez qu’une mise à jour a été téléchargée, vous devez vous connecter à chaque serveur principal de l’entreprise et commencer l’installation au cours de la plage d’inactivité autorisée. Pour les stations de travail, il existe également un paramètre d’objet Stratégie de groupe qui permet de s’assurer que pour les ordinateurs ayant raté une installation planifiée (du fait par exemple, que l’ordinateur client était éteint), l’installation est automatiquement replanifiée lors de l’activation du service Mises à jour automatiques au lancement du système. Pour plus d'informations sur l'utilisation de WSUS durant la phase d'évaluation et de planification, reportez-vous à la bibliothèque technique WSUS (Windows Server Update Services) ; pour plus d'informations sur l'utilisation de SMS pour la planification du déploiement, reportez-vous à la bibliothèque technique pour Systems Management Server 2003.

Demande de modification urgente

Si une demande de modification indique que la mise à jour de logiciel est urgente, vous devez prendre en considération les facteurs suivants :

  • Il se peut que vous deviez déployer la mise à jour de logiciel dans un délai beaucoup plus court qu’à la normale. Par exemple, un déploiement complet peut devoir être réalisé dans les 24 heures qui suivent l’approbation de la demande de modification.

    La figure 3 montre un contrat de niveau de service impliquant un planning de déploiement d’une mise à jour de logiciel. Le planning indique que la mise à jour doit être appliquée à tous les serveurs dans les huit heures suivant l’arrivée d’une notification de mise à jour de logiciel sensible.

    Cc700840.secmod196figure3-0-1(fr-fr,TechNet.10).gif

    Figure 3 Exemple de contrat de niveau de service d’un déploiement d’urgence en huit heures

    Dans l’exemple précédent, une fois l’entreprise au courant de la mise à jour de logiciel, la mise à jour des serveurs cruciaux de l’entreprise doit commencer dans les deux heures (à 12 heures dans le cas présent) avec 98 % des serveurs en conformité à 18 heures. Les serveurs restants doivent être conformes d’ici 22 heures ; si ce n'est pas le cas, ils risquent d’être déconnectés du réseau. Un planning de conformité similaire peut être appliqué aux stations de travail de votre environnement, la plage horaire et la vitesse de réponse pouvant être différentes pour votre entreprise.

  • La plage d’inactivité qui indique quand certains systèmes sensibles de l’entreprise doivent être mis à jour ou redémarrés doit être annulée de façon à permettre le déploiement de la mise à jour de logiciel dans le cadre horaire imparti.

  • Vous devrez appliquer la mise à jour de logiciel à tous les systèmes affectés, quelle que soit leur connexion au réseau.

Si vous utilisez WSUS, vous pouvez utiliser la stratégie de groupe pour forcer les clients à installer une mise à jour de logiciel avant la plage de maintenance planifiée régulièrement. Préalablement, vous devrez également vous assurer qu’une réplication est forcée sur tous les serveurs WSUS enfant qui sont normalement programmés pour synchroniser les mises à jour à des heures de faible activité du réseau, à l’aide de l’option Synchroniser maintenant de la page d’administration du serveur WSUS. Pour plus d’informations sur l’utilisation de WSUS durant la phase d’évaluation et de planification, reportez-vous à la bibliothèque technique WSUS (Windows Server Update Services).

Dans un environnement SMS, vous devez configurer les expéditeurs SMS pour permettre à des transactions de package/publication hautement prioritaires d’être répliquées à toute heure. Il est important que le paramètre de haute priorité ne soit utilisé que pour les packages et les publications de mise à jour de logiciel. Pour plus d’informations sur l’utilisation de SMS durant la phase d’évaluation et de planification, reportez-vous à la bibliothèque technique pour Systems Management Server 2003.

Établissement d’un plan de diffusion

Cette étape consiste à planifier et à déterminer l’ordre dans lequel les ordinateurs de votre environnement de production déploieront la mise à jour de logiciel. Vous devrez peut-être tenir compte des questions suivantes lors de l’établissement du plan de diffusion :

  • Si la mise à jour de logiciel s’applique à tous les serveurs de l’environnement de production, ceux exécutant WSUS et SMS ou les outils de surveillance doivent-ils être mis à jour en premier ?

    Le fait de mettre à jour l’infrastructure de gestion en premier garantit aux administrateurs de pouvoir utiliser ces services pour surveiller la progression du déploiement.

  • Existe-t-il des raisons métier pour que la mise à jour soit appliquée à une partie de l’environnement de production avant une autre ?

    Il peut y avoir un certain nombre de raisons valables pour que la mise à jour de logiciel soit appliquée aux ordinateurs exposés à une faille de sécurité ou à une instabilité potentielle du système, puis une fois ceux-ci mis à jour, que le déploiement soit propagé partout ailleurs.

  • Quel impact la bande passante du réseau disponible entre les sites a-t-elle sur l’ordre du déploiement ?

    Il se peut qu’il soit difficile d’appliquer la mise à jour de logiciel sur certains sites aussi rapidement que sur d’autres, du fait des contraintes dues à la bande passante du réseau. La mise à jour de logiciel peut être déployée plus rapidement sur les sites disposant d’une bonne connectivité réseau que sur ceux pour lesquels la disponibilité du réseau est réduite.

Enfin, vous devez déterminer comment et quand les informations relatives à la mise à jour de logiciel, sa gravité, son impact et les actions devant être entreprises pour son déploiement, seront communiquées aux utilisateurs, à l’entreprise et au bureau de services.

Demande de modification urgente

Dans le cas où la demande de modification revêtirait un caractère urgent, vous devez tenir compte des éléments suivants :

  • Si des composants d’architecture de gestion, tels que Microsoft Operations Manager (MOM), les serveurs de site WSUS et SMS 2003, doivent être également mis à jour, il est préférable que la mise à jour soit effectuée manuellement par les administrateurs locaux afin de s’assurer que ces serveurs ne sont pas redémarrés pendant le déploiement de la mise à jour de logiciel sur les autres ordinateurs de l’environnement de production.

  • Si un site ou un groupe d’ordinateurs a déjà souffert d’une faille de sécurité ou d’une instabilité du système que la mise à jour de logiciel vise à corriger, le déploiement de la mise à jour de logiciel doit être appliqué à ces ordinateurs après résolution du problème. (Exemple : suppression de virus, etc.)


Génération de la version

Lorsqu’un plan de diffusion est en place, l’étape suivante du processus consiste à développer les scripts, outils et procédures que les administrateurs vont utiliser pour déployer la mise à jour de logiciel dans l’environnement de production. Les tâches et activités qui doivent être menées à bien à ce stade dépendent principalement du fait que la mise à jour de logiciel puisse ou non être déployée à l’aide de WSUS ou SMS 2003.

Si vous utilisez WSUS, notez que les mises à jour sont téléchargées directement à partir des serveurs publics Microsoft Update et sont déjà compactées dans un format exécutable (.exe) ; vous n’avez donc pas d’autres tâches à effectuer pour les recompacter avant le déploiement. Pour plus d’informations sur l’utilisation de WSUS durant la phase d’évaluation et de planification, reportez-vous à la bibliothèque technique WSUS (Windows Server Update Services).

Si vous utilisez SMS, la génération de la version est plus simple si la mise à jour peut être déployée à l’aide de l'Assistant Distribution de mises à jour logicielles SMS 2003. Cet Assistant peut créer automatiquement le package SMS, ainsi que le programme requis pour distribuer et installer la mise à jour de logiciel. Toutes les mises à jour de sécurité s’appliquant à une combinaison de produit et de Service Pack spécifique peuvent être alors regroupées dans un package de déploiement de sécurité qui simplifie la gestion et l’administration, tout en réduisant considérablement le nombre de redémarrages des ordinateurs requis. Pour les mises à jour ne pouvant pas être déployées à l’aide de l'Assistant Distribution de mises à jour logicielles SMS 2003, vous devez utiliser les procédures de distribution de logiciels SMS standard pour créer un package et une publication, spécifier le fichier de commandes, le fichier MSI (Microsoft Installer) ou un exécutable qui sera exécuté sur l’ordinateur client ; si la mise à jour n’est pas fournie avec un fichier d’installation, vous devrez également générer un exécutable à l’aide des outils de création MSI. Pour plus d’informations sur l’utilisation de SMS durant la phase d’évaluation et de planification, reportez-vous à la bibliothèque technique pour Systems Management Server 2003.

Tests d’acceptation

Jusqu’à ce point, l’objectif des tests a été de confirmer que la mise à jour de logiciel et le package de diffusion fonctionnent correctement dans un environnement de développement.

Les tests d’acceptation permettent aux développeurs et aux représentants de l'entreprise de vérifier le bon fonctionnement des mises à jour dans un environnement semblable à celui de la production et la parfaite exécution des systèmes cruciaux de l’entreprise une fois la mise à jour de logiciel déployée. Les administrateurs, aidés des représentants de l'entreprise, doivent définir une série de tests qui sera exécutée lorsqu’une mise à jour de logiciel est jugée stratégique pour l’entreprise et une série de tests plus détaillés utilisée lorsque la priorité de la mise à jour de logiciel sera plus faible.

Même si la mise à jour de logiciel est cruciale, vous devez toujours effectuer un minimum de tests pour prouver que :

  • une fois l’installation terminée, l’ordinateur redémarre normalement ;

  • la mise à jour de logiciel, si elle est destinée à des ordinateurs connectés via des connexions réseau lentes ou peu fiables, peut être téléchargée sur ces liens et, une fois cette opération terminée, s’installe correctement ;

  • la mise à jour de logiciel est fournie avec une routine de désinstallation qui peut être utilisée pour sa suppression ;

  • les systèmes et services cruciaux de l’entreprise poursuivent leur exécution une fois la mise à jour de logiciel installée.

Avant de déployer la mise à jour de logiciel en production, il est important de collecter des informations sur les étapes, les procédures et les outils de dépannage utilisés au cours des tests et de les mettre à la disposition du personnel de support des services et de l’équipe des opérations.

Les tests doivent aboutir à la création des éléments suivants :

  • des articles de la Base de connaissances interne qui décrivent des étapes de dépannage standard, ainsi que les solutions palliatives qui y sont associées ;

  • une liste de contacts et un chemin d’escalade ;

  • des scripts, des règles et des informations (tels que des compteurs, des événements et des seuils) qui permettront au personnel des opérations de surveiller avec efficacité la diffusion en production.

Peu importe le nombre de tests effectués, le déploiement d’une mise à jour de logiciel en production produit souvent des effets qui ne peuvent jamais être anticipés ou répliqués dans un environnement de test. Pour éviter l’effet d’un échec potentiel sur un grand nombre d’ordinateurs client, les administrateurs doivent envisager de déployer la mise à jour de logiciel sur un petit nombre représentatif d’ordinateurs et s’assurer que les applications et les systèmes cruciaux de l’entreprise poursuivent leur exécution, avant de la déployer sur la totalité de l’entreprise.

Synthèse

Voici les principaux points de la phase d’évaluation et de planification dont vous devez vous souvenir :

  • Un processus formel est nécessaire pour déterminer si le déploiement de la mise à jour de logiciel est du plus grand intérêt pour l’entreprise.

  • Vous devez désigner un propriétaire de la mise à jour de logiciel qui devra vérifier qu’elle est correctement déployée.

  • Lorsque vous disposez d’une mise à jour de logiciel approuvée, vous devez planifier comment la déployer en production.

  • Vous devez tester le package dans un environnement de tests et, si nécessaire, effectuer un test pilote dans un environnement de production pour confirmer qu’elle ne met pas en danger les applications LOB.


Passage à la phase de déploiement

Le passage à la phase de déploiement du processus de gestion des mises à jour est déclenché lorsque :

  • le package est prêt au déploiement en production ;

  • vous avez reçu l’accord pour déployer la mise à jour de logiciel dans l’environnement de production. Pour plus d’informations sur la phase de déploiement, lisez le module « Gestion des mises à jour : Phase 4 - Déploiement ».


Télécharger la solution complète

Gestion des correctifs avec SMS 2003 (en anglais)



Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2015 Microsoft