 TechNet Magazine October 2007

TechNet Magazine October 2007

Informatique écolo: Création d'un centre de données écologique

Des entreprises du monde entier commencent à réfléchir aux divers moyens d'économiser de l'énergie et de réduire les coûts, mais les conseils pratiques de mise en œuvre sont relativement rares. Franchissez le pas grâce à notre introduction à la planification, la conception et l'implémentation d'un centre de données écologique dans votre organisation.

Dave Ohara Administration de Windows: Guide de réplication Active Directory

Active Directory offre une grande flexibilité pour la prise en charge des environnements de grande taille ou décentralisés. Toutefois, le maintien de l'intégrité de vos données peut s'avérer difficile. La réplication Active Directory définit le mode de communication des mises à jour à l'échelle de votre environnement et le mode de résolution des conflits. Les informations suivantes vous permettront de relever le défi.

Laura E. Hunter System Center: Nouveaux outils de gestion des mises à jour logicielles

System Center Configuration Manager 2007 vous propose une méthode de gestion des mises à jour entièrement nouvelle qui garantit une meilleure mise en œuvre et une meilleure conformité sur chaque client. Découvrez comment cette approche améliorée peut vous aider à mettre à jour tous vos ordinateurs.

Steve Rachui Communications: Serveurs de transport Edge Exchange chez Microsoft

Comment Microsoft assure-t-elle la remise des messages légitimes à ses employés, tout en maintenant le contenu malveillant à l'écart de l'environnement de messagerie ? L'une des méthodes consiste à déployer des serveurs de transport Edge Exchange Server 2007 et Forefront Security for Exchange Server. Découvrez comment ces technologies peuvent contribuer à assurer la sécurité de votre organisation.

Kay Unkroth SQL Server: Optimisation des performances des processeurs sous SQL Server

La clé d'une bonne utilisation des processeurs sur votre serveur de base de données consiste à s'assurer que le processeur passe son temps à traiter ce que vous lui de demandez traiter et non à gaspiller des cycles sur du code mal optimisé ou du matériel lent. Voici certains quelques conseils pour tirer le meilleur parti de SQL Server et de votre matériel.

Zach Nichter Le mot du rédacteur en chef: Le meilleur est à venir

Joshua Hoffman Boîte à outils: Nouveaux produits pour les professionnels de l’informatique

Greg Steen Forum aux questions sur SQL&: Déclencheurs de connexion, défragmentation de fichier de données, et bien plus encore

Edited by Nancy Michell Coup de projecteur sur les utilitaires: Virtual Machine Remote Control Plus

Matthijs ten Seldam L'informatique dans l'entreprise: Calcul de la valeur de l'infrastructure informatique dans l'administration

Acer Maamoun Le petit câbleur: Authenticated Internet Protocol

Joseph Davies Windows PowerShell: Travailler sans script

Don Jones Hé, vous le scripteur !: Que Silverlight soit

The Microsoft Scripting Guys Vigilance sécurité: BitLocker et le délicat problème de la confiance

Justin Troutman Histoires de Bureau: Guide de l'utilisateur expérimenté de WIM et ImageX

Wes Miller Sur le terrain: Recyclez votre PC

Jim Lynch La vie secrète de Windows: Dr. Watson à la rescousse

Raymond Chen


 Informatique &#233;colo: Cr&#233;ation d'un centre de donn&#233;es &#233;cologique
Informatique écolo Dave Ohara

Création d'un centre de données écologique
Vue d'ensemble:
  • Systèmes de surveillance de la consommation énergétique
  • Caractéristiques principales d'un centre de données écologique
  • Effets de H.R. 5646
  • Méthodes recommandées pour la mise en route

L'écologie est un sujet d'actualité brûlant et le concept commence à influencer la façon dont les gens considèrent les centres de données. Des entreprises du monde entier annoncent des façons d'économiser de l'énergie et de réduire
les coûts en achetant de nouveaux matériels et services. Pourtant, on trouve peu de conseils sur les mesures à prendre pour contrôler les coûts d'énergie. Autrefois, l'électricité faisait partie des frais généraux, au même titre que le coût de l'espace. Mais avec la hausse des coûts de l'énergie et des problèmes de fiabilité, d'approvisionnement et de capacité, l'électricité nécessite une stratégie spécifique propre.
Les projets concernant l'optimisation des performances et la réduction des coûts font partie intégrante des méthodes recommandées quotidiennes dans presque tous les aspects de l'activité commerciale. Alors pourquoi ne pas traiter les coûts énergétiques de la même façon ?
En tant que professionnels de l'informatique, un grand nombre d'entre nous prennent des décisions concernant la configuration et l'installation de serveurs, les spécifications des équipements achetés par nos entreprises et les exigences en matière de mise à niveau et de construction de centres de données. Nous fournissons même les premières idées de conception pendant le développement de l'application. Lorsqu'il s'agit de ces projets, nous avons à l'évidence l'occasion unique d'être écologiques et d'influencer le rendement énergétique de n'importe quel centre de données.
La première étape de toute stratégie énergétique consiste à connaître les arcanes de votre consommation énergétique actuelle. Vous devez savoir où votre énergie est utilisée et par quel équipement spécifique, et déterminer les points de consommation efficace et de gaspillage dans le centre de données. Malheureusement, il est rare que des compteurs de consommation d'énergie soient prévus pour décomposer l'utilisation à un niveau où les gens peuvent voir les résultats de leurs actions. En général, la plupart des organisations reçoivent seulement une facture mensuelle qui convertit leur consommation en un montant global. Ceci n'encourage pas vraiment à économiser de l'énergie puisque les individus ne voient jamais l'impact de leurs décisions et n'ont aucun moyen de prouver que leurs changements ont effectivement permis des économies d'énergie.
L'un des premiers problèmes auxquels les gens doivent faire face lorsqu'ils envisagent une initiative de centre de données écologique est de savoir s'ils ont le soutien de la direction. Dans le cadre de cet article, je vais supposer que la réponse est « pas encore ». Le soutien de la direction requiert un engagement sérieux fournissant des ressources et un budget pour votre initiative. Et, si l'on parle beaucoup des centres de données écologiques, dans la réalité, il y a souvent un manque de soutien sérieux de la part de la direction. Si vous bénéficiiez déjà d'un tel soutien de votre direction, vous seriez en train d'exécuter un centre de données écologique en ce moment même.
Ceci dit, même si vous ne disposez pas du soutien dont vous avez besoin, vous pouvez faire beaucoup pour faire progresser votre initiative de centre de données écologique. Alors, comment déterminer les mesures efficaces à prendre pour atteindre vos objectifs ? Heureusement, l'efficacité énergétique n'est pas un concept nouveau et les professionnels de l'informatique peuvent en apprendre beaucoup d'autres industries.

Résumé de la consommation d'énergie
L'une des plus grandes difficultés que je rencontre lorsque j'écris à ce sujet consiste à déchiffrer la diversité de chiffres fournis par des sources différentes. D'après certaines études, les centres de données représentent 1,2 à 2 % de l'électricité consommée aux États-Unis. Selon certaines estimations, si vous considériez les centres de données comme un secteur à part entière, les centres de données américains seraient proches des cinq premiers secteurs en termes de consommation d'énergie. Parallèlement, l'électricité peut représenter jusqu'à 15 à 20 % des frais d'exploitation dans un centre de données d'entreprise américain.
Une étude réalisée par Lawrence Berkeley National Laboratories pour l'American Council for an Energy-Efficient Economy a déterminé que les centres de données peuvent consommer jusqu'à 40 fois plus d'énergie que les immeubles de bureaux conventionnels. Cette étude explique ce que l'on peut faire pour améliorer l'efficacité énergétique au niveau des installations (voir eetd.lbl.gov/emills/PUBS/PDF/ACEEE-datacenters.pdf). Vous pouvez commencer par déterminer dans quelle mesure votre centre de données utilise les meilleurs pratiques définies dans cette étude.
Il ne fait aucun doute qu'il existe énormément de points de vue, d'études et de chiffres concernant la consommation d'énergie. Cependant, il ressort de tous qu'il y a beaucoup de gaspillage. Songez au nombre de serveurs qui ont été achetés dans le but de tirer le meilleur profit ; cela signifie acheter le plus de puissance de processeur, de mémoire, de stockage et d'alimentations redondantes possible pour un budget donné. Au cours des 3 à 5 dernières années, un grand nombre de ces serveurs ont été exécutés à une moyenne de 10 à 15 % de leur capacité. Les gens se concentrent souvent sur les processeurs, mais d'autres composants jouent un rôle important ici : la mémoire, les disques et les interfaces réseau utilisent tous beaucoup d'énergie et, lorsqu'ils sont associés, dépassent la consommation du processeur.
Parallèlement, une capacité matérielle supérieure aux besoins réels (à tous les niveaux, des processeurs aux alimentations redondantes) peut entraîner un gaspillage considérable. Étant donné la culture opposée au risque qui règne dans la plupart des services informatiques, une capacité excédentaire est la norme. La décision la plus sûre est de disposer d'une capacité matérielle excédentaire, même si ce n'est pas nécessairement la décision la plus sage d'un point de vue financier. Toutefois, si l'énergie est un facteur clé, elle est généralement négligée dans les calculs des coûts du cycle de vie. Malheureusement, les encouragements à acheter des solutions efficaces sont inexistants, car il n'y a aucun avantage de coût pour les décideurs après le déploiement.
Il faut toutefois arriver à un compromis. Le pendule penche de l'autre côté quand les dirigeants se rendent compte que seule une petite partie de la capacité du matériel du centre de données est utilisée et ils envisagent la consolidation des serveurs comme une façon de réduire les coûts. Il est beaucoup plus facile de calibrer des serveurs à l'avance plutôt que de tenter de consolider après le déploiement des serveurs.
Comme l'industrie informatique atteint un nouveau niveau de maturité, l'optimisation avec une réduction des coûts devient une priorité. La consommation d'énergie est un indicateur que les dirigeants peuvent utiliser pour mesurer l'efficacité des décisions prises à propos du cycle de vie du matériel informatique. AMD, Intel, et les OEM de serveurs et composants font tous référence à la performance par watt de leurs plates-formes. Les chiffres de performance par watt peuvent servir à calculer les coûts d'exploitation en utilisant la formule inverse : watts par unité de performance. Avec l'éventail de personnes impliquées dans le développement de solutions informatiques (des installations au développement d'applications en passant par les architectes, les unités d'opérations et les divisions), la performance par watt répond à la question « Qu'est-ce qu'on y gagne » et vous permet de comparer les solutions en termes d'efficacité énergétique.
Pourquoi est-il courant d'ignorer les coûts d'énergie et de négliger des décisions qui affectent les coûts d'exploitation et des installations ? Combien de centres de données fonctionnant à capacité réduite avez-vous vus en raison de contraintes d'alimentation et de refroidissement ? Il fut un temps où il était difficile de trouver suffisamment d'espace physique pour le centre de données. Aujourd'hui, cependant, le problème est d'avoir assez de capacité pour alimenter et refroidir tout l'équipement et de savoir dans combien de temps vous serez à court.

L'importance des systèmes de surveillance de la consommation énergétique
La consommation énergétique précise peut être difficile à mesurer. Comme je l'ai mentionné tout à l'heure, la plupart des entreprises cumulent tous les coûts d'énergie en un total plutôt que de ventiler la consommation pour des unités spécifiques. Cette méthode consistant à traiter l'énergie comme une partie des frais généraux fait penser que les coûts d'énergie ne peuvent pas être contrôlés par la division. Cependant, ceci est faux.
Un centre de données peut utiliser dix fois plus d'énergie par mètre carré que des bureaux standard et, par conséquent, même des améliorations mineures de l'efficacité dans les centres de données peuvent permettre de réaliser des économies substantielles. Il n'est donc pas surprenant que les économies soient la raison numéro 1 qui pousse les centres de données à implémenter des programmes d'économie d'énergie. Le problème est que la méthode la plus économique est généralement en place pour la facturation de la consommation d'énergie et les coûts mensuels des installations pour les opérations des centres de données sont cumulés. Les coûts sont ensuite alloués aux groupes en fonction de l'espace qu'ils occupent et/ou par connexion à un port ; cette approche donne une ventilation peu précise des vrais coûts pour l'exécution d'un équipement de centre de données particulier.
Il est rare qu'une organisation dispose d'un compteur mesurant la consommation d'énergie par périphérique de centre de données individuel, surtout parce que l'installation d'un système de mesure de la consommation et de rapport nécessite un investissement préalable significatif. Cependant, un investissement dans un tel système peut entraîner des économies à plus long terme.
Bien entendu, un système de surveillance de l'alimentation seul ne suffit pas : il vous faudra prévoir de quelle façon vous utiliserez les données recueillies pour mieux gérer la consommation d'énergie et avoir au final un retour sur votre investissement. Étudions l'exemple de la société canadienne Abitibi Consolidated, le plus grand producteur au monde de journaux et produits en papier. En 2001, lors de la dérégulation du marché de l'alimentation électrique de l'Ontario, Abitibi Consolidated a dû faire face à une fluctuation des prix du marché et de la disponibilité. Pour optimiser ses achats d'énergie, l'entreprise implémenta un système de surveillance et de mesure de la consommation. Le nouveau système s'est rentabilisé en quelques mois, grâce à une économie de 1 % que l'entreprise a réalisée simplement en achetant son énergie plus efficacement.
Quelle quantité d'énergie devez-vous économiser pour justifier une mise à niveau de la surveillance de la consommation énergétique dans votre centre de données ? Bill Laing, directeur général du développement de Windows Server® 2008 chez Microsoft, a expliqué dans un entretien récent que la nouvelle version de Windows Server avec activation par défaut des économies d'énergie pouvait permettre jusqu'à 20 % de réduction, soit des économies importantes. (La figure 1 montre certaines des options d'alimentation disponibles dans Windows Server 2008 version bêta 3.) Notez, cependant, que les économies ne peuvent pas être calculées comme une réduction directe du coût de l'énergie consommée. Il y a plusieurs autres facteurs impliqués, notamment le coût de la création d'un nouveau centre de données et le nombre d'autres systèmes prenant actuellement en charge des configurations moins efficaces.
Figure 1 Options d'alimentation dans Windows Server 2008 version bêta 3
Figure 1 Options d'alimentation dans Windows Server 2008 version bêta 3
Á l'heure actuelle, vous pourriez sélectionner l'option Performances et puissance processeurs équilibrées sur le serveur dans Windows Server 2003 SP1. Mais sans un système de mesure de la consommation en place, vous ne pourrez pas quantifier les économies, ou d'autres facteurs impliqués dans la réalisation et la prise en charge de cette modification.
Notez également que, pour un grand nombre de centres de données, la consommation en énergie ne varie généralement que de 4 % dans une période donnée de 24 heures, ce qui indique que la consommation ne dépend pas de la charge. Avec les innovations récentes des fournisseurs de matériel, ce résultat est en train de changer pour les nouveaux équipements et la quantité d'énergie consommée diminue sous des charges moindres.

Définition du centre de données écologique
On pourrait remplir des pages et des pages avec les critères ou caractéristiques qui rendent un centre de données écologique. Bien sûr, je ne peux pas tout couvrir dans cet article, mais je souhaite souligner certaines caractéristiques clés que vous devriez garder à l'esprit si vous envisagez sérieusement d'implémenter un centre de données écologique. Même si vous en êtes seulement au stade de la planification, vous pouvez comparer avec cette liste pour déterminer où se trouve votre centre de données actuellement :
  1. Des compteurs sont utilisés pour décomposer la consommation d'énergie au niveau des composants (tels qu'un serveur 2 unités, un serveur 4 unités, un commutateur, un réseau SAN et un onduleur) et quelles divisions sont facturées pour l'électricité utilisée par ces composants.
  2. La consommation d'énergie est contrôlée en continu pour déterminer les pics et les creux de la demande énergétique.
  3. Les capacités énergétiques sont contrôlées au niveau de l'ensemble du centre de données jusqu'aux circuits pour assurer que tous les circuits sont dans les limites acceptables.
  4. Le plan d'économie d'énergie est documenté et récompensé.
  5. Le plan d'économie d'énergie est révisé régulièrement et des mesures adaptées sont prises pour répondre aux défaillances.
  6. En déterminant comment les coûts sont facturés aux divisions, il est possible d'affiner le comportement et d'encourager des économies d'énergie au sein des divisions individuelles. Ce point doit être mis en œuvre au niveau exécutif.
  7. La limitation des processeurs est activée sur les serveurs et le laboratoire de performances mesure la plage d'énergie consommée sous diverses charges.
  8. Le profilage thermique sert à identifier les points chauds et les refroidissements excessifs.
  9. L'ingénierie des performances informatiques inclut des mesures de l'efficacité énergétique.
  10. Des données actives sont à la disposition des organisations individuelles et leur permettent de réagir de manière appropriée. (California ISO va même jusqu'à fournir des données en temps réel au public sur son site Web, comme l'illustre la figure 2.)
Figure 2 Le site Web de California ISO fournit un instantané en direct qui inclut la demande actuelle et le niveau actuel de conservation requis de ses clients
Figure 2 Le site Web de California ISO fournit un instantané en direct qui inclut la demande actuelle et le niveau actuel de conservation requis de ses clients
Plus le nombre de caractéristiques que vous avez en place est élevé, plus vous êtes près de gérer avec succès un système de surveillance de la consommation énergétique avancé. J'ai inclus une fiche d'évaluation (voir la figure 3) avec huit questions que vous pouvez vous poser pour savoir quel est le niveau actuel de votre centre de données : basique, intermédiaire ou avancé.
Figure 3 Votre centre de données est-il écologique ? (Close Figure 3)

Niveau | Question
Basique | Examinez-vous votre facture mensuelle d'électricité ?
Vérifiez-vous régulièrement votre équipement électrique pour la planification de la capacité ?
Intermédiaire | Disposez-vous de compteurs et de rapports automatisés pour la charge et la consommation des circuits électriques ?
Vérifiez-vous l'efficacité énergétique de l'équipement au moment de l'achat ?
Avancé | Contrôlez-vous la consommation d'énergie par rack, périphérique et circuit ?
Analysez-vous la surveillance et les rapports de données historiques ?
Utilisez-vous des rapports en temps réel de consommation d'énergie pour permettre aux différents services de comprendre les impacts des modifications et des déploiements ?
Utilisez-vous les données pour négocier des taux d'énergie favorables avec l'entreprise d'électricité ?

Savoir, c'est déjà gagner la bataille à moitié
Autre problème : la normalisation à l'échelle de l'organisation. Pour réaliser un changement comme celui que j'ai décrit dans cet article (un changement qui modifie le paradigme selon lequel l'énergie est mesurée et qui implique la participation des divisions à l'échelle de l'organisation), il faut que les groupes d'installations à travers plusieurs centres de données travaillant avec une plus grande série de groupes informatiques s'alignent. Ce type de problème d'organisation est l'obstacle majeur à la mise en place d'un programme d'économie d'énergie.
Il est important de s'assurer que vous avez une seule personne ou équipe chargée de comprendre la consommation d'énergie sur l'ensemble des centres de données. Ce centre de connaissances (qui manque à la plupart des entreprises lorsqu'il s'agit de la consommation d'énergie) est essentiel. Il importe également que vos outils recueillent des données des installations disparates d'une manière uniforme et qu'ils rapportent les résultats à chaque division d'une façon cohérente (la figure 4 affiche un exemple de tableau de bord pour les rapports de données).
Figure 4 Exemple de tableau de bord de surveillance des données globales (avec l'aimable autorisation d'OSIsoft)
Figure 4 Exemple de tableau de bord de surveillance des données globales (avec l'aimable autorisation d'OSIsoft)
Sans les bons instruments, vous ne saurez pas si vous fonctionnez vraiment efficacement et les divisions individuelles ne sauront pas non plus si leurs efforts portent leurs fruits. Si vous souhaitez vraiment modifier le comportement humain, vous devez donner des informations en temps réel aux utilisateurs avec les tendances des données historiques afin qu'ils puissent visualiser les résultats de leurs actions. Vous ne pouvez pas récompenser des groupes efficacement pour leurs accomplissements en matière d'efficacité énergétique si chaque division repose sur un système différent, utilisant une série d'outils différente et des mesures différentes pour rendre compte de leur succès.

Forces du secteur
Vous n'êtes pas seul à essayer de rendre votre société plus écologique. Des leaders d'autres marchés (des sociétés telles que Boeing et Toyota aux agences gouvernementales telles que l'État de Californie) réalisent de sérieux investissements pour améliorer le rendement énergétique de leurs opérations et produits.
Quant au monde de l'informatique, en 2006, la Chambre des représentants des États-Unis a passé une loi (H.R. 5646, maintenant loi de droit public 109-431) pour demander à l'EPA (Environmental Protection Agency) d'examiner les coûts d'énergie et la consommation d'électricité par serveur et centre de données et les effets potentiels d'un transfert vers des systèmes à faible consommation. L'étude, qui a été exécutée par ENERGY STAR, un programme EPA, prévoyait une croissance à court terme de la consommation d'énergie par les serveurs informatiques et les centres de données américains, évaluait un coût et des économies d'énergie potentiels associés à des améliorations de l'efficacité énergétique des serveurs informatiques et centres de données et estimait des incitations potentielles et des programmes volontaires pour les serveurs informatiques et les centres de données à faible consommation. Les conclusions de l'étude ont été présentées au Congrès en août 2007. Vous trouverez plus d'informations sur cette étude sur le site energystar.gov.
De nouvelles normes de construction sont également en cours de développement pour des bâtiments écologiques. Ces normes requièrent des critères tels que des capacités de sous-contrôle toutes les heures pour les circuits selon leur fonction et la consommation d'énergie, la création de compteurs qui communiquent les données de consommation d'énergie à un système de gestion des données du compteur et des systèmes de gestion des données de compteur qui stockent les données et créent des rapports montrant la consommation d'énergie horaire, quotidienne, mensuelle et annuelle calculée pour chaque compteur. Plusieurs de ces critères sont nécessaires pour les systèmes de conformité si vous vous inscrivez à des programmes d'économie d'énergie où vous devez prouver que vos changements ont porté leurs fruits (par exemple, les crédits d'énergie renouvelable, les crédits de carbone et les programmes de réduction d'énergie).
Certains utilisateurs ont demandé des tests de spécification, mais il est difficile de représenter le spectre d'utilisation. Des tentatives sont en cours pour standardiser les tests, mais ces tests (comme la plupart des autres tests de performances) peuvent être utilisés pour optimiser les résultats « perçus », qui ne représentent pas le véritable usage. Considérez les miles par gallon (MPG), par exemple. Les notations EPA estiment les miles par gallon qu'un conducteur classique doit parcourir dans des conditions de ville et de route standard. Cependant, la plupart des conducteurs et des environnements ne sont pas standard et les facteurs qui affectent l'efficacité du carburant peuvent varier de manière significative. Ces recommandations s'appliquent également aux économies d'énergie dans le centre de données. Les seuls résultats précis pour votre organisation proviendront des mesures des économies d'énergie dans votre propre environnement.

Où sont les économies ?
Il faut tenir compte de plusieurs facteurs pour déterminer les économies. Savez-vous à combien revient l'ajout d'énergie dans une zone donnée ? Avez-vous une stratégie pour réduire les contraintes énergétiques ? Pouvez-vous résoudre le problème en plaçant vos centres de données à un endroit où l'électricité est moins chère ? Ou devez-vous vous concentrer sur l'amélioration des opérations dans vos installations existantes ?
Pour certaines entreprises, la meilleure façon de réduire les coûts peut être de déplacer les centres de données vers des zones où les sources d'électricité sont meilleur marché. La virtualisation des serveurs offre une autre approche pour la réduction de la consommation. En fait, certaines entreprises d'électricité (PG&E, SoCal Edison et SDG&E, pour n'en citer que quelques-unes) offrent des incitations financières aux clients qui entreprennent des projets de virtualisation des serveurs se traduisant par une réduction de l'équipement en serveurs.
Mais il y a des mesures plus simples, moins radicales que vous pouvez prendre. La plupart des services informatiques n'ont actuellement aucune idée du niveau de la consommation d'énergie de leurs systèmes et cela signifie qu'il y a une opportunité énorme d'économies potentielles. Vous pourriez commencer par examiner la consommation d'énergie associée aux périphériques individuels et voir ensuite s'il y a des modifications que vous pourriez apporter pour chaque périphérique. Plusieurs petites modifications peuvent représenter des économies substantielles.
À titre de comparaison, songez au ménage typique où le propriétaire n'a aucune idée de la quantité d'énergie que consomme chaque objet dans sa maison ; il se contente de payer sa facture totale mensuelle. Vous pouvez acquérir un petit appareil peu coûteux, par exemple un Kill A Watt, pour mesurer la consommation d'énergie des appareils individuels. Combien dépensez-vous pour garder votre micro-ondes alimenté lorsque vous ne l'utilisez pas ? Quelle est la quantité d'énergie consommée lorsque votre chargeur de téléphone reste branché ? En suivant cette approche, vous pouvez ajouter des compteurs d'alimentation à des racks et recueillir des données de divers périphériques. Des outils de gestion peuvent être utilisés pour recueillir des données directement sur certains serveurs avec des Interruptions SNMP de la consommation d'énergie.

Mise en route
La figure 5 présente les méthodes recommandées que vous devriez suivre pour faire avance votre projet. À ce stade, vous devez vraiment comprendre que vous n'êtes pas forcé de choisir entre les deux extrêmes. Vous pouvez opter pour une approche plus équilibrée, ce qui est sans doute plus réaliste. Commencez au niveau local, en identifiant dans votre entreprise les individus qui sont fanatiques des économies d'énergie. Commencez par mesurer certains périphériques dans une division pour vous faire une idée. En créant une impulsion et en montrant des résultats quantifiables, vous pourrez mieux obtenir le soutien dont vous avez besoin pour développer l'investissement de l'entreprise dans sa transformation écologique.
Figure 5 Clés de la mise en place d'un plan d'économie d'énergie (Close Figure 5)

Recueillez les données manuellement pour déterminer l'état de vos systèmes actuels. Déterminez la quantité d'énergie consommée par les périphériques et les applications et ventilez les coûts.
Créez un système de retour en boucle fermée pour mesurer l'efficacité des modifications effectuées.
Veillez à surveiller la consommation d'électricité aux bons endroits et au niveau approprié (par périphérique, organisation informatique, division, application et ainsi de suite).
Créez un fonds pour les projets d'économie d'énergie afin de fournir un apport de capitaux.
Découvrez quels sont les membres de votre organisation qui peuvent aider à encourager l'efficacité énergétique et faites-les participer.
Quels seront les individus moteurs de l'efficacité énergétique dans votre entreprise ? S'agit-il des dirigeants, des cadres moyens ou des individus qui se soucient tout simplement de l'impact qu'a votre entreprise sur l'environnement. Il y a des individus passionnés dans chaque entreprise. Vous devez décider si vous allez opter pour la méthode au niveau local et impliquer ces personnes dès le début.
En fin de compte, quel que soit votre choix, pour planifier un programme d'efficacité énergétique pour votre centre de données, vous aurez besoin de la collaboration de tous les groupes du département informatique. Jusqu'à récemment, l'approche type de la planification des solutions informatiques consistait à ignorer les coûts de l'alimentation très tôt dans la phase de conception pour se concentrer sur les achats de matériel et logiciels, ainsi que sur les coûts de main d'œuvre et d'hébergement de la solution. Lorsque l'énergie est enfouie dans les frais généraux d'exécution des solutions dans un centre de données, l'efficacité énergétique est une priorité basse. L'exposition de la consommation énergétique actuelle des solutions constitue la première étape cruciale dans la modification du comportement de votre organisation.

Dave Ohara a 26 ans d'expérience en technologie ; il a travaillé pour des sociétés telles que Microsoft, Apple et Hewlett-Packard. Touchant au développement des produits, au marketing, à la promotion des technologies, à l'architecture des infrastructures, à l'ingénierie des procédés, à l'ingénierie de la fiabilité et à la logistique de distribution, Dave collabore maintenant avec plusieurs entreprises implémentant des initiatives écologiques.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 Administration de Windows: Guide de r&#233;plication Active&#160;Directory
Administration de Windows Laura E. Hunter

Guide de réplication Active Directory
Vue d'ensemble:
  • Transition vers Active Directory
  • Maintien de la cohérence
  • Gestion de la résolution des conflits
  • Modifications apportées à Windows Server 2008

Avant l'arrivée de Windows 2000 Server et d'Active Directory, de nombreux environnements d'entreprise s'appuyaient sur Windows NT pour l'infrastructure de serveur et la gestion des identités et des
accès. À l'époque de son lancement, Windows NT® 4.0 constituait une solution solide dans l'offre de systèmes d'exploitation réseau (NOS), mais présentait un certain nombre d'inconvénients qui rendaient difficile le déploiement dans une grande entreprise.
Pour commencer, Windows NT utilisait un espace de noms plat pour enregistrer les ressources réseau, ce qui signifiait qu'il n'existait pas de bonne méthode de séparation des ressources en sous-ensembles plus petits ou de configuration d'une administration granulaire. Vous ne pouviez pas, par exemple, configurer un conteneur départemental pour les ressources de votre service de marketing ou configurer un administrateur local disposant des droits de réinitialisation des mots de passe pour les utilisateurs de ce département uniquement. Ainsi, la sécurité de Windows NT était en général soit très forte, soit inexistante ; pour déléguer des tâches administratives à un technicien du support des ordinateurs de bureau, vous deviez souvent accorder bien plus d'autorisations que vous ne le souhaitiez.
De plus, Windows NT stockait toutes ses informations dans une base de données de gestionnaire de comptes de sécurité (SAM) dont la capacité était limitée à 40 Mo. Si votre base de données SAM dépassait ce maximum recommandé (entre 25 000 et 40 000 objets, selon votre configuration), vous deviez fractionner votre environnement en plusieurs domaines distincts, ce qui compliquait l'administration du réseau et l'attribution d'accès aux ressources aux utilisateurs. Chaque domaine NT contenait un contrôleur de domaine principal (PDC) unique, lequel contenait la seule copie en lecture/écriture de la base de données SAM. Bien qu'il fût possible de déployer un ou plusieurs contrôleurs de domaine de sauvegarde (BDC), ces BDC étaient en lecture seule et ne pouvaient pas exécuter de mises à jour requérant une opération d'écriture, telles que la modification du mot de passe d'un utilisateur.
Enfin, Windows NT s'appuyait sur la résolution de nom NetBIOS, qui était basée sur la diffusion et générait souvent un trafic élevé lorsque les utilisateurs recherchaient des ressources réseau, en particulier s'ils utilisaient une connexion WAN lente ou lourdement utilisée.

Apparition d'un nouveau modèle
En 2000, Microsoft lançait Windows® 2000, qui comprenait une révision substantielle de ses produits NOS précédents. Le nouveau service NOS, Active Directory®, était aussi différent de Windows NT que vous pouviez l'imaginer. Au lieu de s'appuyer sur un espace de noms plat, Active Directory était construit sur la norme X.500, qui créait une structure organisationnelle hiérarchique ; vous pouviez dès lors organiser les ressources en plusieurs unités d'organisation dans un seul domaine et déléguer l'administration de chaque unité à un niveau basé sur les tâches.
Le nouveau modèle de réplication multimaître représentait une autre divergence importante par rapport à Windows NT. Terminé le PDC inscriptible unique et ses BDC associés ; dans Active Directory, chaque contrôleur de domaine avait la possibilité d'écrire dans la base de données Active Directory.
Cependant, bien que ce nouveau modèle offrît beaucoup plus de flexibilité en termes de prise en charge des environnements de grande taille et/ou décentralisés, il créait également de nouvelles difficultés au niveau de la conservation de l'intégrité d'Active Directory. Si John Smith et Jane Dow modifient un même objet depuis des bureaux distants, que se passe-t-il si ces modifications sont contradictoires ? Le modèle de réplication Active Directory définit les méthodes de communication des mises à jour à tous les contrôleurs de domaine dans un environnement, ainsi que la gestion des conflits générés par cette possibilité de modification multimaître depuis pratiquement n'importe où.

Mécanique de la réplication Active Directory
Dans ces exemples, nous aborderons uniquement la réplication intrasite. En général, la réplication intrasite est conçue pour répliquer des modifications rapidement sur des contrôleurs de domaine d'un même site, et est exécutée à l'aide de la notification de modification. Dans le cas de la réplication intrasite, DC1 notifie DC2 des modifications à répliquer, de sorte que DC2 puisse extraire ces modifications de DC1. De même, DC2 notifie DC1 lorsque des modifications ont été apportées, de sorte que DC1 puisse extraire ces modifications de DC2. Comme vous pouvez le voir, toute réplication Active Directory se fait par des opérations d'extraction et non par des opérations d'envoi.
Active Directory peut s'étendre à des centaines de milliers ou même des millions d'objets. Il est donc nécessaire de découper la base de données Active Directory en sections, appelées des contextes de nommage. Au minimum, chaque contrôleur de domaine stocke trois contextes de nommage dans sa copie locale de la base de données Active Directory.
Contexte de nommage de schéma Ce contexte de nommage est répliqué dans chaque contrôleur de domaine de la forêt. Il contient des informations sur le schéma Active Directory, qui à son tour définit les différentes classes et attributs d'objet dans Active Directory.
Contexte de nommage de configuration Également répliqué dans tous les contrôleurs de domaine de la forêt, ce contexte de nommage contient les informations de configuration se rapportant à la disposition physique d'Active Directory, ainsi que des informations sur les spécificateurs d'affichage et les quotas Active Directory de la forêt.
Contexte de nommage de domaine Ce contexte de nommage est répliqué dans tous les contrôleurs de domaine d'un seul domaine Active Directory. Le contexte de nommage suivant contient les données Active Directory les plus utilisées : les utilisateurs, groupes, ordinateurs et autres objets qui résident effectivement dans un domaine Active Directory particulier.
Afin d'améliorer le trafic de réplication, chaque contexte de nommage est répliqué séparément de sorte qu'un contexte de nommage rarement modifié, tel que le contexte de nommage de schéma, n'utilise pas de bande passante de réseau, requise par le contexte de nommage de domaine, qui de son côté change plus fréquemment.
Dans la mesure où les modifications d'annuaire peuvent être apportées depuis n'importe quel contrôleur de domaine Active Directory, la réplication Active Directory doit suivre deux types d'opérations d'écriture. Le premier concerne les écritures d'origine, c'est-à-dire lorsqu'une modification particulière est apportée directement sur un contrôleur de domaine particulier. Par exemple, si vous vous connectez à DC1 et modifiez le mot de passe d'un utilisateur, cette modification équivaut à une écriture d'origine sur DC1. Active Directory doit également suivre les écritures répliquées. Comme vous pouvez l'imaginer, cela signifie qu'une modification particulière a été répliquée depuis un autre contrôleur de domaine. La modification considérée comme une écriture d'origine sur DC1 est considérée comme une écriture répliquée lorsque cette modification est répliquée dans DC2, DC3 et autres contrôleurs de domaine à travers le domaine.
Les contrôleurs de domaine Active Directory gèrent la transmission des modifications d'annuaire à l'aide de métadonnées de réplication. Cela signifie que, outre la communication des données réelles qui ont été modifiées d'un contrôleur de domaine à un autre (la description de John Smith a été modifiée en Directeur de RH), Active Directory transmet des informations supplémentaires sur cette modification pour permettre aux contrôleurs de domaine de gérer la réplication de la manière la plus efficace, par exemple, le contrôleur de domaine d'origine de la modification, l'heure de la modification et d'autres éléments d'information clé.
Le premier article de réplication de métadonnées que nous aborderons est le numéro de séquence de mise à jour (USN). Chaque contrôleur de domaine maintient un numéro de séquence de mise à jour qui lui est propre. Lorsqu'une modification est apportée à Active Directory depuis ce contrôleur de domaine, le numéro de séquence de mise à jour est incrémenté de 1. Ainsi, si un contrôleur de domaine a un USN de 1 000 à 11h00 du matin et de 1005 à 11:30 heures du matin, vous savez que 5 modifications ont été apportées à la base de données Active Directory sur ce contrôleur de domaine. La nature exacte de ces modifications est sans importance en ce qui concerne le numéro de séquence de mise à jour ; vous auriez pu modifier 5 objets différents, créer 5 objets, supprimer 5 objets ou n'importe quelle autre combinaison. Le numéro de séquence de mise à jour du contrôleur de domaine augmentera toujours de 5. De plus, les numéros de séquence de mise à jour sont internes à un seul contrôleur de domaine spécifique et n'ont aucune importance lorsqu'ils sont comparés à d'autres contrôleurs de domaine. Un contrôleur de domaine d'un domaine pourrait apporter une modification à 11h30 du matin et attribuer un USN de 1051, et un second contrôleur de domaine du même domaine pourrait apporter une modification précisément au même moment et attribuer un USN de 5084. Bien que ces deux contrôleurs de domaine aient clairement des numéros de séquence de mise à jour radicalement différents pour une modification apportée environ au même moment, il n'est pas important de savoir comment ces modifications sont répliquées ; le numéro de séquence de mise à jour d'un contrôleur de domaine n'a aucune signification pour les autres contrôleurs de domaine en termes de comparaison des modifications.
Mais ceci n'est pas le seul moyen d'incrémenter un numéro de séquence de mise à jour de contrôleur de domaine. N'oubliez pas qu'une modification apportée à la base de données Active Directory peut consister en une écriture d'origine ou en une écriture répliquée. Le numéro de séquence de mise à jour sur un contrôleur de domaine est incrémenté par les deux types d'opération d'écriture, ce qui signifie qu'il est incrémenté lorsque des modifications sont répliquées depuis un autre contrôleur de domaine. Il est clair que les contrôleurs de domaine doivent avoir un moyen de suivre les modifications déjà répliquées pour éviter d'envoyer la base de données entière à chaque réplication. Pour empêcher cela, chaque contrôleur de domaine Active Directory maintient une valeur de référence appelée HWMV (High Watermark Vector) pour les autres contrôleurs de domaine avec lesquels il effectue la réplication. Chaque contrôleur de domaine pourra associer cette valeur HWMV à l’identificateur global unique (GUID) du contrôleur de domaine distant pour empêcher la confusion si un contrôleur de domaine distant est renommé ou supprimé de l'annuaire.
Commençons par un exemple simple, dans lequel vous disposez de deux contrôleurs de domaine configurés dans le domaine contoso.com, dc1.contoso.com et dc2.contoso.com. Puisqu'il n'y a que deux contrôleurs de domaine dans le domaine contoso.com, DC1 et DC2 effectuent la réplication entre eux seulement. (Notez qu'il s'agit ici d'un exemple simplifié qui n'illustre pas toutes les possibilités de la réplication Active Directory ; nous approfondirons cet exemple à mesure que nous avançons).
Précisons en outre que l'USN actuel de DC1 est 3000, que l'USN actuel de DC2 est 4500, et que ces deux contrôleurs de domaine sont entièrement à jour l'un par rapport à l'autre lorsque nous commençons notre exemple :
Étape 1 : DC1 et DC2 sont à jour l'un par rapport à l'autre. DC1 a une valeur HWMV pour DC2 de 4500, et DC2 a une valeur HWMV pour DC1 de 3000, comme illustré à la figure 1.
Figure 1 État actuel de deux contrôleurs de domaine
Figure 1 État actuel de deux contrôleurs de domaine
Étape 2 : Un administrateur crée un objet sur DC1, et l'USN de DC1 est incrémenté à 3001, comme illustré à la figure 2. Notez que le HWMV de DC1 n'a pas changé sur DC2, car DC1 pas encore notifié DC2 que des modifications sont en attente.
Figure 2 Un nouvel objet est ajouté.
Figure 2 Un nouvel objet est ajouté.
Étape 3 : DC1 notifie DC2 que des modifications sont disponibles. DC2 initie alors la réplication avec DC1 pour demander les mises à jour disponibles. Dans le cadre de cette requête, DC2 envoie à DC1 la valeur HWMV qu'il a stockée pour DC1, comme illustré à la figure 3.
Figure 3 Notification de modification
Figure 3 Notification de modification
Étape 4 : DC1 envoie à DC2 la modification qui correspond à l'USN 3001, c'est-à-dire l'objet qui a été créé sur DC1 à l'étape 2. DC2 met à jour son propre USN à 4501 et son HWMV pour DC1 à 3001, comme illustré à la figure 4.
Figure 4 Modifications et mises à jour
Figure 4 Modifications et mises à jour
Jusque-là, tout va bien. Mais, maintenant, il y a un problème. DC2 a une modification qu'il a besoin de répliquer. S'il ne fallait pour continuer que des USN et des valeurs HWMV, à ce stade, DC2 contacterait DC1 pour répliquer la même modification dans DC1 que DC1 vient de répliquer dans DC2. Cela créerait un cycle de réplication infini et utiliserait de plus en plus de bande passante. Pour éviter cela, nous devons ajouter d'autres pièces au puzzle. La première est le vecteur de mise à jour (vecteur UTD ou simplement UTDV).
L'UTDV est une autre métadonnée de réplication, utilisée pour le blocage de la propagation, c'est-à-dire que le but est d'empêcher qu'une même modification n'utilise inutilement de la bande passante par des réplications répétées à l'infini sur le réseau. Chaque contrôleur de domaine maintient une table d'UTDV pour chaque autre contrôleur de domaine qui stocke une réplication du contexte de nommage en question. Pour le contexte de nommage de domaine, chaque contrôleur de domaine d'un domaine maintient un UTDV pour chaque contrôleur de domaine du domaine. Pour le contexte de nommage de configuration et de schéma, l'UTDV est maintenu pour chaque contrôleur de domaine de la forêt. La table d’UTDV assure le suivi non seulement de l'USN le plus élevé que chaque contrôleur de domaine a reçu de ses partenaires de réplication, mais également de la valeur d'USN la plus élevée qu'il a reçue de chaque contrôleur de domaine qui réplique un contexte de nommage donné. Pour faciliter cela, chaque modification répliquée inclut également les informations suivantes :
  • Le GUID du contrôleur de domaine qui réplique la modification. Il peut s'agir d'une modification qui est répliquée en tant qu'écriture d'origine ou qu'écriture répliquée.
  • L'USN du contrôleur de domaine qui réplique la modification. Encore une fois, il peut s'agir d'une modification répliquée en tant qu'écriture d'origine ou qu'écriture répliquée.
  • Le GUID du contrôleur de domaine d'origine de la modification. Si ce GUID est identique au GUID du contrôleur de domaine qui réplique la modification, il s'agit alors d'une écriture d'origine. Dans le cas contraire, la table d'UTDV entre en jeu.
  • L'USN du contrôleur de domaine d'origine de la modification. Si cet USN est identique à l'USN du contrôleur de domaine qui réplique la modification, il s'agit alors d'une écriture d'origine. Dans le cas contraire, la table d'UTDV est utilisée.
Pour mieux illustrer ce processus, nous augmentons la complexité de notre exemple en ajoutant un troisième contrôleur de domaine, DC3. Dans le cas présent, DC1, DC2 et DC3 sont tous des partenaires de réplication mutuels ; DC1 réplique avec DC2 et DC3, DC2 avec DC1 et DC3, et DC3 avec DC1 et DC2 :
Étape 1 : DC1, DC2 et DC3 sont à jour les uns par rapport aux autres.
Étape 2 : DC3 exécute une écriture d'origine unique en réinitialisant le mot de passe pour le compte utilisateur jsmith. DC3 notifie DC1 et DC2 que des modifications sont disponibles. DC1 et DC2 extraient l'écriture d'origine de DC3, puis mettent à jour leurs tables HWMV et UTDV pour DC3, comme illustré à la figure 5.
Figure 5 Mise à jour des tables HWMV et UTDV
Figure 5 Mise à jour des tables HWMV et UTDV
Étape 3 : C'est ici qu'entre en jeu le vecteur de mise à jour. DC2 notifie DC1 que des modifications sont disponibles. DC1 contacte alors DC2 et demande les nouvelles modifications en envoyant à DC2 les informations suivantes :
  • Valeur HWMV de DC1 pour DC2, dans ce cas 4501.
  • Table d'UTDV de DC1 (illustrée à la figure 6), indiquant l'USN d'origine le plus élevé qu'il a reçu de tous les contrôleurs de domaine, y compris DC3.
Figure 6 Table UTDV (Close Figure 6)

Tous les contrôleurs de domaine qui répliquent ce contexte de nommage | UTDV
<GUID de DC2> | 4501
<GUID de DC3> | 7002
Sur la base de la valeur HWMV de 4501, DC2 voit qu'il n'a pas répliqué la modification en question dans DC1 (voir la figure 7).
Figure 7 Une modification doit être répliquée (Close Figure 7)

Propriété | Valeur | GUID du contrôleur de domaine local | USN local | GUID du contrôleur de domaine d'origine | USN d'origine
Propriété Password de jsmith | %#FH%2rfg2 | <GUID de DC2> | 4501 | <GUID de DC3> | 7002
Cependant, sur la base de la table d'UTDV que DC1 a transmise avant le début de la réplication, DC2 détermine que DC1 ne requiert pas cette modification, puisque DC1 a déjà reçu cette modification de DC3. À ce stade, DC1 met simplement à jour son entrée HWMV pour DC2 afin de refléter l'USN incrémenté, comme illustré à la figure 8. Toutefois, pour conserver la bande passante, les données ne sont pas transmises en ligne.
Figure 8 Blocage de la propagation
Figure 8 Blocage de la propagation
Étape 4 : Ce même blocage de la propagation a lieu lorsque DC2 notifie DC3 que des modifications sont disponibles, et lorsque DC1 notifie DC2 et DC3. Les trois contrôleurs de domaine mettent à jour leurs entrées HWMV respectives pour leurs partenaires de réplication, comme illustré à la figure 8, mais les données réelles ne sont pas transmises à nouveau puisqu'elles ont déjà été transmises à chaque contrôleur de domaine à l'étape 2.

Résolution des conflits dans un environnement multimaître
Jusqu'à présent, nos exemples représentaient des situations où un seul administrateur apportait des modifications à un contrôleur de domaine à la fois et où personne d'autre n'intervenait. Dans la réalité, nous savons que ce cas est rare. Les mises à jour appliquées à un objet Active Directory pouvant venir de n'importe quel contrôleur de domaine du domaine, que se passe-t-il si deux administrateurs effectuent des mises à jour contradictoires depuis deux contrôleurs de domaine différents ? Trois types de conflits peuvent survenir dans un environnement Active Directory, et chacun de ces conflits utilise une méthode de résolution différente.
Modifications de propriétés contradictoires . Ce conflit survient si deux administrateurs mettent à jour le même objet de façon contradictoire : un administrateur définit une description de l'utilisateur sur « Marketing », alors qu'un autre sur un contrôleur de domaine différent la définit sur « Ventes et marketing ».
Création d'objets contradictoires . Ce conflit survient si deux administrateurs créent un objet avec le même nom à la même heure, par exemple deux utilisateurs nommés jsmith.
Transfert d'un objet dans un conteneur supprimé . Ce type de conflit est beaucoup plus rare et survient si un administrateur crée ou déplace un objet dans un conteneur, tel qu'une UO, en même temps qu'un autre administrateur sur un contrôleur de domaine différent supprime ce conteneur.
Pour résoudre les deux premiers types de conflit, il est temps de présenter deux autres éléments de métadonnées de réplication qui sont essentiellement utilisés pour la résolution des conflits. La valeur versionID est attribuée à chaque attribut individuel sur un objet, avec une valeur de début de 1 lorsque l'objet est créé. La valeur versionID est incrémentée de 1 lorsqu'un attribut individuel est modifié depuis un contrôleur de domaine quelconque. Ainsi, si l'attribut de description d'un utilisateur particulier est mis à jour de sa valeur par défaut (vide ou <not set>) à « Service de marketing » l'attribut de description aura une valeur de versionID de 2. Si la description est modifiée plus tard en « Service de ventes et marketing », l'attribut de description aura une valeur de versionID de 3, et ainsi de suite. Cette valeur versionID est associée à chaque entrée de réplication, avec les autres éléments de métadonnées que nous avons déjà présentés.
La valeur versionID peut être également utilisée pour réduire le trafic de réplication. Par exemple, si un administrateur sur DC2 a apporté plusieurs modifications à un attribut (peut-être qu'il a fait une faute de frappe dans la modification plusieurs fois), si bien que DC2 a des écritures d'origine correspondant aux valeurs versionID 2, 3, 4 et 5, DC2 répliquera uniquement l'écriture qui correspond à la dernière valeur versionID, c'est-à-dire à versionID 5. Les modifications précédentes étant tout simplement remplacées, cela représente un raccourci pour réduire l'utilisation superflue de la bande passante.
Chaque modification apportée à Active Directory inclut également le second élément de métadonnées supplémentaire utilisé pour la résolution des conflits : l'horodatage, qui indique le moment où la modification a été effectuée.
L'attribut d'horodatage est également utilisé comme mesure dynamique de la l'intégrité de la réplication Active Directory. Si un contrôleur de domaine n'a pas vu de modification avec un horodatage relativement récent en provenance d'un contrôleur de domaine particulier, il commence à générer des messages d'erreur indiquant qu'il pourrait exister un problème au niveau du contrôleur de domaine en question.
Comment ces deux attributs sont-ils utilisés dans la résolution des conflits ? Examinons chaque type de conflit séparément.

Résolution des modifications de propriétés contradictoires
Considérons l'exemple de l'objet utilisateur jsmith du domaine contoso.com. Un administrateur sur DC1 modifie la description de jsmith en « Marketing ». Presque simultanément, un administrateur sur DC3 modifie la même description d'utilisateur en « Ventes et marketing ». À ce stade, les informations de DC1 et DC3 sur l'attribut de description de jsmith se présentent comme illustré à la figure 9.
Figure 9 Modifications presque simultanées (Close Figure 9)

Serveur | Propriété | Valeur | VersionID | Horodatage | GUID du contrôleur de domaine local | USN local | GUID du contrôleur de domaine d'origine | USN d'origine
DC1 | Propriété Description de jsmith | « Marketing » | 2 | 2007-06-07 14:03:25 | <GUID de DC1> | 3003 | <GUID de DC1> | 3003
DC3 | Propriété Description de jsmith | « Ventes et marketing » | 2 | 2007-06-07 14:04:57 | <GUID de DC3> | 7003 | <GUID de DC3> | 7003
Si DC2 reçoit les deux modifications simultanément, il devra déterminer la modification « gagnante ». L'ordre de résolution des conflits est le suivant :
  1. La modification qui présente la valeur de versionID la plus élevée sera acceptée comme la modification « gagnante » ; la modification « perdante » sera remplacée. En l'occurrence, la valeur de versionID est 2 pour les deux enregistrements, nous devons donc passer au critère de résolution suivant.
  2. Si les deux enregistrements présentent la même valeur de versionID, la modification qui présente la valeur d'horodatage la plus récente sera acceptée comme la modification « gagnante » ; la modification « perdante » sera remplacée. En l'occurrence, l'horodatage de l'écriture d'origine de DC3 est ultérieur, la description de jsmith sera donc définie sur « Ventes et marketing ». Dans le cas, rare, où la valeur de versionID et la valeur d'horodatage sont identiques, nous appliquons un troisième critère définitif :
  3. Si les deux enregistrements ont les mêmes valeurs de versionID et d'horodatage, l'écriture par le contrôleur de domaine avec le GUID le plus bas sera gagnante ; l'écriture du GUID le plus élevé sera remplacée. Donc si le GUID de DC1 est 1234567890 et le GUID de DC3 est 2345678901, l'écriture d'origine de DC1 est gagnante si la valeur de versionID et la valeur d'horodatage sont identiques.
Vous pensez probablement que ce serait plus judicieux de laisser l'horodatage faire loi. Mais cela n'est pas aussi simple. Si l'horodatage était le critère de résolution des conflits principal dans Active Directory, tout ce qu'un administrateur malveillant devrait faire pour propager ses modifications serait de retarder l'horloge sur un contrôleur de domaine particulier pour toujours faire passer ses modifications.

Résolution de la création d'objets contradictoires
Dans le cas où deux objets sont créés avec le même nom, Active Directory utilise les mêmes trois critères décrits dans la section précédente pour déterminer l'objet « gagnant ». Contrairement à la section précédente, toutefois, l'objet « perdant » n'est pas remplacé. Au lieu de cela, l'objet perdant est renommé avec les caractères CNF (pour conflit), suivis de deux points et du GUID de l'objet « perdant ». Cela permet aux administrateurs de déterminer plus méthodologiquement l'objet à retenir et l'objet à supprimer.

Résolution du transfert d'un objet dans un conteneur supprimé
Comme mentionné précédemment, la résolution du transfert d'un objet dans un conteneur supprimé est un conflit relativement rare qui survient uniquement dans l'un des deux scénarios suivants. Dans le premier scénario, un administrateur sur un contrôleur de domaine crée un objet dans un conteneur particulier, par exemple l'UO Formation, au même moment qu'un administrateur sur un autre contrôleur de domaine supprime l'UO Formation. Le second scénario peut survenir lorsqu'un administrateur sur un contrôleur de domaine déplace un objet dans un conteneur au même moment qu'un administrateur sur un autre contrôleur de domaine supprime ce conteneur.
Dans ce cas, la résolution est assez simple : Active Directory déplace l'objet « orphelin » dans un conteneur spécial d'Active Directory conçu à cet effet, le conteneur LostAndFound situé à la racine de chaque domaine Active Directory. Pour le domaine de contoso.com, le conteneur LostAndFound se trouverait sur le chemin LDAP suivant : LDAP://cn=LostAndFound,dc=contoso,dc=com. Si vous ne voyez pas le conteneur LostAndFound lorsque vous ouvrez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory, cliquez simplement sur Affichage | Fonctionnalités avancées.

Protection contre la fonction de restauration du numéro de séquence de mise à jour (USN)
L'une des situations les plus graves que vous puissiez rencontrer dans un environnement Active Directory est également la plus simple à éviter une fois vous en comprenez la cause et comment la traiter. La restauration du numéro de séquence de mise à jour (USN) est une condition d'erreur qui peut arrêter complètement la réplication sur votre réseau. Elle est provoquée par un contrôleur de domaine resté hors connexion trop longtemps puis remis en service, ou par la restauration d'un contrôleur de domaine à l'aide d'une méthode non prise en charge.
Une cause sous-jacente de la restauration du numéro de séquence de mise à jour concerne la méthode de suppression des objets dans l'environnement multimaître Active Directory. Lorsqu’un objet est supprimé sur un contrôleur de domaine, au lieu d'être simplement supprimé, il est désactivé (objet tombstone) afin de pouvoir être répliqué dans d'autres contrôleurs de domaine, les avertissant ainsi de la suppression. En particulier, un objet tombstone possède un attribut isDeleted qui est défini sur TRUE. Afin de réduire la taille de l'objet tombstone, la plupart des valeurs contenues dans l'objet, comme la description, les informations personnelles et l'appartenance de groupe d'un objet utilisateur, sont supprimées (pour plus d'informations sur ce processus, voir l'article de Gil Kirkpatrick « Réanimation des objets tombstone d'Active Directory », disponible en ligne à l'adresse technetmagazine.com/issues/2007/09).
La restauration du numéro de séquence de mise à jour peut survenir parce que ces objets tombstone ne subsistent pas indéfiniment. Ils sont complètement purgés de la base de données Active Directory après 60 ou 180 jours par défaut (selon la version de Windows Server® que vous exécutiez lors de la création de votre environnement Active Directory). Cette période de 60 à 180 jours est appelée durée de vie de désactivation. Tous les contrôleurs de domaine doivent être capables d'effectuer une réplication au moins une fois pendant cette période sans quoi ils deviennent pire qu'inutiles : ils créent une opportunité pour la restauration du numéro de séquence de mise à jour. Essentiellement, la restauration du numéro de séquence de mise à jour survient lorsqu'un contrôleur de domaine est tellement périmé qu'il a « manqué » un ou plusieurs objets tombstone et est incapable de mettre à jour sa copie locale de la base de données Active Directory sur celle des autres contrôleurs de domaine. Pour éviter cela, tout contrôleur de domaine qui est resté hors connexion plus longtemps que la durée de vie de désactivation ne doit pas être remis en marche ; il doit être reconstruit entièrement après suppression des métadonnées de l'ancien contrôleur de domaine d'Active Directory en suivant les étapes indiquées dans l'article de la Base de connaissances de Microsoft 216498 (support.microsoft.com/kb/216498).
La restauration du numéro de séquence de mise à jour survient également lorsqu'un contrôleur de domaine a été restauré par une méthode non prise en charge, en général en utilisant un outil de clonage de disque ou de capture d'image. Lorsque cela se produit, la base de données Active Directory restaurée ne se rend pas compte qu'elle « revient en arrière », car la méthode de restauration n'était pas compatible avec Active Directory. Dans Windows 2000 et dans la version préliminaire initiale de Windows Server 2003, il était difficile de détecter la restauration du numéro de séquence de mise à jour. Toutefois, Windows Server 2003 SP1, ainsi que le prochain Windows Server 2008 sont dotés de contrôles intégrés pour la détection des contrôleurs de domaine incorrectement restaurés. Dans ces versions de système d'exploitation plus récentes, un contrôleur de domaine enregistre les ID d'événement 1115, 2095, 2103 et 2110 dans le journal des événements des services d'annuaire. Le texte de ces événements, ainsi que les étapes nécessaires pour une récupération après restauration du numéro de séquence de mise à jour, sont disponibles dans l'article de la Base de connaissances 875495 (support.microsoft.com/kb/ 875495) pour Windows Server 2003. (Les informations sur la restauration du numéro de séquence de mise à jour dans Windows 2000 sont disponibles dans l'article de la Base de connaissances 885875, à l'adresse support.microsoft.com/kb/ 885875.)

Mise à jour du modèle multimaître dans 2008
Dans la version à venir de Windows Server 2008, Microsoft a apporté une modification mineure au modèle multimaître en introduisant le contrôleur de domaine en lecture seule (RODC). Le RODC est essentiellement conçu pour les déploiements de succursale, ou pour tout autre scénario sans équipe informatique dédiée. Il est nécessaire dans ces cas d'effectuer des étapes supplémentaires pour assurer l'intégrité d'un contrôleur de domaine particulier. Nous pourrions consacrer un article entier aux détails techniques du RODC, mais nous nous limiterons ici aux points importants que vous devez connaître.
Comme le nom l'indique, la copie de la base de données Active Directory qui réside sur un RODC est en lecture seule. Vous pouvez vous connecter à un RODC pour lire presque toutes les informations dont vous avez besoin, mais vous ne pouvez pas exécuter d'opération d'écriture.
De plus, un RODC n'exécute pas de réplication sortante. Cela représente une différence fondamentale avec le modèle de réplication multimaître que nous avons abordé jusqu'ici. Un RODC reçoit les réplications entrantes depuis d'autres contrôleurs de domaine Windows Server 2008 inscriptibles, mais il ne réplique aucune information vers d'autres contrôleurs de domaine. Cela crée une couche supplémentaire de sécurité, si bien que même si un utilisateur malveillant pouvait modifier Active Directory depuis le RODC, ces modifications ne se propageraient pas au reste de votre environnement.
Le plus intéressant est peut-être le fait que, par défaut, le RODC ne réplique pas les mots de passe utilisateur. Lorsque la base de données Active Directory est répliquée en entrée dans un RODC depuis un contrôleur de domaine inscriptible, tous les objets utilisateur sont répliqués sans les informations de mot de passe de l'utilisateur. Cela fournit encore une autre couche de sécurité dans un environnement de succursale, si bien que si un contrôleur de domaine « s'envole », il n'existe aucune information de mot de passe sur le disque dur du contrôleur de domaine. Dans l'ensemble, l'application de ces modifications à l'idée d'origine de la réplication Active Directory multimaître a créé un modèle beaucoup plus solide pour sécuriser les contrôleurs de domaine dans les succursales ou autres sites distants.

Laura E. Hunter a remporté quatre fois la récompense MVP de Microsoft pour la mise en réseau Windows Server. Elle travaille depuis dix ans dans l'industrie informatique et est l'auteur ou co-auteur de nombreux livres, articles et livres blancs, notamment Active Directory Cookbook, Second Edition (O'Reilly, 2006).


 System Center: Nouveaux outils de gestion des mises &#224; jour logicielles
System Center Steve Rachui

Nouveaux outils de gestion des mises à jour logicielles
Vue d'ensemble:
  • Anciennes méthodes de gestion des mises à jour
  • Nouveau processus de SCCM 2007
  • Configuration personnalisée et flexibilité
  • Planification avancée des mises à jour

La gestion des mises à jour logicielles a été introduite pour la première fois dans Systems Management Server (SMS) 2.0 avec les outils d’analyse des mises à jour de sécurité et d'Office. Ces outils ont subi plusieurs révisions : l'outil d'inventaire
des mises à jour de sécurité étendu prend désormais en charge l'analyse d'autres produits, l'outil d'inventaire pour les mises à jour Microsoft® combine les outils de sécurité et Office en un produit unique et l'outil d'inventaire pour les mises à jour Dell. L'outil de publication des mises à jour personnalisées a été également introduit pour prendre en charge la réparation de produits tiers. L'outil d'Inventaire pour les mises à jour Microsoft (ITMU) a à lui seul subi trois révisions. Chacun de ces outils présente ses propres catalogues, infrastructure d'analyse et exigences et difficultés. Les catalogues de ces systèmes se sont agrandis progressivement et sont devenus si grands, en fait, que les anciennes mises à jour ont été supprimées afin de libérer de la place pour les nouvelles.
Avec le tableau d'options, le déploiement des mises à jour à l'aide de ces outils pouvait être complexe. Une simplification du processus s'imposait donc. La prochaine version de SMS—System Center Configuration Manager 2007 (SCCM) représente un pas important dans cette direction. Avec SCCM, le mécanisme des mises à jour logicielles permet d'assurer de meilleurs résultats. Grâce à cette méthode de gestion des mises à jour entièrement différente, les anciens catalogues et moteurs d'analyse ne sont plus qu'un souvenir. L'état de mise à jour, habituellement signalé via l'inventaire matériel, utilise un nouveau mécanisme, le message d'état, pour assurer une meilleure détermination de la conformité et une meilleure mise en œuvre sur chaque client. Je pense que vous constaterez vous-même que la nouvelle approche de la gestion des mises à jour dans SCCM 2007 représente une amélioration considérable.
SCCM 2007 introduit deux nouveaux composants que je souhaite aborder avant d'examiner les fonctionnalités de gestion des mises à jour.
Point de mise à jour logicielle Comme nous l'avons vu, les catalogues n'existent plus dans SCCM. SCCM fonctionne désormais directement avec un serveur Windows Server® Update Services (WSUS) dédié qui joue le rôle de point de mise à jour logicielle (SUP) pour fournir les téléchargements de métadonnées et l'analyse des clients. Dans SCCM, les fonctionnalités de livraison binaire des mises à jour de WSUS sont désactivées pour permettre au système de se concentrer sur le processus d'analyse. Cet ajustement permet à WSUS d'analyser jusqu'à 25 000 clients par SUP sur un serveur dédié. SCCM permet également de configurer le SUP derrière un cluster NLB (Network Load Balancing) pour une meilleure disponibilité et meilleure évolutivité, activant jusqu'à quatre SUP pour un total de 100 000 clients par site principal.
Eléments de configuration (CI) Un élément de configuration est une nouvelle approche utilisée dans SCCM pour définir les configurations spécifiques qui doivent exister sur les systèmes cibles. La gestion des mises à jour SCCM utilise désormais cette infrastructure. Les mises à jour ne devraient plus être envisagées en termes de distribution logicielle normale, bien qu'il existe des similarités. Au lieu de cela, les mises à jour résident sur leur propre nœud dans la console d'administration et utilisent ce mécanisme d'élément de configuration tout à fait unique. Côté client, les mises à jour sont téléchargées de façon sélective et sont enregistrées localement.

Configuration de la gestion des mises à jour
La configuration de la gestion des mises à jour consiste en trois opérations : l'activation de l'agent client, la configuration du SUP et la configuration des mises à jour pour la distribution.
L'agent client SCCM (illustré à la figure 1) est identique aux autres agents client et est configuré sur le même nœud de la console d'administration. La page des propriétés du nœud des agents client des mises à jour logicielles est l'endroit où les administrateurs activent cet agent et configurent l'installation des mises à jour et les paramètres de réévaluation du déploiement. Le paramètre servant à activer l'agent client des mises à jour logicielles concerne le site tout entier, ce qui signifie que chaque client SCCM affecté au site dans lequel cette fonction est activée verra ce rôle activé. Si cette fonction ne doit pas être activée sur certains systèmes d'un environnement, vous pouvez remplacer le paramètre à l'échelle du site pour chaque système en utilisant les paramètres de remplacement de la stratégie locale.
Figure 1 Propriétés des agents client
Figure 1 Propriétés des agents client
Ces paramètres permettent également à l'administrateur de spécifier la façon de traiter les échéances des mises à jour. Supposons, par exemple, que vous avez quatre mises à jour qui attendent d'être installées, dont une (mise à jour A) doit être installée avant les trois autres. Mais supposons qu'il soit préférable d'installer les quatre mises à jour en même temps, y compris celles qui peuvent attendre. L'option imposant l'application des déploiements obligatoires de cet onglet vous permet de configurer ce choix. En outre, ces paramètres permettent aux administrateurs de spécifier que toutes les notifications et indications visibles du processus de mise à jour doivent être éliminées. Ces options sont indiquées à la figure 1.
Les paramètres de l'onglet de réévaluation des déploiements permettent aux administrateurs de préparer un calendrier de réévaluation des déploiements. Les clients SCCM seront évalués selon ce calendrier pour voir si les mises à jour précédemment installées sont toujours nécessaires et pour les réinstaller si elles ont disparu.

Configuration du SUP
Comme je l'ai mentionné précédemment, le SUP est le composant permettant de télécharger toutes les informations disponibles sur les mises à jour en fonction du calendrier et d'interagir directement avec les clients SCCM pour exécuter des analyses de conformité en fonction de sa base de données de mises à jour. Avant la configuration d'un SUP, un serveur WSUS 3.0 ou version ultérieure doit être installé, étant donné que cette opération n'est pas exécutée par le processus SUP, lequel ne fait que configurer le WSUS pour une utilisation par SCCM. De plus, la console d'administrateur WSUS doit être installée sur le serveur de site pour activer la connectivité avec le serveur WSUS. Une fois que SCCM prend le rôle SUP du serveur WSUS, ce dernier lui est dédié et ne peut être utilisé que par les clients SCCM.
Le SUP est un nouveau rôle de système de site dans SCCM. Pour commencer la configuration, naviguez jusqu'au nœud des systèmes de sites de la console d'administrateur et ajoutez un nouveau système de site. L'étape suivante consiste à sélectionner le point de mise à jour logicielle et à exécuter l'Assistant qui recueillera les informations suivantes :
  • Configuration de proxy
  • Informations sur le port et SSL
  • Mode de synchronisation des mises à jour par ce SUP : depuis Microsoft Update, via un SUP en amont ou manuellement
  • Planification de la synchronisation
  • Classifications des mises à jour présentant un intérêt, telles que les mises à jour critiques, les pilotes, les mises à jour de sécurité, les correctifs cumulatifs, etc.
  • Produits de mises à jour disponibles : Windows®, Exchange, SQL Server™, etc. (voir figure 2)
  • Langue
Figure 2 Paramètres de produit dans l'Assistant Rôle de site
Figure 2 Paramètres de produit dans l'Assistant Rôle de site
Une fois l'Assistant terminé, le SUP sera installé et les configurations internes seront ajustées pour prendre en charge les exigences de SCCM. Il est une judicieux de confirmer que l'installation a réussi en consultant le fichier SUPSetup.log situé dans le dossier des journaux à l'emplacement où SCCM a été installé.
Une fois le SUP installé, la synchronisation doit être exécutée pour forcer le SUP à récupérer les mises à jour et à les stocker dans la base de données SUP et SCCM. La synchronisation peut être exécutée manuellement ou programmée pour une exécution durant le lancement de l'Assistant de configuration SUP. La synchronisation manuelle des mises à jour peut être initialisée à tout moment et il est recommandé de vérifier que la synchronisation a bien lieu après la première installation du SUP. La figure 3 montre comment effectuer cette opération.
Figure 3 Exécution manuelle de la synchronisation
Figure 3 Exécution manuelle de la synchronisation
Le processus de synchronisation comporte deux étapes. Tout d'abord, le serveur (WSUS) SUP est configuré sur les paramètres SCCM et les mises à jour configurées sont synchronisées avec le serveur SUP (WSUS) lui-même. À la fin de cette opération, les informations sur les mises à jour provenant du SUP (WSUS) sont synchronisées dans la base de données SCCM et mises à disposition pour le déploiement des mises à jour. Cette deuxième étape crée les CI requis (un pour chaque mise à jour logicielle) dans la base de données SCCM et peut prendre un certain temps. La synchronisation initiale peut parfois durer plusieurs heures. Le processus de synchronisation peut être consulté dans le journal WSyncMgr, dont un extrait est reproduit aux figures 4 et 5. La figure 4 illustre, en particulier, le processus de synchronisation demandant que le serveur (WSUS) SUP mette à jour sa liste de mises à jour depuis Microsoft Update. La figure 5 illustre le début du processus de synchronisation de l'inventaire SUP avec la base de données SCCM.
Figure 4 Synchronisation de la liste de mises à jour
Figure 4 Synchronisation de la liste de mises à jour
Figure 5 Synchronisation des mises à jour en tant que CI dans la base de données SCCM
Figure 5 Synchronisation des mises à jour en tant que CI dans la base de données SCCM
Une fois un serveur WSUS configuré en tant que SUP, toute tâche administrative requise peut être accomplie à l'aide de la console d'administration de SCCM. Si les modifications de configuration sont faites directement sur le serveur WSUS, elles risquent d'avoir un impact négatif sur SCCM. En outre, ces configurations sont réinitialisées toutes les heures lorsque SCCM vérifie son SUP pour s'assurer que les configurations sont correctes.
Dans une hiérarchie à plusieurs niveaux, vous devez avoir au moins un SUP sur chaque site principal où seront déployées les mises à jour logicielles. Ces SUP fonctionneront ensemble dans une hiérarchie dans laquelle un seul SUP, généralement celui qui se trouve au sommet de la hiérarchie, effectue la synchronisation avec Microsoft Update. Les autres SUP effectuent la synchronisation depuis un partenaire de réplication SUP en amont configuré.

Configuration du déploiement de mises à jour
Une fois l'agent client configuré et le SUP configuré et synchronisé, vous êtes prêt à préparer un véritable déploiement. Tout d'abord, examinons les divers nœuds de l'interface utilisateur administrative de SCCM. En général, il existe cinq nœuds principaux présentant un intérêt : Référentiel des mises à jour, Listes de mises à jour, Modèles de déploiement, Gestion des déploiements et Packages de déploiement.
Le référentiel des mises à jour est l'emplacement dans lequel toutes les mises à jour synchronisées sont stockées et attendent d'être déployées. Vous pouvez déployer une ou plusieurs mises à jour en les sélectionnant et en lançant l'Assistant de déploiement des mises à jour logicielles qui effectue deux tâches : la configuration du modèle de déploiement (ou la sélection d'un modèle qui existe déjà) et la configuration du déploiement proprement dit. J'aborderai ce processus sous peu. La liste des mises à jour peut devenir très volumineuse, et la fonctionnalité Dossiers de recherche, nouvelle fonctionnalité de SCCM 2007, peut vous aider à trouver les mises à jour qui vous intéressent en fonction de 28 critères liés aux mises à jour, notamment Gravité, Classification, Produit, Date de publication et Remplacement.
Les listes de mises à jour permettent aux administrateurs de créer une série de mises à jour bien définies à gérer. Elles peuvent être utilisées dans les rapports sur la conformité, la création de déploiements et la délégation de l'administration. Une fois créées, ces liste de mises à jour sont répliquées dans la hiérarchie afin d'être réutilisées dans les sites enfants, tout comme les packages ou les publications. Les listes de mises à jour ne sont pas liées à un déploiement particulier lorsqu'elles sont répliquées ; il s'agit simplement de listes de mises à jour. Une fois la liste terminée et répliquée, vous pouvez déployer les mises à jour qu'elle contient d'un seul coup en sélectionnant la liste et en choisissant de déployer les mises à jour.

Modèles de déploiement
Les modèles de déploiement contiennent des paramètres courants (tels que des informations sur la planification et la collection cible) utilisés pendant le déploiement des mises à jour logicielles, et ont été créés pour réduire le temps de déploiement des mises à jour. Les modèles peuvent être créés pour gérer plusieurs déploiements dans un même environnement et peuvent être utilisés dans l'Assistant de déploiement par simple sélection. Les paramètres pré-remplis par le modèle de déploiement incluent la collection cible, les paramètres de l'échéance de la mise à jour (comme illustré à la figure 6), les paramètres de redémarrage et les fenêtres de maintenance. Lorsqu'un grand nombre de mises à jour figurent dans un déploiement, les performances du système cible peuvent être affectées à mesure que chaque échéance de mise à jour arrive simultanément. En outre, notez que les paramètres au sein du modèle sont appliqués au déploiement lors de la création de celui-ci. Ces paramètres restent en vigueur sur le déploiement à moins qu'ils ne soient modifiés manuellement dans le déploiement. Il est important de se rappeler que la simple modification des paramètres du modèle ultérieurement n'entraînera pas la modification des paramètres des déploiements existants qui utilisent le modèle modifié.
Figure 6 Configuration des échéances de déploiement dans l'Assistant
Figure 6 Configuration des échéances de déploiement dans l'Assistant
Les options de la figure 6 peuvent être configurées durant l'exécution de l'Assistant de modèle de déploiement ou de l'Assistant de déploiement de mises à jour logicielles (si un nouveau modèle est en cours de création). Notez que le paramètre de durée dans cet écran est réglé sur 0. La valeur par défaut de ce paramètre est deux semaines. Si ce paramètre est configuré sur une valeur autre que 0, le client connaîtra un retard qui équivaut, au maximum, à la durée de cette valeur avant le déploiement des mises à jour. Entre le moment où le déploiement est mis à disposition et l'application de l'échéance configurée, la mise à jour pourra être installée manuellement par les utilisateurs finaux dans le cas d'installations programmées avant l'échéance. À l'échéance, la mise à jour sera appliquée et installée. Si vous rencontrez des retards dans le déploiement des mises à jour, assurez-vous que ce paramètre est correctement configuré pour vos besoins.

Gestion des déploiements
Une fois un déploiement de mises à jour logicielles configuré, vous pouvez y accéder par le biais du nœud de gestion des déploiements. Notez qu'un déploiement de logiciel configuré est différent d'un package de déploiement. Les paramètres liés au déploiement, de même que les mises à jour incluses dans le déploiement, peuvent être affichés et manipulés sur ce nœud, mais pas le package lui-même. Ces paramètres de déploiement reflètent les paramètres qui proviennent de l'Assistant de mises à jour logicielles ainsi que ceux qui sont hérités du modèle choisi.

Packages de déploiement
Les packages de déploiement sont identiques aux packages SMS standard, en ce sens qu'ils définissent les détails de la mise à jour : répertoire source, point de distribution, etc. Les packages de déploiement sont indépendants du déploiement proprement dit utilisé pour distribuer les mises à jour et sont essentiellement un emplacement servant à stocker les mises à jour. Si plusieurs packages de déploiement contiennent les mises à jour nécessaires pour un déploiement, les agents SCCM déterminent le meilleur emplacement à partir duquel la mise à jour sera récupérée et peuvent utiliser n'importe quel package de déploiement contenant la mise à jour.
L'Assistant de déploiement de mises à jour logicielles est utilisé pour déployer des mises à jour dans SCCM. Cet Assistant peut être utilisé avec des mises à jour individuelles ou les listes de mises à jour. La figure 7 montre comment démarrer l'Assistant.
Figure 7 Démarrage de l'Assistant de déploiement de mises à jour logicielles
Figure 7 Démarrage de l'Assistant de déploiement de mises à jour logicielles
Cet Assistant vous demande toutes sortes d'informations : un nom pour le déploiement, s'il faut utiliser les paramètres du modèle existant ou d'un nouveau modèle (si un nouveau modèle est choisi, l'Assistant demandera les paramètres du modèle décrit précédemment), les paramètres du package de déploiement (existant ou nouveau), les paramètres du point de distribution, les options d'emplacement pour le téléchargement, les langues des mises à jour à télécharger et des informations sur le calendrier de déploiement.
Une fois la configuration terminée, la stratégie est mise à jour afin d'informer les clients des mises à jour ciblées et les mises à jour sont installées sur les systèmes clients. Les processus client sont différents des versions précédentes et n'entrent pas dans le cadre de cet article. Une différence essentielle, toutefois, réside dans le fait que les analyses des mises à jour ne sont non plus exécutées localement (le SUP se charge de toutes les analyses) mais les informations sur la conformité des mises à jour sont stockées dans le référentiel WMI (Windows Management Instrumentation) local, comme dans les versions précédentes.
Contrairement aux versions précédentes, cependant, l'inventaire matériel n'est plus utilisé pour envoyer l'état des mises à jour au serveur de site. Au lieu de cela, les messages d'état (nouveaux types de messages d'état simplifiés) sont envoyés au serveur de site via le point de gestion. Les messages d'état fournissent des données sur chaque client géré pour les analyses de conformité et pour surveiller la progression des déploiements. Il existe un certain nombre de nouveaux rapports dans SCCM for Software Updates Management, notamment la conformité globale des ordinateurs individuels pour toutes les mises à jour déployées vers chaque client, l'état d'application des déploiements par client, et des rapports sur les erreurs client après analyse et déploiement qui proposent une liste des plus gros problèmes à résoudre.
Outre l'application planifiée/obligatoire habituelle des déploiements des mises à jour, SCCM vous permet d'installer les mises à jour approuvées avant la date d'échéance de l'installation en suivant un calendrier très semblable à celui des mises à jour automatiques. Cet ajout très utile contribuera à augmenter le nombre de systèmes conformes avant la date d'échéance des déploiements.
SCCM vous permet également de déployer des mises à jour personnalisées. L'outil de publication de mises à jour personnalisées de SMS 2003 R2 a été modifié de sorte à pouvoir être utilisé avec SCCM 2007 en tant que System Center Updates Publisher, permettant ainsi de déployer des mises à jour personnalisées comme indiqué précédemment.
Les changements apportés à la gestion des mises à jour sont considérables dans SCCM, mais d'un point de vue administratif, ils devraient faciliter l'utilisation de SCCM et représentent une amélioration appréciable par rapport aux versions précédentes. Bien que certaines modifications conceptuelles risquent au début de s'avérer difficiles à saisir pour les utilisateurs habitués à SMS 2003, la nouvelle approche vaut qu'ils se donnent la peine de s'y intéresser. Amusez-vous bien !

Steve Rachui est technicien de support de gestion au sein du groupe Product Support Services chez Microsoft. Il assure le support de SMS depuis la version 1.2. Vous pouvez contacter Steve à l'adresse suivante : steverac@microsoft.com.


 Communications: Serveurs de transport Edge Exchange chez Microsoft
Communications Kay Unkroth

Serveurs de transport Edge Exchange chez Microsoft
Vue d'ensemble:
  • Rôle de serveur de transport Edge Exchange
  • Configuration d'un laboratoire de test
  • Agents et événements de transport
  • Agents vu de l'intérieur
Télécharger le code de cet article: ExchangeEdge2007_10.exe (354KB)

Durant une journée ouvrée normale, Microsoft reçoit environ 13 millions de tentatives de soumission de message depuis Internet et bloque plus de 10,5 millions de ces messages, à caractère non légitime. Dans les situations
critiques, telles que les attaques de courrier indésirable ou les attaques de virus sur Internet, le volume peut augmenter jusqu'à plus de 90 millions. Ceci s'applique bien sûr exclusivement à Microsoft, mais les escroqueries, le hameçonnage, les virus véhiculés par courrier électronique, les attaques DHA (Directory Harvest Attack), les attaques par déni de service distribué (DDoS) et autres soucis similaires ne sont pas spécifiques à Microsoft. Face à de tels problèmes, comment assurer la remise de tous les messages légitimes aux utilisateurs tout en maintenant le flot de contenu malveillant et illégitime à l'écart de l'environnement de messagerie ?
L'une des méthodes permettant d'y parvenir consiste à mettre en place une protection de messagerie fiable en déployant des serveurs de transport Edge Exchange Server 2007 et Forefront Security for Exchange Server dans un réseau de périmètre entre Internet et votre environnement de production. Cette approche place une équipe organisée de plus de 10 agents de transport Edge sur votre périmètre pour vous aider à protéger les systèmes de production et les utilisateurs. L'avantage que constitue le blocage du contenu indésirable au point le plus extérieur possible est évident. Dans l'idéal, ceci doit se produire avant que le contenu soit remis à vos serveurs, compte tenu de la charge que votre environnement de messagerie pourrait autrement avoir à supporter dans une situation critique. Pourtant, la protection de la messagerie est loin de se limiter au blocage des messages.
Cet article est la première partie d'une série de 2 articles au cours desquels nous discuterons de l'architecture et des fonctionnalités essentielles des agents anti-courrier indésirable et antivirus disponibles dans Exchange Server 2007 et Forefront Security for Exchange Server. Pour que les explications demeurent réalistes et pratiques, je vous montrerai d'abord dans ce premier article comment mettre en place un laboratoire de test qui reflète la conception de protection de la messagerie utilisée par Microsoft dans son propre environnement de production d'entreprise. Je couvrirai ensuite plus en détail l'architecture de transport Edge d'Exchange Server 2007.
Au cours de cet article, j'aurai souvent recours à des scripts et des fichiers de commandes pour automatiser les tâches de configuration les plus importantes. Ces fichiers incluent des commentaires qui expliquent les étapes individuelles entreprises. Vous trouverez ces scripts dans le téléchargement disponible sur le site Web de TechNet Magazine à l'adresse technetmagazine.com/code07.aspx.

Topologie de transport Edge
La figure 1 illustre la conception de transport Edge implémentée par l'équipe Microsoft IT dans l'environnement de production d'entreprise. Avant de vous faire découvrir l'architecture de transport Edge, je souhaiterais mettre l'accent sur certaines fonctionnalités de conception très intéressantes. Si les détails de mise en œuvre complets vous intéressent, consultez le livre blanc IT Showcase auquel il est fait référence dans l'encadré Ressources Exchange.
Figure 1 Topologie de transport Edge chez Microsoft
Figure 1 Topologie de transport Edge chez Microsoft
En analysant la figure 1, vous remarquerez que la topologie de transport Edge de Microsoft est entièrement redondante. Il n'existe aucun point de défaillance, à quelque endroit que ce soit. Pour l'équilibrage de la charge, Microsoft IT utilise un tourniquet (round robin) DNS en externe et des connecteurs de messagerie avec plusieurs têtes de pont en interne. Il est également à noter que tous les serveurs de transport (transport Hub et transport Edge) exécutent Forefront Security for Exchange Server pour l'analyse antivirus. Ceci permet à Microsoft IT d'analyser tous les messages entrants, sortants et internes dès qu'ils atteignent un serveur de transport de la topologie de routage de message.
Une autre caractéristique de conception importante de la sécurité est que les serveurs de transport Edge ne font pas partie de l'environnement Active Directory® d'entreprise. Il n'est en fait pas nécessaire de déployer les serveurs de transport Edge dans une forêt Active Directory. Cependant, pour conserver une infrastructure de gestion cohérente, appliquer un ensemble commun de stratégies et prendre en charge l'authentification unique, Microsoft IT déploie tous les serveurs de transport Edge dans une forêt extranet, séparée de l'environnement de production.
Enfin, vous pouvez voir clairement que tous les messages provenant d'Internet atteignent Microsoft via des serveurs de transport Edge situés en Amérique du Nord. Les serveurs de transport Edge basés à Dublin et à Singapour gèrent uniquement les messages sortants. La concentration de tout le trafic entrant sur les serveurs de transport Edge d'Amérique du Nord permet de centraliser la sécurité et les contrôles anti-courrier indésirable, tout en évitant le transfert de messages sortants depuis de grands centres de données régionaux sur la dorsale principale de messagerie interne.
Omesh Desai, ingénieur système de Microsoft IT, a conçu la topologie de transport Edge de Microsoft. Lorsque j'ai demandé à Omesh quelles étaient les caractéristiques de conception les plus importantes, sa réponse a été « Dans notre conception de transport Edge, nous tirons parti des fonctionnalités anti-courrier indésirable et antivirus natives d'Exchange pour la protection de la messagerie sur plusieurs couches de la dorsale principale de messagerie. La sécurité du périmètre de messagerie est la première priorité, mais un modèle d'administration et de gestion simple est également important pour nous. Les serveurs de transport Edge nous aident à accroître la sécurité grâce à des configurations de pare-feu plus strictes, tout en améliorant la précision du filtrage de courrier indésirable via des services de réputation d'IP, des mises à jour automatiques de filtre de contenu, l'agrégation de listes fiables et la validation de l'oblitération de courrier électronique. Toute communication interne de serveur à serveur est par défaut chiffrée et nous chiffrons également, si possible, la communication avec les destinations externes.
« Nos serveurs de transport Edge sont chacun équipés de processeurs 64 bits double cœur et de huit gigaoctets de mémoire. Avec six de ces serveurs, où la charge est équilibrée sur deux centres de données, nous disposons de capacités suffisantes pour prendre également en charge les pics de soumission de messages importants, qui surviennent par exemple pendant les attaques de virus sur Internet ».

Laboratoire de test du transport Edge
Configuration du laboratoire de test
Comme il est recommandé d'utiliser des noms de domaine inexistants et des adresses IP privées, j'utilise AdventureWorks.com et des adresses IP de plage 192.168.xxx.0 à 24. Il n'y a pas de systèmes redondants ou de groupes de pare-feu parce que je ne teste pas l'équilibrage de la charge ou la tolérance de panne. (En outre, il est évident que, pour des raisons de sécurité, nous ne discuterons pas ici des véritables systèmes de pare-feu que Microsoft IT utilise). De tels détails ne sont de toute façon pas importants pour cet environnement de test.
Mon environnement de test utilise Isa Server 2006 car il s'agit probablement de l'un des systèmes de pare-feu les plus couramment utilisés avec Exchange Server 2007. L'exécution d'Isa Server 2006 sur les pare-feu extérieur comme intérieur contribue à maintenir la complexité de l'environnement de test à un niveau modéré. Dans les environnements de production, je recommande toutefois l'utilisation de systèmes de pare-feu extérieur et intérieur différents pour accroître la sécurité. Je n'ai pas déployé de stratégies de sécurité d'IP (IPsec), ni préparé l'environnement pour l'utilisation du protocole TLS (Transport Layer Security) car ces sujets dépassent l'étendue de cet article.
Cependant, j'ai utilisé des machines virtuelles et un logiciel d'évaluation 32 bits, que vous pouvez télécharger à partir du site Web de Microsoft. Microsoft ne prend pas en charge la version 32 bits d'Exchange Server 2007 en production, mais cela ne constitue pas un problème dans un environnement de test.
Mon laboratoire de test s'appuie dans la mesure du possible sur les paramètres par défaut. Seuls la configuration IP, les pare-feu et les zones DNS nécessitent une attention particulière avant exécuter l'installation d'Exchange Server 2007 et d'abonner le serveur de transport Edge à l'environnement de production. Pour les détails concernant la configuration IP, consultez le fichier Test Lab—IP Configuration.xls que vous trouverez dans le téléchargement associé. Si vous utilisez les mêmes attributions d'adresses IP, vous pouvez configurer rapidement le pare-feu extérieur, nommé ISA01, en exécutant le script ISA01_Firewall_Policies.vbs directement sur l'ordinateur ISA01, et utiliser ISA02_Firewall_Policies.vbs pour le pare-feu intérieur (ISA02). Le téléchargement associé inclut également des fichiers de commandes permettant de configurer les serveurs DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat et AD02_DNS_Config.bat). Comme ces fichiers de commandes utilisent l'outil de ligne de commande DNS (dnscmd.exe), les outils de support de Windows doivent être installés. Si ce n'est pas le cas, vous devrez créer les enregistrements DNS manuellement à l'aide de la console DNS.
Pour éviter toute interférence provenant d'environnements existants, mon laboratoire de test n'est pas connecté à Internet. Cette isolation est une bonne précaution. Elle provoque l'échec des téléchargements de mises à jour de signatures, de réputations d'IP et de mises à jour de filtres de contenu, mais ce n'est pas critique pour le test. Pour éviter les messages d'erreur, accédez à Mises à jour de l’analyseur dans la console de l'Administrateur de sécurité de Forefront Server, définissez ensuite la fréquence de mise à jour de tous les moteurs d'analyse sur une seule fois et spécifiez une date passée.

Pour explorer ces fonctionnalités en action, il est recommandé de mettre en place un environnement de test, le bon sens suggérant de ne jamais utiliser un système de production à des fins de test. Cet environnement nécessite au minimum un serveur exécutant Exchange Server 2007 pour les rôles de Boîte aux lettres, Accès au client et Transport Hub. Vous aurez besoin d'un second serveur Exchange pour le rôle de serveur de Transport Edge. Vous pourriez ignorer l'installation du serveur de transport Edge si vous déployez tous les agents de transport sur le serveur multirôle en exécutant le script Install-AntispamAgents.ps1 (vous le trouverez sur les serveurs de transport Hub dans le dossier %ProgramFiles%\Microsoft\Exchange Server\Scripts). Toutefois, cette approche ne ressemblerait que de très loin au déploiement de Microsoft IT. Pour un laboratoire de test réaliste, vous devrez inclure quelques serveurs supplémentaires. La figure 2 illustre l'environnement de test que j'ai utilisé pour préparer cet article. Une illustration plus détaillée est disponible dans le téléchargement associé. Pour plus d'informations sur la configuration du laboratoire, consultez l'encadré « Configuration du laboratoire de test ».
Figure 2 Environnement de test du transport Edge
Figure 2 Environnement de test du transport Edge
Pendant l'abonnement du serveur de transport Edge et la configuration des connecteurs associés, Microsoft IT supprime tous les connecteurs par défaut et crée ensuite quatre connecteurs d'envoi pour communiquer efficacement avec les différents types d'hôtes SMTP (Simple Mail Transfer Protocol) et de serveurs de transport Hub internes. Le premier connecteur d'envoi est un connecteur Internet général pour toutes les destinations qui ne correspondent pas à des définitions d'espace d'adressage spécifiques.
Le second connecteur d'envoi est un connecteur Internet avec des définitions d'espace d'adressage détaillées pour les destinations connues qui ne prennent pas en charge le protocole Extended SMTP (domaines HELO). En définissant le paramètre ForceHELO pour ce connecteur sur $true, Microsoft IT évite une séquence inutile de EHLO, « Failure Response 500, HELO » lors de l'établissement des connexions SMTP.
Le troisième connecteur d'envoi est un connecteur Internet avec des définitions d'espace d'adressage détaillées pour les partenaires et autres domaines distants prenant en charge TLS pour la communication sécurisée sur les connexions chiffrées (domaines TLS). Le paramètre RequireTLS de ce connecteur est défini sur $true.
Le quatrième connecteur d'envoi est un connecteur entrant pour le transfert des messages Internet reçus vers les serveurs de transport Hub de l'environnement d'entreprise. Ici encore, pour plus de détails concernant la configuration du serveur de transport Edge, consultez le livre blanc IT Showcase auquel il est fait référence dans l'encadré « Ressources Exchange » à la fin de cet article.
Pour appliquer au laboratoire de test une topologie de connecteur du style de celle de Microsoft IT, je me suis appuyé sur une procédure basée sur les scripts qu'Omesh a créés en interne pour Microsoft. Pour des raisons de sécurité, j'ai modifié et ai raccourci radicalement chaque commande, mais la topologie de connecteur résultante correspond toujours à celle de Microsoft IT. En voici les étapes :
  1. Sur le serveur Exchange multirôle (HUB-MBX-01) et le serveur de transport Edge (EDGE01), supprimez les connecteurs par défaut.
  2. Sur HUB-MBX-01, créez un nouveau connecteur de réception en exécutant le script HUB-MBX-01_recv_connector.ps1 que vous trouverez dans le téléchargement associé à cet article.
  3. Sur EDGE01, créez deux nouveaux connecteurs de réception pour la connectivité de messagerie interne et externe en exécutant le script EDGE01_recv_connector.ps1.
  4. Sur EDGE01, créez un fichier d'abonnement en exécutant cette commande :
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
Copiez le fichier d'abonnement résultant dans le dossier racine du serveur de transport Hub (c:\subscriptionfile.xml).
5. Sur HUB-MBX-01, assurez-vous que le chemin vers le fichier d'abonnement est c:\subscriptionfile.xml et exécutez ensuite le script HUB-MBX-01_complete_subscription.ps1. Ce script importe le fichier d'abonnement pour la synchronisation Edge sans création automatique de connecteur d'envoi, crée les connecteurs d'envoi pour la connectivité Internet et interne, et copie la configuration résultante sur le serveur de transport Edge à l'aide de la synchronisation Edge.
6. Vérifiez la configuration en envoyant à Administrator@adventureworks.com des messages de test en tant que Contoso.User@contoso.com et Fabrikam.User@fabrikam.com depuis l'hôte Internet, et en répondant aux messages reçus pour vous assurer que le transfert de messages entrants et sortants fonctionne.
Je vous suggère d'ouvrir les fichiers de script individuels dans le Bloc-notes et d'analyser les applets de commande et les paramètres que ces scripts utilisent pour effectuer la configuration. Des informations détaillées sur ces applets de commande et ces paramètres sont disponibles en ligne dans la documentation produit d'Exchange Server 2007.

Architecture de transport Edge
Abordons maintenant les agents de transport Edge, qui attendent que quelqu'un leur envoie un HELO ou EHLO depuis que j'ai installé le rôle de serveur de transport Edge. Si vous exécutez la cmdlet Get-TransportAgent sur le serveur de transport Edge, vous devriez voir les 11 entrées répertoriées à la figure 3. Tous les agents sont activés par défaut pour fournir la protection de messagerie avec des paramètres appropriés.
Figure 3 Agents de transport (Close Figure 3)

Agents de réception SMTP
Agent de filtrage des connexions
Agent de réécriture d'adresse entrant
Agent de règle Edge
Agent de filtrage de contenu
Agent d'identification d'expéditeur
Agent de filtrage d'expéditeur
Agent de filtrage de destinataire
Agent d'analyse de protocole
Agent de filtrage de pièce jointe
Agents de routage
Agent de réécriture d'adresse sortant
Agent de routage FSE
L'applet de commande Get-TransportAgent et la figure 3 répertorient les agents dans l'ordre de leur priorité, même s'il ne s'agit pas de l'ordre dans lequel les agents effectuent leur travail. L'ordre de travail dépend principalement de la séquence des événements de réception et de routage SMTP pour lesquels les agents sont inscrits. Pour voir la correspondance entre agents et événements, observez le diagramme présenté à la figure 4, qui illustre la façon dont les agents de transport s'intègrent dans l'architecture de transport Edge.
Figure 4 Agents de transport dans l'architecture de transport Edge
Figure 4 Agents de transport dans l'architecture de transport Edge
Les événements de transport surviennent à diverses étapes du traitement de message pour invoquer du code supplémentaire pour le filtrage du courrier indésirable, l'analyse antivirus et d'autres tâches. Dans cette conception extensible à couplage souple, le processus de transport Edge (EdgeTransport.exe) joue le rôle de source d'événement. Les gestionnaires d'événements, en d'autres termes les agents de transport, sont des objets gérés délégués basés sur Microsoft® .NET Framework 2.0, inscrits auprès de la source d'événement pour la réception de notifications de rappel.
La figure 5 illustre les inscriptions d'événement pour tous les agents installés sur un serveur de transport Edge avec Forefront Security. Ces inscriptions sont peut-être un peu difficiles à déchiffrer en raison du grand nombre d'inscriptions d'agent, mais ne désespérez pas. Si vous exécutez la commande Get-TransportPipeline | Format-List sur un serveur de transport Edge, vous pouvez analyser plus commodément les inscriptions pour chaque événement de transport individuel. Assurez-vous seulement que le service Transport Microsoft Exchange (MSExchangeTransport.exe) s'exécute et que vous avez envoyé au moins un message via le serveur de transport Edge depuis le dernier redémarrage du service. Comme le révèle le résultat, plusieurs agents peuvent s'inscrire pour le même type d'événement et chaque agent peut s'inscrire pour plusieurs événements. Les inscriptions d'événement dépendent seulement des exigences de traitement de l'agent correspondant.
Figure 5 Inscriptions d'événement pour les agents de transport
Figure 5 Inscriptions d'événement pour les agents de transport
L'un des événements les plus importants est l'événement de routage OnSubmittedMessage, déclenché lorsqu'un message atteint la file d'attente de soumission. Tous les messages doivent passer par cette file d'attente, qu'ils entrent par le SMTP, le système de fichiers ou tout autre mécanisme. Le catégoriseur est un composant fondamental de l'architecture de transport d'Exchange Server, responsable de la résolution des destinataires, de la bifurcation et du routage des messages et de la génération de notification d'état de remise (DSN). L'événement OnSubmittedMessage est donc un choix d'inscription parfait pour les agents qui doivent traiter tous les messages reçus. L'Agent de routage FSE est un composant de Forefront Security inscrit pour l'événement OnSubmittedMessage afin de transmettre tous les messages reçus aux moteurs d'analyse antivirus. Comme l'agent de routage FSE est inscrit pour l'événement OnSubmittedMessage, aucun message ne peut contourner la solution d'antivirus.
Pourquoi tous les agents ne s'inscrivent-ils pas simplement pour l'événement OnSubmittedMessage et considèrent que le travail est terminé ? Parce que vous souhaitez bloquer les messages indésirables au point le plus extérieur possible, avant que votre serveur confirme une livraison réussie. Dans le cas contraire, vos serveurs pourraient avoir à traiter 90 millions de messages indésirables pendant une attaque de courrier indésirable ou de virus, en ayant probablement à générer 90 millions de rapports de non-remise (NDR), qui à leur tour pourraient poser une menace sérieuse pour les passants innocents. Les attaques de courrier indésirable et de virus utilisent presque toujours des informations de créateur falsifiées. L'envoi de millions de rapports de non-remise aux destinataires qui n'ont pas créé les messages d'origine est non seulement un gaspillage de vos ressources et des ressources des organisations cibles, mais également une opportunité pour les utilisateurs malveillants de lancer des attaques par inondation de courrier électronique et par déni de service distribué. Il est important d'arrêter les expéditeurs malveillants dans leur lancée, pour votre propre protection et la protection des autres.
Pour bloquer un message efficacement, un agent de transport doit interrompre la conversation SMTP avec l'hôte distant avant que votre serveur confirme la réception des données avec un code d'état 250 OK. Conformément au principe SMTP stocker et transférer, votre serveur peut rejeter en toute sécurité toutes les données reçues sans générer de rapport de non-remise si la remise des messages n'a pas été confirmée. Les agents de réception SMTP peuvent accomplir ceci. Ils interagissent avec la session SMTP parce que le pipeline de transport invoque ces agents en fonction des événements de réception SMTP lorsque l'hôte à distance se connecte au serveur, établit une session SMTP, transmet des verbes SMTP, soumet des messages et met fin à la connexion. (Les événements de réception SMTP liés à chaque étape sont répertoriés à la figure 6.) En raison de la capacité de rejeter des messages avant la remise et de déconnecter des hôtes SMTP distants, tous les agents anti-courrier indésirable Exchange Server 2007 sont implémentés en tant qu'agents de réception SMTP.
Figure 6 Événements de session SMTP (Close Figure 6)

Action | Événements connexes
Connexion au serveur | OnConnectEvent
Établissement de la session SMTP | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
Transmission des verbes SMTP | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
Soumission des messages | OnEndOfHeaders, OnEndOfData
Rejet d'une commande ou d'un message | OnReject
Réinitialisation de la connexion | OnRsetCommand
Arrêt de la connexion | OnDisconnect
Il est important de reconnaître la différence entre agents de routage et agents de réception SMTP en ce qui concerne leur contexte de traitement. Les agents de routage ont un accès complet aux propriétés de message, les agents de réception SMTP sont plus sensibles au contexte parce que ces agents interagissent avec la session SMTP. Par exemple, il n'est pas possible pour un filtre de courrier indésirable d'agir en fonction des propriétés du message avant que l'hôte à distance ait en fait transféré le message. Il est par conséquent important d'inscrire l'agent pour l'événement de réception SMTP correct. Consultez l'encadré « Développement d'agent de transport » pour un aperçu plus complet.

Ressources Exchange
  • Transport Edge et protection de la messagerie Microsoft Exchange Server 2007 (Livre blanc technique Microsoft IT Showcase)
  • Centre de scripts Windows PowerShell
  • TechCenter Exchange Server 2007
  • Blog de l'équipe Microsoft Exchange « You Had Me From EHLO »

Restez connecté
Faisons une pause avant de plonger encore plus en détail dans l'architecture de transport et les scénarios de test. J'ai couvert pas mal de terrain, d'un déploiement de serveurs de transport Edge du style de celui de Microsoft IT aux événements intérieurs déclenchés dans le pipeline de transport pendant le traitement des messages. Dans le prochain article de cette série en deux parties, je continuerai en analysant le comportement des agents de transport Edge dans quelques scénarios de test intéressants.
Entre-temps, je vous recommande de télécharger la version d'essai de 90 jours de Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) et de suivre les explications de Steve pour la compilation et l'installation d'agents d'exemple dans votre environnement de test. Même si vous n'êtes pas développeur, l'exécution de ces tâches est très simple. Je ne serais pas surpris de voir un nombre croissant d'applications professionnelles s'appuyant sur des agents personnalisés, en raison de la facilité avec laquelle ces composants peuvent être développés dans Exchange Server 2007 avec Visual Studio 2005.

Kay Unkroth est un entrepreneur qui a travaillé comme ingénieur de support technique, développeur système, consultant, formateur et auteur spécialiste des technologies de serveur Microsoft pendant plus de 15 années. Kay est également cofondateur et président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.


 SQL&#160;Server: Optimisation des performances des processeurs sous SQL&#160;Server
SQL Server Zach Nichter

Optimisation des performances des processeurs sous SQL Server
Vue d'ensemble:
  • Dépannage des problèmes de performances des bases de données
  • Examen des causes matérielles
  • Utilisation de PerfMon pour traquer les goulots d'étranglement des bases de données
  • Évaluation des performances des requêtes

Le dépannage des problèmes de performances sur un système de base de données peut apparaître comme une tâche écrasante. Savoir où chercher les problèmes est essentiel, mais il est encore plus important de savoir pourquoi votre système réagit comme il le fait suite à une requête donnée. Un certain nombre de facteurs peuvent affecter l'utilisation du processeur
sur un serveur de base de données : compilation et recompilation d'instructions SQL, index manquants, opérations multi-thread, goulots d'étranglement de disque, goulots d'étranglement de mémoire, maintenance de routine, opérations d'extraction, de transformation et de chargement (ETL), entre autres. Le fait que le processeur soit très sollicité n'est pas un problème en soi, après tout les processeurs ont été créés pour servir. La clé d'une bonne utilisation des processeurs sur votre serveur de base de données consiste à s'assurer que le processeur passe son temps à traiter ce que vous lui demandez de traiter et non à gaspiller des cycles sur du code mal optimisé ou du matériel lent.

Deux voies convergentes
Partant d'un niveau hiérarchique élevé, deux grandes voies s'ouvrent à vous pour identifier les problèmes de performances du processeur. La première consiste à examiner les performances matérielles du système, un exercice qui permet de s'orienter lorsque l'on aborde la deuxième voie, à savoir l'analyse de l'efficacité de traitement des requêtes du serveur. Cette deuxième voie est généralement plus efficace pour l'identification des problèmes de performances de SQL Server™. À moins de savoir exactement où résident les problèmes de performances des requêtes, vous devez toujours commencer par une évaluation des performances système. Au final, vous explorez généralement les deux voies. Posons quelques principes fondamentaux avant d'examiner ces deux voies.

Poser les bases
Hyper-threading
L'hyper-threading est un sujet qui mérite d'être abordé plus avant pour la façon dont il affecte SQL Server. L'hyper-threading présente en fait deux processeurs logiques au système d'exploitation pour chaque processeur physique. Cette technologie consiste à réserver des créneaux d'utilisation sur les processeurs physiques, de façon à mieux les exploiter. Le site Web d'Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) donne une description plus complète de cette technologie.
Sur les systèmes SQL Server, le SGBD (système de gestion de base de données) contrôle ses propres files d'attente et threads de façon très efficace, si bien que l'hyper-threading vient surcharger les processeurs physiques de systèmes qui les sollicitent déjà beaucoup. Lorsque SQL Server met en attente plusieurs requêtes destinées à différents planificateurs, le système d'exploitation doit effectuer de nombreuses commutations de contexte des threads sur les processeurs physiques pour satisfaire les requêtes en cours, même si les deux processeurs logiques reposent sur le même processeur physique. Si vous constatez un taux de commutation de contexte supérieur à 5 000 par processeur physique, il est fortement recommandé de désactiver l'hyper-threading sur votre système et de tester à nouveau les performances.
Dans de rares cas, des applications qui sollicitent intensément le processeur sous SQL Server peuvent utiliser l'hyper-threading de façon efficace. Testez toujours vos applications sous SQL Server avec l'hyper-threading activé et désactivé avant d'implémenter des modifications sur vos systèmes de production.

Un processeur double cœur haut de gamme est beaucoup plus performant que la mémoire vive d'un ordinateur, qui est elle-même plus rapide qu'un périphérique externe. Un bon processeur peut contrôler environ six fois le débit des mémoires DDR2 actuelles les plus performantes, et environ deux fois le débit des meilleures mémoires DDR3. Le débit mémoire type est plus de 10 fois supérieur à celui des lecteurs Fibre Channel les plus rapides. En outre, les disques durs peuvent uniquement exécuter un nombre fini d'opérations d'entrée/sortie par seconde, une valeur qui est entièrement limitée par le nombre de recherches par seconde pouvant être exécutées par un lecteur. Pour être honnête, il est relativement rare qu'un seul périphérique de stockage soit utilisé pour gérer tous les besoins de stockage des systèmes de base de données d'entreprise. La plupart des configurations actuelles sont constituées de réseaux de stockage (SAN) sur les serveurs de base de données d'entreprise ou de grands ensembles RAID qui peuvent annuler ou tout au moins réduire les problèmes liés à l'entrée/sortie du disque sur les processeurs. Rappelez-vous que quelle que soit votre configuration, les goulots d'étranglement de disque et mémoire peuvent affecter les performances de vos processeurs.
En raison des différences de vitesse d'E/S, l'extraction de données de disques est beaucoup plus coûteuse que l'extraction de données de la mémoire. Une page de données dans SQL Server fait 8 Ko. Dans le contexte de SQL Server, une extension est composée de 8 pages de 8 Ko, soit 64 Ko. Il est important de bien comprendre ceci, car lorsque SQL Server demande une page de données particulière sur le disque, ce n'est pas seulement la page de données qui est récupérée mais toute l'extension qui héberge la page de données. Ce mode de récupération est plus efficace pour SQL Server pour plusieurs raisons, mais je n'entrerai pas dans les détails ici. Á performances optimales, l'extraction d'une page de données déjà présente dans la mémoire cache à partir du pool de mémoires tampons doit prendre moins d'une demi-milliseconde. La récupération d'une extension à partir d'un disque doit prendre entre 2 et 4 millisecondes dans un environnement optimal. Selon moi, une lecture dans un sous-système de disques performant et sain devrait prendre entre 4 et 10 ms. La récupération d'une page de données à partir de la mémoire est généralement entre 4 et 20 fois plus rapide que la récupération d'une page de données à partir du disque.
Lorsque SQL Server demande une page de données, il vérifie le cache des tampons en mémoire avant de chercher la page de données sur le sous-système de disque. Si la page de données est trouvée dans le pool de mémoires tampons, le processeur récupère les données et exécute la tâche requise. Ceci est appelé défaut de page logiciel. Les défauts de page logiciels sont idéaux pour SQL Server dans la mesure où les données qui sont récupérées dans le cadre d'une requête doivent figurer dans le cache des mémoires tampons avant d'être utilisées. Une page de données qui ne figure pas dans le cache des mémoires tampons doit être récupérée à partir du sous-système de disques du serveur. Lorsque le système d'exploitation doit extraire la page de données du disque, il s'agit d'un défaut de page matériel.
Lors de la corrélation des performances mémoire, des performances disque et des performances processeur, un dénominateur commun permet de tout mettre en perspective : le débit. En termes peu scientifiques, le débit indique la quantité de données que vous pouvez faire passer par un conduit fini.

Voie 1 : Performances système
Seules quelques méthodes permettent de déterminer si un serveur souffre d'un goulot d'étranglement au niveau du processeur, et si c'est le cas, les causes potentielles sont relativement limitées. Certains de ces problèmes peuvent être suivis à l'aide de PerfMon ou tout autre outil de surveillance de système semblable, tandis que les autres sont suivis à l'aide du Générateur de profils SQL Server ou d'autres outils similaires. Une autre méthode consiste à utiliser les commandes SQL via Query Analyser ou SSMS (SQL Server Management Studio).
Lorsque j'évalue les performances système, j'applique la philosophie suivante : « Commencer large, puis se concentrer sur les détails ». Évidemment, il est impossible d'analyser les zones à problèmes tant qu'elles n'ont pas été identifiées. Après avoir évalué l'utilisation globale du processeur avec des outils tels que PerfMon, vous pouvez utiliser ce dernier pour analyser des compteurs de performances très simples et faciles à comprendre.
L'un des compteurs de performances les plus connus indique le pourcentage de temps processeur. Lorsque vous exécutez PerfMon, il est sélectionné dès que vous ouvrez la fenêtre Ajouter des compteurs. Le compteur Pourcentage de temps processeur indique le temps pendant lequel les processeurs restent actifs. L'utilisation des processeurs est généralement considérée comme élevée lorsque cette valeur est supérieure ou égale à 80 pour cent pendant la majorité de votre période d'exécution maximale. Il est normal et prévisible que des pics de 100 % se produisent de temps en temps, même si le taux d'utilisation du serveur reste inférieur à 80 %.
Un autre compteur important est Longueur de la file d'attente du processeur, qui figure sous l'objet de performances System de PerfMon. Longueur de la file d'attente du processeur indique le nombre de threads qui sont en attente d'utilisation sur le processeur. SQL Server gère ses tâches à l'aide de planificateurs dans le moteur de base de données, où il place en file d'attente et traite ses propres requêtes. Dans la mesure où SQL Server gère son propre travail, il utilise un seul thread de processeur pour chaque processeur logique. Cela signifie qu'il doit y avoir un nombre minimal de threads prêts à travailler dans la file d'attente du processeur sur un système dédié à SQL Server. En général, vous ne devez pas avoir plus de cinq fois le nombre de processeurs physiques sur un système SQL Server dédié, mais je considère que plus de deux fois est déjà problématique. Sur les serveurs où le SGBD partage un système avec les autres applications, utilisez le compteur de performances Pourcentage de temps processeur en parallèle avec le compteur Changements de contexte/seconde (j'aborderai les commutateurs de contexte plus bas) pour déterminer si vos autres applications ou le SGBD doivent être transférés vers un serveur différent.
Lorsque je vois des files d'attente de processeur en conjonction avec une forte sollicitation du processeur, je me tourne vers les compteurs Compilations/seconde et Recompilations/seconde de SQL Server : Objet de performances SQL Statistics (voir la figure 1). La compilation et la recompilation des plans de requête viennent alourdir la charge du processeur d'un système. Vous devez voir des valeurs proches de zéro pour les recompilations, mais gardez un œil sur les tendances de vos systèmes pour déterminer comment votre serveur se comporte normalement et le nombre de compilations considéré comme normal. Les recompilations ne peuvent pas toujours être évitées, mais les requêtes et les procédures stockées peuvent être optimisées pour réduire les recompilations et recycler les plans de requête. Comparez ces valeurs aux véritables instructions SQL qui parviennent au système par l'intermédiaire de Nombre de requêtes de lots/seconde, qui figure également dans SQL Server : Objet de performances SQL Statistics. Si les compilations et recompilations par seconde comprennent un pourcentage élevé de requêtes de lots qui parviennent au système, cette zone doit être vérifiée. Dans certaines situations, les développeurs de code SQL peuvent ne pas comprendre comment ou pourquoi leur code contribue à ces types de problèmes de ressources système. Plus loin dans cet article, je fournirai quelques références pour réduire ce type d'activité.
Figure 1 Sélection des compteurs à surveiller
Figure 1 Sélection des compteurs à surveiller
Pendant que vous êtes dans PerfMon, consultez le compteur de performances Changements de contexte/seconde (voir la figure 2). Ce compteur indique combien de threads doivent être retirés des planificateurs du système d'exploitation (et non pas des planificateurs SQL) pour exécuter les threads en attente. Les commutateurs de contexte sont beaucoup plus fréquents sur les systèmes de base de données qui sont partagés avec d'autres applications, telles qu'IIS ou d'autres composants de serveur d'applications de fournisseurs tiers. Le seuil que j'utilise pour Changements de contexte/seconde est d'environ 5 000 fois le nombre de processeurs du serveur. Cette valeur peut également être élevée sur les systèmes où la technologie hyper-threading est activée et dont le processeur est sollicité de façon modérée. Lorsque la sollicitation du processeur et les changements de contexte par seconde dépassent tous les deux leur seuil de façon régulière, cela indique un goulot d'étranglement au niveau du processeur. S'il s'agit d'un phénomène régulier, vous devez envisager l'achat de processeurs plus rapides ou plus nombreux si votre système est obsolète. Pour de plus amples renseignements, voir l'encadré « Hyper-threading ».
Figure 2 Compteurs de performances à surveiller (Close Figure 2)

Compteur de performances | Objet Compteur | Seuil | Remarques
% temps processeur | Processeur | > 80% | Les causes potentielles incluent la pression sur la mémoire, une faible réutilisation des plans de requête, la non optimisation des requêtes.
Changements de contexte/seconde | Système | > 5 000 x processeurs | Les causes potentielles incluent l'exécution d'autres applications sur le serveur, la présence de plusieurs instances de SQL Server s'exécutant sur le même serveur, l'activation de la fonction d'hyper-threading.
Longueur de la file d'attente du processeur | Système | > 5 x processeurs | Les causes potentielles incluent l'exécution d'autres applications sur le serveur, un nombre de compilations et recompilations élevé, la présence de plusieurs instances de SQL Server s'exécutant sur le même serveur, l'activation de la fonction d'hyper-threading.
Compilations/sec | SQLServer:SQL Statistics | Tendance | Comparer à Nombre de requêtes de lot/seconde.
Recompilations/seconde | SQLServer:SQL Statistics | Tendance | Comparer à Nombre de requêtes de lot/seconde.
Nombre de requêtes de lot/seconde | SQLServer:SQL Statistics | Tendance | Comparer à Compilation et Recompilations par seconde.
Espérance de vie d'une page | SQLServer:Buffer Manager | < 300 | Risque de pression sur la mémoire.
Écritures différées/seconde | SQLServer:Buffer Manager | Tendance | Risque de gros transferts de données à partir des caches ou de pression sur la mémoire.
Points de contrôle/sec | SQLServer:Buffer Manager | Tendance | Évaluer les points de contrôle par rapport Espérance de vie d'une page et à Écriture différée/seconde.
Taux d'accès au cache : Plans SQL | SQLServer:Plan Cache | < 70% | Indique une faible réutilisation des plans.
Taux d'accès au tampon de cache | SQLServer:Buffer Manager | < 97% | Risque de pression sur la mémoire.
L'écriture différée (SQL Server 2000) ou le moniteur de ressource (SQL Server 2005) de SQL Server constituent une autre zone à surveiller lorsque le processeur est fortement sollicité. Le vidage des caches de mémoire tampon et de procédure peut augmenter le temps processeur à l'aide du thread de ressources appelé Moniteur de ressource. Le Moniteur de ressource est un processus SQL Server qui détermine les pages à conserver et les pages à vider du pool de mémoires tampons dans le disque. Chaque page contenue dans les caches de mémoire tampon et de procédure est associée à un coût qui représente les ressources qui sont consommées lorsque cette page est placée dans le cache. Ce coût est réduit à chaque fois que Moniteur de ressource l'analyse. Lorsqu'une requête nécessite de l'espace de cache, les pages sont supprimées de la mémoire en fonction du coût associé à chaque page. Les pages avec les valeurs les plus basses sont éliminées en premier. L'activité de Moniteur de ressource peut être suivie avec le compteur de performances Écritures différées/seconde sous SQL Server : Objet de perfomances Buffer Manager dans PerfMon. Vous devez analyser la tendance de cette valeur pour déterminer le seuil type sur votre système. Ce compteur est généralement consulté conjointement avec les compteurs Espérance de vie d'une page et Points de vérification/seconde pour déterminer si la mémoire est soumise à une pression.
Le compteur Espérance de vie d'une page permet de mesurer la pression sur la mémoire. Le compteur Espérance de vie d'une page affiche le temps de séjour d'une page de données dans le cache de mémoires tampons. 300 secondes est un seuil considéré comme normal par les professionnels pour ce compteur. Toute valeur inférieure à une moyenne de 300 secondes pendant une période prolongée indique que les pages de données sont vidées de la mémoire trop fréquemment. Dans ce cas, le Moniteur de ressource est plus sollicité, ce qui en retour entraîne davantage d'activité au niveau des processeurs. Le compteur Espérance de vie d'une page doit être évalué en parallèle avec le compteur Pages de points de contrôle/seconde. Lorsqu'un point de contrôle figure dans le système, les pages de données déjà consultées dans le cache de mémoires tampons sont déplacées vers le disque, ce qui fait baisser la valeur d'espérance de vie d'une page. Le processus Moniteur de ressource fournit le mécanisme permettant de vider ces pages sur le disque. Par conséquent, pendant ces points de contrôle vous devez également vous attendre à voir la valeur Écritures différées/seconde augmenter. Si la valeur d'espérance de vie d'une page augmente tout de suite après la fin d'un point de contrôle, vous pouvez ignorer ce symptôme temporaire. Par contre, si vous constatez que la une valeur est régulièrement inférieure au seuil d'espérance de vie d'une page, il y a de très bonnes chances que de la mémoire supplémentaire résolve vos problèmes et restitue certaines ressources au processeur. Tous ces compteurs figurent dans SQL Server : Objet de performances Buffer Manager.

Voie 2 : Performances des requêtes
Suivi SP
Lors du suivi de votre application SQL Server, il est intéressant de se familiariser avec les procédures stockées utilisées pour le suivi. L'utilisation de l'interface graphique (Générateur de profils SQL Server) pour le suivi peut accroître la charge de système de 15 à 25 %. Si vous pouvez utiliser des procédures stockées lors du suivi, cette charge peut diminuer de moitié.
Lorsque je sais que mon système est soumis à un goulot d'étranglement quelque part et que je veux déterminer les instructions SQL qui posent problème sur mon serveur, j'exécute la requête ci-dessous. Cette requête permet d'examiner en détail les instructions et les ressources en cours d'utilisation, ainsi que les instructions qui doivent faire l'objet d'une amélioration des performances. Pour plus d'informations sur le suivi du code SQL, consultez l'article msdn2.microsoft.com/ms191006.aspx.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Les plans de requête sont évalués, optimisés, compilés et placés dans le cache de procédure lorsqu'une nouvelle requête est soumise à SQL Server. Lorsqu'une requête est soumise au serveur, le cache de procédure est consulté pour tenter d'associer un plan à une requête. Si aucun plan n'est trouvé, SQL Server crée nouveau un plan à cet effet, ce qui peut être une opération coûteuse.
Points à prendre en compte pour l'optimisation de processeur T-SQL :
  • Réutilisation des plans de requête
  • Réduction des compilations et recompilations
  • Tri des opérations
  • Jointures incorrectes
  • Index manquants
  • Analyses de tables/index
  • Usage de fonctions dans les clauses SELECT et WHERE
  • Opérations multi-thread
Essayons de prendre un peu de recul. SQL Server extrait généralement les données de la mémoire et du disque, et vous travaillez généralement avec plusieurs pages de données. Le plus souvent, plusieurs sections d'une application exploitent un enregistrement, exécutant plusieurs petites requêtes ou jointures de tables pour offrir une vue complète des données pertinentes. Dans les environnements OLAP, vos applications peuvent par exemple extraire des millions de lignes d'une ou deux tables de sorte que vous puissiez consolider, cumuler et résumer des données pour un rapport de ventes régional. Dans ce genre de situation, les données renvoyées peuvent être mesurées en millisecondes si elles sont en mémoire, mais ces millisecondes peuvent se transformer en minutes lors de l'extraction de ces mêmes données à partir d'un disque plutôt que de la mémoire.
Le premier exemple est une situation avec un volume élevé de transactions et la réutilisation des plans dépend de l'application. Une faible réutilisation des plans entraîne un grand nombre de compilations d'instructions SQL qui, à leur tour, sollicitent lourdement le processeur. Dans le deuxième exemple, la forte sollicitation des ressources système entraîne une suractivité du processeur du système car les données existantes doivent constamment être vidées du cache de mémoires tampons pour faire de la place pour le gros volume de nouvelles pages de données.
Imaginez un système hautement transactionnel, où une instruction SQL, telle que celle qui est indiquée ci-dessous, est exécutée 2 000 fois pendant une période de 15 minutes afin de récupérer des informations sur le carton d'expédition. Sans recyclage des plans de requête, vous pourriez avoir un temps d'exécution individuel d'environ 450 ms par instruction. Si le même plan de requête est utilisé après l'exécution initiale, chaque requête suivante pourrait s'exécuter en environ 2 ms, ce qui ramène le temps d'exécution total à environ 5 secondes.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
La réutilisation des plans de requête est essentielle pour atteindre des performances optimales sur les systèmes hautement transactionnels, et s'obtient généralement par le paramétrage des requêtes ou des procédures enregistrées. Voici quelques ressources d'excellente qualité pour plus d'informations sur la réutilisation de plans de requêtes :
  • Problèmes de la compilation par lot, de la recompilation et de la mise en cache des plans dans SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • Optimisation des procédures stockées de SQL Server pour éviter les recompilations (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • Recompilation des requêtes dans SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)
Vous trouverez une foule d'informations utiles dans les vues de gestion dynamique de SQL Server 2005. Lorsque le processeur est très sollicité, j'utilise une ou deux vues de gestion dynamique pour m'aider à déterminer si le processeur est utilisé de façon correcte ou non.
L'une de ces vues est sys.dm_os_wait_stats, qui permet aux administrateurs de base de données de déterminer chaque type de ressource ou fonction que SQL Server doit utiliser et de mesurer le temps d'attente du système lié à cette ressource. Les compteurs de ces vues de gestion dynamique sont cumulatifs. Cela signifie que pour bien identifier les ressources pouvant affecter les différentes zones du système, vous devez d'abord émettre une commande DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR) pour réinitialiser tous les compteurs après avoir examiné les données des problèmes non résolus. La vue de gestion dynamique sys.dm_os_wait_stats est l'équivalent de la commande de vérification de la cohérence de la base de données DBCC SQLPERF(WAITSTATS) dans SQL Server 2000. Vous trouverez plus de détails sur les différents types d'attente dans la documentation en ligne de SQL Server à l'adresse msdn2.microsoft.com/ ms179984.aspx.
Il est important de comprendre que les temps d'attente sont normaux dans un système même si tout s'exécute de façon optimale. Vous devez simplement déterminer si ces temps morts sont affectés par des goulots d'étranglement au niveau du processeur. Les attentes de signal doivent être aussi réduites que possible par rapport au temps d'attente global. Le temps d'accès d'une ressource donnée à une ressource de type processeur peut être déterminé simplement en soustrayant le temps d'attente de signal du temps d'attente total. Cette valeur ne doit pas être supérieure à environ 20 % du temps d'attente total.
La vue de gestion dynamique sys. dm_exec_sessions affiche toutes les sessions ouvertes sur SQL Server. Cette vue offre un aperçu de haut niveau des performances de chaque session et des tâches que chaque session a exécutées depuis son ouverture. Elle inclut le temps total d'attente de la session, l'utilisation totale du processeur, l'utilisation de la mémoire et un décompte des lectures et des écritures. La vue de gestion dynamique indique également la connexion, l'heure de connexion, l'ordinateur hôte et la dernière fois où la session a effectué une requête SQL Server.
Avec la vue de gestion dynamique sys.dm_exec_sessions, vous ne pourrez déterminer que les sessions actives. Par conséquent, en cas de forte sollicitation du processeur, il s'agit de l'un des premiers endroits à vérifier. Analysez les sessions qui présentent une forte sollicitation du processeur. Déterminez l'application et l'utilisateur qui ont exécuté la tâche, puis approfondissez vos recherches. L'association des vues de gestion dynamique sys.dm_exec_sessions et sys.dm_exec_requests permet d'obtenir la plupart des informations disponibles via les procédures stockées sp_who et sp_who2. Si vous reliez ces données, ainsi que la fonction de gestion dynamique sys.exec_sql_text via la colonne sql_handle, vous pouvez obtenir la requête en cours d'exécution de la session. Les fragments de code de la figure 3 indiquent comment extraire ces données en même temps pour déterminer ce qui se passe actuellement sur un serveur.
Figure 3 Identification de l'activité du serveur (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
J'ai remarqué que cette instruction permet de déterminer les applications qui ont besoin d'attention. Lorsque je compare le processeur, la mémoire, les lectures, les écritures et les lectures logiques des sessions d'une application et que je constate que la ressource processeur est beaucoup plus sollicitée que les autres ressources utilisées, je porte toute mon attention sur ces instructions SQL.
Pour suivre les instructions SQL d'une application dans l'ordre chronologique, j'ai recours aux informations de suivi de SQL Server. Vous pouvez les obtenir par l'intermédiaire de l'outil Générateur de profils de SQL Server ou des informations de suivi des procédures stockées du système pour faciliter l'évaluation de l'activité en cours. (Voir l'encadré « Suivi SP » pour plus d'informations à ce sujet). Recherchez les instructions à forte sollicitation du processeur dans le Générateur de profils, ainsi que les hachages et les avertissements de tri, les échecs de cache et autres indicateurs rouges. Cela permet d'identifier des instructions SQL ou une période spécifiques ayant entraîné une forte sollicitation des ressources. Le Générateur de profils peut suivre le texte des instructions SQL, les plans d'exécution, l'utilisation du processeur, l'utilisation de la mémoire, les lectures logiques, les écritures, la mise en cache des plans de requête, les recompilations, l'éjection des plans de requête du cache, les absences dans le cache, les analyses de tables et d'index, les statistiques manquantes et bien d'autres événements.
Après avoir réuni les données collectées à partir des procédures stockées sp_trace ou du Générateur de profils SQL Server, j'utilise généralement une base de données, remplie avec les données de suivi soit après les faits, soit après avoir configuré l'écriture des informations de suivi dans la base de données. Le remplissage de la base de données a posteriori peut se faire à l'aide de la fonction système de SQL Server appelée fn_trace_getinfo. L'avantage de cette approche est que je peux interroger et trier les données de plusieurs façons pour voir quelles instructions SQL ont le plus sollicité le processeur ou ont présenté le moins de lectures, le nombre de recompilations et de nombreuses autres choses. Voici un exemple de la façon dont cette fonction est utilisée pour charger une table avec un fichier de suivi du Générateur de profils. La valeur par défaut spécifie que les fichiers de suivi seront chargés dans leur ordre de création :
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Conclusion
Comme vous l'avez vu, une forte sollicitation du processeur n'indique par forcément un goulot d'étranglement au niveau du processeur. Cet usage intensif du processeur peut masquer plusieurs autres goulots d'étranglement aussi bien au niveau du matériel que des logiciels. Si vous diagnostiquez une forte utilisation du processeur alors que vos autres compteurs semblent normaux, vous pouvez commencer à rechercher la cause dans le système et isoler une solution (qu'il s'agisse d'acheter des processeurs supplémentaires ou d'optimiser votre code SQL). Quoi qu'il arrive, ne renoncez pas ! Avec les conseils fournis dans cet article et un peu de pratique et de recherche, l'optimisation de l'utilisation des processeurs sous SQL Server est un plan d'exécution réalisable.

Zach Nichter est un spécialiste de SQL Server bénéficiant de plus de 10 années d’expérience. Il a occupé plusieurs postes de support SQL Server, notamment en tant qu’administrateur de base de données, chef d’équipe, responsable et consultant. Actuellement, Zach est employé par Levi Strauss & Co. comme architecte administrateur de base de données ; son travail porte principalement sur les performances, la surveillance, l’architecture et d’autres initiatives stratégiques de SQL Server. Zach tient en outre un blog vidéo à l'adresse www.sqlcatch.com.


 Le mot du r&#233;dacteur en chef: Le meilleur est &#224; venir
Le mot du rédacteur en chef
Le meilleur est à venir
Joshua Hoffman

Aussi étrange que cela puisse paraître, je vais débuter mon premier mot du rédacteur en chef par un souvenir. Le fait de recourir à ce genre d'artifice si tôt dans ma nouvelle carrière pourrait bien se retourner contre moi, mais qu'importe.
Au cours de l'été 2005, les deux éditions inaugurales de TechNet Magazine avaient été très bien reçues et il était temps de mettre en place le calendrier de production et fournir un contenu technique irréprochable aux professionnels de façon régulière. Joshua Trupin, notre rédacteur en chef et Stephen Toub (alors rédacteur technique de notre publication sœur, MSDN Magazine), avaient accompli une tâche immense en réunissant des experts et en planifiant les deux premiers numéros, alors que ce n'était pas leur travail principal.
C'est alors que j'ai rejoint l'équipe en tant que nouveau rédacteur technique, intimidé par la confiance qui m'était accordée et leurs réalisations. La production d'un magazine n'est pas une mince affaire. Je suis informaticien jusqu'au bout des doigts et avais travaillé les quatre années précédentes chez Microsoft Consulting Services. Je ne connaissais pratiquement rien à la publication. J'avais une liste de lecture d'un km. J'avais trois problèmes pour lesquels il me fallait commencer à planifier tout de suite. J'avais de nouveaux collègues, auteurs, réviseurs techniques, partenaires commerciaux et, bien sûr, de nouveaux lecteurs à découvrir. Et, par-dessus tout, j'avais des dates limites d'impression impossibles à déplacer (ce qui, comme vous pouvez l'imaginer, est un concept difficile à comprendre pour un ancien de Microsoft).
Mais l'équipe m'a fait bon accueil, m'a supporté et m'a mis à l'aise, et surtout m'a aidé dans ma tâche bien plus que vous ne pouvez vous l'imaginer. Les auteurs, les réviseurs, les partenaires et vous, nos lecteurs, avez rendu ce travail fascinant, stimulant et très enrichissant. C'est un véritable privilège d'avoir fait autant de nouveaux amis. Lorsque je reviens sur ces deux dernières années, je suis fier de tout ce que cette équipe a accompli. Mais maintenant, en tant que nouveau rédacteur en chef, je suis encore plus motivé par ce qui nous attend.
Ce magazine a pour mission de permettre aux professionnels de l'informatique d'exploiter les produits et les technologies de Microsoft dans les meilleures conditions possibles (faites-moi confiance, nos fins de mois en dépendent). Vous nous avez dit que nous avions bien fait et que, encore plus important, nous devions nous améliorer. Vos commentaires sont importants. Au cours des mois et années à venir nous continuerons à nous améliorer, en ajoutant de nouveaux auteurs et articles, en améliorant notre plate-forme en ligne avec de nouveaux contenus et de nouveaux médias, qui devraient tous vous permettre d'apprendre comme vous le souhaitez. Tout ceci ne peut cependant pas réussir sans votre participation. Dites-nous ce que vous avez aimé et ce qui vous a rebuté. Où devons-nous orienter nos efforts ? Vous avez le contrôle, n'hésitez pas à en profiter. Envoyez un message à tnmag@microsoft.com et faites entendre votre voix. —Joshua Hoffman

Remerciements aux experts techniques Microsoft suivants : Omesh Desai, Raja Ganjikunta, Saleem Hakani, Justin Hall, Michael Murgolo, John Orefice, Jim Truher, Marc Umeno, Jeff Wettlaufer, Buck Woody et Minxiao Zhou.


 Bo&#238;te &#224; outils: Nouveaux produits pour les professionnels de l’informatique
Boîte à outils
Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Des scripts plus efficaces
PowerShell Analyzer
www.pwershellanalyzer.com
Tout le monde ne parle que de Windows PowerShell™, et avec raison. Si vous n'avez pas eu la chance d'essayer ce langage de script nouvelle génération, n'attendez plus ! Et si vous êtes passé à Microsoft® Echange 2007, vous vous rendrez rapidement compte que le nouvel environnement de ligne de commande Exchange Management Shell est basé sur Windows PowerShell, ce qui vous permet d'effectuer toutes les tâches que peut effectuer la console de gestion Exchange mais à partir de la ligne de commande, ce qui est très utile pour l'automatisation des tâches répétitives. Malheureusement, la syntaxe et la sémantique peuvent s'avérer difficiles à comprendre. Et c'est ici qu'intervient PowerShell Analyzer, de ShellTools !
L'application est en fait un environnement de développement intégré servant à écrire et déboguer des scripts Windows PowerShell. Toutefois, et contrairement à un cycle de test écriture/compilation traditionnel, l'application maintient l'esprit de l'administrateur sur le clavier, vous offrant ainsi une interactivité en temps réel avec un espace d'exécution Windows PowerShell. PowerShell Analyzer vous permet soit d'entrer des commandes ligne par ligne, soit de créer, modifier et exécuter des scripts Windows PowerShell dans un éditeur, dans la partie inférieure de l'interface utilisateur. Ces options vous proposent toutes deux une complétion de code de base, une aide appréciable pour les nombreux paramètres des applets de commande. (Pour ceux qui ne sont pas familiers avec Windows PowerShell, les applets de commande sont des commandes abstraites, orientées vers les tâches et paramétrées.)
PowerShell Analyzer vous offre, en outre, un onglet d'accès rapide qui vous donne des descriptions détaillées, des explications de la syntaxe et des paramètres et des exemples pour chacune des applets de commande. Vous disposez également de références sur les fournisseurs de Windows PowerShell, les fichiers d'aide intégrés et les alias abrégés des applets de commande.
Lorsque vous exécutez des commandes depuis Windows PowerShell, on vous renvoie en fait des objets Microsoft .NET Framework et non pas uniquement les résultats de texte apparents à l'écran. PowerShell Analyzer vous permet de capturer les propriétés des résultats renvoyés et de les transférer à un certain nombre de « visualiseurs ». Ces visualiseurs vous permettent d'interagir avec les objets (exploration sous forme d'arborescence de données XML, par exemple, ou vue sous forme de tableau hiérarchique des données) et de créer plusieurs graphiques différents pour représenter visuellement le DataSet renvoyé. Bien sûr, ces options ne sont pas toutes disponibles pour chaque commande ou script que vous exécutez, mais, le cas échéant, elles vous offrent une jolie série de représentations de vos données que vous pouvez ensuite enregistrer ou exporter et réutiliser plus tard.
PowerShell Analyzer vous permet également de travailler avec plusieurs espaces d'exécution en même temps et de passer facilement d'une tâche à l'autre. La fenêtre de l'éditeur, quant à elle, vous propose des styles de délimitation et de mise en évidence de code personnalisables pour rendre vos scripts plus lisibles.
En résumé, si vous envisagez d'utiliser Windows PowerShell, un outil comme PowerShell Analyzer facilitera considérablement la création, la modification et le débogage de vos scripts et l'affichage de vos données.

Prix : 129 $ (vente directe) pour une licence unique.
Figure powershell

Défragmentation des disques
Disk Defrag d'Auslogics
www.auslogics.com/disk-defrag
Plus vous utilisez votre disque dur, plus les fichiers qu'il contient sont fragmentés. La création et la suppression de fichiers, l'installation et la suppression d'applications et même la création de caches et fichiers temporaires contribuent tous à la fragmentation. En outre, la fragmentation peut augmenter de façon spectaculaire lorsque l'espace libre sur le lecteur est limité, étant donné que les nouveaux fichiers sont placés dans les « trous » disponibles d'un espace majoritairement rempli. Toute cette fragmentation ralentira les performances du système.
Tout le monde sait, bien sûr, qui les versions actuelles de Windows® incluent des outils de défragmentation. Mais si vous cherchez une solution dédiée ou si vous êtes récemment passé à Windows Vista® et que le contrôle et la présentation de l'interface utilisateur offerts par les versions précédentes de l'outil de défragmentation vous manquent, vous pouvez essayer une alternative très intéressante : Disk Defrag, d'Auslogics.
Disk Defrag fonctionne avec Windows XP, Windows 2000, Windows Server® 2003 et Windows Vista. Et, comme vous le devinez peut-être, il peut défragmenter des volumes FAT16, FAT32 et NTFS. L'application est légère et l'installation se fait en quelques clics.
L'exécution de l'application est tout aussi simple. Il vous suffit de choisir le lecteur que vous souhaitez défragmenter, de cliquer sur Suivant et le tour est joué ! Une fois son exécution terminée, Disk Defrag vous offre un aperçu rapide des résultats, affichant le nombre total de fichiers, répertoires, fichiers fragmentés, fichiers défragmentés et fichiers ignorés, de même que le pourcentage de réduction de la fragmentation. Si vous le souhaitez, vous pouvez également cliquer sur le bouton d'affichage de rapport de Disk Defrag et l'application créera une version HTML du rapport de défragmentation. Ce rapport vous donne d'autres informations utiles sur votre disque, telles qu'un liste des fichiers ignorés avec leur emplacement, le nombre de fragments, la durée de l'exécution et des informations sur les clusters de votre disque.

Prix : Gratuit.
Disk Defrag est facile à installer et utiliser
Disk Defrag est facile à installer et utiliser

Transfert de fichiers
FileZilla
filezilla.sourceforge.net
Il n'y a rien de mieux qu'un bon client SFTP pour vous faciliter la tâche. Ceci est particulièrement vrai lorsque le client est solidement écrit et gratuit, ce qui est le cas du client FileZilla. FileZilla est un projet Open Source destiné à une classe informatique, hébergé sur SourceForge.net et qui a été lancé par Tim Kosse et deux de ses amis en 2001. FileZilla s'exécute sur toutes les plates-formes Windows, de Windows NT® 4.0 à Windows Vista. Le projet s'est considérablement développé au cours des six dernières années, mais Kosse est toujours responsable de l'application.
Outre les connexions FTP standard, le client prend en charge les connexions via SFTP avec la version 2 de Secure Shell (SSH2), via FTP sur TLS et via FTP sur SSL avec chiffrement implicite et explicite, ce qui vous permet de vous connecter à une foule de serveurs. FileZilla peut prendre en charge les pare-feu locaux en vous permettant de limiter les ports locaux utilisés et de configurer une liaison IP spécifique pour les transferts non passifs pour IPv4 et IPv6. Le client prend également en charge un certain nombre de configurations de proxys, dont les proxys SOCKS4/5, HTTP1.1 et FTP.
Pour ce qui est de l'authentification serveur pour vos connexions FTP, FileZilla prend en charge les configurations anonymes, les configurations par nom d'utilisateur/mot de passe et les configurations basées sur les comptes. En outre, vous pouvez activer la prise en charge GSS (Generic Security Services) de Kerberos (qui nécessite l'installation de Kerberos pour Windows sur votre système) et créer une liste de serveurs GSS. Bien sûr, il vous faudra un ticket Kerberos v5 valide avant de pouvoir utiliser GSS. Vous pouvez également activer la prise en charge de votre serveur Ident pour les connexions aux serveurs qui l'exigent pour l'identification de votre client.
FileZilla gère facilement toute une foule de sites FTP et vous permet d'organiser vos connexions sous forme d'arborescence. Pour chaque connexion que vous établissez, vous pouvez également déterminer les répertoires locaux et distants par défaut, spécifier le port auquel vous devez vous connecter, choisir de contourner votre proxy configuré, choisir explicitement des modes de transfert actifs ou passifs et même déterminer le décalage du fuseau horaire du serveur. Outre les connexions enregistrées, FileZilla possède également une fonctionnalité Quickconnect, pour les transferts ponctuels, qui vous permet tout simplement de taper l'adresse, le nom d'utilisateur, le mot de passe et le port et de cliquer sur un bouton pour vous connecter. Une fois tous vos paramètres et toutes vos connexions configurés, vous pouvez les exporter vers XML pour les sauvegarder ou les réutiliser sur d'autres systèmes.
L'interface utilisateur de l'application, qui est similaire à l'interface l'Explorateur Windows, vous permet de glisser-déplacer des fichiers entre les systèmes locaux et distants. Pour les transferts de fichiers, vous pouvez spécifier un paramètre de remplacement des fichiers par défaut en plus de l'option qui vous permet de limiter votre vitesse de téléchargement en fonction d'un ensemble de règles prédéfini ou de la configurer sur une vitesse Ko/s constante. Par défaut, FileZilla est configuré pour utiliser les transferts de fichiers compressés MODE Z sur les serveurs qui le prennent en charge, mais vous pouvez ajuster le niveau de compression ou désactiver la fonctionnalité. Le client possède également une fonctionnalité de mise en attente du transfert qui vous permet de mettre attente un groupe de fichiers à transférer puis d'importer et exporter cette liste de transfert pour une réutilisation ultérieure. Cette fonctionnalité est très utile pour les tâches d'administration système répétitives.

Prix : Gratuit.

Modification des exécutables
PE Explorer
www.heaventools.com
Si aimez explorer à fond vos applications, vous devriez essayer PE Explorer de HeavenTools. Cette application vous permet d'examiner en profondeur les données internes de vos fichiers PE (Portable Executable) qui sont utilisés comme fichiers binaires exécutables pour les applications Windows. En quelques mots, PE Explorer offre une interface utilisateur permettant d'explorer et modifier le contenu de ces exécutables. PE Explorer peut ouvrir une variété de types de fichiers allant des types courants tels que EXE et DLL aux types moins familiers tels que DPL et CPL.
La première fois que vous choisissez d'explorer un exécutable, PE Explorer affiche des informations sur les en-têtes du fichier, notamment le nombre de sections de code, la taille de l'image, le sous-système d'application et des informations sur la taille de la pile. Une autre vue affiche un aperçu général des en-têtes des sections de l'exécutable. Si vous double-cliquez sur l'en-tête d'une section, vous affichez une fenêtre qui vous permet d'explorer le contenu de la section.
Bien qu'elle ne soit pas destinée aux novices peu aventureux, cette application vous permet d'extraire, recalculer et supprimer des sections de votre PE chargé. Cet outil est très utile pour détecter les virus et logiciels malveillants, et vous pouvez utiliser sa visionneuse de signature numérique pour examiner et valider la signature numérique Microsoft Authenticode, le cas échéant, dans le fichier exécutable chargé. Il s'agit là d'une façon efficace de vérifier l'éditeur et l'intégrité de l'exécutable.
PE Explorer contient également un désassembleur rapide qui vous permet de vérifier le code d'assembly de votre exécutable. En outre, il prend en charge les jeux d'instructions Intel x86 courants avec des extensions telles que MMX, 3D Now! et SSE/2/3. Le désassembleur extrait également les chaînes de texte ASCII de la portion de données de votre PE.
PE Explorer offre également un scanneur de dépendances qui analyse tous les modules auquel votre fichier PE est lié statiquement et ceux qui ont été chargés avec délai, et les affiche ensuite dans une arborescence hiérarchique en indiquant les limites du PE.
L'un des modules les plus amusants de PE Explorer est, à mon avis, l'éditeur de ressources. Cette fonctionnalité vous permet d'afficher, d'extraire, de remplacer, de modifier et de supprimer les ressources d'un exécutable spécifié. L'interface utilisateur vous montre une structure en forme de répertoire des ressources intégrées telles que les images, sons, dialogues, menus, données XML, données HTML et barres d'outils. Ces ressources ne prennent pas toutes en charge les modifications directes, mais, en général, vous pouvez les remplacer et les modifier. Cela vous permettrait, par exemple, d'ajouter votre propre personnalisation à une application, de modifier les messages de dialogues, de personnaliser les actions de la barre d'outils, et ainsi de suite, sans avoir accès au code source lui-même. PE Explorer est un outil très pratique pour ceux qui s'intéressent aux exécutables. Mais si l'éditeur de ressources est la seule fonctionnalité dont vous avez vraiment besoin, essayez l'application Tuner de ressources du même éditeur, beaucoup moins chère.

Prix : 129 $ (vente directe) pour une licence personnelle ; 199 $ (vente directe) pour une licence d'entreprise.
Figure peexplorer

Critique
Endpoint Security
www.awprofessional.com
L'ajout d'un périmètre réseau traditionnel solide à votre infrastructure interne est une étape importante dans la protection de vos actifs. Toutefois, elle ne constitue pas une garantie de protection absolue. Avec la mobilité et la connectivité sans cesse grandissantes du matériel et des logiciels actuels, il n'existe pas de vrai périmètre sur votre infrastructure d'entreprise, et c'est plutôt votre infrastructure qui s'étend à ces points de terminaison distants. En fait, pendant que vous vous protégez contre les attaques provenant de l'extérieur de votre environnement, il est plus probable qu'une attaque sera accidentellement lancée par un utilisateur qui connecte son portable au réseau non contrôlé de votre entreprise depuis son domicile.
Si vous souhaitez en savoir plus sur le contrôle d'accès réseau et renforcer les points de terminaison de votre infrastructure, consultez le livre de Mark Kadrich, Endpoint Security (Addison-Wesley Professional, 2007). Ce livre propose tout d'abord une définition des points de terminaison et vous en montre ensuite les diverses variétés qui existent, notamment les clients Windows, les clients Linux, les périphériques intégrés, les téléphones mobiles et les assistants personnels numériques. Kadrich considère le réseau comme un « problème de contrôle ». Rejetant la représentation typique d'un réseau complexe avec un degré d'analogie organique, il le décrit plutôt comme quelque chose qui peut être défini et visualisé d'une manière utile et pratique.
Le livre examine les bases du contrôle de l’accès au réseau et de l'établissement d'un niveau de confiance minimal. Cette discussion se penche également sur la façon de créer une base sécurisée pour vos systèmes de points de terminaison en renforçant et en contrôlant votre logiciel source et votre environnement de création. Cet ouvrage propose un aperçu général des outils qui peuvent aider à renforcer la sécurité et la fiabilité des points de terminaison, notamment l'utilisation d'un pare-feu et d'un antivirus, et insiste sur l'importance d'une gestion proactive des correctifs. Il examine enfin des outils plus avancés, tels que les systèmes de détection et de prévention des intrusions, les contrôleurs de l'intégrité des hôtes et le chiffrement.
La deuxième partie du livre aborde le renforcement de la sécurité des systèmes d'exploitation de divers types de clients, notamment Microsoft Windows, Apple OS X et Linux. Chaque chapitre vous montre comment vérifier l'intégrité initiale de votre système de points de terminaison. Certains chapitres se penchent sur la menace que représentent certains périphériques, tels que les PDA, les Smartphones et les périphériques intégrés, pour votre infrastructure et sur la façon de sécuriser divers types de communication avec eux.
Enfin, Kadrich examine quatre études de cas et identifie comment les points de terminaison ont été compromis dans chacune d'elles et comment il aurait été possible de limiter les dégâts. En résumé, le livre Endpoint Security est bourré d'informations très utiles pour les professionnels de la sécurité, et vous propose une vision indépendante des fournisseurs sur la façon de renforcer la sécurité de votre réseau grâce à un périmètre de points de terminaison.

Prix : 54,99 $ catalogue.

Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste, constamment à la recherche de nouveaux outils et de nouvelles références destinés à faciliter les opérations et le développement pour les professionnels de l’informatique. Vous avez une suggestion ? Transmettez-la lui à tntools@microsoft.com


 Forum aux questions sur SQL&amp;: D&#233;clencheurs de connexion, d&#233;fragmentation de fichier de donn&#233;es, et bien plus encore
Forum aux questions sur SQL&
Déclencheurs de connexion, défragmentation de fichier de données, et bien plus encore
Par Nancy Michell

Configuration du compte de service
Conseil : Des mots de passe plus sûrs
Le moteur SQL Server 2000 conserve deux copies de chaque mot de passe de compte de connexion SQL Server. L'une des versions est le véritable mot de passe fourni par l'utilisateur, la seconde étant le mot de passe en majuscules.
Cette méthode permet la validation non sensible à la casse des mots de passe, car un utilisateur peut ouvrir une session avec un mélange de casse ou en majuscules et se voir accorder l'accès au serveur. Cependant, cet avantage a un certain défaut. L'enregistrement des mots de passe en majuscules rend les attaques de force brute visant à deviner les mots de passe plus faciles en réduisant le nombre de mots de passe possibles.
SQL Server 2005 enregistre uniquement la copie d'origine du mot de passe. Un mot de passe entré par un utilisateur doit correspondre au mot de passe enregistré sur le serveur. Si le mot de passe ne correspond pas, l'ouverture de session échoue et l'accès est refusé à l'utilisateur. En cas d'oubli de la casse exacte des caractères du mot de passe, le mot de passe doit être réinitialisé.
En supposant que l'identifiant de compte de connexion d'un utilisateur est SQLCOMMUNITY, vous pouvez réinitialiser son mot de passe SQL Server en utilisant la commande suivante :
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
Cette commande réinitialisera le mot de passe pour le compte de connexion SQL Server de SQLCOMMUNITY à « k3t9h4s8wJF7t ».

Q Dans SQL Server™ 2000, j'avais l'habitude de définir le compte de service pour le moteur et l'agent SQL Server à l'aide de l'applet Services dans les Outils d'administration. J'ai maintenant entendu dire que dans SQL Server 2005, je dois utiliser l'outil Gestionnaire de configuration. Pourquoi ne puis-je pas continuer à utiliser les outils de Windows ?
R SQL Server 2005 a été conçu pour être plus sûr que les versions précédentes. Dans de nombreux cas, les utilisateurs définissaient simplement des comptes internes, tels que LocalSystem, pour exécuter SQL Server. Mais ces comptes ont souvent plus ou moins d'autorisations sous Windows® que ce dont ils ont besoin. Vous devez créer un compte Windows sans privilèges élevés pour exécuter les services d'agent et de moteur SQL Server 2005. Si vous sélectionnez ces comptes avec le Gestionnaire de configuration, ils se verront automatiquement accorder les droits et les autorisations correctes dans SQL Server et le système d'exploitation. Si vous utilisez les outils de Windows pour gérer les services de SQL Server, vous pourriez ne pas accorder les droits corrects, ou en accorder trop.
Pour plus de détails, consultez l'astuce Modification du compte de service.

Qui ouvre une session sur mon serveur ?
Q Je veux savoir qui ouvre une session sur mon serveur et quand. Je veux également restreindre certains utilisateurs à certaines périodes et aimerais savoir comment déclencher un suivi pour dépister l'activité des utilisateurs. Est-ce que ces opérations sont possibles ?
A Oui, vous pouvez faire tout cela avec SQL Server 2005 si le Service Pack 2 est installé.
SQL Server 2005 vous permet de créer des déclencheurs de connexion qui peuvent déclencher une procédure stockée ou T-SQL en réponse à un événement LOGON. Vous pouvez utiliser un déclencheur de connexion pour vérifier et contrôler des utilisateurs en effectuant le suivi de l'activité de connexion, en limitant les connexion SQL Server ou en limitant le nombre de sessions de connexions spécifiques. Notez que l'événement est uniquement déclenché une fois la connexion authentifiée avec succès, mais juste avant que la session utilisateur soit en fait établie. Par conséquent, tous les messages provenant de l'intérieur du déclencheur (tels que les messages ou les erreurs) de l'instruction PRINT sont envoyés au journal d'erreurs de SQL Server. Si l'authentification vient à échouer pour une connexion, les déclencheurs d'ouverture de session ne seront pas déclenchés.
L'exemple suivant illustre comment vous pouvez créer un déclencheur de connexion et envoyer un message au journal d'erreurs de SQL Server dès qu'un utilisateur se connecte :
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
Pour afficher tous les déclencheurs définis au niveau du serveur, utilisez la requête suivante :
SELECT * FROM sys.server_triggers;

Meilleures pratiques de défragmentation
Q Quelle est la meilleure façon de réparer la fragmentation de fichier de données dans SQL Server ? Si nous utilisons les outils de défragmentation de Windows, ceux-ci traitent le fichier de données SQL comme un ensemble et ne le défragmenteront pas de façon granulaire.
R Vous pourriez sauvegarder la base de données puis la restaurer. Si vous disposez de suffisamment d'espace pour un fichier contigu, la base de données devrait être écrite de manière contiguë. Cela dit, la défragmentation des fichiers physiques ne justifie normalement pas le temps d'indisponibilité qu'elle génère. Il n'y a généralement pas beaucoup de fragmentation de toute façon. Il est beaucoup plus utile de réindexer régulièrement vos données pour réduire autant que possible la fragmentation interne. Ceci permettra de maximiser l'efficacité des lectures anticipées et la quantité de données pouvant être placée dans la mémoire tampon.
Les facteurs les plus importants pour des E/S disque efficaces sont un alignement de disque et une configuration RAID corrects, un dimensionnement des baies de disques capable de gérer la charge d'E/S et une disposition correcte des fichiers de journaux, données, TempDB et de sauvegarde. Si vous évitez d'utiliser la croissance et la réduction automatique comme méthodes principales de calibrage de taille des fichiers de données, vous réduirez le nombre de fragments de fichiers de niveau volume créés. Par exemple, le recours à 10 croissances automatiques de 500 Mo chacune ajoutera probablement 10 nouveaux fragments de fichier physiques. Par opposition, une croissance manuelle unique 5 Go en ajoutera seulement un.

Conseil : Modification du compte de service
Saviez-vous que lorsque le compte de service de SQL Server est configuré avec un compte Windows NT®, SQL Server définit les droits d'utilisateur et les autorisations de Windows sur plusieurs fichiers, dossiers et clés de Registre ? Vous pouvez également définir le compte de service SQL Server à partir de la console Services des Outils d'administration. Cependant, lorsque vous effectuez ceci avec Services, les droits et les autorisations ne sont pas définis et vous pouvez rencontrer des problèmes sérieux en raison du manque de paramètres de sécurité appropriés sur les éléments SQL Server et Windows mentionnés précédemment.
Il est donc fortement recommandé d'utiliser le Gestionnaire de configuration de SQL Server et non la console Services pour la modification de SQL Server ou du compte de service de l'agent SQL Server. Cependant, si vous avez déjà apporté des modifications au compte en utilisant la console Services, vous pouvez toujours résoudre ce problème.
Étape 1 : Appliquez des autorisations complètes sur les clés de Registre suivantes et leurs sous-clés :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
Étape 2 : Définissez le contrôle total pour le compte de démarrage du service MSSQLServer et le service SQLServerAgent (un compte local Windows NT ou un compte de domaine Windows NT) sur ce dossier NTFS :
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
Au lieu d'effectuer ceci manuellement, il est cependant recommandé d'utiliser le Gestionnaire de configuration SQL Server pour apporter des modifications aux comptes de services SQL Server/Agent.

Merci aux informaticiens Microsoft ci-dessous pour l’apport de leur expertise technique : Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko et Buck Woody.


 Coup de projecteur sur les utilitaires: Virtual Machine Remote Control Plus
Coup de projecteur sur les utilitaires
Virtual Machine Remote Control Plus
Matthijs ten Seldam
Télécharger le code de cet article: UtilitySpotlight2007_10.exe (10163KB)

La virtualisation est un sujet très en vogue actuellement. De nombreux professionnels de l'informatique utilisent la virtualisation de matériel pour apprendre et tester des scénarios. Pour cette raison, Microsoft propose désormais Virtual PC 2007, solution de virtualisation logicielle qui cible les installations autonomes composées d'un nombre de machines virtuelles limité. Notez que ce nouveau produit ne remplace pas Virtual Server 2005
qui a introduit la virtualisation dans le centre de données.
Microsoft® Virtual Server 2005 vous permet de virtualiser de nombreuses charges de travail de serveur, mais, contrairement à Virtual PC, l'interface de Virtual Server est une application Web. Bien que la gestion Web ait ses avantages, beaucoup préfèrent, pour l'administration quotidienne, une interface utilisateur riche qui se comporte comme une application Windows®.
Virtual Machine Remote Control Plus, ou VMRCplus pour faire court, est une autre interface utilisateur pour Virtual Server 2005. Comme il s'agit d'une application Windows Forms, VMRCplus offre une gestion aisée de Virtual Server et de ses machines virtuelles. Notez que Virtual Server est accompagné d'un outil appelé VMRC, qui est utilisé pour le contrôle à distance des machines virtuelles. Toutefois, VMRCplus offre à la fois la gestion de configuration de Virtual Server et le contrôle à distance des machines virtuelles, le tout dans une seule application.

Virtual Machine Manager
La fenêtre principale de VMRCplus, appelée Virtual Machine Manager, est illustrée à la figure 1. Dans cet exemple, Virtual Machine Manager est connecté à localhost, avec cinq machines en exécution, trois dans un état enregistré et les autres désactivées. La sixième machine de la liste est sélectionnée, et affiche des informations supplémentaires, notamment le système d'exploitation invité, la charge du processeur, les informations sur les E/S du réseau et du disque et la version des éléments additionnels installés. Notez que la liste est triée par état.
Figure 1 Virtual Machine Manager de VMRCplus
Figure 1 Virtual Machine Manager de VMRCplus
Grâce à Virtual Machine Manager, vous pouvez vous connecter à des hôtes Virtual Server et afficher leurs machines virtuelles. Vous passez d'un hôte à l'autre en sélectionnant leur onglet et vous connectez à un hôte depuis la liste déroulante de la barre d'outils ou en tapant un nom d'hôte ou une adresse IP. Une fois que vous vous êtes connecté, VMRCplus ajoute le nom ou l'adresse IP à la liste.
Certaines propriétés de l'hôte Virtual Server, telles que les informations liées au processeur et à la mémoire, sont affichées au bas de la fenêtre. Un compteur de mémoire vous offre un relevé rapide de la quantité de RAM qu'il reste pour les machines virtuelles.

Gestion de Virtual Server
Virtual Machine Manager vous permet non seulement d'afficher des informations, mais aussi de configurer des paramètres. Depuis l'option d'affichage du menu, vous pouvez déterminer l’intervalle d’actualisation de VMRCplus pour mettre à jour la liste Virtual Machine. Le paramètre de l’intervalle d’actualisation actuel est affiché dans le coin inférieur droit de la fenêtre, comme illustré à la figure 1.
Le menu de Virtual Server vous permet d'accéder à la configuration de Virtual Server, notamment aux paramètres de Virtual Machine Remote Control (VMRC), à l'emplacement par défaut des nouvelles machines virtuelles, aux paramètres de sécurité et aux propriétés de service. Sur la page des paramètres VMRC, vous pouvez configurer n'importe quelle propriété, désactiver VMRC entièrement ou rétablir les paramètres par défaut de Virtual Server.
La page des paramètres de sécurité vous permet de spécifier les autorisations de Virtual Server. Par défaut, le groupe Administrateurs locaux possède le contrôle total de Virtual Server. Vous pouvez spécifier des autorisations pour les groupes ou les utilisateurs. Si vous n'êtes pas membre du groupe Administrateurs locaux, vous devez d'abord ajouter un groupe ou votre compte et définir les autorisations appropriées. Vous n'avez toutefois pas besoin d'exécuter VMRCplus en tant qu'administrateur. Les privilèges utilisateur habituels suffisent.
Les propriétés de l'hôte Virtual Server, notamment les propriétés physiques, sont illustrées à la figure 2. Notez que cet hôte prend en charge la technologie de virtualisation assistée par matériel, comme le montre les fonctionnalités du processeur.
Figure 2 Propriétés de Virtual Server
Figure 2 Propriétés de Virtual Server

Disques virtuels et gestion des réseaux
VMRCplus inclut d'autres gestionnaires destinés à des fonctionnalités spécifiques de Virtual Server. Virtual Disks Manager possède une interface à onglets correspondant aux types de disques virtuels que vous pouvez créer, notamment les disques durs (dynamiques ou fixes), les disquettes et les disques de différenciation. Vous pouvez également inspecter vos disques virtuels.
Virtual Disks Manager vous permet de gérer les réseaux virtuels. Vous pouvez ajouter un réseau virtuel à partir d'un fichier de configuration réseau virtuel (VNC) ou en créer un. Lorsque vous créez le réseau virtuel, vous pouvez attacher une carte réseau hôte ou désigner le réseau comme étant pour les invités seulement. À partir de la même fenêtre, vous pouvez activer un serveur DHCP virtuel et ouvrir ses paramètres.

Gestion des machines virtuelles
Les gestionnaires précédents se concentraient tous sur la gestion de Virtual Server. Que propose VMRCplus pour créer et configurer des machines virtuelles ?
La création de machines virtuelles est relativement aisée : sélectionnez Virtual machine | Create (Machine virtuelle | Créer) dans le menu. La boîte de dialogue qui en résulte offre plusieurs paramètres par défaut équivalents à ceux de Virtual Server, mais il y a des différences sous l'interface. Par exemple, VMRCplus crée toujours deux disques durs virtuels et les connecte à SCSI. VMRCplus vous permet également de créer plusieurs machines virtuelles d'un seul coup. Il vous suffit de sélectionner « Create multiple virtual machines » (Créer plusieurs machines virtuelles) et de choisir le nombre que vous voulez. VMRCplus ajoute un trait d'union et un numéro de séquence au nom de l'ordinateur virtuel que vous fournissez.
La fonctionnalité qui permet de créer plusieurs machines virtuelles à partir d'une machine virtuelle parent est extrêmement puissante. Supposons que vous ayez créé une machine virtuelle dotée des dernières additions, Service Pack, correctifs et outils, et que vous souhaitiez l'utiliser comme base pour d'autres machines virtuelles. En supposant que vous ayez exécuté sysprep comme étape finale et fermé le parent, vous pouvez maintenant créer plusieurs machines virtuelles qui hériteront des propriétés de votre parent.
En quelques secondes, vous pouvez créer plusieurs machines virtuelles basées sur ce parent, et vous pouvez les démarrer rapidement depuis de la même référence. Quand vous n'en avez plus besoin, après une séance de tests par exemple, vous pouvez les supprimer. Et cette opération de suppression est elle aussi aisée : VMRCplus prend en charge la multi-sélection dans la liste des machines virtuelles, ainsi que le tri des colonnes. Vous pouvez donc facilement sélectionner et retirer plusieurs machines virtuelles (ce qui a pour effet de supprimer leur enregistrement), ou les supprimer (ce qui supprime également les fichiers).
Il existe d'autres commandes de sélection multiple que vous pouvez utiliser sur les machines virtuelles, telles que multi-sélectionner et démarrer, multi-sélectionner et ouvrir la console ou multi-sélectionner et enregistrer l'état. Vous pouvez effectuer ces opérations via l'interface utilisateur ou les touches de raccourci.
Il est également facile de configurer une machine virtuelle à l'aide de la page des paramètres matériels. Vous pouvez déterminer la quantité de mémoire, ajouter des contrôleurs SCSI, attacher des disques ou des images (oui, oui, par glisser-déplacer) et activer et configurer des cartes réseau. La fenêtre des propriétés avancées vous permet de déterminer les éléments de configuration avancés. Par exemple, vous pouvez exécuter des machines virtuelles sous un compte utilisateur spécifique afin de configurer une machine pour être lancée automatiquement au démarrage de Virtual Server.

Contrôle à distance
Enfin, VMRCplus propose également Console Manager qui contient les sessions de contrôle à distance (sessions VMRC) avec les machines virtuelles. Vous ouvrez une console en sélectionnant une ou plusieurs machines virtuelles en cours d'exécution et cliquez sur le bouton de console de la machine virtuelle dans la barre d'outils des propriétés.
La fenêtre de Console Manager, illustrée à la figure 3, prend en charge un tri par onglets des sessions à distance. Vous pouvez passer d'une machine virtuelle à l'autre en sélectionnant l'onglet qui lui correspond. Il y a également une barre d'outils contenant les fonctions les plus fréquemment utilisées.
Figure 3 Console Manager
Figure 3 Console Manager
Comme vous le voyez, Console Manager possède des menus contextuels qui vous permettent d'attacher une image de disquette virtuelle ou une image ISO, de monter des lecteurs hôtes et d'installer des additions actuelles. Il y a également une barre d'état qui affiche l'état des CD/DVD et disquettes, la version des additions actuelles dans la machine virtuelle, la clé de l'hôte actuellement active et le paramètre de redimensionnement de l'écran dynamique. VMRCplus vous permet de configurer la clé de l'hôte. Vous pouvez également accéder aux paramètres matériels et aux propriétés avancées des machines virtuelles.
VMRCplus offre d'autres fonctionnalités très pratiques. Par exemple, vous pouvez prendre la capture d'écran des paramètres de machine virtuelle et l'enregistrer dans un fichier au format .jpg, ce qui peut être très utile dans les scénarios de dépannage. Vous pouvez également envoyer du texte à une machine virtuelle sous forme de frappes de touches. Cette fonction n'est pas conçue comme une fonction de presse-papiers, mais elle est très pratique lorsque vous souhaitez, par exemple, copier et coller une clé de produit de l'hôte sur la machine virtuelle.
Au départ, VMRCplus a été créé par Paul Despe comme un outil de développement prenant en charge certaines fonctions de base, mais il ne couvrait pas toutes les fonctionnalités de Virtual Server. Il était utilisé à des fins de test seulement et présentait plusieurs problèmes. Il y a environ un an, j'ai pris le code et j'ai commencé à réécrire, améliorer et étendre ses fonctionnalités. Depuis, il est devenu extrêmement populaire auprès des utilisateurs de Virtual Server au sein de Microsoft. Notez, toutefois, que VMRCplus n'est pas une application prise en charge par Microsoft. Elle est fournie en l'état et est sujette au contrat de licence utilisateur final inclus.
VMRCplus a été développé pour Virtual Server 2005 Service Pack 1. Bien que les versions précédentes devraient être compatibles, il a été seulement testé avec le Service Pack 1. Par conséquent, les utilisateurs doivent mettre à jour les hôtes de leur Virtual Server avec le Service Pack 1 avant de l'utiliser. VMRCplus est disponible en téléchargement sur le site Web de TechNet Magazine à l'adresse technetmagazine.com/code07.aspx.

Matthijs ten Seldam est consultant principal chez Microsoft Consulting Services. Il est spécialisé dans les domaines de la sécurité, du déploiement et de l'automation. Il est également expert dans le domaine de la virtualisation.


 L'informatique dans l'entreprise: Calcul de la valeur de l'infrastructure informatique dans l'administration
L'informatique dans l'entreprise
Calcul de la valeur de l'infrastructure informatique dans l'administration
Acer Maamoun

Démontrer les avantages d'un investissement dans l'infrastructure informatique, matérielle et logicielle, peut s'avérer difficile dans les organisations gouvernementales. Comme dans toute autre grande organisation, les responsables doivent justifier le budget requis pour toute addition ou amélioration par une étude de cas.
Vu la diversité des méthodes de présentation d'une étude de cas, les responsables doivent choisir celle qui convient le mieux à la culture de leur organisation. Cette situation est valable aussi bien pour les organisations gouvernementales que pour les entreprises. L'alignement de l'informatique sur les autres priorités de l'entreprise est essentiel. Dans le secteur gouvernemental, les organisations informatiques ont réussi à articuler des études de cas en utilisant le concept de valeur publique dans l'approche de la création de portefeuilles de projets et d'initiatives.
L'élaboration d'une étude de cas visant à démontrer que l'amélioration de l'infrastructure mène à une meilleure productivité ou à une amélioration du service est un processus difficile. Examinons certaines solutions servant à définir et à mesurer la valeur régissant les investissements dans l'infrastructure informatique qui sont adoptées par les organisations informatiques gouvernementales.

Justification des investissements
Les organisations gouvernementales se plaignent souvent de recevoir trop de requêtes de divers services, et chaque requête, bien sûr, est urgente. Les nouvelles initiatives ont tendance à se conformer aux exigences ou aux priorités des services individuels. Ces initiatives peuvent avoir l'air d'être un assortiment aléatoire, mais elles sont souvent étroitement alignées sur la valeur publique recherchée par un service donné.
D'autre part, les coûts d'exploitation qui sont calculés en fonction du budget utilisé pour prendre en charge les opérations de services individuels peuvent masquer le coût (et la valeur) de fonctions ou services partagés à l'échelle de l'entreprise. Dans cet environnement, la valeur des investissements dans la nouvelle infrastructure ou dans les améliorations de l'infrastructure existante qui ont un impact à l'échelle de l'entreprise ou qui correspondent indirectement aux objectifs des services individuels peut être extrêmement difficile à évaluer correctement.
Par conséquent, l'organisation informatique éprouve souvent des difficultés à accepter une vision de l'informatique telle qu'elle est décrite par le GSA Federal Enterprise Architecture Framework (whitehouse.gov/omb/egov/a-1-fea.html). Dans cet environnement, la plupart des efforts visant à utiliser une vision partagée de l'architecture d'entreprise, un modèle de développement d'études de cas commun et un processus de gestion de portefeuille pour formuler des requêtes d'investissement et de dépenses informatiques sur un pied d'égalité aboutissent difficilement. Un modèle plus efficace consiste à prendre en charge un portefeuille d'activités informatiques qui optimisent les avantages de la valeur publique. Pour ce faire, il est nécessaire de sélectionner des critères de valeur publique communs et de les appliquer à tous les processus liés aux études de cas, gestion de portefeuilles, réalisation des avantages et évaluation.

Mesure de la valeur
Il existe de nombreux problèmes liés aux investissements informatiques à l'échelle de l'entreprise. Tout d'abord, ces investissements ont un impact indirect et durable en termes d'avantages pour la valeur publique. Ces avantages sont accrus par différentes parties de l'organisation, souvent de manière inégale et pas toujours facile à identifier à l'avance. De plus, les risques et les coûts qui leur sont associés sont plus facilement perçus que la valeur publique qui, elle, est plus difficile à cerner.
Une étude de cas devrait être basée sur la façon dont l'investissement dans l'infrastructure ouvre la porte à des investissements futurs et favorise les activités actuelles. Il existe différentes façons de calculer cette valeur, chacune avec ses propres avantages et inconvénients, et chacune avec un degré différent d'adéquation à la culture et maturité d'une organisation donnée.
Mathématique Ces méthodes sont basées sur une modélisation mathématique des avantages potentiels. Une méthode efficace, appelée options réelles, est basée sur la théorie financière. Elle intègre les idées de modification et de flexibilité futures en considérant explicitement le droit de prendre une mesure (c'est-à-dire l'option réelle) à un coût donné et sur une période donnée. Les options incluent le report, le développement, le transfert ou l'abandon des investissements, la modification des entrées ou des résultats et le développement de pilotes.
Les options réelles sont particulièrement appropriées lorsqu'une décision d'investissement est influencée par des événements futurs. Dans le cas de l'infrastructure informatique, ces événements peuvent inclure les éléments suivants : exigences réglementaires, demande métier ou même un événement critique tel qu'une défaillance opérationnelle majeure.
Simulation L'analyse de l'incertitude est basée sur la simulation de Monte Carlo qui utilise des outils automatisés pour calculer les résultats de scénarios alternatifs basés sur la sélection de valeurs variables et la répétition du processus. La simulation nécessite l'identification d'une plage de valeurs (telle que le nombre de postes de travail concernés ou de canaux électroniques) et la distribution de probabilité pour chaque variable. La simulation propose une plage de résultats possibles et permet d'identifier la valeur moyenne des avantages ainsi que les coûts et risques. En choisissant soigneusement les variables de valeur et de risque pour refléter l'impact possible des investissements dans l'infrastructure, vous pouvez mettre en perspective le retour de ces investissements.
Scénarios Si les modèles mathématiques ou de simulation ne sont pas pratiques ou ne sont pas adaptés à la culture et aux compétences de l'organisation, des techniques basées sur les scénarios peuvent alors être utilisées. En prenant en compte les objectifs ou la mission de l'agence, les priorités politiques et les tendances écologiques (y compris au niveau technologique), l'organisation peut développer un nombre limité de scénarios plausibles pour les trois à cinq années qui suivent. Chaque scénario doit porter exclusivement sur les avantages de l'investissement dans l'infrastructure.
Contrairement aux exercices de planification à long terme, les scénarios n'ont pas besoin d'être mutuellement exclusifs et il est possible de leur attribuer des probabilités. Les scénarios peuvent tenir compte des élections futures, des résultats de débats politiques et des événements possibles sur le marché informatique tels que les acquisitions ou les changements importants dans les stratégies des fournisseurs.
Le scénario du pire Cette variation de l'approche basée sur les scénarios est appliquée lorsque l'organisation informatique pense qu'un investissement urgent s'impose afin de répondre aux besoins imminents de l'entreprise ou de maintenir tout simplement les niveaux de service actuels. Si les problèmes d'infrastructure ne sont pas réglés, ils empirent et deviennent plus difficiles à résoudre. Les demandes de changements engendrent souvent la résistance et la critique. Un tel problème peut être partiellement résolu en mettant l'accent sur les mesures appropriées à certaines des performances en question, telles que le temps de réponse aux demandes et la durée des réparations. Ces informations doivent être largement mises à disposition afin que tous le monde soit au courant des changements de performances possibles.
Les scénarios du pire mettent intentionnellement l'accent sur les conséquences liées à l'absence d'investissement en se concentrant sur les avantages négatifs et les risques. Cette approche doit être utilisée avec beaucoup de prudence et uniquement dans des circonstances véritablement exceptionnelles. L'utilisation routinière de cette approche risque de donner l'impression que l'organisation informatique essaie de renverser les processus de gestion des investissements existants, ce qui mènerait au conflit et au désalignement que ces propres processus ont contribué à résoudre.

Choix d'une méthodologie de planification
La figure 1 résume les avantages et inconvénients de chaque méthode et son utilisation. Une fois une méthode sélectionnée, elle doit être régulièrement utilisée à travers l'organisation pour garantir la comparabilité.
Figure 1 Méthodologies d'études de cas (Close Figure 1)

Méthode Avantages Inconvénients Considérer le moment
Options réelles (mathématiques)
  • Rigoureux
  • Base théorique solide
  • Complexe
  • Non adéquat lorsque les valeurs intangibles prévalent
  • La valeur et la valeur future sont généralement quantifiables
  • Il existe une solide culture d'évaluation des investissements
  • Les compétences sont facilement disponibles
Simulation
  • Permet d'explorer d'autres valeurs
  • Manière facile de générer des alternatives
  • Les moyennes n'ont pas beaucoup de sens avec les intangibles
  • La sélection de plages dans la variable est critique
  • Les avantages tangibles prévalent
  • La prise en charge des outils est disponible
Scénario
  • Permet n'importe quelle combinaison d'avantages tangibles et intangibles
  • Permet d'explorer des scénarios très différents, combinant des techniques différentes
  • Nécessite une solide discipline pour converger vers des scénarios comparables
  • L'horizon temporel peut varier
  • Les valeurs intangibles prévalent ou la nature des avantages est incertaine
  • La culture de l'organisation est hostile à d'autres méthodes
Scénario du pire
  • Envisage efficacement les conséquences d'une absence d'investissement
  • Simple à créer
  • N'aide pas à hiérarchiser
  • Peut être utilisé à mauvais escient
  • L'investissement est absolument critique et en retard
L'efficacité de ces approches dépend d'une variété de facteurs. Pour les comprendre, il est utile de commencer par répondre aux questions suivantes : L'approche est-elle fortement intégrée ou compatible avec les processus obligatoires (tels que le budget et la planification des immobilisations) ? Est-ce que la méthode d'étude de cas choisie est facile à utiliser et capable de faire passer le message de valeur aux parties prenantes ?
Les organisations doivent atteindre un équilibre entre la flexibilité dans le choix des indicateurs de valeur qui répondent aux besoins de l'agence et les conseils visant à assurer la comparabilité à travers les agences. En outre, la possibilité d'utiliser une métrique donnée tout au long du cycle de vie de l'investissement et non pas seulement durant l'étude de cas est extrêmement importante. De même, le plan doit être adapté à différents types d'investissements.
En conséquence, une approche de valeur doit être sélectionnée et développée conjointement avec les membres de la structure de gouvernance de l'organisation. Il est essentiel que l'infrastructure sélectionnée fournisse une manière efficace de communiquer la valeur aux parties prenantes internes et externes. Ceci est vrai aussi bien pour les dirigeants d'entreprise que les responsables élus ou la direction de l'agence.
Ressources supplémentaires
  • Webcast: L'informatique en tant qu'actif stratégique
  • Série IT Manager Connections

Acer Maamoun est consultant en stratégie d'entreprise chez Microsoft. Il possède plus de 18 années d'expérience dans le domaine de la stratégie informatique et de l'alignement métier.


 Le petit c&#226;bleur: Authenticated Internet Protocol
Le petit câbleur
Authenticated Internet Protocol
Joseph Davy
Certaines parties de cet article font référence à une version préliminaire de Windows Server 2008. Ces informations sont susceptibles d'être modifiées.

Windows Vista et Windows Server 2008 (maintenant en phase de test de version Bêta) prennent tous deux en charge le protocole AuthIP (Authenticated Internet Protocol), une version améliorée du protocole IKE (Internet Key Exchange). AuthIP et IKE sont tous deux des protocoles utilisés pour déterminer le matériel de génération de clé et négocier les paramètres de sécurité pour les communications protégées utilisant
la sécurité du protocole Internet (IPsec). AuthIP propose une configuration et une maintenance de stratégie IPSec simplifiées dans de nombreuses configurations et offre une flexibilité supplémentaire pour l'authentification d'homologue IPSec. Cet article décrit les détails du protocole AuthIP et les comportements de coexistence entre homologues IPSec prenant en charge AuthIP et IKE, ou seulement IKE.

Aperçu général d'IKE
Exemples de négociation
Pour démontrer le comportement de coexistence, examinons ce qui se passe entre les homologues IPSec basés sur Windows Vista et Windows XP lors d'une tentative de négociation de protection IPSec.

Exemple 1 : Deux homologues IPSec basés sur Windows Vista en mode de requête
Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows Vista (Homologue 2). Les deux homologues sont configurés en mode de requête pour les communications entrantes comme sortantes. En mode de requête, un homologue IPSec demande la protection IPSec mais ne la requiert pas. Les messages échangés sont les suivants :
  1. Homologue 1 envoie un segment TCP de synchronisation (SYN) en texte clair, établissant une connexion TCP avec Homologue 2.
  2. Homologue 2 envoie un segment TCP d'accusé de réception de synchronisation (ACK).
  3. Homologue 1 envoie un segment TCP ACK.
  4. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant une négociation en mode principal AuthIP.
  5. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
  6. Homologue 2 répond par un message ISAKMP basé sur AuthIP, poursuivant la négociation en mode principal AuthIP.
  7. Homologue 1 et Homologue 2 terminent la négociation en mode principal, mode rapide et mode étendu (facultatif) AuthIP.
  8. Les segments suivants envoyés sur la connexion TCP sont protégés avec IPSec.
L'ordre exact des Messages 1 à 5 dépend de la latence du réseau. Les exemples décrits dans cet article correspondent à un réseau à latence très faible, dans lequel la connexion TCP (Messages 1 à 3) se termine avant qu'Homologue 1 puisse envoyer les messages ISAKMP initiaux (Messages 4 et 5). Sur un réseau à latence plus élevée, Homologue 1 enverrait le segment TCP SYN en texte clair, le message ISAKMP basé sur AuthIP et ensuite le message ISAKMP basé sur IKE comme trois premiers messages de l'échange de messages.

Exemple 2 : Homologue IPsec basé sur Windows Vista en mode de requête et homologue IPSec basé sur Windows XP en mode de requête
Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows XP (Homologue 2). Les deux homologues sont configurés en mode de requête pour les communications entrantes comme sortantes. Les messages échangés sont les suivants :
  1. Homologue 1 envoie un segment TCP SYN en texte clair, établissant une connexion TCP avec Homologue 2.
  2. Homologue 2 envoie un segment TCP SYN-ACK.
  3. Homologue 1 envoie un segment TCP ACK.
  4. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant une négociation en mode principal AuthIP.
  5. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
  6. Homologue 2 répond par un message ISAKMP basé sur IKE, poursuivant la négociation en mode principal IKE.
  7. Homologue 1 et Homologue 2 terminent la négociation IKE en mode principal et en mode rapide.
  8. Les segments suivants envoyés sur la connexion TCP sont protégés avec IPSec.

Exemple 3 : Homologue IPsec basé sur Windows Vista en mode de requête et homologue IPSec basé sur Windows XP en mode d'exigence
Dans cet exemple, un homologue IPSec basé sur Windows Vista (Homologue 1) est l'initiateur et le répondeur exécute Windows XP (Homologue 2). L'homologue 1 est configuré avec le mode de requête pour les communications sortantes et l'homologue 2 est configuré avec le mode d'exigence pour les communications entrantes. En mode d'exigence, un homologue IPSec requiert la protection IPSec et rejette silencieusement les paquets non protégés. Les messages échangés sont les suivants :
  1. Homologue 1 envoie un segment TCP SYN en texte clair établissant une connexion TCP, qu'Homologue 2 rejette silencieusement.
  2. Homologue 1 envoie un message ISAKMP basé sur AuthIP, établissant le mode de négociation principal AuthIP, que Homologue 2 rejette silencieusement.
  3. Homologue 1 envoie un message ISAKMP basé sur IKE, établissant une négociation en mode principal IKE.
  4. Homologue 2 répond par un message ISAKMP basé sur IKE, poursuivant la négociation en mode principal IKE.
  5. Homologue 1 et Homologue 2 terminent la négociation IKE en mode principal et en mode rapide.
  6. Homologue 1 retransmet le segment TCP SYN (protégé avec IPsec).
  7. Homologue 2 envoie le segment TCP SYN-ACK (protégé avec IPsec).
  8. Homologue 1 envoie le segment TCP ACK (protégé avec IPsec).

IKE est une norme Internet, définie dans la RFC 2409 (ietf.org/rfc/rfc2409.txt), qui définit un mécanisme d'établissement des associations de sécurité IPSec (les SA). Une SA est une combinaison de clés et de stratégie fixée par accord mutuel qui définit les services et mécanismes de sécurité qui aident à protéger la communication entre les homologues IPSec. En particulier, IKE combine le protocole ISAKMP (Internet Security Association and Key Management Protocol) de la RFC 2408 et le protocole Oakley Key Determination (RFC 2412). IKE utilise le protocole Oakley Key Determination pour générer le matériel de clé secret pour les communications protégées.
IKE utilise ISAKMP pour négocier des SA. ISAKMP inclut des options pour l'identification et l'authentification des homologues, la gestion des SA et l'échange du matériel de clé. ISAKMP est une infrastructure pour la négociation de communications protégées indépendante des protocoles d'échange de clés, des algorithmes de chiffrement et d'intégrité et des méthodes d'authentification spécifiques.
Les homologues IPsec utilisent IKE pour la négociation en mode principal et mode rapide. La négociation en mode principal crée la SA ISAKMP, qui protège les négociations de sécurité. Durant la négociation en mode principal, l'initiateur et le répondeur échangent une série de messages ISAKMP afin de négocier les algorithmes de chiffrement et de hachage pour la SA ISAKMP, l'échange de matériel de détermination de clé, et s'identifient et s'authentifient mutuellement.
Dans la phase de négociation en mode rapide, les deux SA IPSec (une SA pour les données entrantes et une SA pour les données sortantes) sont créées, ce qui protège les données envoyées entre deux homologues IPSec. Durant la négociation en mode rapide, l'initiateur et le répondeur échangent une série de messages ISAKMP chiffrés afin de négocier les algorithmes de chiffrement et de hachage pour les SA IPsec entrantes comme sortantes.
Pour plus d'informations sur le mode principal et le mode rapide basés sur IKE, consultez l'article « Négociation IKE pour les associations de sécurité IPSec » à l'adresse microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Présentation d'AuthIP
AuthIP est une version améliorée de IKE offrant une souplesse accrue avec prise en charge de l'authentification basée sur l'utilisateur, de l'authentification avec informations d'identification multiples, de la négociation de méthode d'authentification améliorée et de l'authentification asymétrique. Comme IKE, AuthIP prend en charge la négociation en modes principal et rapide. AuthIP prend également en charge le mode étendu, une partie de la négociation d'homologue IPSec pendant laquelle une deuxième session d'authentification peut être exécutée. Le mode étendu, qui est facultatif, peut être utilisé pour les authentifications multiples. Par exemple, en mode étendu, vous pouvez effectuer des authentifications séparées basées sur l'ordinateur ou basées sur l'utilisateur.
La prise en charge de l'authentification multiple fait partie de la mise en œuvre d'IPSec pour la plate-forme de protection d'accès réseau (NAP), dans laquelle les homologues IPSec s'authentifient avec les informations d'identification de l'ordinateur et utilisent également un certificat d'état pour prouver qu'ils sont conformes aux exigences d'état système. Pour plus d'informations sur la protection d'accès réseau, consultez la page microsoft.com/nap. Pour de plus amples renseignements sur les fonctionnalités d'AuthIP, consultez l'article « AuthIP dans Windows Vista » à l'adresse microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Messages AuthIP
IKE et AuthIP utilisent tous deux ISAKMP comme protocole d'échange de clés et de négociation de SA. Les messages ISAKMP sont envoyés via le protocole UDP (User Datagram Protocol) et consistent en un en-tête ISAKMP et une ou plusieurs charges utiles ISAKMP. L'en-tête ISAKMP contient des informations sur le message, notamment le type de message. La figure 1 représente le format de l'en-tête ISAKMP.
Figure 1 Format de l'en-tête ISAKMP
Figure 1 Format de l'en-tête ISAKMP
Dans l'en-tête ISAKMP, le cookie d'initiation et le cookie de réponse sont définis sur un nombre aléatoire différent de zéro choisi par les homologues IPSec. Le champ Charge utile suivante indique la première charge utile du message ISAKMP, juste après l'en-tête ISAKMP. La RFC 2408 répertorie les valeurs définies dans le champ Charge utile. Les types de charge utile 128 à 255 sont réservés pour l'utilisation privée. Les champs Version principale et Version secondaire indiquent les versions d'ISAKMP sur l'homologue IPSec envoyant le message ISAKMP. Pour IKE et AuthIP, la version principale est 1 et la version secondaire est 0.
Le champ Type d'échange indique le type d'échange ISAKMP effectué. Le type d'échange détermine la structure et l'ordre des charges utiles ISAKMP. La RFC 2408 répertorie les valeurs définies dans le champ Type d'échange. Les types d'échange 128 à 255 sont réservés pour l'utilisation privée.
Le champ Indicateurs contient trois indicateurs définis dans la RFC 2408. Le bit le moins significatif (le bit 0) est le bit de chiffrement, qui indique que les charges utiles ISAKMP sont chiffrées (lorsqu'il est défini sur 1) ou ne sont pas chiffrées (lorsqu'il est défini sur 0). Le chiffrement est effectué en utilisant l'algorithme négocié pour la SA ISAKMP, qui est identifié par la combinaison des champs Cookie d'initiation et Cookie de réponse. Le bit le moins significatif suivant (bit 1) est le bit Commit, qui indique que l'échange de clés est synchronisé (lorsqu'il est défini sur 1) ou n'est pas synchronisé (lorsqu'il est défini sur 0). Le bit Commit est utilisé pour s'assurer que la SA termine sa négociation avant que les données chiffrées soient envoyées. Le bit le moins significatif suivant (bit 2) est le bit Authentication Only, qui est utilisé pour indiquer que le message contient (lorsqu'il est défini sur 1) ou ne contient pas (lorsqu'il est défini sur 0) l'intégralité de la charge utile Notify du type d'échange informationnel et qu'il a été authentifié mais n'a pas été chiffré.
Le champ ID de message contient un identificateur unique au message. ID de message est utilisé pour empêcher les collisions lorsque les deux homologues IPSec tentent simultanément d'établir une SA IPSec. Le champ Longueur indique la longueur du message ISAKMP entier.
Pour IKE, le message ISAKMP contient une série de charges utiles ISAKMP. La première charge utile est indiquée par le champ Charge utile suivante de l'en-tête ISAKMP. Chaque charge utile ISAKMP possède son propre champ Charge utile suivante pour indiquer la charge utile suivante. Le champ Charge utile suivante de la dernière charge utile est défini sur 0. La figure 2 correspond au format des messages IKE.
Figure 2 Format des messages IKE
Figure 2 Format des messages IKE
AuthIP utilise les messages ISAKMP avec les types d'échange 243 (mode principal), 244 (mode rapide), 245 (mode prolongé) et 246 (Notification) dans le champ Type d'échange de l'en-tête ISAKMP. Une différence importante dans les messages ISAKMP basés sur AuthIP est qu'ils contiennent seulement une charge utile ISAKMP : la charge utile Crypto ou Notify. La charge utile Crypto contient les charges utiles intégrées utilisées pour la négociation en mode principal, mode rapide ou mode étendu. La charge utile Crypto peut contenir une série de charges utiles en texte clair ou chiffrées, en fonction du bit Encryption du champ Indicateurs de l'en-tête ISAKMP. La figure 3 correspond au format des messages AuthIP contenant la charge utile Crypto.
Figure 3 Format des messages AuthIP contenant la charge utile Crypto
Figure 3 Format des messages AuthIP contenant la charge utile Crypto

Coexistence d'AuthIP et IKE
Windows Vista® et Windows Server® 2008 prennent tous deux en charge IKE et AuthIP. Cependant, Windows® XP et Windows Server 2003 prennent uniquement en charge IKE. Un homologue IPSec initiateur qui prend en charge AuthIP comme IKE et possède une stratégie de sécurité de connexion utilisant AuthIP et IKE doit déterminer si l'homologue PSec répondant prend en charge AuthIP ou IKE. Il doit ensuite utiliser le protocole le plus approprié pour la négociation de la protection IPSec, en préférant l'utilisation d'AuthIP à celle d'IKE.
Pour déterminer le protocole de négociation de l'homologue IPSec répondant, un homologue IPSec initiateur qui utilise AuthIP et IKE envoie simultanément les messages suivants :
  • Message 1 : message AuthIP établissant la négociation en mode principal
  • Message 1 : message IKE établissant la négociation en mode principal
Si le nœud répondant prend en charge AuthIP, il doit répondre au Message 1 avec un message AuthIP poursuivant la négociation en mode principal et rejeter silencieusement Message 2. Un nœud répondant qui ne prend pas en charge AuthIP rejette silencieusement Message 1 car le champ Type d'échange qu'il contient possède une valeur qu'il ne prend pas en charge, et répond au Message 2.
Pour empêcher la négociation basée sur IKE entre deux homologues IPSec exécutant Windows Vista ou Windows Server 2008 lorsque Message 1 est abandonné par le réseau ou arrive après Message 2, les homologues IPsec exécutant Windows Vista ou Windows Server 2008 envoient Message 2 avec une charge utile Supported Vendor ID ISAKMP prise en charge par AuthIP. La charge utile Supported Vendor ID AuthIP indique que l'homologue IPsec prend en charge AuthIP.
Par conséquent, si un homologue IPSec exécutant Windows Vista ou Windows Server 2008 reçoit Message 2 avec la charge utile Supported Vendor ID AuthIP, il attend que l'homologue IPSec initiateur retransmette Message 1 et Message 2, et répond à Message 1.
L'homologue IPSec initiateur continue à retransmettre les messages 1 et 2 jusqu'à ce qu'il reçoive une réponse ou arrive à expiration. Lorsque l'initiateur reçoit une réponse, il détermine la capacité du répondeur d'après l'en-tête ISAKMP de la réponse. Si Type d'échange est défini sur 243 (type d'échange de la négociation en mode principal basée sur AuthIP), le répondeur prend en charge AuthIP. Si Type d'échange est défini sur 2 (type d'échange de la protection d'identité et de la négociation en mode principal basée sur IKE), le répondeur prend en charge IKE.
En fonction de la réponse, l'initiateur répond avec le message AuthIP suivant pour la négociation en mode principal AuthIP ou le message IKE suivant pour la négociation en mode principal IKE. Les homologues IPSec doivent utiliser le protocole qui a été utilisé pour négocier la SA ISAKMP pendant toute sa durée de vie.

Joseph Davy est rédacteur technique chez Microsoft et auteur de la rubrique en ligne mensuelle TechNet Le petit câbleur sur Microsoft.com/technet/community/columns/cableguy.


 Windows&#160;PowerShell: Travailler sans script
Windows PowerShell
Travailler sans script
Don Jones

Quand je parle de Windows PowerShell, lors d'une conférence, sur le groupe de discussion public de Windows PowerShell, voire sur mon site, je rencontre toujours des administrateurs qui me disent qu'ils « vont remettre à plus tard » leur apprentissage de Windows PowerShell. Pourquoi ? En général, la réponse est
« je n'ai pas le temps d'apprendre à créer des scripts pour l'instant ».
C'est un sentiment courant. Nous autres administrateurs avons autre chose à faire, et n'avons vraiment pas beaucoup de temps libre pour apprendre une nouvelle technologie. Cependant nous devons progresser, apprendre de nouveaux logiciels, tels que Windows Vista®, Windows Server® 2008 et Exchange Server 2007 de façon à continuer de maîtriser les technologies essentielles pour nos tâches. Windows PowerShell™ représente une grosse partie de ces technologies.
Une autre excuse qui revient souvent pour remettre au lendemain l'apprentissage de l'écriture de script dans Windows PowerShell est la « peur de se transformer en programmeur », comme un collègue administrateur l'a élégamment dit. Voici un domaine où je pourrais vous être utile. Vous serez surpris d'apprendre que vous pouvez faire des choses stupéfiantes avec Windows PowerShell, sans écrire une seule ligne de code.

Présentation du pipeline
J'ai déjà écrit sur le pipeline orienté objet, extrêmement souple et puissant, de Windows PowerShell. (L'expression « orienté objet » peut laisser entendre que je passe du côté des programmeurs, mais je m'inscris en faux). L'une des choses que je préfère avec le pipeline est qu'il peut être utilisé de façon interactive. Vous pouvez obtenir des résultats instantanés et raffiner ces résultats de façon à obtenir exactement ce que vous voulez. Par exemple, supposons que je doive souhaite obtenir un inventaire de l'espace disque disponible sur plusieurs ordinateurs distants. Admettons que les noms de ces ordinateurs figurent dans un fichier texte appelé C:\Computers.txt. C'est juste un fichier de texte brut avec un nom d'ordinateur sur chaque ligne, on est encore loin de la base de données.
Pour commencer, je vais essayer d'obtenir ces informations à partir de mon ordinateur local. Après tout, si j'y arrive sur un ordinateur, la même tâche sur plusieurs ordinateurs devrait être très facile. Et, promis, pas question d'écrire un script ! Je vais tout faire de façon interactive dans l'environnement de ligne de commande et obtenir des résultats dès que j'appuierai sur la touche Entrée.
Quelques petites informations techniques. Lorsque vous devez faire l'inventaire des informations de gestion sur des ordinateurs distants, il est recommandé d'utiliser Windows® Management Instrumentation (WMI). Maintenant, supposons que, dans le cadre de cet exemple, je ne sache plus rien sauf qu'il faut utiliser WMI. Je passe donc sur Live Search et tape « Windows wmi espace disque disponible » comme terme de recherche. Plusieurs résultats remontent avec l'expression « Win32_LogicalDisk » dans l'extrait. Il me semble que c'est une classe WMI, peur-être même celle que je recherche. Je ne vais pas me fatiguer à cliquer sur les autres résultats. Par contre, j'entre « Win32_LogicalDisk » comme nouveau terme de recherche et l'un des premiers résultats renvoie sur une page de documentation Win32_LogicalDisk du site MSDN® (msdn2.microsoft.com/aa394173.aspx). Donc j'ouvre la page et vois que l'une des propriétés de cette classe est FreeSpace, ce qui semble très prometteur.

Recherche d'une applet de commande
Pour l'étape suivante, je dois rechercher une applet de commande qui récupérera les propriétés d'une classe WMI. L'un des aspects les plus remarquables de Windows PowerShell est qu'il dispose de fonctionnalités intuitives extraordinaires, en clair son environnement de ligne de commande se laisse découvrir facilement. Donc je tape Help *WMI* pour découvrir ce que l'environnement de ligne de commande sait du fonctionnement avec WMI. Les résultats, illustrés à la figure 1, sont l'alias Gwmi et son applet de commande cible, Get-WMIObject. En fait, vous disposez de deux accès à la même fonctionnalité, ce qui signifie que je n'ai pas à me torturer les méninges pour savoir laquelle utiliser. Les deux font la même chose et Gwmi est plus court à taper, je vais donc l'utiliser :
Figure 1 Ce que l'environnement de ligne de commande sait sur WMI
Figure 1 Ce que l'environnement de ligne de commande sait sur WMI
PS C:\> gwmi win32_logicaldisk
Windows PowerShell n'est pas sensible à la casse, il sait que nous autres administrateurs n'avons pas le temps de nous arrêter sur des détails secondaires, tels que l'utilisation de la touche majuscule.
Les résultats de cette commande, illustrés à la figure 2, incluent mes cinq lecteurs locaux et leurs propriétés FreeSpace, qui semblent exprimées en octets. Je trouve également une propriété DriveType pour chacun de ces lecteurs et je vois des valeurs de 2, 3 et 5 sur mon ordinateur.
Figure 2 Tous mes lecteurs locaux et leurs propriétés FreeSpace
Figure 2 Tous mes lecteurs locaux et leurs propriétés FreeSpace

Applet de commande du mois
Vous auriez pu utiliser Get-Content pour lire le contenu d'un fichier texte. Il traite chaque ligne du fichier comme un objet [de chaîne], transmettant ces objets aux autres applets de commande via le pipeline. Mais Get-Content dispose d'un certain nombre d'options qui le rendent plus souple : Le paramètre -readCount, par exemple, permet de spécifier le nombre d'objets [de chaîne] transférés à la fois dans le pipeline (la valeur par défaut consiste à tout envoyer), tandis que le paramètre –totalCount contrôle le nombre total de lignes lues dans le fichier. Deux de ces paramètres sont utiles pour manipuler de très gros fichiers qu'il peut être intéressant de traiter par sections pour des raisons de performances.
Voici une autre option qui vous facilitera la vie. Le paramètre -encoding permet de lire correctement un large éventail de types de codage de fichiers, notamment Unicode, ASCII, UTF7, UTF8 et bien d'autres. Pour consulter la liste complète des types de codage pris en charge, exécutez help gc (gc est un alias pour Get-Content).

Tri des données
À ce stade, j'ai deux problèmes. Tout d'abord, toutes ces propriétés m'ennuient, je cherche FreeSpace. Ensuite, je ne veux pas savoir quel est l'espace libre sur les lecteurs optiques, les lecteurs amovibles ou les unités réseau. Seuls les disques durs locaux m'intéressent. Cette propriété DriveType pourra sans doute m'aider à faire la distinction. Je reviens à mon navigateur Web et constate que la documentation contient un tableau expliquant les différentes valeurs de DriveType. Je recherche DriveType 3, qui indique que le lecteur est un disque dur local. Je décide de voir si la commande Gwmi peut filtrer mes données. L'exécution de Help Gwmi –full indique de façon détaillée comment la commande fonctionne et donne quelques exemples. Je vois un paramètre qui paraît utile, –filter, et décide de l'essayer :
gwmi win32_logicaldisk -filter "drivetype = 3"
Ça marche ! Ma liste de lecteurs contient uniquement les disques fixes locaux. Mon deuxième problème est résolu. Je vais pouvoir revenir sur le premier et me débarrasser de toutes les propriétés dont je ne veux pas.
J'exécute Get-Command pour obtenir la liste de toutes les applets de commande de Windows PowerShell et je finis par trouver Select-Object. La description dit que cette applet « sélectionnera les propriétés spécifiées d'un objet ou d'une série d'objets ». Donc j'essaye ceci :
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
En canalisant les résultats de Gwmi vers Select (l'alias de Select-Object) j'obtiens précisément la propriété voulue. Oups. Ces résultats ne sont pas si bons que ça, car j'ai juste une liste de numéros, je ne sais pas à quels lecteurs correspondent ces chiffres et les valeurs d'espace libre. Donc je reviens à la documentation et vois que la propriété DeviceID contient la lettre de lecteur. Je retape rapidement ma commande et essaie à nouveau :
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
Parfait ! Et puisque seules deux propriétés sont dans la liste, l'environnement de ligne de commande est capable de placer les informations dans un joli tableau. (Le mois prochain j'expliquerai comment Windows PowerShell choisit d'utiliser des listes ou des tableaux).

Calcul
J'ai récupéré des informations sur l'espace libre, mais c'est en octets et ce n'est pas vraiment aussi utile que les méga-octets ou les giga-octets. Il est clair que la propriété FreeSpace ne suffit pas à elle seule, il me faut plutôt une valeur calculée à partir de cette propriété. L'applet de commande ForEach-Object (ou l'un de ses nombreux alias, tels que %) peut m'aider. Cette applet de commande me permet d'utiliser une variable spéciale, $_, pour référencer le disque logique actif et d'accéder séparément aux propriétés des disques et de faire un ou deux calculs. Voici ma commande modifiée :
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
Tout ce que j'ai fait ici a été de supprimer Select et de le remplacer par l'alias de ForEach-Object (%). Cette applet de commande veut simplement savoir ce qu'elle doit faire avec chaque Win32_LogicalDisk rencontré et je lui ai dit d'obtenir la propriété DeviceID et de diviser la propriété FreeSpace par un gigaoctet. Windows PowerShell « sait » ce qu'est un Ko, un Mo et un Go, par conséquent mon résultat sera en gigaoctet.

De nombreux ordinateurs
Maintenant que ceci fonctionne pour un ordinateur, il est temps de l'appliquer à plusieurs systèmes. Je sais comment obtenir le contenu d'un fichier texte. Pour cela il suffit de procéder comme au bon vieux temps de MS-DOS®, avec la commande Type, qui dans Windows PowerShell se trouve être un alias de Get-Content.
Type c:\computers.txt
Je veux passer sur tous ces ordinateurs et exécuter la commande WMI que j'ai déjà utilisée. L'applet de commande ForEach Object porte bien son nom. C'est donc le moment de tout révéler, comme dans les émissions de décoration à la télé, et de regarder ma commande finale :
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
Effrayant, n'est-ce pas ? Du fait de mon usage exclusif des alias au lieu des noms d'applet de commande, c'est dur à lire. Cependant, c'est assez facile à déchiffrer si vous prenez les différents éléments un par un :
  • Je commence par « typer » le contenu de mon fichier texte.
  • Je canalise son contenu vers ForEach-Object.
  • ForEach-object renvoie l'élément actuel, avec la variable $_. (Le nom de l'ordinateur actif.)
  • ForEach-Object exécute ensuite ma commande WMI, qui contient un autre appel de ForEach-Object.
Le développement de ces noms d'alias en noms d'applet de commande facilite les choses. Voici donc la même commande, mais cette fois-ci j'ai explicité les applets de commande et réparti la commande sur plusieurs lignes pour examiner chaque section plus facilement :
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
Les résultats, pas très esthétiques mais fonctionnels, sont illustrés à la figure 3.
Figure 3 Les résultats définitifs
Figure 3 Les résultats définitifs

Pas de script
Le but de cette procédure détaillée est de démontrer que vous pouvez utiliser Windows PowerShell sans aucun script. Et, avec juste quelques exemples comme celui-ci, assortis d'un peu d'exploration dans Windows PowerShell même, vous pourrez trouver tous les éléments nécessaires pour accomplir les tâches que vous vous êtes fixées.
Windows PowerShell est ici pour durer. Pourquoi ne pas commencer à apprendre comment l'utiliser dès maintenant ? Vous finirez par vous demander comment vous avez pu vous en passer et le spectre d'un script ne vous empêchera plus de vous y plonger.

Don Jones est le gourou principal des scripts chez SAPIEN Technologies et formateur pour Scriptingtraining Com. Vous pouvez le joindre par le biais de son site Web à l’adresse suivante : ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: Que Silverlight soit
Hé, vous le scripteur !
Que Silverlight soit
Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_10.exe (156KB)

L'histoire de l'humanité a longtemps été marquée par des affrontements entre des forces diamétralement opposées : les Romains contre les hordes barbares ; les Hatfield contre les Mccoy ; les scripteurs contre ceux qui croient qu'une chronique sur les scripts d'administration système devrait vraiment parler de script d'administration système plutôt que de conflits historiques entre des forces diamétralement opposées. [Ou, par exemple, de crochets à viande... —Ed].
Le monde informatique n'est pas à l'abri de ces conflits entre forces diamétralement opposées. Nous pensons en particulier au conflit entre les développeurs et les administrateurs système. Comme l'a dit Karl Marx en examinant la situation : « Ou cet homme est mort ou ma montre s'est arrêtée ».
Heu... désolé, en fait c'était Groucho Marx. Karl Marx a dit, « l'Art est toujours et partout l'aveu secret et, simultanément, le mouvement immortel de son époque ». À dire vrai, nous n'avons aucune idée que ce que cela peut bien vouloir dire. En plus, Groucho Marx était bien plus drôle que Karl Marx, même si les mots d'esprit de Groucho ne s'appliquent pas particulièrement bien au conflit entre les développeurs et les administrateurs système.
Néanmoins, nous sommes assez sûrs que c'est Karl Marx qui obligeait les scripteurs à réciter le serment d'allégeance à l'automatisation chaque matin avant de commencer à travailler : « Les administrateurs système ne sont pas des développeurs ». Et c'était incontestablement vrai : les administrateurs système n'étaient pas des développeurs. Les développeurs étaient des personnes qui écrivaient des programmes logiciels alors que les administrateurs système étaient des individus qui ... eh bien, pour vous dire la vérité, nous ne sommes pas sûrs que quelqu'un chez Microsoft ait jamais vraiment su ce que faisaient les administrateurs système. Mais quoi qu'ils fissent, ils n'écrivaient assurément pas des programmes informatiques.
Bien sûr, Karl Marx a également écrit la chanson « Les temps changent » (Ou du moins, c'est ce qu'il nous a affirmé).
Grâce en partie au Centre de scripts TechNet (microsoft.com/TechNet/scriptcenter), les administrateurs système ont progressivement découvert VBScript et ont commencé à écrire leurs propres utilitaires qui, s'ils n'étaient pas aussi achevés et exhaustifs qu'un programme informatique classique, effectuaient néanmoins des tâches de gestion utiles. En écrivant ces utilitaires, les administrateurs système ont eu à faire appel à des compétences très semblables à celles utilisées par les développeurs.
Et ce n'est qu'une partie de l'histoire. L'avènement de Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) signifie que Microsoft® .NET Framework n'est plus hors de portée des administrateurs système et auteurs de scripts. Windows Vista® a familiarisé le monde avec les gadgets (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx), mettant ainsi les administrateurs système (ou du moins les administrateurs système qui écrivent des scripts) sur un pied d'égalité avec les développeurs. Et maintenant (roulement de tambour, s'il vous plait) voici Microsoft Silverlight, le « plug-in internavigateur et interplates-forme conçu pour offrir la nouvelle génération d'expériences média basées sur .NET Framework et de riches applications interactives destinées au Web ».
Cela semble impressionnant, n'est-ce pas ? Vous vous demandez ce que cela a à voir avec des auteurs de scripts d'administration système tels que vous ? Pour être honnête, nous n'en sommes pas entièrement sûrs. Cependant, Silverlight facilite énormément la création d'interfaces utilisateur et de présentations multimédias particulièrement sympathiques. Et bien que la documentation marketing présente immanquablement Silverlight comme un moyen de créer des applications Web, voici un fait peu connu : Silverlight semble fonctionner aussi bien dans les applications HTML que HTA (microsoft.com/technet/scriptcenter/hubs/htas.mspx), un support très apprécié des rédacteurs de scripts. Par conséquent, vous auriez peut-être intérêt à prendre le temps d'essayer Silverlight.

Avant de poursuivre ...
Nous devons vous préciser que nous n'aborderons pas les nombreuses fonctionnalités et utilisations potentielles de Silverlight aujourd'hui ; notre objectif principal est de vous présenter suffisamment d'extraits de code pour vous permettre de commencer à expérimenter cette technologie. Si vous aimeriez installer Silverlight (à propos, c'est gratuit), rendez-vous sur la page d'accueil de Silverlight à l'adresse microsoft.com/silverlight. Vous trouverez également des SDK, exemples de projets et bien d'autres choses utiles à l'adresse silverlight.net/GetStarted.
Pour le moment, nous allons supposer que vous avez déjà installé Silverlight. Nous supposerons également que vous vous êtes rendu dans la section de téléchargements de codes du site Web de TechNet Magazine (technetmagazine.com/code07.aspx) et que vous avez téléchargé les fichiers décrits à la figure 1.
Figure 1 Composants d'un projet Silverlight (Close Figure 1)

Fichier | Description
CreateSilverlight.js | Il s'agit d'un script JScript (dans sa version initiale, Silverlight ne prend en charge que les scripts JScript) servant à spécifier les paramètres initiaux de démarrage de Silverlight, y compris le fichier XAML utilisé pour configurer l'interface utilisateur et les objets graphiques.
SampleProject.js | Il s'agit simplement d'un fichier blanc où vous pouvez mettre des fonctions JScript.
Silverlight.js | Ce fichier sert à initialiser la commande Silverlight.
SampleProject.html | C'est le fichier le plus excitant. SampleProject.html est simplement un fichier HTML qui inclut le code de lecture des trois fichiers .js. Il inclut également le code permettant d'instancier la commande Silverlight.
SampleProject.xaml | À quoi est-ce que cela sert ? Pour le découvrir, il faut que vous reveniez à la partie principale de cette rubrique.
Vous n'avez pas forcément besoin de SampleProject.js, du moins pas dans le cadre de la chronique de ce mois. Silverlight vous permet de joindre des scripts aux objets et événements de votre projet ; ces scripts peuvent être codés en dur dans votre fichier HTML ou (comme dans c'est le cas ici) être lus depuis un fichier « include » extérieur tel que celui-ci. Nous allons également transformer SampleProject Html en fichier HTA : il suffit de le renommer SampleProject hta. C'était facile, n'est-ce pas ?
Veillez à enregistrer tous ces fichiers dans un dossier. Ensuite, préparez-vous à vous amuser.

Le fichier XAML
Comme vous l'avez peut-être deviné, ce mois-ci Hé, vous le scripteur ! s'intéresse principalement au fichier XAML. (Incidemment, XAML est prononcé « zamel, », qui rime avec caramel. Ou avec hydromel. Ou même avec rimmel.) XAML est l'acronyme d'Extensible Application Markup Language. Entre autres choses, XAML fournit un moyen de créer des interfaces utilisateur à l'aide d'un langage semblable au XML. Est-ce qu'il est ainsi plus facile pour une personne, plus particulièrement un administrateur système, de créer des interfaces utilisateur ? C'est ce que vous allez découvrir.
Pour entamer cette quête, lancez le Bloc-notes et ouvrez le fichier SampleProject.xaml. Si vous voyez un code existant, remplacez-le par le code suivant :
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
Remarque. SampleProject hta est déjà préconfiguré pour charger des informations provenant de SampleProject.xaml. Pour utiliser un fichier XAML différent, vous devez modifier le fichier CreateSilverlight.js.
Après avoir collé le code, enregistrez le fichier et double-cliquez ensuite sur SampleProject.hta. Devinez ce que vous allez voir ? C'est bien cela : un grand cadre gris et vide.
Mais attendez, ne partez pas ! C'est exactement ce que vous êtes censé voir.
S'il n'y a pas grand chose à voir, c'est que nous n'avons encore rien fait : en effet, jusqu'à présent, nous nous sommes contentés d'ajouter un canevas à notre fichier XAML. Mais c'est une étape importante. Après tout, si vous voulez vous essayer à la peinture à l'huile, vous devez commencer par trouver un canevas sur lequel peindre. Il en va de même dans Silverlight : pour pouvoir commencer à ajouter des éléments à notre projet, nous avons d'abord besoin d'un canevas sur lequel « peindre ». Et maintenant nous en avons un.
Au fait, pourquoi avons-nous obtenu une boîte grise de 300 pixels de large sur 300 pixels de haut ? C'est simple : il s'agit des spécifications figurant, par défaut, dans le fichier CreateSilverlight.js. Si vous n'aimez pas ces valeurs par défaut, il vous suffit d'ouvrir CreateSilverlight.js et de modifier les paramètres à votre gré. Est-ce que vous préfèreriez un canevas blanc de 800 pixels de large sur 300 pixels de haut ? (Ce qui serait préférable pour les exemples que nous sommes sur le point d'utiliser.) Alors assurez-vous simplement que CreateSilverlight.js contient les trois lignes suivantes :
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
Remarque. Voilà une remarque judicieuse : dans le fichier .js d'origine, l'arrière-plan est défini sur #D6D6D6. Maintenant, nous l'avons défini sur blanc. Il se trouve que, dans un fichier XAML vous pouvez utiliser des valeurs RVB pour représenter des couleurs, ou vous pouvez utiliser des noms de couleur pour représenter des couleurs. (Voir msdn2.microsoft.com/bb188314.aspx pour obtenir la liste complète des valeurs de couleurs et des noms de couleurs.) Bien que les scripteurs aiment appeler les couleurs par leurs valeurs RVB (« Ma maison ? C'est une FFFFFACD avec un habillage FFCD5C5C »), nous avons décidé ici d'utiliser les noms de couleurs.
Petit tuyau cadeau : vous n'êtes pas tenu de vous limiter à des couleurs unies pour l'arrière-plan du canevas. Copiez et collez le code présenté à la figure 2 dans votre fichier XAML et voyez que vous obtenez.
Figure 2 Jolies couleurs (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Vous avez essayé ? Plutôt génial, pas vrai ?
Bien sûr, un canevas blanc tout bête n'a pas grand intérêt. C'est pourquoi nous allons poursuivre et ajouter des objets à ce canevas. Bien que Silverlight vous permette d'ajouter toutes sortes d'objets différents (y compris des ellipses, rectangles, lignes et polygones), nous ajouterons un bon vieux bloc de texte à notre canevas. Comment ? En insérant les balises suivantes entre les balises <Canvas> et </Canvas> tags dans notre fichier XAML :
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
Comme vous pouvez le voir, le XAML n'est vraiment pas difficile à utiliser. Nous allons commencer par utiliser la balise <TextBlock>, en veillant à faire figurer les paramètres TextBlock (tels que Name et FontSize) à l'intérieur de la balise. Nous indiquerons ensuite que nous en avons terminé avec notre TextBlock en utilisant la balise </TextBlock.> Ce qu'il y a de chouette à ça ? C'est à peu de choses près ainsi qu'il faut procéder pour ajouter n'importe vous quel objet à un fichier XAML. Vous souhaitez ajouter un rectangle de 300 pixels de large sur 100 pixels de haut ? Pas de problème :
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
Au fait, lorsque vous ajoutez une forme (un rectangle par exemple) à votre canevas, pensez à indiquer une couleur de remplissage et/ou une couleur de trait. Si ne vous faites pas, Silverlight ajoutera un rectangle transparent au canevas. Le rectangle sera bien présent, mais à moins de disposer de la vision laser de Superman, vous ne pourrez pas le voir.
Puisque nous parlons des couleurs de remplissage et de trait, sachez que c'est ainsi que vous pouvez colorer certains objets Silverlight. Pour d'autres objets, vous devez utiliser un pinceau, comme le LinearGradientBrush que nous vous avons montré (mais dont nous n'avons pas parlé) dans notre tuyau cadeau. Si vous préférez peindre les objets d'une couleur unie, vous pouvez utiliser ce que l'on appelle avec justesse le SolidColorBrush. Par exemple, examinez les balises XAML de la figure 3 qui « peignent » notre texte (techniquement, cela peint la propriété Foreground de TextBlock) en rouge.
Figure 3 Peindre un texte (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Pour un effet encore plus intéressant, essayez la propriété ImageBrush, qui remplit le texte avec une image :
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
Et voici encore un autre tuyau : si vous essayez la propriété ImageBrush, vous voudrez sans doute augmenter la valeur de FontSize parce que plus le texte est grand, meilleur est l'effet produit.
Faites un essai et voyez ce que vous obtenez. Vous serez favorablement impressionné.

Mais attendez : vous n'avez encore rien vu.
Nous devons être honnêtes avec vous : jusqu'ici, nous nous étions réservé le meilleur. S'il est agréable de pouvoir afficher du texte dans Silverlight, il est encore plus agréable de pouvoir dessiner des rectangles, des ellipses et des polygones. Mais tout ceci n'est encore rien face aux animations qui peuvent être ajoutées à un projet Silverlight.
Une fois encore, rappelons que dans cet article, nous ne pouvons que vous présenter certaines des façons dont vous pouvez créer une animation Silverlight car nous n'avons tout simplement pas la place d'en expliquer davantage. (Ne nous en veuillez pas; nous n'arrêtons pas de suggérer que TechNet Magazine devienne Hé, vous le scripteur ! Magazine, mais apparemment nos messages électroniques n'atteignent pas leur destination.)
Sans plus de cérémonie, voici un effet intéressant grâce auquel notre texte s'estompe lentement (mais sûrement) et disparaît. Ajoutez le code de la figure 4 entre les balises <TextBlock> et </TextBlock> dans votre fichier XAML.
Figure 4 Astuces pour TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Il est vrai que cela peut sembler compliqué mais, heureusement, une bonne partie de tout ceci est tout simplement du balisage réutilisable. Pour commencer, vous ne pouvez pas simplement ajouter une animation à un fichier XAML : vous devez indiquer quand cette animation est supposée être lue. Pour cela, il convient de préciser une série de déclencheurs pour TextBlock. Dans le cas présent, nous allons créer un déclencheur qui démarrera l'animation chaque fois que TextBlock est chargé :
<EventTrigger RoutedEvent="TextBlock.Loaded">
Dans Silverlight, les animations doivent avoir lieu sur une table de montage séquentiel ou storyboard (un terme emprunté à l'industrie cinématographique). C'est à cela que servent les balises <BeginStoryboard> et <Storyboard.>
Pour que notre texte s'estompe, nous devons modifier la propriété Opacity. Nous augmenterons graduellement la valeur de 0,0 (transparent) à 1,0 (couleur unie). Comme la propriété Opacity se trouve être une propriété double (une propriété basée sur une valeur numérique à double-précision), nous utilisons une animation DoubleAnimation. Vous vous demandez comment faire pour utiliser une animation DoubleAnimation ? Eh bien, en indiquant l'objet que nous voulons animer (dans le cas présent il s'agit de Test, le nom nous avons donné au TextBlock), en précisant la propriété cible (Opacity) et en indiquant ensuite la plage d'animation (de 0,0 d'opacité à 1,0 d'opacité) et la durée de l'animation complète (5 secondes). En d'autres termes :
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
Remarque. Veillez à utiliser la syntaxe 0:0:5 (heures, minutes, secondes) afin d'indiquer 5 secondes. L'utilisation de la valeur 5 seule ne produira pas une erreur, mais l'animation prendra cinq jours pour s'achever.
Avez-vous essayé cela ? Maintenant, essayez ceci : Dans la balise DoubleAnimation, définissez la propriété AutoReverse sur True :
AutoReverse="True"
votre animation apparaîtra en fondu, puis disparaîtra à nouveau.
Définissez la propriété RepeatBehavior sur Forever et votre texte continuera d'apparaître et disparaître en fondu pendant... en fait, éternellement.
RepeatBehavior="Forever"
L'éternité vous semble-t-elle un peu longue ? Alors définissez RepeatBehavior sur 3x, par exemple, pour que l'animation s'exécute trois fois puis s'arrête.
RepeatBehavior="3x"
Plutôt sympa, à notre avis. Cependant, que faire si vous n'aimez pas que le texte apparaisse et disparaisse en fondu et que vous préférez qu'il change graduellement de couleur ? Dans ce cas, vous devriez utiliser une animation ColorAnimation :
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
Remarque. Pensez juste à vérifier que vous commencez avec un texte rouge si vous essayez cet effet. Rappelez-vous que nous vous avons déjà montré comment peindre votre texte en rouge.
C'était amusant, n'est-ce pas ? Et pourtant, vous semblez un peu déçu. En voilà sans doute la raison : l'animation ColorAnimation était plaisante, mais vous espériez pouvoir faire véritablement voler des choses tout autour de l'écran. Allons, ne boudez pas. Quel genre de logiciel serait donc Silverlight s'il ne vous permettait pas de faire voler des objets sur votre écran ? Essayez ce qui suit :
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
Comme vous pouvez le voir, nous obligeons notre TextBlock à quitter lentement sa position de départ pour se diriger vers un endroit situé à 150 pixels du bord gauche du canevas (Canvas.Left). Si nous voulions déplacer TextBlock vers le haut et le bas, nous utiliserions simplement la propriété Canevas.Top :
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
Serait-il alors possible (notre cœur bat à tout rompre) de combiner ces animations pour que TextBlock se déplace d'un côté à l'autre et de haut en bas ? Nous en restons sans voix. Mais voici une suggestion : Collez les deux animations dans votre fichier XAML (l'un juste après l'autre) et voyez ce qui se passe.
Remarque. OK, nous vous avons menti : nous savions dès le départ qu'il était possible d'associer ces animations. En fait, vous pourriez ajouter une foule d'animations dans un seul projet Silverlight. C'est un peu compliqué, et vous devrez probablement inclure des balises supplémentaires pour vous assurer qu'une animation s'achève avant que la suivante ne commence. Mais cela vous permet également de réaliser des animations plutôt sophistiquées simplement en saisissant quelques balises de type XML.

Désolé, les gars, c'est tout pour aujourd'hui.
Oui, oui, nous aussi nous détestons l'idée de vous quitter, surtout qu'on commençait à peine à s'amuser. Mais ne vous inquiétez pas, ce n'est pas un adieu. Si vous aimeriez en savoir plus sur Silverlight, envoyez-nous un petit mot à l'adresse scripter@microsoft.com. Si un nombre suffisant de personnes est intéressé, nous verrons ce que nous pouvons présenter à ce sujet dans les chroniques à venir. En outre, n'oubliez pas de visiter TechNet Script Center (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx) car nous y afficherons des liens vers des exemples complets de XAML à votre intention. D'ici là, comme Karl Marx et Frederick Engels le disaient à la fin de leur Lettre du Comité de correspondance communiste de Bruxelles à G.A Kottgen : « Bonne nuit, et prudence sur la route ».

Les scripteurs Microsoft travaillent pour (enfin, sont employés par) Microsoft. Lorsqu’ils ne sont pas en train de jouer au base-ball, d’entraîner une équipe ou de regarder un match (ou de se livrer à de multiples autres activités), ils dirigent le Script Center TechNet. Vous pouvez le vérifier vous-même sur www.scriptingguys.com.


 Vigilance s&#233;curit&#233;: BitLocker et le d&#233;licat probl&#232;me de la confiance
Vigilance sécurité
BitLocker et le délicat problème de la confiance
Justin Troutman

Windows Vista. Je n'ai encore jamais abordé ce sujet dans un article jusqu'ici, ce qui explique que la rédaction de cette rubrique me procure le même émoi que celui éprouvé par un enfant entrant dans un magasin de jouets à qui l'on a dit de choisir ce qu'il veut. En effet, je pourrais aborder un grand nombre de fonctionnalités, explorer bien des aspects, orienter la discussion sur de nombreux sujets.
Il n'y a pas très longtemps, je lisais le blog du grand manitou de la sécurité, Bruce Schneier, lorsque je suis tombé sur la mention d'un produit que je ne connaissais pas : BitLocker™. J'ai vite compris qu'il était destiné à fournir une fonctionnalité de chiffrement dans Windows Vista® et j'ai immédiatement tiqué en m'écriant : « Oh non. Windows Vista s'occupe de chiffrement ? Ça ne peut pas valoir grand chose. Et même s'il n'est pas mauvais, il y a forcément une porte dérobée quelque part. »
Certains arguments historiques (valide ou pas) permettent de comprendre pourquoi certaines personnes hésitent à faire confiance aux fonctionnalités de sécurité incluses dans Windows®. Mais ce n'est pas ce qui m'a poussé à écrire cette rubrique. Mon désir est plutôt de vous présenter les raisons valables qui justifient, à mon avis, que l'on donne une chance à BitLocker. Je souhaite également donner mon avis sur le genre de philosophie qui permet d'assurer la vitalité des logiciels et matériels de chiffrement.
Mais ne vous y trompez pas : je ne propose pas BitLocker comme une panacée universelle en matière de sécurité. BitLocker est juste l'une des nombreuses pièces composant le puzzle de la sécurité. Son objectif est d'offrir de la résilience face à certains types de menaces.
BitLocker s'intéresse plus particulièrement à la sécurité des ordinateurs portables perdus ou volés. Les employés mobiles transportent sans cesse toutes sortes d'informations confidentielles dans une multitude de lieux : trains et avions, restaurants et hôtels, bureaux à domicile et succursales. Or ils transportent ces informations sur des portables et autres périphériques mobiles qui, le plus souvent, ne disposent d'aucune sécurité réelle et rendent les données qu'ils contiennent extrêmement vulnérables. Alors qu'arrive-t-il à ces données lorsqu'un utilisateur oublie un ordinateur portable quelque part ?
S'il n'est pas possible d'éliminer le manque de rigueur caractéristique de la nature humaine, vous pouvez heureusement limiter les problèmes susceptibles d'en découler. Pour une entreprise, le coût du remplacement d'un ordinateur portable est minime par rapport au coût du traitement de données confidentielles qui ont été compromises. C'est le type de sécurité que BitLocker cherche à fournir.

Crédits
J'aborde BitLocker d'une manière un peu étrange... c'est que, voyez-vous, je ne l'ai pas encore essayé. Je sais que vous vous demandez probablement comment quelqu'un qui n'a même pas essayé BitLocker a pu se forger une opinion à son propos et, a fortiori, avoir quelque chose à en dire. Laissez-moi m'expliquer. Ce que je souhaite surtout, c'est débattre du chiffrement à un plus haut niveau et des philosophies de conception qui jouent un rôle essentiel dans l'élaboration d'une solution efficace.
Tout ceci trouve son origine dans le contenu du blog de Bruce Schneier. Imaginons que vous ayez envie de voir un certain film. En fonction de ce que vous avez vu de la bande-annonce et du choix des acteurs principaux, vous avez fait des suppositions sur ce film. Une bonne distribution, c'est vrai, ne garantit pas que le film sera bon. Cependant, la liste des acteurs est parfois très révélatrice sur le film et sur ce que vous pouvez sans doute en attendre. Les rôles principaux sont-ils tenus par Chris Rock et Ben Stiller ? Ou est-ce un film réunissant Kate Winslet et Johnny Depp ?
Dans le même ordre d'idée, lorsque j'ai découvert qu'un grand manitou de la sécurité internationalement respecté parlait de BitLocker sur son blog, j'en ai tiré quelques conclusions. Tout d'abord, je me suis dit que cette nouvelle technologie était soit suffisamment bonne pour mériter une mention honorable soit si ridiculement mauvaise qu'il fallait la dénoncer publiquement. À ma grande surprise, le verdict final de Bruce Schneier était positif.
Une phrase, en particulier, retenait l'attention : « Il n'y a pas de porte dérobée pour la surveillance policière ». C'est une déclaration marquante. Elle était faite avec beaucoup d'assurance et s'accompagnait d'un lien vers le blog de l'équipe chargée de l'intégrité des systèmes chez Microsoft®. J'ai suivi ce lien, ce qui m'a conduit jusqu'à un commentaire de Niels Ferguson, un développeur s'occupant de sécurité chez Microsoft, lequel s'élevait contre des rumeurs spéculatives selon lesquelles Microsoft aurait intentionnellement inclus des portes dérobées dans BitLocker à des fins d'application de la loi. Ferguson déclarait sans ambages que les portes dérobées étaient inacceptables et qu'il ne participerait à aucun projet qui les prendrait en charge. (Il expliquait également que même si Microsoft était contraint par la loi à inclure une porte dérobée, l'entreprise l'annoncerait publiquement ou retirerait carrément ce produit.)
La signature au bas de cette annonce (celle de Niels Ferguson) explique la confiance de Schneier, et a suscité le même sentiment en moi. Ferguson est quelqu'un qui sait de quoi il parle et son expérience professionnelle permet d'avoir confiance dans ses affirmations. Bruce Schneier et Niels Ferguson sont les coauteurs de Practical Cryptography (un ouvrage de séminaire sur l'application simple, correcte et sécurisée d'un bon système de chiffrement). Ce sont également les co-concepteurs de l'algorithme de chiffrement par bloc Twofish, un réseau de Feistel de 128 bits qui a prouvé sa valeur en parvenant à se classer parmi les finalistes du concours AES (Advanced Encryption Standard).
Bien sûr, disposer d'un cryptographe aguerri sur un projet ne garantit pas que le produit final sera sûr. Même les maîtres de cet art sont faillibles. Mais indépendamment du comportement de BitLocker dans le temps, vous pouvez au moins être certain que de solides stratégies conceptuelles ont contribué à sa création.
Puisque nous parlons d'erreurs, on peut citer les tentatives de bonne foi de développeurs sans aucun sens de ce qu'est le chiffrement, et les tentatives de mauvaise foi de ceux qui cherchent surtout à sortir un produit. Ces deux attitudes, indépendamment de l'intention à leur origine, ouvrent la porte à des failles de sécurité. Ce n'est pourtant pas le cas avec BitLocker, semble-t-il. Le fait qu'au moins un cryptographe compétent ait été impliqué et que de nombreuses ressources soutiennent cet effort est de bon augure.

Quand on parle de confiance
Il y a peu de temps, Phil Zimmerman, le créateur du logiciel de chiffrement PGP, m'a fait part de certaines règles de base. Si l'on publiait un jour un « Credo de sécurité pour les développeurs », ses conseils arriveraient certainement en tête de liste. Bien que ses remarques ne se soient pas spécifiquement adressées à BitLocker, les philosophies de conception qu'elles recommandent peuvent s'appliquer à pratiquement n'importe quelle solution de chiffrement. Vous les trouverez peut-être évidentes, ou extrêmes, mais face aux problèmes de sécurité actuels, elles méritent d'être énoncées de façon explicite.
Lorsqu'il conçoit une infrastructure de chiffrement, le développeur doit rechercher la simplicité, l'exactitude et la sécurité. Bien que les erreurs soient inévitables, elles ne doivent pas être considérées comme des événements naturels que l'on ignore d'un haussement d'épaule. Le développeur doit être un défenseur acharné du perfectionnisme le plus méticuleux. Comme Zimmerman l'a exprimé : « Concevez vos produits comme si une erreur pouvait coûter la vie à quelqu'un ». Vous pensez qu'il exagère ? Lors de la conférence ACSAC (Annual Computer Security Applications Conference) 2005, Brian Snow, cryptographe à la NSA (il a depuis pris sa retraite), a déclaré : « Je veux des fonctions et des assurances dans un dispositif de sécurité. Nous ne faisons pas reposer le test bêta sur le client. Si mon produit connaît une défaillance, quelqu'un pourrait mourir ». N'oubliez pas que les erreurs peuvent avoir plus que de simples conséquences monétaires.
Les utilisateurs méritent des assurances. Gagner, et conserver, la confiance des utilisateurs est crucial. Zimmerman le dit très clairement lorsqu'il déclare : « Gagnez la confiance des utilisateurs. Une fois vous endossez ce fardeau, vous ne pouvez plus jamais le déposer. » En agissant de la sorte, l'entreprise préserve l'assurance du client et sa propre réputation d'entreprise sûre. Si cette confiance est perdue, il est impossible de la regagner.
Ce sont là les perspectives que, je j'espère, Microsoft a gardées présentes à l'esprit lors de la conception de BitLocker (ou de n'importe quel autre produit de la société, du reste). Ceci dit, je veux expliquer pourquoi je crois réellement que Microsoft a fait ce qu'il fallait et fourni un outil technologique de chiffrement qu'il convient de prendre au sérieux.

Le pauvre et son éléphant
Essentiellement, BitLocker est l'élément de Windows Vista (en particulier pour les versions Entreprise ou Intégrale) qui chiffre toutes données de volumes système. Si cette application vous semble simple, pensez aux contraintes qui pèsent sur elle. Étant donné que BitLocker chiffre des données au niveau par secteur et que le texte chiffré ne peut pas dépasser la longueur du texte en clair, il n'y a aucune marge de manœuvre pour quoi que ce quoi d'autre, comme une valeur à usage unique (un numéro ou une chaîne utilisés une fois seulement pour l'authentification), un vecteur d'initialisation ou un code d'authentification de message (MAC). J'avais imaginé que de telles contraintes et les conditions qu'elles imposent étaient probables, mais je savais également que le problème de l'authentification des messages serait résolu d'une façon ou d'une autre.
BitLocker repose sur ce que l'on appelle souvent l'authentification du pauvre. Ce compromis n'est pas aussi modéré qu'on le souhaite généralement puisque il suppose que texte chiffré manipulé ne produit pas un texte en clair significatif. En d'autres termes, si le texte chiffré est manipulé, il doit, par exemple, provoquer une panne du système plutôt que d'autoriser un adversaire à exécuter une certaine fonction.
L'équipe de Microsoft à l'origine de BitLocker savait qu'il faudrait plus de temps pour analyser un algorithme de chiffrement par bloc entièrement nouveau qu'on ne pouvait l'accepter mais les conceptions déjà existantes n'avaient pas encore été assez bien analysées ou n'étaient pas suffisantes. Donc, pour le chiffrement, Microsoft a choisi l’algorithme AES en mode CBC (Cipher Block Chaining) que j'appellerai AES-CBC. Ceci ne se remarque pas dans le modèle d'attaque à texte clair choisi (nom abrégé : IND-CPA), mais l'intégrité n'est pas préservée. Et comme il n'y a pas de place pour un code MAC et que le CBC est un mode de confidentialité, il n'y a absolument aucune préservation de l'intégrité. C'est là que doit intervenir Éléphant.
Le nouveau composant Éléphant utilise deux diffuseurs, conçus pour fournir une authentification du pauvre bien meilleure qu'un simple AES-CBC. (Je dois cependant signaler qu'il existe une option permettant d'exécuter AES-CBC sans Éléphant pour ceux d'entre vous qui doivent respecter des règles strictes de conformité aux normes.) Bien qu'elle ne soit pas toujours idéale, l'authentification du pauvre est la solution la plus appropriée face à certaines contraintes et Éléphant a pour but de tirer le meilleur parti de la situation. Comment exactement ceci fonctionne-t-il ?
L'illustration de la figure 1 l'explique. Lorsque le chiffrement a lieu, le texte en clair est combiné, à l'aide de XOR, à une clé de niveau secteur. Le texte passe ensuite par deux diffuseurs sans clé. Puis le texte est chiffré à l'aide d'AES-CBC. La clé de secteur et AES-CBC requièrent tous deux du matériel de clé et sont donc codés de façon indépendante. Cette méthode simplifie la formalisation d'une preuve pour réduire la sécurité de la construction AES-CBC et Éléphant à celle d'AES-CBC. Éléphant est une nouvelle primitive et les nouvelles primitives sont parfois reçues avec réticence lorsqu'elles n'ont pas été rigoureusement analysées. Mais cette approche équilibre les choses étant donné que BitLocker peut montrer qu'AES-CBC avec Éléphant n'est pas plus facile à attaquer qu'AES-CBC seul.
Figure 1 Authentification du pauvre avec Éléphant
Figure 1 Authentification du pauvre avec Éléphant
La clé de secteur et les composants AES-CBC reçoivent tous deux 256 bits de matériel de clé, de sorte que la clé fait 512 bits. Par défaut, cependant, ces composants utilisent seulement 128 bits de matériel de clé, ce qui signifie qu'une partie du matériel de clé n'est pas utilisé. La raison en est simplement qu'il est plus facile de jeter les bits inutiles que de modifier l'infrastructure de gestion des clés lorsque les longueurs de clés varient.
La longueur du bloc peut prendre n'importe quelle valeur multiple de 2, dans la plage entre 512 et 8192 octets. Pour garantir qu'aucune modification du texte chiffré n'entraîne une modification aléatoire de tout le texte en clair d'un secteur, l'algorithme de chiffrement par bloc est conçu pour tolérer de telles variations de la taille du bloc. De plus, s'il se comporte comme un chiffrement par bloc ajustable (comme l'ont décrit Liskov, Rivest et Wagner), avec un algorithme changeant légèrement d'un secteur à un autre, un adversaire ne peut pas parvenir à déplacer le texte chiffré d'un secteur vers un autre secteur.

L'épreuve du temps
Spéculer sur la sécurité du chiffrement de BitLocker revient à parler de l'arbre plutôt que de la forêt. Pour BitLocker, être sûr n'est pas nécessairement suffisant pour pouvoir accomplir sa tâche. Ceci est dû au fait que BitLocker n'est pas une solution en soi mais juste l'un des nombreux éléments périphériques de Windows Vista. Microsoft déclare que BitLocker est solidement intégré à Windows Vista. Mais si l'intégration au système d'exploitation est si étroite, ne serait-il pas logique de supposer qu'une défaillance d'un autre composant pourrait à son tour entraîner une défaillance de BitLocker ou permettre qu'il soit compromis ?
Personnellement, je suis partisan de la modularité et de l'isolement des défaillances. Une étroite intégration dépourvue de modularité conduit à la complexité. Il est vrai que ce n'est peut-être pas le cas avec Windows Vista et BitLocker, mais seul le temps, et des analyses poussées, diront de quoi il retourne.
Alors, quel est mon avis sur BitLocker ? Je tire mon chapeau à l'équipe de Microsoft chargée de l'intégrité des systèmes pour s'être appuyée sur des cryptographes véritables et fiables qui ont fait les choses comme les cryptographes doivent le faire. Il est clair que cette fonctionnalité a été conçue pour la cryptographie, pas pour une campagne de commercialisation. En réponse à cette question, je déclare donc qu'il faut prendre BitLocker au sérieux. N'oublions pas cependant que ceci ne permet pas de déterminer si la sécurité est solide. Une fois encore, seules l'épreuve du temps et une évaluation en situation réelle pourront le dire. Un grand nombre de primitives et de protocoles de chiffrement ont été percés à jour. Mais au moins, l'équipe de Microsoft chargée de l'intégrité des systèmes nous a fourni des connaissances et des plates-formes sur lesquelles s'appuyer pour construire des solutions encore meilleures.

Justin Troutman est un cryptographe aguerri et un étudiant de premier cycle en mathématiques. Son intérêt se porte principalement sur le chiffrement symétrique. Il est également le fondateur d'Extorque, qui se spécialise dans la recherche et les services de conseils en chiffrement


 Histoires de Bureau: Guide de l'utilisateur exp&#233;riment&#233; de WIM et ImageX
Histoires de Bureau
Guide de l'utilisateur expérimenté de WIM et ImageX
Wes Miller
Cet article se base sur une version préliminaire du Kit d’installation automatisée (Windows AIK) et de Windows Server 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

J'ai abordé dans plusieurs de mes articles précédents ImageX et le format Windows Imaging (WIM). À Tech Ed, il y a quelques mois, j'ai entendu les commentaires et les questions de professionnels de l'informatique commençant à utiliser les Services de déploiement Windows (WDS), ImageX et le Kit d’installation automatisée (Windows AIK) et me suis rendu compte
que les utilisateurs avaient besoin de davantage de conseils. J'aimerais donc dans l'article de ce mois-ci me concentrer sur ImageX et le format WIM, et la façon d'en tirer le meilleur parti. Ensemble, ImageX et WIM vous permettent de déployer facilement non seulement Windows Vista® et Windows Server® 2008, mais également Windows® XP, Windows Server 2003 et Windows 2000.

Modifications de Windows AIK
La sortie prochaine de Windows Server 2008 peut vous inciter à vous demander quel sera son impact sur Windows AIK. Microsoft a l'intention de publier une version mise à jour de Windows AIK coïncidant avec le calendrier de sortie de Windows Server 2008. Aucune modification significative n'a été apportée au format WIM (l'outil ImageX et le format restent inchangés) ; WDS pour Windows Server 2003 n'a pas non plus changé. Contrairement à la rumeur, la multidiffusion ne sera pas disponible pour Windows Server 2003 WDS. Seuls les serveurs WDS exécutant Windows Server 2008 bénéficieront de la nouvelle fonctionnalité de déploiement en multidiffusion pour WDS.
Windows PE 2.0 et le programme d'installation de Windows seront modifiés afin de prendre en charge :
  • Le déploiement de Windows Server 2008 et de Windows Vista.
  • Le déploiement multidiffusion avec WDS à partir d'un serveur WDS Windows Server 2008.
  • Le déploiement des versions x64 ainsi que des versions x86 de Windows Vista et de Windows Server 2008 à partir de Windows PE x86.
Tout d'abord, cela signifie que Windows PE 2.0 pourra déployer Windows Server 2008 tout aussi facilement que Windows Vista : les mêmes outils et processus fonctionnent pour l'un comme pour l'autre. Deuxièmement, vous pourrez utiliser le déploiement multidiffusion avec WDS une fois que vos serveurs WDS s'exécuteront sur Windows Server 2008. Enfin, cela signifie que vous aurez la possibilité d'utiliser un disque Windows PE 2.0 x86 et de déployer une image x86 ou x64 de Windows à partir de celui-ci.
J'ai mentionné ce dernier point à Tech•Ed au cours de ma session sur Windows x64. Malheureusement, il y a eu une certaine confusion autour de ceci dans les blogs et dans la communauté technique Windows. Cela ne signifie pas que Microsoft distribuera Windows x64 et Windows x86 sur tous les DVD Windows Vista ou Windows Server 2008. Cela ne signifie pas non plus que vous devez combiner les images Windows x64 et Windows x86 dans un fichier WIM unique (bien que vous puissiez le faire). Cette procédure ne permet en aucun cas de réaliser une économie de stockage grâce à une seule instance, mais elle a toutefois l'avantage de permettre aux images WIM d'être groupées dans un seul fichier.
Cela signifie en fait que les clients d'entreprise et les OEM qui ont passé des années à développer des processus de déploiement basés sur x86 (ainsi que des scripts et des outils personnalisés) pourront maintenant déployer Windows x86 ou x64 depuis WIM à l'aide d'un programme d'installation 32 bits, ce que ces clients d'entreprise demandent depuis l'arrivée de Windows x64 en 2005.

ImageX au quotidien
Utilisation de /mount, /mountrw et /delete
Voici quelques conseils importants pour l'utilisation des commutateurs /mount, /mountrw et /delete avec ImageX :
  • Montez un volume avec /mountrw si vous avez l'intention de le modifier.
  • Montez une image WIM dans un répertoire vide, simplement pour éviter toute confusion avec les fichiers qui sont stockés et pour empêcher ImageX de lancer un message d'avertissement inutile.
  • N'oubliez pas les commutateurs /unmount /commit pour votre image en lecture/écriture si vous voulez enregistrer les modifications que vous avez effectuées. J'ai bien trop souvent effectué des modifications et oublié ensuite de les valider (et les ai par conséquent perdues).
  • La suppression de fichiers avec /mountrw et la suppression d'images de volume avec /delete ne permettent pas de récupérer de l'espace ; elles peuvent en fait utiliser davantage d'espace. Consultez la section de cet article concernant /export pour plus de détails.
  • Vous ne pouvez monter un fichier WIM unique qu'une seule fois pour l'accès en lecture/écriture. Deux utilisateurs ne peuvent pas modifier la même image WIM simultanément et vous ne pouvez pas modifier deux images de volume simultanément.
  • Même en mode de lecture seule (/mount), vous devez limiter le nombre d'images de volume que vous montez simultanément, car le pilote est dépendant de la quantité de mémoire de réserve non paginée disponible sur votre système pour chaque image montée. Cela se traduit par une limite qui peut varier en fonction du système (ou de l'architecture de systèmes). Je recommande de ne pas essayer de monter plus de cinq images simultanément.
  • Les modifications importantes avec /mountrw ne prendront que peu de temps lorsque vous les effectuerez, mais peuvent entraîner une durée de traitement de /commit considérable, car il doit compresser et stocker toutes les données du nouveau fichier.
  • Utilisez /delete et /mountrw avec précaution. Une fois les modifications validées, elles ne peuvent pas être annulées.
  • Vous ne pouvez pas exécuter /delete s'il y a seulement une image de volume dans un fichier WIM (supprimez le fichier WIM entier ou ajoutez à la place une autre image de volume).
  • Pour obtenir rapidement une arborescence des contenus d'une image de volume, utilisez cette commande à la place de /mount :
ImageX /dir <path_to_wim_file> <image index>
  • Si vous modifiez deux fichiers WIM à la fois, n'essayez pas d'exécuter /unmount pour les deux en même temps. Séquencez vos événements /mount et /unmount pour que l'un ne bloque pas l'autre.

ImageX a été conçu tout spécialement pour refléter la façon dont les OEM et les clients d'entreprise indiquent qu'ils utilisent ces outils. La figure 1 présente ce processus.
Figure 1 Utilisation d'ImageX
Figure 1 Utilisation d'ImageX
Il est à souligner que l'étape 5 est essentielle. En réalité, une image change constamment. Par conséquent, la capture et la modification de l'image se devait d'être aussi rapide et facile que possible.
À cette fin, vous pouvez ajouter une image supplémentaire (en utilisant le commutateur /append) à une image que vous avez déjà créée. Au début, l'équipe de développement pensait que vous souhaiteriez ajouter une référence supplémentaire (version de Windows) à votre image précédente, mais plus j'ai travaillé avec les clients d'entreprise à un stade précoce du développement de Windows Vista, plus j'ai entendu qu'elle était utilisée pour déployer rapidement X, puis recapturer X1 dans lequel les modifications de l'étape 2 avaient été effectuées. Il était ainsi possible de recapturer rapidement l'image puisque seul un nombre réduit de fichiers avait été modifié.
Lorsque l'équipe a compris cela, elle s'est rendu compte qu'il n'était peut-être pas toujours judicieux de conserver l'image originale. Plus loin dans cet article, j'aborderai le commutateur /export qui a été ajouté tout spécialement en raison de ce scénario et de celui qui suit.

Le changement est une constante
Très tôt, l'équipe de développement a décidé que les fichiers WIM devaient être modifiables. Puisqu'ils avaient déjà décidé qu'un format de création d'image basé sur les secteurs ne fonctionnerait pas (voir l'article de décembre 2006 sur technetmagazine.com/issues/2006/12/DesktopFiles pour des explications), ils ont dû créer une solution qui monterait facilement les fichiers de en mode natif en tant que partie du système de fichiers Windows et modifierait les images de volume montées dans le fichier WIM. Ceci impliquait un plus grand nombre d'« éléments mobiles », comme j'aime à les appeler. Le montage d'une image basée sur les secteurs est relativement facile, mais le montage d'un format d'archivage propriétaire tel que WIM a nécessité des outils très spécifiques.
Le format devait bénéficier d'un accès à partir de l'invite de commande, ce qui éliminait les extensions du shell Windows habituellement utilisées pour gérer les fichiers ZIP et CAB de manière native. Malheureusement, ces gestionnaires offrent uniquement à l'Explorateur Windows un accès abstrait à un objet.
Par conséquent, la solution WIM comprend un pilote (wimfltr.sys) et ImageX, qui sert en fait de méthode de chargement du pilote et gère l'interface de montage de l'image WIM. Le pilote sert à ajouter une abstraction au système de fichiers Windows, comme illustré à la figure 2. Lorsque vous exécutez une commande telle que celle-ci, vous indiquez à ImageX de charger le pilote wimfltr.sys et au pilote de superposer la première image de volume (le 1 des commandes utilisées ici) sur le montage de répertoire vide, comme vous pouvez le voir ici :
Figure 2 Montage d'une image de volume WIM
Figure 2 Montage d'une image de volume WIM
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
Il s'agit du comportement par défaut dans Windows AIK. Ainsi, lorsque vous explorez ou générez une liste des répertoires dans le répertoire de montage, vous voyez la racine de Volume Image 1 dans boot.wim. Bien sûr, l'utilisation de /mountrw ou /mount déterminera si ce répertoire est en lecture seule ou en lecture/écriture (voir l'encadré « Utilisation de /mount, /mountrw et /delete » pour plus de détails).
La fonctionnalité /mountrw a été conçue au départ pour ajouter facilement des pilotes ou autres fichiers ou contenus pouvant être copiés avec xcopy, définir des fichiers de réponse ou modifier le registre hors connexion d'un fichier WIM monté pour le modifier selon les besoins (voir la figure 3). Elle n'a pas été conçue pour que des applications entières soient ajoutées ou supprimées (puisque les applications installées avec MSI ne peuvent pas être installées hors connexion).
Figure 3 Modification d'un fichier WIM monté
Figure 3 Modification d'un fichier WIM monté
Il est essentiel de comprendre que lorsque vous effectuez des modifications dans le fichier WIM lorsqu'il est monté, vous ne modifiez pas directement le fichier WIM (tout du moins pas tout de suite) ; au lieu de cela, vous modifiez un cache du fichier WIM qui est en fait une fusion de la superposition et des modifications que vous avez effectuées. Comme je le fais remarquer dans l'encadré, ceci m'a déjà coûté cher. Veillez, lorsque vous avez terminé, à utiliser les commutateurs /unmount et /commit car ce n'est qu'une fois ceci effectué que vos modifications seront validées dans le fichier WIM. Si vous ne le faites pas, elles seront complètement perdues.
Lorsque vous enregistrez vos modifications en les validant, vous indiquez au pilote d'effectuer les modifications dans le fichier WIM même. Le pilote ajoute les données de fichiers supplémentaires. (Notez que si vous avez effectué une grande quantité de modifications, cela signifie que le traitement de /commit peut prendre un temps considérable, car ce n'est qu'alors que vous ajoutez les données des fichiers à l'image WIM).
En outre, contrairement à un format de création d'image basé sur les secteurs, vous pourriez avoir modifié un ou plusieurs fichiers dans l'image du volume. Par conséquent, ils ne possèdent plus une instance unique (à moins que ce même fichier ait déjà été enregistré une fois) et cela se traduira par la perte des données du fichier d'origine. Un volume WIM, contrairement à un volume NTFS ou FAT, ne marque pas un fichier comme supprimé. Il n'y fait plus référence mais n'effectue aucun nettoyage. Par conséquent, si vous effectuez des modifications fréquentes avec /mountrw, que vous ajoutez plusieurs images avec /append ou encore utilisez /delete pour supprimer un fichier d'image de volume, cela a pour seul effet de faire oublier les références aux données de fichiers au fichier WIM. Il n'abandonne en aucun cas les données de fichiers connexes.
C'est pourquoi l'équipe de développement a créé le commutateur /export, également connu en quelque sorte comme le « défragmenteur WIM ».

Exportation
Remarques importantes concernant /export
Lorsque /export est utilisé pour créer un nouveau fichier WIM, vous pouvez spécifier le type de compression à utiliser au lieu d'accepter le type de compression par défaut actuellement utilisé. Si vous modifiez le type de compression actuel, l'exportation peut prendre un temps considérable.
Lorsqu'il est utilisé efficacement comme /append (en ajoutant une image de volume à un fichier WIM existant), /export ne vous permet pas de modifier l'attribut /compression du fichier WIM.
Vous pouvez spécifier le commutateur /boot si vous exportez une image de volume Windows PE 2.0 entièrement nouvelle.

Le commutateur /export a été créé en réponse aux deux scénarios précédemment mentionnés et à quelques autres scénarios plus ésotériques découverts par l'équipe. Pour résumer, /export vous permet de prendre une image de volume existante (ou deux, ou trois) et de l'exporter. Cela signifie prendre rapidement les fichiers WIM X et X1 ci-dessus et créer un nouveau fichier WIM avec X seulement, avec X1 seulement, ou avec X1 et Y1, en exportant à partir d'un autre fichier WIM.
Imaginons un scénario dans lequel vous apportez des modifications à X et ajoutez (avec /append) les modifications en tant que X1. Vous décidez que vous voulez supprimer X car vous l'avez remplacé en tant que nouvelle image pour ce trimestre. Vous pouvez utiliser le commutateur /delete et ImageX oubliera l'image X. Cependant, pour économiser de l'espace en éliminant toute information liée à X, vous exécuteriez cette commande :
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
Ceci exportera la deuxième image de volume vers un nouveau fichier WIM avec le nouveau nom, en éliminant complètement les informations précédentes de Volume Image 1. Vous pouvez également procéder à l'exportation à partir d'images WIM fractionnées si vous voulez les rassembler dans un fichier WIM (comme je le décrirai plus loin dans cette rubrique). Les images fractionnées ne peuvent pas être modifiées à l'aide de /mountrw, ce qui peut être l'une des raisons pour lesquelles vous souhaiteriez les reconstruire. Il est important de noter qu'il n'existe aucune commande /import pour ImageX puisque /export peut soit créer de nouveaux fichiers WIM, soit effectuer des ajouts aux fichiers existants. Consultez l'encadré « Remarques importantes concernant /export » pour plus d'informations sur ce sujet.
C'est également essentiel si vous exécutez peimg /prep : bien que cette commande prépare votre image Windows PE à utiliser, elle ne nettoie rien dans l'image WIM. Dans l'idéal, dans le cadre de votre processus de publication Windows PE, vous devez préparer l'image, puis l'exporter dans un nouveau fichier boot.wim. Notez que le processus de démarrage ne peut rechercher le fichier WIM que dans \sources\boot.wim. Veillez donc à ce qu'il soit correctement nommé et marqué comme image de volume de démarrage.
J'ai mentionné qu'il est probablement souhaitable d'optimiser vos images en exécutant /export avec celles-ci lorsque vous êtes prêt à mettre hors service les anciennes images de volume ou à combiner plusieurs images ensemble. Vous devrez également optimiser vos images si vous avez effectué de nombreuses modifications avec /mountrw ou /delete. Dans le cas contraire, votre fichier WIM continuera à croître au fil du temps (de manière mystérieuse impossible à diagnostiquer). Si vous utilisez /mountrw ou /delete régulièrement, envisagez d'utilisez /export dans votre séquence de travail pour vous assurer que vos images sont entièrement optimisées.

Fractionnement
Très rapidement, un autre problème est survenu : la nécessité probable de fractionner les fichiers WIM sur plusieurs supports amovibles. Nous avions prévu que Windows serait livré sur un ou plusieurs CD (et potentiellement sur DVD, comme ce fut le cas) et avons par conséquent ajouté la prise en charge du fractionnement dans WIM et ImageX.
Comme je l'ai mentionné, une image fractionnée à l'aide de /split est fondamentalement en lecture seule. Vous ne pouvez pas exécuter /capture directement sur une nouvelle image fractionnée, elle ne peut pas être montée à l'aide d'ImageX et ne peut pas être ajoutée à l'aide de /append. Par conséquent, je recommande de fractionner un fichier WIM uniquement après avoir terminé le flux de travail standard et d'être prêt à effectuer la publication. Pour être plus précis, faites toutes vos modifications sur le fichier WIM normal et envisagez le fractionnement dans le cadre du processus de publication de votre scénario de déploiement.
En ce qui concerne l'application de l'image, les images fractionnées peuvent poser une difficulté. Je recommande d'utiliser ImageX au lieu d'un programme d'installation pour l'utilisation d'images fractionnées. Je recommande également d'appliquer les images sur le réseau (pour des performances optimales sans créer d'image du disque à partir duquel vous effectuez l'application) ou de les copier directement sur le lecteur et de les appliquer ensuite (notez que vous serez dépendant du disque, car le disque lit et écrit à partir de/sur lui-même au moment de l'application).

Recherche de la validation
Lorsque vous utilisez ImageX, vous déplacez beaucoup de données, des données très importantes. L'une des questions que j'ai fréquemment entendues à Tech•Ed cette année était « Comment puis-je m'assurer que mes images sont valides » ? Pour tout dire, ce n'est pas enfantin, mais ce n'est pas vraiment difficile non plus.
L'essentiel est de comprendre que WIM est, comme la plupart des formats d'archivage, susceptible d'altération. Le plus souvent, cette altération survient lorsqu'un fichier WIM est transmis sur le réseau. À un state très précoce du développement de Windows Vista, nous avons observé des problèmes spécifiques avec des cartes réseau particulières. Si elles abandonnaient des paquets, le fichier WIM était corrompu et pas toujours d'une manière facile à diagnostiquer. Cette situation reflétait en fait ce qui était arrivé des années auparavant lorsque la taille du fichier driver.cab avait augmenté. Une altération aléatoire similaire était survenue. Généralement, si vous obtenez des rapports d'images incorrectes ou d'échec d'installation, il est souhaitable de vérifier le type de carte réseau utilisé sur les systèmes générant ces rapports. C'est le cas que vous utilisiez ImageX seul ou que vous exécutiez WDS.
Par conséquent, comment voir si une image est bonne ou pas ? Pour commencer, vous pouvez utiliser le commutateur /check. Celui-ci enregistre des vérifications d'intégrité supplémentaires dans le fichier WIM et vérifie, avant l'application, qu'il n'a pas été corrompu. Veillez à exécuter /check au moment de l'application également, ce qui validera l'image (bien qu'un temps plus long soit nécessaire).
En outre, si vous rencontrez des problèmes, ou souhaitez juste être méticuleux, vous pouvez exécuter un utilitaire de hachage pour les fichiers avant la capture et après l'application. Vous pouvez également effectuer une vérification après la capture en montant l'image et en effectuant un nouveau hachage, ce qui n'est pas une mauvaise façon de s'assurer qu'une image a été correctement capturée.
Il est souhaitable de s'assurer que les images sont correctement capturées dès le début. Le commutateur /check et le format lui-même sont conçus comme des points de contrôle, et non comme outils de récupération pour la réparation d'une image incorrectement capturée.

Démarrage et indicateurs
J'ai mentionné auparavant que vous pouvez utiliser /boot pour capturer une image de volume WIM de Windows PE et la démarrer. Considérez ceci comme un secteur d'amorçage sur une image de volume particulière. Il peut uniquement exister sur une image de volume par WIM, et est uniquement valide pour Windows PE 2.0. Notez que vous ne pouvez pas lancer un démarrage WIM de Windows PE 1. x ; ce n'est tout simplement pas possible.
Vous pouvez observer des références aux indicateurs dans les images de volume Windows. Les indicateurs sont uniquement utilisés par le programme d'installation de Windows. Un indicateur 2 sur une image de volume signifie qu'elle contient Windows PE et le programme d'installation. Un indicateur 9 signifie qu'elle contient uniquement Windows PE. Tout autre indicateur ou l'absence d'indicateur signifient que l'image ne peut pas et ne sera pas utilisée par le programme d'installation. Remarquez que vous pouvez définir des indicateurs sur une image après qu'elle a été capturée en utilisant ImageX pour les modifier. Je recommande l'utilisation de Windows AIK (et éventuellement Business Desktop Deployment Solution Accelerator) pour créer votre image de démarrage WIM Windows PE car, pour commencer, les indicateurs seront correctement définis.

Remarque pour les utilisateurs de HTA
On m'a récemment communiqué des problèmes concernant l'exécution de fichiers HTA sur Windows PE 2.0. Il semble malheureusement qu'il y ait un problème avec les fichiers HTA contenant tout script de taille significative. Á la figure 4, observez la capture d'écran de l'exemple de fichier que j'ai créé et notez l'erreur de script (sans aucune information) renvoyée. Ce problème a été signalé par plusieurs clients et j'en ai moi-même fait l'expérience.
Figure 4 Erreur de script HTA
Figure 4 Erreur de script HTA
Heureusement, ce problème est cependant facile à corriger. Pendant la préparation de votre image, ajoutez la prise en charge de XML ainsi que la prise en charge de HTA. La dépendance manquante dans le composant HTA semble être incluse dans le module de complément XML, résolvant ainsi ce problème.
J'aimerais remercier Bruce Green, développeur ImageX, ainsi que Minxiao Zhou et Raja Ganjikunta de l'équipe de test de déploiement de Windows pour leur contribution à cette rubrique.

Wes Miller est responsable du développement chez Pluck (www.pluck.com) à Austin, au Texas. Auparavant, il a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


 Sur le terrain: Recyclez votre PC
Sur le terrain
Recyclez votre PC
Jim Lynch

Le programme Community Microsoft Authorized Refurbisher (MAR) (microsoft.com/mar) est un projet extraordinaire et relativement peu connu de l'initiative Microsoft Unlimited Potential, dans laquelle Microsoft prend en charge des projets divers pour améliorer la formation, créer des entreprises et des emplois, et générer des opportunités économiques viables pour de nombreuses communautés défavorisées. Lancé au Royaume-Uni en 2000, le programme Community MAR réunit maintenant de plus de 800 reconditionneurs de PC dans 50 pays.
L'un des aspects les plus stupéfiants du programme Community MAR est sa capacité à fournir des licences pour Windows® 2000 et Windows XP au prix de 5 dollars. Les programmes MAR fournissent ces licences (plus de 200 000 par an) sur des PC reconditionnés à des organisations à but non lucratif, écoles, bibliothèques, collèges et, aux États-Unis, à des programmes d'accès à la technologie pour les personnes à faible revenu ou handicapées. Ainsi, les programmes Community MAR touchent ceux qui se trouvent de l'autre côté du fossé numérique, fournissant l'accès à des opportunités éducatives et professionnelles.
Dans le but de toucher les enfants défavorisés, les programmes Community MAR couvrent le monde entier. Par exemple, Operation Homelink fournit des ordinateurs aux familles de militaires américains à faible revenu ; Computer Aid International, au Royaume-Uni est la plus grande organisation non gouvernementale fournissant des ordinateurs en Afrique ; et le réseau canadien de reconditionneurs Computers for Schools fournit un nombre important des ordinateurs destinés aux écoles canadiennes.
La valeur de la réutilisation
L'agence de protection écologique américaine (EPA) en coopération avec l'université du Tennessee a démontré récemment la valeur de la réutilisation des produits électroniques en termes d'énergie, matériaux, émissions de carbone et2toxiques. Selon leur calculatrice d'évaluation des avantages environnementaux et économiques associés à l'achat de produits (eerc.ra.utk.edu/ccpct/eebc/eebc.html), la réutilisation d'un seul ordinateur avec un moniteur à tube cathodique économise :
  • 30 livres de déchets dangereux
  • 77 livres de déchets solides
  • 77 livres de matériaux
  • 147 livres (17,5 gallons) d'eau non polluée
  • 32 tonnes d'air non pollué
  • 1 333 livres de gaz carbonique2 non émis
  • 7 719 kilowatts d'énergie

En fait, le programme Community MAR commença en 2 000 pour aider à augmenter le flux d'équipement fonctionnant dans les écoles et les œuvres de bienfaisance au Royaume-Uni, qui traditionnellement avaient un accès limité à la technologie. Le programme s'est étendu aux États-Unis et à l'Australie en 2003 et il est devenu mondial en 2005. Il est maintenant disponible pour tous les types de reconditionneurs (commerciaux, non commerciaux, gouvernementaux et aux écoles). En cours de route, il a créé également une réutilisation vivante des ordinateurs et de l'industrie de reconditionnement.
L'un des avantages moins évident du programme Community MAR est l'avantage écologique. Étendre la vie des équipements électroniques est la manière la plus efficace de recyclage, car la fonction d'un appareil est conservée et génère des avantages économiques, écologiques et sociaux élevés. Le recyclage de fin de vie est certainement une bonne chose et il est nécessaire, mais il perd de 10 à 30 pour cent de matériaux et d'énergie par article.
Il est clair que la fabrication d'ordinateurs représente un coût écologique énorme. D'après le scientiste écologique Eric D. Williams de l'université de l'état d'Arizona, la production de l'ordinateur de bureau et moniteur standard de 53 livres en moyenne requiert 530 livres de combustible fossile, 50 livres de produits chimiques et 3 330 livres d'eau. L'extension de sa vie de deux ou trois années, permet d'économiser de 5 à 20 fois plus d'énergie que son recyclage de fin de vie (voir l'encadré « La valeur de la réutilisation » pour des chiffres encore plus étonnants).
En général, grâce à ce programme innovateur, Microsoft aide à créer des opportunités qui peuvent transformer des communautés en apportant les avantages de la technologie aux personnes défavorisées. Un autre avantage étonnant est le fait que le programme Community MAR a sensibilisé le public à la réutilisation des ordinateurs.

Jim Lynchest Directeur de programme pour le recyclage et la réutilisation des ordinateurs chez TechSoup.org, une organisation non lucrative basée à San Francisco dont la mission est de fournir du matériel, des logiciels et des techniques à très faible coût aux œuvres de bienfaisance partout dans le monde.


 La vie secr&#232;te de Windows: Dr. Watson &#224; la rescousse
La vie secrète de Windows
Dr. Watson à la rescousse
Raymond Chen

Vous avez peut-être remarqué que si vous demandez à Dr. Watson (drwtsn32.exe) d'effectuer un vidage de mémoire du processus Winlogon, Windows® s'arrête dès qu'il est terminé. Certaines personnes se demandent, « Pourquoi la connexion d'un débogueur à Winlogon arrête-t-elle le système entier » ?
Ce n'est en fait pas ce qui se passe. L'exécution de Dr. Watson sur un processus n'est pas équivalente à la connexion d'un débogueur à un processus. La connexion d'un débogueur implique l'utilisation d'un outil tel que ntsd, ce qui fonctionne, pourvu que vous disposiez des privilèges nécessaires. En effet, il s'agit de la manière dont l'équipe Windows débogue les problèmes avec Winlogon. Donc, la réponse directe à cette question est « La connexion d'un débogueur à Winlogon n'arrête pas le système ».
Mais Dr. Watson est médecin légiste, pas médecin généraliste, et effectue tout d'abord un vidage de mémoire d'un processus problématique, en arrêtant ensuite le processus. Puisque Dr. Watson n'essaie en fait pas de réparer le problème, s'il laissait le processus continuer de s'exécuter, celui-ci se terminerait une fois de plus. Et Dr. Watson serait immédiatement appelé, ce qui provoquerait une boucle infinie. Dans un sens, Dr. Watson est un débogueur qui n'effectue en fait aucun débogage. Ce bon médecin fait acte de présence, prend des notes détaillées et termine ensuite le processus. Et cela se résume tout simplement à ceci, l'arrêt de Winlogon une fois le vidage de mémoire effectué, qui provoque l'arrêt du système.
Si vous terminez Winlogon, votre système redémarrera
Si vous terminez Winlogon, votre système redémarrera
Winlogon est ce que l'on appelle un « processus système critique » et la mort d'un processus critique force le redémarrage du système. Pourquoi le système considère-t-il Winlogon critique pour son fonctionnement ? Pour commencer, Winlogon est responsable du traitement de la séquence de touches de sécurité (Ctrl + Alt + Suppr). Si Winlogon s'arrête, la séquence de touches de sécurité ne fonctionne plus. Cette conséquence à elle seule est déjà mauvaise. Ce qui est pire, c'est qu'une fois le responsable officiel de la séquence de touches de sécurité disparu, un programme peut tout simplement attendre que l'utilisateur appuie sur Ctrl + Alt + Suppr pour afficher en réponse une fausse boîte de dialogue de mot de passe. Ce ne serait pas une très bonne séquence de touches de sécurité si elle pouvait être imitée ! Comme mesure protectrice, Windows s'arrête de lui-même avant que cette mauvaise situation empire.
Maintenant, si vous exécutez le Gestionnaire des tâches, mettez en surbrillance un processus système critique tel que Winlogon, cliquez sur Terminer le processus et confirmez, vous avez tout simplement terminé Winlogon et le système redémarre (en supposant bien sûr que vous exécutez la session en tant qu'administrateur élevé et possédez donc des autorisations suffisantes pour terminer le processus).
Dans les versions précédentes de Windows, le Gestionnaire des tâches essayait de vous empêcher de terminer ces processus système critiques, mais son algorithme de jugement des processus critiques n'était pas très avancé. En étant suffisamment retors, vous pouviez tromper le Gestionnaire des tâches et créer un programme qu'il considérait comme impossible à terminer. Ce qui n'était évidemment pas le cas. Vous pouviez toujours terminer le programme ; il suffisait d'utiliser un programme différent du Gestionnaire des tâches pour le faire. (Vous pourriez par exemple utiliser le programme taskkill)
Pour éviter d'être trompé, le Gestionnaire des tâches arrêtait simplement d'essayer de vous empêcher de terminer les processus système critiques. Après tout, si vous ne faites rien, vous ne pouvez rien faire de mal. Ceci signifie que le Gestionnaire des tâches ne vérifie plus vos actions lorsque vous terminez un processus. Il ne vous rappellera pas à l'ordre lorsque vous essayez de terminer quelque chose que vous auriez probablement plus d'intérêt à laisser en paix. Si vous choisissez de terminer un processus système critique, vous devrez simplement en assumer les conséquences.

Raymond Chen, The Old New Thing, et son livre du même titre (Addison-Wesley, 2007) traitent de l’historique de Windows et de la programmation Win32. Il laisse l'amélioration des mécanismes aux autres.