Août 2008 Août 2008
SQL Server: Astuces pour une maintenance de base de données efficace
Trop souvent, des gens qui n'ont pas eu une formation d'administrateur de bases de données se retrouvent responsables d'une base de données. Ils n'ont pas la formation et les connaissances adéquates pour gérer leur base de données et des problèmes commencent à se développer. Voici quelques notions de base pour tous ces administrateurs de bases de données involontaires qui ont besoin d'un cours accéléré sur les meilleures pratiques de maintenance des bases de données. Paul S. Randal
Administration de Windows: Prenez le pouls de votre serveur
Vos utilisateurs se plaignent de la lenteur d'exécution d'un serveur. Savez-vous ce que vous devez faire pour diagnostiquer le problème ? PerfMon peut être un outil indispensable pour régler ce problème car il possède de nombreuses fonctionnalités de diagnostic. Découvrez un aperçu des indicateurs de performances clés que vous devez utiliser pour diagnostiquer toute une série de goulots d'étranglement courants qui peuvent ralentir vos serveurs. Steven Choy
System Center: Windows PowerShell dans System Center Operations Manager
Windows PowerShell a été intégré à System Center Operations Manager 2007 et constitue un outil puissant d'exécution et d'automation des tâches administratives courantes. Découvrez comment vous pouvez utiliser Windows PowerShell dans Operations Manager pour exécuter la maintenance de routine, gérer des agents et bien plus encore. Marco Shaw
Internet Information Services: Montée en charge des applications ASP.NET : Principaux enseignements
Le succès de la montée en charge d'une application ASP.NET repose sur un effort de collaboration entre les développeurs et les administrateurs réseau qui commence dès le début du cycle de vie de l'application. Découvrez les facteurs nécessaires pour faire monter en charge une application et voyez comment cette collaboration peut aider à garantir que l'application s'exécutera comme prévu. Richard Campbell
Columns
Le mot du rédacteur en chef: En direct de Tech•Ed: | Lettres: Les lecteurs ont la parole: | Boîte à outils: Nouveaux produits pour les professionnels de l’informatique:
Forum aux questions SQL: Partitionnement, vérifications de cohérence et bien plus encore: Paul Randal répond à vos questions sur SQL Server, explique comment effectuer des vérifications de cohérence et autres opérations de maintenances sur des bases de données très volumineuses, comment gérer une mise à jour accidentelle et bien plus encore.Paul S. Randal | Coup de projecteur sur les utilitaires: Utilitaire de nettoyage Windows Installer: Les informations de configuration Windows Installer en trop peuvent entraîner des problèmes lorsque vous tentez de mettre à jour ou de désinstaller une application. Exécutez l'utilitaire de nettoyage Windows Installer pour supprimer les informations Windows Installer d'une application, puis réinstallez l'application.Lance Whitney | Au cœur de SharePoint: Dépannage de l'intégration de messagerie: L'intégration de SharePoint dans un environnement de messagerie sécurisé n'est pas tâche facile, mais son impact positif sur la productivité justifiera tous les efforts consacrés à ce projet. Voici des indications sur la manière de dépanner les problèmes qui peuvent se présenter lors de la configuration de l'environnement.Pav Cherny
Windows PowerShell: Un aperçu furtif de la gestion à distance de la version 2.0: Windows PowerShell 2.0 est actuellement en cours de création et le tout dernier CTP offre de nouvelles fonctions exceptionnelles. Cet article examine l'accès à distance, une des fonctions les plus passionnantes du CTP2 Windows PowerShell 2.0.Don Jones | Hé, vous le scripteur !: La voie Express: Avec Windows Vista, le contrôle ActiveX UserAccounts.CommonDialog servant à ouvrir une boîte de dialogue d'ouverture de fichier n'existe plus. Voici comment résoudre ce problème à l'aide de Visual Basic Express Edition.Les scripteurs Microsoft | Histoires de Bureau: Services de déploiement Windows (WDS) 101: Explorez les différentes versions de Services de déploiement Windows, voyez comment vous pouvez capturer une image de système d'exploitation personnalisée et découvrez ce dont vous avez besoin pour exécuter des installations plus automatisées.Wes Miller
Vigilance sécurité: Mots de passe et cartes de crédit, deuxième partie: Dans la dernière partie de cette série en trois parties, Jesper Johansson décrit comment les fournisseurs de logiciels, les suites de sécurité et les activités de marketing freinent les vrais efforts de sécurité et nous avertit sur la manière dont ces pratiques peuvent mener à la destruction de l'écosystème de sécurité technologique.Jesper M. Johansson | Informatique durable: Filtrage du greenwashing: Comprendre votre consommation d'énergie constitue désormais une partie essentielle de la gestion d'une infrastructure informatique. Découvrez les stratégies que vous pouvez utiliser pour implémenter un contrôle de la consommation électrique dans votre environnement pour mieux comprendre la consommation d'énergie des périphériques au sein de votre organisation.Dave Ohara | Sur le terrain: IMAP sauve le monde: Vos messages électroniques sont-ils enregistrés à différents emplacements, en différents formats et sur des systèmes d'exploitation différents ? Dara Korra'ti explique comment vous pouvez accéder à tous vos messages depuis un seul emplacement à l'aide d'IMAP4.R'ykandar Korra'ti
La vie secrète de Windows: Hommage au passé: Raymond explique comment l'ancien titan Alpha AXP est sorti de sa retraite pour aider au développement d'une nouvelle génération de systèmes 64 bits.Raymond Chen


SQL Server
Astuces pour une maintenance de base de données efficace
Paul S. Randal
En un coup d'œil :
  • Gestion des fichiers de données et des fichiers journaux des transactions
  • Élimination de la fragmentation de l'index
  • Garantie de l'exactitude et de l'actualité des statistiques
  • Détection des pages de bases de données corrompues
  • Mise en place d'une stratégie de sauvegarde efficace

Sommaire
Gestion des fichiers de données et fichiers journaux
Fragmentation de l'index
Statistiques
Détection de corruption
Sauvegardes
Conclusion
On me demande plusieurs fois par semaine des conseils sur la façon de maintenir efficacement une base de données de production. Parfois, les questions proviennent d'administrateurs de bases de données qui implémentent de nouvelles solutions et ont besoin d'aide
pour ajuster les pratiques de maintenance aux caractéristiques de leurs nouvelles bases de données. Plus fréquemment, cependant, les questions proviennent de personnes qui ne sont pas des administrateurs de bases de données professionnels mais qui, pour une raison ou une autre, se sont retrouvées propriétaires ou responsables d'une base de données. Je les appelle « administrateurs de bases de données DBA involontaires ». Cet article vise à fournir les bases des meilleures pratiques de maintenance des bases de données pour tous les administrateurs de bases de données involontaires.
Comme pour la majorité des tâches et procédures de l'univers informatique, il n'existe pas de solution unique pour assurer une maintenance efficace des bases de données, mais certains aspects clés doivent presque toujours être traités. Mes cinq premiers domaines de préoccupation sont (dans aucun ordre d'importance particulier) :
  • Gestion des fichiers de données et des fichiers journaux
  • Fragmentation de l'index
  • Statistiques
  • Détection de corruption
  • Sauvegardes
Une base de données non maintenue (ou mal maintenue) peut développer des problèmes dans un ou plusieurs de ces domaines, ce qui peut entraîner par la suite des performances médiocres des applications, voire des pannes et des pertes de données.
Dans cet article, j'expliquerai pourquoi ces questions sont importantes et vous montrerai des moyens simples de résoudre les problèmes. Je baserai mes explications sur SQL Server® 2005, mais je mettrai également en évidence les différences majeures que vous trouverez dans SQL Server 2000 et la prochaine version de SQL Server 2008.

Gestion des fichiers de données et des fichiers journaux
La première chose que je recommande toujours de vérifier lorsque l'on reprend la gestion d'une base de données concerne les paramètres liés à la gestion des fichiers de données et des fichiers journaux (des transactions). Vous devez notamment vous assurer que :
  • les fichiers de données et fichiers journaux sont non seulement séparés les uns des autres, mais également isolés de tout le reste
  • la croissance automatique est configurée correctement
  • l'initialisation instantanée des fichiers est configurée
  • la réduction automatique n'est pas activée et la réduction ne fait pas partie des plans de maintenance
Lorsque des fichiers de données et des fichiers journaux (qui devraient idéalement se trouver sur des volumes séparés) partagent un volume avec une autre application qui crée ou développe des fichiers, il existe un risque de fragmentation des fichiers. Dans les fichiers de données, une fragmentation excessive des fichiers peut contribuer à une baisse des performances des requêtes (en particulier les requêtes qui analysent de très grandes quantités de données). Dans les fichiers journaux, la fragmentation peut avoir un impact beaucoup plus important sur les performances, surtout si la croissance automatique est définie pour augmenter la taille de fichier seulement très légèrement à chaque fois que cela est nécessaire.
Les fichiers journaux sont intérieurement divisés en sections appelées Fichiers journaux virtuels et plus la fragmentation est importante dans le fichier journal (j'utilise le singulier ici parce qu'il n'y a aucun intérêt à avoir plusieurs fichiers journaux : il ne devrait y en avoir qu'un par base de données), plus le nombre de fichiers journaux virtuels est élevé. Lorsqu'un fichier journal a plus de, disons, 200 fichiers journaux virtuels, cela peut avoir un impact négatif sur les performances pour les opérations liées aux journaux telles que les lectures de journaux (pour une réplication/restauration transactionnelle, par exemple), les sauvegardes de journaux, voire les déclencheurs dans SQL Server 2000 (l'implémentation de déclencheurs est passée du journal de transactions à la structure de gestion des versions des lignes dans SQL Server 2005).
La meilleure pratique pour le calibrage des fichiers de données et fichiers journaux consiste à les créer avec une taille initiale appropriée. Pour les fichiers de données, la taille initiale doit prendre en compte l'ajout potentiel à court terme de données supplémentaires à la base de données. Par exemple, si la taille initiale des données est 50 Go, mais que vous savez que dans les six mois à venir 50 Go de données supplémentaires seront ajoutés, mieux vaut créer un fichier de données de 100 Go dès le départ, plutôt que de l'agrandir plusieurs fois jusqu'à ce qu'il atteigne cette taille.
C'est un peu plus compliqué pour les fichiers journaux, malheureusement, et vous devez tenir compte de facteurs tels que la taille des transactions (les transactions de longue durée ne peuvent pas être supprimées du journal tant qu'elles ne sont pas terminées) et la fréquence de sauvegarde du journal (puisque c'est ce qui supprime la portion inactive du journal). Pour plus d'informations, consultez « 8 Steps to Better Transaction Log Throughput », un blog très apprécié sur SQLskills.com écrit par ma femme, Kimberly Tripp.
Une fois configurées, les tailles de fichiers doivent être surveillées régulièrement et augmentées manuellement de façon proactive à une heure appropriée. La croissance automatique doit rester une protection au cas où pour que les fichiers puissent grandir au besoin si un événement anormal survient. L'argument contre la croissance automatique pour la gestion complète des fichiers est que la croissance automatique de petits volumes entraîne la fragmentation des fichiers et que la croissance automatique peut être un processus laborieux qui freine la charge de travail de l'application à des moments imprévisibles.
La taille de croissance automatique doit être définie sur une valeur spécifique, plutôt qu'un pourcentage, pour limiter le temps et l'espace nécessaires pour exécuter la croissance automatique, le cas échéant. Vous souhaiterez par exemple définir un fichier de données de 100 Go pour qu'il ait une taille de croissance automatique fixe de 5 Go, au lieu de, disons, 10 %. Ceci signifie qu'il grandira toujours de 5 Go, quelle que soit la taille finale du fichier, plutôt qu'un volume sans cesse croissant (10 Go, 11 Go, 12 Go et ainsi de suite) à chaque fois que le fichier augmente.
Lorsqu'un journal de transactions est agrandi (manuellement ou par croissance automatique), il est toujours initialisé à zéro. Les fichiers de données ont le même comportement par défaut dans SQL Server 2000, mais à partir de SQL Server 2005, vous pouvez activer l'initialisation instantanée des fichiers, qui ignore l'initialisation à zéro des fichiers et rend ainsi la croissance et la croissance automatique pratiquement instantanées. Contrairement aux idées reçues, cette fonctionnalité est disponible dans toutes les éditions de SQL Server. Pour plus d'informations, entrez « initialisation instantanée des fichiers » dans l'index de la documentation en ligne de SQL Server 2005 ou SQL Server 2008.
Enfin, il convient de s'assurer que la réduction n'est pas activée. La réduction peut être utilisée pour réduire la taille d'un fichier de données ou d'un fichier journal, mais il s'agit d'un processus très intrusif sollicitant un grand nombre de ressources qui entraîne des quantités importantes de fragmentation d'analyse logique dans les fichiers de données (voir ci-dessous pour plus de détails) et se traduit par une baisse des performances. J'ai modifié l'entrée de la documentation en ligne SQL Server 2005 pour que la réduction inclue un avertissement à cet effet. Une réduction manuelle des fichiers de données et des fichiers journaux peut cependant être acceptable dans certaines circonstances.
Vidéo
Regardez Paul Randal démontrer comment la réduction et la réduction automatique peuvent entraîner de graves problèmes de fragmentation pour votre base de données.

La réduction automatique est la plus dangereuse car elle démarre toutes les 30 minutes en arrière-plan et essaie de réduire les bases de données lorsque l'option de base de données Réduction automatique est définie sur True. Il s'agit d'un processus quelque peu imprévisible car il réduit uniquement les bases de données ayant plus de 25 % d'espace disponible. La réduction automatique utilise beaucoup de ressources et entraîne une fragmentation provoquant une chute des performances, ce qui veut dire qu'il vaut mieux l'éviter en toutes circonstances. Vous devez toujours désactiver la réduction automatique à l'aide de la commande suivante :
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
Un plan de maintenance régulier qui inclut une commande de réduction manuelle de la base de données est presque autant déconseillé. Si vous vous rendez compte que votre base de données ne cesse de grandir après sa réduction par le plan de maintenance, c'est parce que la base de données a besoin de cet espace pour son exécution.
Le mieux est de permettre à la base de données d'atteindre une taille d'état stable et d'éviter toute réduction. Vous trouverez plus d'informations sur les inconvénients de la réduction, ainsi que des commentaires sur les nouveaux algorithmes de SQL Server 2005 sur mon vieux blog MSDN® à l'adresse blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Fragmentation de l’index
Outre la fragmentation au niveau du système de fichiers et à l'intérieur du fichier journal, il est également possible d'avoir une fragmentation au sein des fichiers de données, dans les structures qui stockent les données de tables et d'index. Il existe deux types de fragmentation de base pouvant survenir au sein d'un fichier de données :
  • La fragmentation au sein des pages de données et d'index individuelles (appelée parfois fragmentation interne)
  • La fragmentation au sein des structures d'index ou de tables composées de pages (appelée fragmentation d'analyse logique et fragmentation d'analyse d'extension)
La fragmentation interne survient lorsqu'une page contient beaucoup d'espace vide. Comme l'illustre la figure 1, chaque page d'une base de données fait 8 Ko et a un en-tête de 96 octets ; par conséquent, une page peut stocker environ 8096 octets de données de tables ou d'index (vous pouvez trouver les détails spécifiques des tables et index pour les structures des données et lignes sur mon blog à l'adresse sqlskills.com/blogs/paul dans la catégorie Inside The Storage Engine). Un espace vide peut apparaître si chaque enregistrement de table ou d'index fait plus de la moitié de la taille d'une page, car dans ce cas un seul enregistrement peut être stocké par page. Ceci peut être très difficile voire impossible à corriger, car il faudrait une modification du schéma de table ou d'index, par exemple en changeant la clé d'index pour qu'elle corresponde à quelque chose qui n'entraîne pas de points d'insertion aléatoires comme le fait un GUID.
Figure 1 Structure d'une page de base de données (Cliquez sur l'image pour l'agrandir)
La fragmentation interne provient plus fréquemment de modifications des données, telles que des insertions, des mises à jour et des suppressions, qui peuvent laisser un espace vide sur une page. Un facteur de remplissage mal géré peut également contribuer à la fragmentation ; consultez la documentation en ligne pour plus de détails. Suivant le schéma de table/d'index et les caractéristiques de l'application, cet espace vide peut ne jamais être réutilisé une fois créé et peut entraîner des quantités d'espace inutilisable de plus en plus importantes dans la base de données.
Imaginons par exemple une table de 100 millions de lignes avec une taille d'enregistrement moyenne de 400 octets. Au fil du temps, le schéma de modification des données de l'application laisse en moyenne 2800 octets d'espace libre sur chaque page. L'espace total requis par la table est de 59 Go environ, calculé comme 8096-2800 / 400 = 13 enregistrements par page de 8 Ko, puis en divisant 100 millions par 13 pour obtenir le nombre de pages. Si l'espace n'était pas gaspillé, 20 enregistrements tiendraient sur chaque page, ce qui amènerait l'espace requis total à 38 Go. Ceci représente une économie énorme !
L'espace gaspillé sur des pages de données/d'index peut ainsi entraîner la nécessité de pages supplémentaires pour contenir la même quantité de données. Non seulement cela occupe davantage d'espace disque, mais cela signifie également qu'une requête doit émettre plus d'E/S pour lire la même quantité de données. Toutes ces pages supplémentaires occupent davantage d'espace dans le cache de données et utilisent par conséquent une plus grande part de la mémoire du serveur.
La fragmentation d'analyse logique est provoquée par une opération appelée « fractionnement de page ». Celle-ci survient lorsqu'un enregistrement doit être inséré sur une page d'index spécifique (selon la définition de touche clé) mais qu'il n'y a pas suffisamment d'espace sur la page pour toutes les données insérées. La page est fractionnée en deux et environ 50 % des enregistrements sont transférés sur une nouvelle page allouée. Cette nouvelle page n'est généralement pas physiquement contiguë à l'ancienne page et est donc appelée fragmentée. Le concept de fragmentation d'analyse d'extension est similaire. La fragmentation au sein des structures de tables/d'index affecte la capacité de SQL Server à réaliser des analyses efficaces, que ce soit sur l'intégralité d'une table/d'un index ou limitées par une clause WHERE de requête (telle que SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).
La figure 2 présente des pages d'index récemment créées avec un facteur de remplissage de 100 % et aucune fragmentation : les pages sont pleines et l'ordre physique des pages correspond à l'ordre logique. La figure 3 montre la fragmentation qui peut survenir après des insertions/mises à jour/suppressions aléatoires.
Figure 2 Nouvelles pages d'index sans fragmentation ; pages pleines à 100 % (Cliquez sur l'image pour l'agrandir)
Figure 3 Pages d'index présentant une fragmentation interne et d'analyse logique après des insertions, mises à jour et suppressions aléatoires (Cliquez sur l'image pour l'agrandir)
Il est parfois possible d'empêcher la fragmentation en modifiant le schéma de table/d'index, mais comme je l'ai mentionné plus haut, cela peut être très difficile, voire impossible. S'il n'est pas possible d'empêcher la fragmentation, il existe des façons de supprimer la fragmentation une fois qu'elle est survenue, notamment en reconstruisant ou réorganisant un index.
La reconstruction d'un index nécessite la création d'une nouvelle copie de l'index (bien compactée et la plus contiguë possible), puis la suppression de l'ancien index fragmenté. Comme SQL Server crée une nouvelle copie de l'index avant de supprimer l'ancien, il a besoin d'un espace libre dans les fichiers de données à peu près équivalent à la taille de l'index. Dans SQL Server 2000, la reconstruction d'un index était toujours une opération hors connexion. Cependant, dans SQL Server 2005 Enterprise Edition, la reconstruction d'un index peut se faire en ligne, avec quelques restrictions. La réorganisation, en revanche, utilise un algorithme sur place pour compacter et défragmenter l'index ; elle nécessite uniquement 8 Ko d'espace supplémentaire pour s'exécuter, et elle s'exécute toujours en ligne. En fait, dans SQL Server 2000, j'ai spécifiquement écrit le code de réorganisation d'index comme une alternative occupant peu d'espace en ligne pour reconstruire un index.
Dans SQL Server 2005, les commandes à examiner sont ALTER INDEX … REBUILD pour reconstruire des index et ALTER INDEX … REORGANIZE pour les réorganiser. Cette syntaxe remplace respectivement les commandes DBCC DBREINDEX et DBCC INDEXDEFRAG de SQL Server 2000.
Il y a beaucoup de compromis entre ces méthodes, tels que la quantité de journalisation des transactions générée, la quantité d'espace libre dans la base de données requise et si le processus est interruptible sans perte de travail. Vous trouverez un livre blanc abordant entre autres ces compromis à l'adresse microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Ce livre blanc s'appuie sur SQL Server 2000 mais les concepts restent valables dans les versions ultérieures.
Certains choisissent simplement de reconstruire ou réorganiser tous les index chaque soir ou chaque semaine (en utilisant par exemple une option de plan de maintenance) plutôt que de rechercher les index fragmentés et d'envisager les avantages d'une suppression de la fragmentation. Il peut s'agir d'une bonne solution pour un administrateur de base de données involontaire qui souhaite simplement mettre quelque chose en place avec le minimum d'effort, mais cela peut être un choix désastreux pour les bases de données ou systèmes plus volumineux où les ressources sont rares.
L'une des approches plus sophistiquées consiste à utiliser la vue de gestion dynamique sys.dm_db_index_physical_stats (ou DBCC SHOWCONTIG dans SQL Server 2000) pour déterminer périodiquement quels index sont fragmentés, puis à déterminer s'il convient d'y toucher et comment. Le livre blanc aborde également l'utilisation de ces choix plus ciblés. En outre, vous pouvez voir des exemples de code permettant d'effectuer ce filtrage dans l'Exemple D de l'entrée de la documentation en ligne pour la vue de gestion dynamique sys.dm_db_index_physical_stats dans SQL Server 2005 (msdn.microsoft.com/library/ms188917) ou l'exemple E de l'entrée de la documentation en ligne pour DBCC SHOWCONTIG dans SQL Server 2000 et versions ultérieures (à l'adresse msdn.microsoft.com/library/aa258803).
Quelle que soit la méthode que vous utilisez, il est vivement conseillé d'examiner et de réparer la fragmentation régulièrement.
Le Processeur de requête est la partie de SQL Server qui détermine la façon dont une requête doit être exécutée, plus précisément quels tables et index utiliser et quelles opérations réaliser sur ceux-ci pour obtenir les résultats ; c'est ce qu'on appelle un plan de requête. Certaines des entrées les plus importantes de ce processus de prise de décision sont des statistiques qui décrivent la distribution des valeurs de données pour les colonnes d'une table ou d'un index. Évidemment, les statistiques doivent être précises et à jour pour être utiles au Processeur de requête, sans quoi des plans de requêtes offrant des performances médiocres risquent d'être choisis.
Les statistiques sont générées en lisant les données de la table/l'index et en déterminant la distribution des données pour les colonnes pertinentes. Les statistiques peuvent être créées en analysant toutes les valeurs de données pour une colonne particulière (analyse complète) mais elles peuvent également se fonder sur un pourcentage spécifié par l'utilisateur des données (analyse échantillonnée). Si la distribution des valeurs dans une colonne est à peu près équilibrée, une analyse échantillonnée devrait suffire, ce qui permet une création et une mise à jour des statistiques plus rapides qu'avec une analyse complète.
Notez qu'il est possible de créer et de gérer automatiquement les statistiques en activant les options de base de données AUTO_CREATE_STATISTICS et AUTO_UPDATE_STATISTICS, comme illustré à la figure 4. Celles-ci sont activées par défaut, mais si vous venez d'hériter d'une base de données, mieux vaut vous en assurer. Il arrive que les statistiques deviennent obsolètes, auquel cas il est possible de les mettre à jour manuellement en utilisant l'opération UPDATE STATISTICS sur des jeux de statistiques spécifiques. Vous pouvez également utiliser la procédure stockée sp_updatestats, qui met à jour toutes les statistiques qui sont obsolètes (dans SQL Server 2000, sp_updatestats met à jour toutes les statistiques, quel que soit leur âge).
Figure 4 Modification des paramètres de bases de données via SQL Server Management Studio (Cliquez sur l'image pour l'agrandir)
Si vous souhaitez mettre à jour les statistiques dans le cadre de votre plan de maintenance habituel, il y a une chose dont vous devez être conscient. Par défaut, les options UPDATE STATISTICS et sp_updatestats utilisent le niveau d'échantillonnage spécifié précédemment (le cas échéant), ce qui peut correspondre à une analyse incomplète. Les reconstructions d'index mettent automatiquement à jour les statistiques avec une analyse complète. Si vous mettez les statistiques à jour manuellement après une reconstruction d'index, vous risquez de vous retrouver avec des statistiques moins précises ! Ceci peut arriver si une analyse échantillonnée à partir d'une mise à jour manuelle remplace l'analyse complète générée par la reconstruction d'index. En revanche, la réorganisation d'un index ne met pas du tout les statistiques à jour.
Encore une fois, beaucoup de gens ont un plan de maintenance qui met à jour toutes les statistiques à un moment donné, avant ou après la reconstruction de tous les index, et finissent ainsi par se retrouver, sans le savoir, avec des statistiques potentiellement moins précises. Si vous choisissez de reconstruire simplement tous les index de temps en temps, ces reconstructions s'occuperont aussi des statistiques. Si vous optez pour une option plus complexe avec la suppression de la fragmentation, vous devez faire de même avec la maintenance des statistiques. Voici ce que je suggère :
  • Analysez les index et déterminez ceux qui doivent être traités et comment effectuer la suppression de la fragmentation.
  • Pour tous les index qui n'ont pas été reconstruits, mettez les statistiques à jour.
  • Mettez les statistiques à jour pour toutes les colonnes non indexées.
Pour plus d'informations sur les statistiques, consultez le livre blanc « Statistiques utilisées par l'optimiseur de requête dans Microsoft® SQL Server 2005 » (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Détection des corruptions
J'ai parlé de la maintenance liée aux performances. À présent, je veux passer à la détection et à l'atténuation des corruptions.
Il est très peu probable que la base de données que vous gérez contienne des informations totalement inutiles qui n'intéressent personne ; alors comment faites-vous pour vous assurer de l'intégrité et de la récupérabilité des données en cas de problème majeur ? Les détails de l'élaboration d'un plan de récupération après incident complet d'une stratégie de haute disponibilité n'entrent pas dans le cadre de cet article, mais il y a quelques mesures simples que vous pouvez prendre pour démarrer.
La grande majorité des corruptions sont dues au « matériel ». Pourquoi y ai-je mis des guillemets ? Eh bien, le matériel ici est vraiment un raccourci pour « quelque chose dans le sous-système d'E/S en-dessous de SQL Server ». Le sous-système d'E/S est constitué d'éléments tels que le système d'exploitation, les pilotes de système de fichiers, les pilotes de périphériques, les contrôleurs RAID, les câbles, les réseaux, et les lecteurs de disques. Cela signifie qu'il y a beaucoup d'endroits où des problèmes peuvent survenir (et surviennent).
L'un des problèmes les plus courants survient lorsqu'une panne d'électricité se produit et qu'un lecteur de disque est en train d'écrire une page de base de données. Si le lecteur ne peut pas compléter l'écriture avant de manquer d'électricité (ou que les opérations d'écriture sont mises en cache et qu'il n'y a pas assez de batterie de secours pour vider le cache du lecteur), vous risquez d'obtenir une image de page incomplète sur le disque. Ceci peut arriver parce qu'une page de base de données de 8 Ko est en fait composée de 16 secteurs de disque de 512 octets contigus. Une écriture incomplète pourrait écrire certains des secteurs de la nouvelle page mais laisser certains des secteurs de l'image de la page précédente. On parle dans ce cas de page endommagée. Comment détecter quand cela se produit ?
SQL Server est doté d'un mécanisme permettant de détecter cette situation. Il consiste à stocker quelques bits de chaque secteur de la page et à écrire un modèle spécifique à leur place (ceci se produit juste avant que la page soit écrite sur le disque). Si le modèle n'est pas le même lorsque la page est relue, SQL Server sait que la page a été « endommagée » et signale une erreur.
Dans SQL Server 2005 et les versions ultérieures, un mécanisme plus complet appelé total de contrôle de pagination est disponible pour détecter les éventuelles corruptions présentes sur une page. Celui-ci consiste à écrire un total de contrôle de pagination entier sur la page juste avant son écriture, puis de le tester lorsque la page est relue, comme pour la détection de page endommagée. Une fois les totaux de contrôle de pagination activés, la page doit être lue dans le pool de mémoires tampons, modifiée d'une façon ou d'une autre, puis réécrite sur le disque avant d'être protégée par un total de contrôle de pagination.
Il vaut donc mieux activer les totaux de contrôle de pagination pour SQL Server 2005 et les versions ultérieures et la détection de pages endommagées pour SQL Server 2000. Pour activer les totaux de contrôle de pagination, utilisez :﻿
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
Pour activer la détection de pages endommagées pour SQL Server 2000, utilisez ceci :
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
Ces mécanismes vous permettent de détecter les corruptions sur les pages, mais uniquement lorsque les pages sont lues. Comment forcer facilement la lecture de toutes les pages allouées ? La meilleure méthode pour ce faire (et pour trouver tous les autres types de corruption) consiste à utiliser la commande DBCC CHECKDB. Quelles que soient les options spécifiées, cette commande lira toujours toutes les pages de la base de données, ce qui entraîne la vérification de tous les totaux de contrôle de pagination ou de toutes les détections de pages endommagées. Vous devez également configurer des alertes pour être prévenu si des utilisateurs rencontrent des problèmes de corruption lorsqu'ils exécutent des requêtes. Vous pouvez être averti de tous les problèmes décrits ci-dessus grâce à une alerte pour les erreurs de gravité 24 (Figure 5).
Figure 5 Configuration d'une alerte pour toutes les erreurs de gravité 24(Cliquez sur l'image pour l'agrandir)
Une autre méthode recommandée consiste à exécuter régulièrement DBCC CHECKDB sur les bases de données pour vérifier leur intégrité. Il existe de nombreuses variations de cette commande et de questions sur la fréquence d'exécution. Il n'y a malheureusement pas de livre blanc disponible sur ce sujet. Cependant, comme DBCC CHECKDB était le principal morceau de code que j'ai écrit pour SQL Server 2005, j'en ai beaucoup parlé dans mon blog. Vous trouverez dans la catégorie « CHECKDB From Every Angle » de mon blog (sqlskills.com/blogs/paul) de nombreux articles approfondis sur la vérification de la cohérence, les meilleures pratiques et des conseils concernant les procédures. Pour les administrateurs de bases de données involontaires, la règle de base est d'exécuter DBCC CHECKDB aussi souvent que vous exécutez une sauvegarde de base de données complète (vous trouverez davantage de détails à ce propos ci-dessous). Je recommande d'exécuter la commande suivante :
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
Si cette commande produit un résultat, c'est que DBCC a trouvé des corruptions dans la base de données. La question suivante est : que faire si DBCC CHECKDB trouve des corruptions ? C'est là qu'interviennent les sauvegardes.
Lorsqu'une corruption ou un autre incident survient, la méthode de récupération la plus efficace est la restauration de la base de données à partir de sauvegardes. Ceci suppose d'abord que vous disposez de sauvegardes et ensuite qu'elles ne sont pas corrompues. Bien trop souvent, les gens veulent savoir comment rétablir une base de données très corrompue alors qu'ils n'ont pas de sauvegarde. La réponse simple est que ne vous pouvez pas le faire, pas sans éprouver une certaine perte de données qui pourrait nuire à votre logique métier et à l'intégrité des données relationnelles.
Les sauvegardes régulières sont donc vivement recommandées. Les subtilités de l'utilisation de la sauvegarde et de la restauration n'entrent pas dans le cadre de cet article, mais permettez-moi de vous donner une introduction rapide à l'élaboration d'une stratégie de sauvegarde.
Premièrement, vous devez régulièrement réaliser des sauvegardes de bases de données complètes. Ceci vous donne un point dans le temps unique vers lequel vous pouvez effectuer la restauration ultérieurement. Vous pouvez effectuer une sauvegarde de base de données complète à l'aide de la commande BACKUP DATABASE. Consultez la documentation en ligne pour des exemples. Pour plus de protection, vous pouvez utiliser l'option AVEC TOTAL DE CONTRÔLE, qui vérifie les totaux de contrôle de pagination (le cas échéant) des pages lues et calcule un total de contrôle sur l'ensemble de la sauvegarde. Vous devez choisir une fréquence qui reflète le volume de données ou de travail que votre entreprise est prête à perdre. Ainsi, si vous effectuez une sauvegarde de base de données complète une fois par jour, vous risquez de perdre une journée de travail en cas d'incident. Si vous utilisez uniquement des sauvegardes de bases de données complètes, vous devez être dans le mode de récupération SIMPLE (appelé couramment mode de récupération) pour éviter des complexités liées à la gestion de la croissance du journal des transactions.
Deuxièmement, conservez toujours les sauvegardes pendant quelques jours au cas où l'une d'entre elles serait endommagée : une sauvegarde vieille de quelques jours vaut mieux qu'aucune sauvegarde. Vérifiez également l'intégrité de vos sauvegardes en utilisant la commande RESTORE WITH VERIFYONLY (voir la documentation en ligne). Si vous avez utilisé l'option AVEC TOTAL DE CONTRÔLE lorsque la sauvegarde a été créée, l'exécution de la commande de vérification vérifiera que le total de contrôle de la sauvegarde est toujours valide et elle revérifiera toutes les sommes de contrôle de pages des pages de la sauvegarde.
Troisièmement, si une sauvegarde de base de données complète quotidienne ne vous permet pas de satisfaire la perte de données/travail maximale que votre entreprise peut assumer, vous pouvez songer à des sauvegardes de bases de données différentielles. Une sauvegarde de base de données différentielle repose sur une sauvegarde de base de données complète et contient un enregistrement de toutes les modifications depuis la dernière sauvegarde de base de données complète (la croyance que les sauvegardes différentielles sont incrémentielles est une idée reçue : elles ne le sont pas). Exemple de stratégie : une sauvegarde de base de données quotidienne, avec une sauvegarde de base de données différentielle toutes les quatre heures. Une sauvegarde différentielle fournit un point unique supplémentaire pour l'option de récupération. Si vous utilisez uniquement des sauvegardes de bases de données complètes et différentielles, vous devez toujours utiliser le mode de récupération SIMPLE.
Pour finir, la meilleure option de récupérabilité est fournie par les sauvegardes de journaux. Celles-ci sont disponibles uniquement dans les modes de récupération COMPLÈTE (ou BULK_LOGGED) et fournissent une sauvegarde de tous les enregistrements de journaux générés depuis la sauvegarde précédente des journaux. Si vous conservez un jeu de sauvegardes de journaux avec sauvegardes de bases de données complètes périodiques (voire des sauvegardes de bases de données différentielles), vous disposez d'un nombre illimité de points dans le temps vers lesquels effectuer la récupération, y compris une récupération en temps réel. Le compromis réside dans le fait que le journal des transactions continuera de grandir à moins qu'il ne soit libéré par une sauvegarde de journal. Exemple de stratégie : une sauvegarde de base de données complète tous les jours, une sauvegarde de base de données différentielle toutes les quatre heures et une sauvegarde de journal toutes les demi-heures.
Le choix d'une stratégie de sauvegarde et sa configuration peuvent être compliqués. Il vous faut au minimum une sauvegarde de base de données complète régulière pour disposer d'au moins un point dans le temps vers lequel effectuer la récupération.
Comme vous pouvez le voir, pour garantir que votre base de données reste intègre et disponible, il y a quelques tâches indispensables. Voici ma liste de vérification finale pour un administrateur de base de données involontaire héritant d'une base de données :
  • Supprimer toute fragmentation excessive du fichier journal des transactions.
  • Définir la croissance automatique correctement.
  • Désactiver toutes les opérations de réduction automatique planifiées.
  • Activer l'initialisation instantanée des fichiers.
  • Mettre en place un processus régulier pour détecter et supprimer la fragmentation d'index.
  • Activer AUTO_CREATE_STATISTICS et AUTO_UPDATE_STATISTICS et prévoir un processus régulier pour la mise à jour des statistiques.
  • Activer les totaux de contrôle de pagination (ou au moins la détection des pages endommagées sur SQL Server 2000).
  • Avoir un processus régulier pour exécuter DBCC CHECKDB.
  • Avoir un processus régulier en place pour effectuer des sauvegardes de bases de données complètes, plus des sauvegardes différentielles et de journaux pour une récupération ponctuelle.
J'ai donné des commandes T-SQL dans l'article, mais vous pouvez également faire beaucoup de chose à partir de Management Studio. J'espère vous avoir donné des astuces utiles pour une maintenance efficace des bases de données. Si vous avez des commentaires ou questions, envoyez-moi un message à l'adresse paul@sqlskills.com.

Paul S. Randal est directeur général de SQLskills.COM et MVP SQL Server. Il a travaillé sur le moteur de stockage de données de SQL Server chez Microsoft de 1999 à 2007. Paul est un spécialiste de la récupération après incident, de la haute disponibilité et de la maintenance de base de données. Vous trouverez son blog à l'adresse SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. La reproduction partielle ou totale sans autorisation est interdite.


Administration de Windows
Prenez le pouls de votre serveur
Steven Choy
En un coup d'œil :
  • Personnalisation de l'Analyseur de performances
  • Conseils sur les éléments à mesurer et la fréquence de mesure
  • Présentation des compteurs de performances clés et de ce qu'il faut rechercher

Sommaire
Rendre les résultats plus lisibles
Que mesurer et quand
Goulot d'étranglement du disque dur
Goulot d'étranglement de la mémoire
Goulot d'étranglement du processeur
Goulot d'étranglement du réseau
Goulot d'étranglement de processus
Conclusion
Imaginez que vous venez d'arriver au bureau un lundi matin et que vous êtes accueilli par un utilisateur anxieux qui se plaint de la lenteur de son serveur. Que pouvez-vous faire ? L'analyseur
de performances, un outil pratique intégré à Windows®, peut vous aider à diagnostiquer le problème.
Vous pouvez accéder à l'Analyseur de performances en tapant perfmon dans l'invite de commande ou en sélectionnant Analyseur de performances ou Analyseur de fiabilité et de performances (dans Windows Vista® et Windows Server® 2008) dans le menu Outils d'administration. Pour ajouter des compteurs de performances et des objets à contrôler, il vous suffit de cliquer sur le signe plus et de faire votre choix.
Comment donc prendre le pouls d'un serveur ? Il existe plus que 60 objets de performances de base, et chaque objet contient plusieurs compteurs. Dans cet article, j'aborderai les compteurs qui révèlent les signes vitaux d'un serveur et je décrirai les intervalles d'échantillonnage typiques que les techniciens du support technique de Microsoft® utilisent le plus souvent pour résoudre les problèmes de performances.
Bien sûr, une ligne de base offre un point de référence critique durant le dépannage. Puisque la charge du serveur dépend des besoins métier et varie également de temps à autre en fonction du cycle conjoncturel, il est important d'établir une ligne de base déterminée par la charge de travail normale sur une période de temps spécifiée. Cela vous permet d'observer les changements et d'identifier les tendances.

Rendre les résultats plus lisibles
Avant de plonger dans une analyse des compteurs qui représentent les signes vitaux des serveurs, je vous ferai part de deux astuces qui vous permettront de mesurer plus facilement les signes vitaux des serveurs à l'aide de l'Analyseur de performances. Notez que ces astuces ne sont pas nécessaires dans Windows Vista et Windows Server 2008, mais si vous exécutez l'Analyseur de performances sur des versions antérieures de Windows, elles peuvent vous être d'une grande utilité.
Tout d'abord, vous pouvez supprimer tous les bruits qui obscurcissent l'affichage graphique des lignes de tendance. Dans Windows Vista et Windows Server 2008, l'Analyseur de performances peut afficher jusqu'à 1 000 points de données en vue graphique. Dans les versions précédentes de Windows, la limite est de 100 points de données. Lorsqu'il y a plus de 100 points, l'Analyseur de performances met les points de données dans des « récipients ». Un récipient est représenté par une ligne verticale indiquant le minimum, la moyenne et le maximum des points d'échantillonnage inclus dans le récipient.
Comme l'indique le graphique de la figure 1, il est difficile de distinguer la ligne de tendance lorsque tant de données sont affichées en même temps. Le graphique de la figure 2 montre comme il est plus facile de saisir rapidement les données lorsque toutes les informations visuelles superflues sont désactivées. Pour savoir comment désactiver ces lignes verticales, consultez l'article de la base de connaissances disponible à l'adresse support.microsoft.com/kb/283110.
Figure 1 Données de performances affichées avec des récipients gênants et sans virgule (Cliquez sur l'image pour l'agrandir)
Figure 2 Une vue plus propre des données avec virgules de séparation (Cliquez sur l'image pour l'agrandir)
La deuxième astuce consiste à ajouter des virgules de séparation dans les chiffres, ce qui facilite considérablement la lecture des valeurs affichées dans les compteurs. Les virgules de séparation sont activées par défaut dans Windows Vista et Windows Server 2008. Dans les versions précédentes de Windows, cependant, l'Analyseur de performances n'active pas les virgules par défaut.
Ceci peut ne pas sembler très important, mais jetez un coup d'œil sur la figure 1, qui montre les compteurs de performances sans les virgules, puis sur la figure 2, qui montre les compteurs avec les virgules. Je trouve que la deuxième figure est le beaucoup plus lisible. Pour des instructions simples concernant l'ajout de virgules de séparation à vos compteurs de performances dans Windows XP, consultez l'article de la base de connaissances à l'adresse support.microsoft.com/kb/300884.

Que mesurer et quand
Les goulots d'étranglement surviennent lorsqu'une ressource atteint sa capacité maximale, ralentissant ainsi les performances du système tout entier. Les goulots d'étranglement sont généralement causés par des ressources insuffisantes ou mal configurées, des composants qui ne fonctionnent pas correctement et des demandes de ressources inexactes par un programme.
Il existe cinq principaux domaines de ressources qui peuvent causer des goulots d'étranglement et affecter les performances du serveur : le disque physique, la mémoire, le processus, le processeur et le réseau. Si l'une de ces ressources est surutilisée, votre serveur ou votre application peut ralentir considérablement ou même tomber en panne. J'examinerai chacun de ces cinq domaines, vous aiderai à choisir les compteurs que vous devez utiliser et proposerai des seuils pour mesurer le pouls de vos serveurs.
Puisque l'intervalle d'échantillonnage a un impact significatif sur la taille du fichier journal et la charge de serveur, vous devez définir l'intervalle d'échantillonnage en fonction du temps moyen qui s'est écoulé avant que le problème ne survienne afin que de pouvoir établir une ligne de référence avant que le problème ne se reproduise. Ceci vous permettra de détecter les éventuelles tendances menant au problème.
Quinze minutes offriront une bonne fenêtre pour établir une ligne de référence durant les opérations normales. Définissez l'intervalle d'échantillonnage à 15 secondes si le temps moyen qui s'est écoulé avant que le problème ne survienne est d'environ quatre heures. Si cette période est de huit heures ou plus, définissez l'intervalle d'échantillonnage à au moins cinq minutes, autrement, vous finirez avec un énorme fichier journal, ce qui compliquera l'analyse des données.

Goulot d'étranglement du disque dur
Étant donné que le système disque stocke et gère les programmes et données du serveur, un goulot d'étranglement affectant l'utilisation du disque et la vitesse aura un impact important sur les performances globales du serveur.
Notez que si les objets de disque n'ont pas été activés sur votre serveur, vous devrez utiliser l'outil de ligne de commande Diskperf pour les activer. Notez également que % temps disque peut dépasser 100 %, et donc, je préfère utiliser % temps d'inactivité, Moyenne disque s/lecture et Moyenne disque s/écriture pour me donner une image plus précise du degré d'activité du disque dur. Vous trouverez plus d'informations sur le Pourcentage du temps disque dans l'article de la base de connaissances disponible à l'adresse support.microsoft.com/kb/310067.
Voici les compteurs qu'utilisent les techniciens du service technique Microsoft pour la surveillance des disques.
Disque logique\% Espace libre Ce compteur mesure le pourcentage d'espace libre sur le lecteur de disque logique sélectionné. Notez que s'il descend en dessous de 15 %, vous risquez de manquer d'espace libre lorsque le système d'exploitation enregistre des fichiers critiques. Une solution logique consiste à ajouter de l'espace disque.
Disque physique\% temps d'inactivité Ce compteur mesure le pourcentage de temps durant lequel le disque était inactif pendant l'intervalle d'échantillonnage. Si ce compteur descend en dessous de 20 %, cela signifie que le système de disque est saturé. Vous pouvez envisager de remplacer le système de disque actuel par un système de disque plus rapide.
Disque physique\Moyenne disque s/lectureCe compteur mesure, en secondes, le temps moyen nécessaire pour lire les données du disque. Si le chiffre est supérieur à 25 millisecondes (ms), cela signifie que le système de disque a des problèmes de latence lorsqu'il lit du disque. Pour les serveurs stratégiques hébergeant SQL Server® et Exchange Server, le seuil acceptable est beaucoup plus bas, environ 10 ms. La solution la plus logique dans ce cas est de remplacer le système de disque actuel par un système de disque plus rapide.
Disque physique\Longueur moyenne disque s/écriture Ce compteur mesure, en secondes, le temps moyen nécessaire pour écrire les données sur disque. Si le chiffre est supérieur à 25 ms, cela signifie que le système de disque a des problèmes de latence lorsqu'il écrit sur disque. Pour les serveurs stratégiques hébergeant SQL Server et Exchange Server, le seuil acceptable est beaucoup plus bas, environ 10 ms. La solution la plus logique dans ce cas est de remplacer le système de disque par un système de disque plus rapide.
Disque physique\Longueur moyenne de file d'attente du disque Ce compteur indique le nombre d'opérations d'E/S qui attendent que le disque dur soit disponible. Si la valeur est supérieure au nombre de piles plus deux, cela signifie que le disque lui-même peut constituer le goulot d'étranglement.
Mémoire\Octets du cache Ce compteur indique la quantité de mémoire utilisée pour le cache du système de fichiers. Il peut y avoir un goulot d'étranglement de disque si cette valeur est supérieure à 200 Mo.

Goulot d'étranglement de la mémoire
Un manque de mémoire est généralement dû à une insuffisance de mémoire RAM, une fuite de mémoire ou un commutateur de mémoire placé dans le fichier boot.ini. Avant d'aborder les compteurs de mémoire, je voudrais évoquer le commutateur /3GB.
Une augmentation de la mémoire réduit l'activité d'E/S de disque, ce qui entraîne une amélioration des performances des applications. Le commutateur /3GB a été introduit dans Windows NT® pour fournir davantage de mémoire aux programmes en mode utilisateur.
Windows utilise un espace d'adressage virtuel de 4 Go (quelle que soit la quantité de mémoire RAM physique du système). Par défaut, les 2 Go inférieurs sont réservés aux programmes en mode utilisateur et les 2 Go supérieurs aux programmes en mode noyau. Avec le commutateur /3GB, 3 Go sont octroyés aux processus en mode utilisateur. Ceci, bien sûr, se fait au détriment de la mémoire du noyau qui aura seulement 1 Go d'espace d'adressage virtuel. Ceci peut causer des problèmes parce que les Octets de réserve non paginée, Octets de réserve paginée, Entrées libres en table des pages système, et le segment du Bureau sont tous compressés dans cet espace de 1 Go. Vous ne devriez donc utiliser le commutateur /3GB qu'après avoir effectué des tests approfondis dans votre environnement.
Cette solution est à considérer si vous soupçonnez un goulot d'étranglement lié à la mémoire. Si le commutateur /3GB n'est pas la cause des problèmes, vous pouvez utiliser les compteurs suivants pour diagnostiquer un goulot d'étranglement de mémoire potentiel.
Mémoire\% octets validés utilisés Ce compteur mesure le rapport octets validés/limite de mémoire dédiée, en d'autres termes, la quantité de mémoire virtuelle utilisée. Il indique une mémoire insuffisante si le chiffre est supérieur à 80 %. La solution la plus logique dans ce cas est d'ajouter de la mémoire.
Mémoire\% mégaoctets disponibles Ce compteur mesure la quantité de mémoire physique, en mégaoctets, disponible pour l'exécution des processus. Si cette valeur est inférieure à 5 % de la mémoire RAM physique totale, cela signifie qu'il y a une insuffisance de mémoire, ce qui risque d'accroître l'activité de pagination. Pour corriger ce problème, il vous suffit d'ajouter de la mémoire.
Mémoire\Entrées libres en table des pages système Ce compteur indique le nombre d'entrées de la table de pagination qui ne sont pas actuellement utilisées par le système. Si ce nombre est inférieur à 5 000, il est fort possible que vous ayez une fuite de mémoire.
Mémoire\Octets de réserve non paginée Ce compteur mesure la taille, en octets, de la réserve non paginée. Cette zone de mémoire système est destinée aux objets qui ne peuvent pas être écrits sur disque mais qui doivent rester dans la mémoire physique tant qu'ils sont alloués. Si la valeur est supérieure à 175 Mo (ou 100 Mo avec le commutateur /3GB), il est possible que vous ayez une fuite de mémoire. Un ID d’événement 2019 typique est enregistré dans le journal des événements système.
Mémoire\Octets de réserve paginée Ce compteur mesure la taille, en octets, de la réserve paginée. Cette zone de mémoire système est destinée aux objets qui peuvent être écrits sur disque lorsqu'ils ne sont pas utilisés. Si la valeur est supérieure à 250 Mo (ou 170 Mo avec le commutateur /3GB), il est possible que vous ayez une fuite de mémoire. Un ID d’événement 2020 typique est enregistré dans le journal des événements système.
Mémoire\Pages par seconde Ce compteur mesure la vitesse à laquelle les pages sont lues du disque ou écrites sur disque pour corriger les défauts des pages matérielles. Si la valeur est supérieure à 1 000, suite à une pagination excessive, il peut y avoir une fuite de mémoire.

﻿Goulot d'étranglement du processeur
La surcharge d'un processeur peut être due au fait que le processeur lui-même n'offre pas une puissance suffisante ou à une application inefficace. Vous devez vérifier si le processeur consacre beaucoup de temps à la pagination en raison d'une insuffisance de mémoire physique. Lorsqu'ils sont confrontés à un goulot d'étranglement du processeur potentiel, les techniciens du service technique Microsoft utilisent les compteurs suivants.
Processeur\% temps processeur Ce compteur mesure le pourcentage de temps que le processeur passe à exécuter un thread actif. Si le pourcentage est supérieur à 85 %, cela signifie que le processeur est surchargé et que le serveur peut nécessiter un processeur plus rapide.
Processeur\% temps utilisateur Ce compteur mesure le pourcentage de temps que le processeur passe en mode utilisateur. Si cette valeur est élevée, cela signifie que le serveur est occupé par l'application. Une solution possible consiste à optimiser l'application qui utilise trop les ressources du processeur.
Processeur\% temps d'interruption Ce compteur mesure le temps que le processeur passe à recevoir et à traiter des interruptions matérielles durant des intervalles d'échantillonnage spécifiques. Ce compteur indique la possibilité d'un problème de matériel si la valeur est supérieure à 15 %.
Système\Longueur de la file d'attente du processeur Ce compteur indique le nombre de threads existant dans la file d'attente du processeur. Le serveur ne reçoit pas suffisamment de puissance processeur si la valeur est plus de deux fois supérieure au nombre de processeurs pendant un certain temps.

Goulot d'étranglement du réseau
Un goulot d'étranglement du réseau affecte la capacité du serveur à envoyer et recevoir des données sur le réseau. Il peut être dû à un problème lié à la carte réseau du serveur, ou peut-être au fait que le réseau est saturé et a besoin d'être segmenté. Vous pouvez utiliser les compteurs suivants pour diagnostiquer les goulots d'étranglement du réseau potentiels.
Interface réseau\Total des octets/s Ce compteur mesure la vitesse à laquelle les octets sont envoyés et reçus via chaque carte réseau, y compris les caractères de trame. Le réseau est saturé si vous découvrez que plus de 70 % de l'interface sont en utilisation. Pour une carte de 100 Mbits/s, l'interface utilisée est 8,7 Mo/s (100 Mbits/s = 100 000 Kbits/s = 12,5 Mo/s* 70 %). Dans une telle situation, vous devriez ajouter une carte réseau plus rapide ou segmenter le réseau.
Interface réseau\Longueur de la file d'attente de sortie Ce compteur mesure la longueur de la file d'attente de sortie, en paquets. Il y a saturation du réseau si la valeur est supérieure à 2. Vous pouvez résoudre ce problème en ajoutant une carte réseau plus rapide ou en segmentant le réseau.

Goulot d'étranglement de processus
Les performances du serveur seront affectées de manière significative si vous avez un processus qui ne fonctionne pas correctement ou des processus non optimisés. Les fuites de threads et de handles finiront par provoquer la panne d'un serveur, et un usage excessif du processeur ralentira considérablement un serveur. Les compteurs suivants sont indispensables lorsque vous diagnostiquez des goulots d'étranglement liés aux processus.
Processus\Nombre de handles Ce compteur mesure le nombre total de handles qui sont actuellement ouverts par un processus. Ce compteur indique la possibilité d'une fuite de handles si le nombre est supérieur à 10 000.
Processus\Nombre de threads Ce compteur mesure le nombre de threads actuellement actifs dans un processus. Il peut y avoir une fuite de thread si ce nombre est supérieur à 500 entre le nombre minimum et maximum de threads.
Processus\Octets privés Ce compteur indique la quantité de mémoire allouée au processus qui ne peut pas être partagée avec d'autres processus. Si la valeur est supérieure à 250 entre le nombre minimum et maximum de threads, il est possible qu'il y ait une fuite de mémoire.

Conclusion
Vous connaissez maintenant les compteurs utilisés par les techniciens du service technique Microsoft pour diagnostiquer divers goulots d'étranglement. Bien sûr, vous choisirez probablement votre propre série de compteurs préférés, ceux qui répondent à vos besoins spécifiques. Vous pouvez choisir de gagner du temps en n'ajoutant pas tous vos compteurs préférés manuellement à chaque fois que vous avez besoin de contrôler vos serveurs. Fort heureusement, il existe une option dans l'Analyseur de performances qui vous permet d'enregistrer tous vos compteurs dans un modèle, afin de pouvoir les utiliser plus tard.
Vous ne savez toujours pas si vous devez exécuter l'Analyseur de performances localement ou à distance, ni quel sera le gain des performances lorsque vous exécuterez l'Analyseur de performances localement ? Tout cela dépend de votre environnement spécifique. Le gain de performances sur le serveur est presque négligeable si vous définissez des intervalles à au moins cinq minutes.
Vous pouvez choisir d'exécuter l'Analyseur de performances localement si vous savez qu'un problème de performances existe sur le serveur, puisque l'Analyseur de performances risque de ne pas pouvoir capturer les données depuis un ordinateur distant lorsqu'il est à court de ressources sur le serveur. Son exécution à distance depuis un ordinateur central convient mieux lorsque vous voulez contrôler ou établir un point de référence sur plusieurs serveurs.

Steven Choy est ingénieur de terrain principal chez Microsoft. Il a aidé des agences gouvernementales et des clients commerciaux au cours de leurs projets de déploiement et de migration d'ordinateurs de bureau, de gestion des correctifs et de stratégie de groupe. Il s'intéresse actuellement à la virtualisation et à l'état des serveurs.


System Center
Windows PowerShell dans System Center Operations Manager
Marco Shaw
En un coup d'œil :
  • Interface de commande Operations Manager
  • Fournisseur d'analyse Operations Manager
  • Automation de tâches administratives courantes
  • Quelques exemples réels Windows PowerShell

Sommaire
Interface de commande Operations Manager
Fournisseur d'analyse Operations Manager
Automation de tâches courantes
Le monde réel
Conclusion
System Center Operations Manager 2007 (OpsMgr) permet aux administrateurs d'accéder à Windows PowerShell, un nouveau puissant langage de script pour l'automation de tâches. Présenté au public en novembre 2006, il a été téléchargé plus de deux millions de fois depuis.
Dans cet article, je parlerai de Windows PowerShell® et de comment il s'applique à Operations Manager. J'indiquerai quelques unes des tâches courantes que Windows PowerShell vous aidera à exécuter beaucoup plus facilement et de manière plus automatisée. J'indiquerai également certains sites Web qui fournissent des scripts et des explications utiles. J'ai rassemblé des conseils et blogs de nombreux experts qui utilisent Windows PowerShell.
Bien que Microsoft ait commencé le lancement des versions CTP de Windows PowerShell 2.0, ces versions ne sont pas prêtes pour l'intégration à la production, elles n'ont pas été mises à l'essai avec Operations Manager et ne doivent pas être installées sur un système de production.

Interface de commande Operations Manager
Dans Operations Manager, vous accédez à Windows PowerShell par l'interface de commande, qui est similaire à l'environnement de Windows PowerShell par défaut, sauf qu'elle charge un fichier de console de même qu'un script qui initialise l'environnement avec des applets de commande et des fonctions d'Operations Manager et une connexion par défaut.
Vous pouvez démarrer l'interface de commande à partir d'une icône dans le menu Démarrer d'Operations Manager ou en cliquant, avec le bouton droit de la souris, sur un nom d'ordinateur dans la console d'interface utilisateur d'Operations Manager (voir figure 1). Ceci vous mène directement au chemin de lecteur d'analyse d'Operations Manager (que j'aborderai bientôt).
Figure 1 Ouverture de l'interface de commande à partir de l'interface utilisateur d'Operations Manager (cliquez sur l'image pour l'agrandir)
Windows PowerShell s'intègre à Operations Manager grâce au kit de développement logiciel d'Operations Manager. Heureusement pour les administrateurs, des applets de commande ont déjà été prévues pour la plupart des tâches que vous souhaiteriez automatiser ou terminer depuis une ligne de commande. S'il n'y a pas d'applets de commande pour une tâche particulière, vous pouvez utiliser Windows PowerShell pour interagir avec le SDK.
Les commandes fournies par l'interface de commande d'Operations Manager sont contenues dans un logiciel enfichable, une DLL (bibliothèque de liens dynamiques) chargée par Windows PowerShell qui contient des applets de commande pour l'administration d'Operations Manager. Le composant logiciel enfichable inclut également le fournisseur Windows PowerShell d'analyse d'Operations Manager. Également connu comme le fournisseur d'analyse, cet outil permet d'accéder à des connexions, groupes et objets d'analyse, ce qui ressemble beaucoup à la navigation dans un système de fichiers.
Vous pouvez obtenir une liste de toutes les applets de commande spécifiques à Operations Manager en utilisant l'applet de commande Get-OperationsManagerCommand, comme illustré à la figure 2. (Dans la première version, cette fonction ne prenait pas en charge la tabulation. Elle est devenue une applet de commande dans la version SP1.) La version originale d'Operations Manager comprenait 74 applets de commande, alors qu'Operations Manager SP1 en compte 87.
Figure 2 Obtenir une liste des applets de commande d'Operations Manager (cliquez sur l'image pour l'agrandir)

Fournisseur d'analyse d'Operations Manager
En utilisant l'applet de commande Set-Location (ou son alias "cd") vous pouvez naviguer dans la disposition des groupes et des ordinateurs. La disposition de base du lecteur d'analyse (Monitoringdrive) par défaut ressemble à ce qui suit :
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
À partir de là, vous pouvez avoir des objets plus spécifiques. Notez que le cas que nous analysons ici est simple et qu'il ne comprend qu'un seul serveur d'administration. Le premier serveur d'administration installé dans un groupe d'administration est connu sous le nom de serveur d'administration racine (RMS).
Lorsque vous démarrez l'interface de commande, celle-ci créé un lecteur nommé Monitoring (analyse), mappe le lecteur vers le fournisseur d'analyse d'Operations Manager et définit le chemin vers la racine du lecteur d'analyse. L'interface de commande recherche alors le registre pour le nom du RMS par défaut auquel se connecter. Si la connexion au RMS réussit, l'emplacement ou le chemin actuel est attribué au nom de la connexion, ou RMS, comme illustré à la figure 3.
Figure 3 L'emplacement de l'interface de commande est défini sur le RMS (cliquez sur l'image pour l'agrandir)

Automation des tâches courantes
Voyons comment Windows PowerShell peut gérer quelques unes des tâches administratives les plus courantes.
Gestion du mode de maintenance Quelle que soit la tâche que vous devez exécuter, vous voudrez probablement spécifier la date et l'heure à laquelle elle doit être exécutée. Observons rapidement l'applet de commande Get-Date : vous verrez à quel point cette opération est facile. La figure 4 illustre quelques exemples.
Figure 4 Utilisation de l'applet de commande Get-Date (cliquez sur l'image pour l'agrandir)
Comme vous pouvez le constater, j'ai créé une variable $date qui contient un objet représentant l'heure actuelle. Ensuite, j'ai utilisé quelques méthodes documentées et prises en charge par l'objet pour illustrer comment vous pouvez facilement obtenir la date et l'heure cinq minutes plus tard, puis cinq heures plus tard. Si je voulais obtenir des valeurs du passé, j'utiliserais simplement (-5) au lieu de (5).
Lorsque vous devez bloquer toutes les alertes venant d'un ordinateur, vous pouvez activer le mode de maintenance. Operations Manager 2007 vous permet de mettre en mode de maintenance un service Windows®, ou même une base de données en particulier, au lieu d'un ordinateur ou d'un groupe entier. Il existe trois applets de commande qui gèrent tout particulièrement des tâches du mode de maintenance : Get-MaintenanceWindow, New-MaintenanceWindow et Set-MaintenanceWindow.
Pour mettre un ordinateur en mode de maintenance depuis l'interface de commande, accédez à l'ordinateur ou l'objet d'analyse souhaité en utilisant le fournisseur d'analyse et invoquez l'applet de commande New-MaintenanceWindow, comme illustré à la figure 5. Comme vous pouvez le voir, cette action met l'ordinateur nommé Denver.contoso.com en mode de maintenance. J'ai également défini l'heure de démarrage de la fenêtre de maintenance à l'heure actuelle et l'heure de fin dans exactement une heure. Notez que, mettre un ordinateur en mode de maintenance avec cette méthode ne permet pas d'annuler toutes les alertes puisque les instances HealthService et HealthServiceWatcher sont toujours activées.
Figure 5 Utilisation de l'applet de commande New-MaintenanceWindow (cliquez sur l'image pour l'agrandir)
Boris Yanushpolsky, responsable de programme de l'équipe Microsoft Operations Manager, a donné un code Windows PowerShell très utile que l'on peut utiliser pour définir tous les objets relatifs à un ordinateur en mode de maintenance. Il a, en outre, expliqué comment l'utiliser une fois que vous avez créé un script. Pour davantage d'informations à ce sujet, lisez son blog à l'adresse blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
Parfois vous devez déterminer si des objets qui sont en mode de maintenance ne doivent pas l'être. Mais parcourir tous les objets pour résoudre cette question peut s'avérer difficile. Heureusement, encore une fois, Boris Yanushpolsky nous propose une solution avec un script de Windows PowerShell qui utilise le kit de développement logiciel d'Operations Manager. Vous pouvez copier le code directement depuis son blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) et le coller dans une fenêtre de l'interface de commande pour obtenir une liste de tous les objets en mode de maintenance.
Lorsqu'un objet est en mode de maintenance, vous pouvez vouloir terminer la période de maintenance avant l'heure de fin spécifiée à l'origine. Si vous connaissez un peu Windows PowerShell, vous vous attendez peut-être à une applet de commande avec un verbe d'arrêt ou d'élimination. En réalité, vous devez utiliser Set-MaintenanceWindow, comme illustré à la figure 6.
Figure 6 Utilisation de Set-MaintenanceWindow pour modifier l'heure de fin (cliquez sur l'image pour l'agrandir)
Gestion des agents Souvent, les administrateurs travaillent avec des agents et il existe six applets de commande et une fonction (depuis la version originale) qui traitent les différentes tâches relatives aux agents. Vous pouvez en obtenir une liste avec cette commande :
Get-Command *-agent*
Depuis la version SP1, Install-AgentByName n'est plus empaqueté sous forme de fonction, mais d'applet de commande. Il est recommandé d'utiliser l'applet de commande d'Install-AgentByName car il constitue une meilleure base pour la prise en charge et la cohérence.
L'aide intégrée à l'interface de commande offre quelques exemples intéressants d'utilisation des applets de commande Install-Agent et Uninstall-Agent. Roger Sprague, ingénieur logiciel senior au sein de l'équipe Microsoft Operations Manager, a publié sur son blog une méthode alternative illustrée à la figure 7 (voir le message de blog original à l'adresse blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Ce script fonctionne correctement avec la version RTM d'Operations Manager (vous devez vous trouver dans la racine du fournisseur d'analyse. Dans cet article, \oxford.contoso.com), mais il ne marche pas avec Operations Manager SP1. Pour le faire fonctionner avec Operations Manager SP1, il faut modifier la première commande de la figure 7 comme suit :
$managementServer = Get-RootManagementServer
Figure 7 Installation d'un agent
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
À ce stade, l'agent est installé sur le système distant devant être analysé, mais il y a encore une étape à franchir : le serveur de gestion doit accepter le nouvel agent pour que l'analyse complète puisse avoir lieu. Si aucune autre action n'est effectuée, le serveur d'analyse accepte automatiquement le nouvel agent pour l'analyse. Mais il est possible d'accélérer ce processus d'acceptation en utilisant l'applet de commande Get-AgentPendingAction. Cette applet de commande uniligne accélère le processus d'acceptation de l'agent :
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
En canalisant le processus vers Reject-AgentPendingAction au lieu d’Approve-AgentPending Action, si l'action est encore en suspens vous pouvez bloquer l'acceptation de cet agent par le serveur Operations Manager. Si elle n'est pas en suspens, utilisez l'applet de commande Uninstall-Agent.
Comme je l'ai dit, vous pouvez également utiliser Install-AgentByName pour spécifier un ordinateur directement à la ligne de commande sur laquelle doit être installé l'agent.
Utilisation de packs d'administration Il y a quatre applets de commande qui vous aideront à gérer les différentes tâches des packs d'administration. Vous pouvez en obtenir une liste comme indiqué ci-après :
Get-Command –noun ManagementPack
Cette commande simple fournit les packs d'administration actuellement installés et leurs numéros de version :
Get-ManagementPack | Format-Table –autosize
Maintenant, j'utiliserai l'interface de commande pour installer deux packs d'administration courants en utilisant ces programmes d'installation :
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Puisque mon objectif ici est de montrer comment l'interface de commande peut faciliter différentes tâches, j'utiliserai le moins de commandes possible (comme illustré à la figure 8). J'aurais pu modifier cette procédure d'installation pour transmettre l'option de fermeture au programme d'installation (les fichiers .msi), mais j'ai voulu sélectionner l'emplacement où les fichiers seront extraits manuellement.
Figure 8 Installer des packs d'administration (cliquez sur l'image pour l'agrandir)
Ensuite, je dois installer les bibliothèques communes, ce que je peux faire comme suit :
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Puis, j'installe les autres packs d'administration requis :
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Comme le montre la figure 9, l'aide intégrée à l'interface de commande est un parfait exemple de l'utilisation de l'applet de commande Export-ManagementPack pour exporter des packs d'administration descellés. Si vous souhaitez exporter tous les packs d'administration, modifiez cette ligne
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
Figure 9 Exportation d'un pack d'administration (cliquez sur l'image pour l'agrandir)
Manipulation des rôles d'utilisateur L'applet de commande Get-UserRole offre quelques fonctionnalités permettant d'administrer des utilisateurs, mais, curieusement, il n'est pas accompagné d'un applet de commande Set supplémentaire et, normalement, il n'est pas utilisé pour faire des modifications ni des mises à jour (selon la documentation du kit de développement logiciel de Windows PowerShell). Comme vous pouvez le voir à la figure 10, j'obtiens d'abord une liste des rôles d'utilisateur actuels, puis j'ajoute un utilisateur au groupe des opérateurs en lecture seule (voir figure 11).
Figure 10 Afficher des rôles d'utilisateur (cliquez sur l'image pour l'agrandir)
Figure 11 Ajouter un utilisateur (cliquez sur l'image pour l'agrandir)
Activer Audit Collection Services (ACS) L'ACS est une nouvelle fonction facultative d'Operations Manager 2007 qui fournit une méthode centralisée de gestion des informations sur l'audit de sécurité. L'ACS n'est pas activé par défaut et, généralement, il faudra le configurer durant une phase de déploiement ultérieure d'Operations Manager.
Lorsqu'il faut activer un grand nombre d'agents pour l'ACS, Windows PowerShell peut faciliter l'automatisation de la configuration. Quand la version bêta d'Operations Manager est sortie, Microsoft a fourni un script pour activer l'ACS sur tous les agents. Neale Browne, collaborateur et blogueur pour SystemCenterForum.org, est allé plus loin en ajoutant la prise en charge de paramètres supplémentaires.
Le site SystemCenterForum.org (un site communautaire qui fournit des solutions Microsoft® System Center) a produit deux scripts Windows PowerShell différents pour automatiser la configuration de l'ACS. Pour configurer tous les agents dans un groupe particulier, utilisez systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Pour configurer tous les agents analysés, téléchargez systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Activer le proxy d'agent Votre environnement Operations Manager peut inclure des périphériques analysés sans agent. Ces périphériques doivent être attribués à un serveur d'administration ou à un périphérique administré par agent qui assurera l'analyse à distance. Vous trouverez une description détaillée de l'utilisation du script Windows PowerShell pour configurer un grand nombre d'agents à l'adresse systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Une version mise à jour du script est disponible à l'adresse systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip.
Il existe d'autres conditions dans lesquelles certains packs d'administration nécessitent qu'un agent soit configuré pour servir également de proxy. Pour plus de détails, consultez la documentation du pack d'administration.

Le monde réel
Voici quelques exemples pratiques illustrant comment Windows PowerShell peut faciliter l'automation.
Résoudre des alertes Vous avez certainement déjà dû effacer plusieurs alertes sur un ordinateur. Peut-être y a-t-il eu un problème avec une application ou les alertes n'avaient pas été résolues. Voici une commande uniligne qui résoudra toutes les alertes avec un état de résolution zéro :
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
Dans l'exemple suivant, le résultat obtenu est identique, sauf que la commande s'exécute beaucoup plus rapidement dans un environnement plus grand et un nombre plus grand d'alertes :
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
La différence de performance est due au fait que, lors de l'utilisation du paramètre de critère, la valeur transmise est communiquée directement à la base de données SQL Server® et que seules les données pertinentes sont renvoyées. Ceci réduit le nombre d'objets qui doivent être retransmis à la console Windows PowerShell.
Maintenant, vous disposez d'une façon rapide de supprimer toutes les alertes en suspens sur un ordinateur. Selon vos besoins, vous pouvez configurer l'exécution automatique.
Enfin, vous disposez d'une commande rapide qui vous permet d'afficher toutes les alertes pour un jour spécifique :
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
Vous pouvez modifier très facilement la valeur de date et rediriger la sortie vers l'applet de commande Resolve-Alert.
Test d'alertes Parfois vous souhaitez surveiller certains événements dans l'Observateur d'événements Windows et les tester. Ces deux lignes créent rapidement une entrée dans le journal des événements :
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
Par défaut, cependant, cette opération enregistrera l'entrée dans le journal des événements d'Operations Manager, qui n'est probablement pas l'endroit où vous cherchez les événements enregistrés. Heureusement, Stefan Stranger, ingénieur de terrain principal chez Microsoft, a écrit un script qui permet de créer des événements dans l'Observateur d'événements. Ce script offre donc une plus grande flexibilité en permettant d'enregistrer dans un journal spécifique. Vous trouverez le script à l'adresse go.microsoft.com/fwlink/?LinkId=120308. (Stefan a empaqueté le script dans un fichier .cab. Vous devrez télécharger le fichier, puis cliquer dessus avec le bouton droit de la souris pour extraire le script).
La seule chose à remarquer, avec le script de Stefan, est que la valeur entrée pour la source d'événement détermine sur quel journal l'entrée sera écrite. Peut-être la façon la plus facile pour assurer qu'une alerte est dirigée vers le bon journal est d'ouvrir l'Observateur d'événements de Windows et rechercher la source de la dernière entrée.
Définir le propriétaire Parfois, il peut être utile de définir automatiquement le propriétaire d'une alerte. Voici une façon simple de le faire à partir de l'interface de commande :
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
La première ligne de ce code obtient l'ID d'un objet événement spécifique et le transmet à la variable $alert. Dans la deuxième ligne, cette variable est utilisée pour définir le propriétaire, et, enfin, la mise à jour est appliquée à la base de données d'Operations Manager. Si vous vérifiez le propriétaire de l'alerte avec la commande suivante, vous verrez qu'il a changé :
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Pour définir le propriétaire pour une série entière d'alertes, vous pouvez simplifier le code comme ceci :
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
Restaurer l'état d'analyse Il est probable que vous ayez déjà rencontré des agents dont l'état était « non analysé ». Dans ce cas, vous devrez peut-être restaurer rapidement l'état d'analyse complète de tous les agents, puis essayer de comprendre ce qui s'est passé. L'exécution du script à la figure 12 directement depuis l'interface de commande devrait restaurer l'état d'analyse complète de tous les agents concernés.
Figure 12 Réinitialisation du magasin du service de contrôle d'intégrité
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
Examinez le code de la figure 12. Après avoir déclaré une variable, j'obtiens une liste de tous les agents de ce RMS et j'applique un filtre aux éléments qui semblent poser problème. Ensuite, j'appelle de manière asynchrone une tâche qui réinitialise le magasin du service de contrôle d'intégrité sur tous les agents de la liste filtrée.
Associer des alertes à des packs d'administration La figure 13 illustre comment obtenir une liste de toutes les nouvelles alertes ainsi que le pack d'administration associé à chacune d'entre elles.
Quelques astuces étaient requises pour que le code puisse résoudre tous les noms de pack d'administration. Les applets de commande varient selon que l'alerte provient d'une règle ou d'un moniteur. (Remarquez que, à la figure 13, j'ai dû implémenter une petite solution de contournement pour l'applet de commande Get-Monitor. Depuis Operations Manager SP1, l'applet de commande prend en charge un nouveau paramètre d'ID qui simplifie légèrement le code).
Figure 13 Rechercher le pack d'administration
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
Création facile d'un rapport Lorsque vous mettez à jour votre environnement, il peut être utile d'auditer la version de tous les agents installés. Il suffit d'un simple script pour imprimer un rapport en bonne et due forme :
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
La figure 14 illustre la sortie générée par le script. Ce script est une version développée des exemples indiqués ici systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Figure 14 Sortie indiquant la version de certains agents (cliquez sur l'image pour l'agrandir)
Planifier une tâche Vous souhaitez peut-être exécuter régulièrement un script Windows PowerShell. Imaginons que vous utilisez un ordinateur client pour vous connecter et gérer votre serveur Operations Manager et que les outils d'administration d'Operations Manager sont installés localement. Supposons aussi que vous souhaitiez exécuter le rapport de version d'agent tous les jours et enregistrer la sortie dans un fichier dont le nom sera la date actuelle. Vous pouvez utiliser le planificateur des tâches intégré de Windows pour exécuter le script depuis votre ordinateur local.
Pour cela, il vous suffit de définir une nouvelle tâche en utilisant le programme powershell.exe (généralement situé dans C:\Windows\System32\WindowsPowerShell\v1.0). Après avoir créé la tâche, éditez-la et configurez la commande pour que l'exécution ressemble à ce qui suit :
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Il s'est avéré qu'un grand nombre de modifications du code Windows PowerShell d'origine étaient nécessaires, comme vous pouvez le voir à la figure 15. J'ai dû ajouter le composant logiciel enfichable Operations Manager PowerShell, créer un lecteur d'analyse mappé sur le fournisseur OperationsManagerMonitoring et créer une connexion au RMS. Je charge également le script personnalisé OpsMgr de Windows PowerShell (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) pour charger des fonctions spécifiques d'Operations Manager.
Figure 15 Planification du script de version d'agent
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
Mais ce n'est pas tout. Vous remarquerez peut-être que, à chaque fois que vous exécutez le programme, une fenêtre de console noire surgit à l'écran comme si quelqu'un était connecté au système sur lequel le script est exécuté. Vous trouverez une petite astuce qui vous permettra de résoudre cela. Elle nous est offerte par Don Jones et Jeffery Hicks de Sapien à l'adresse suivante : blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Essentiellement, vous devez encapsuler le script dans un VBScript. Pour cela, utilisez un code comme celui de la figure 16 au lieu d'appeler ce qui suit à partir de votre tâche planifiée :
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Figure 16 Masquer les fenêtres publicitaires
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
La tâche utilise alors le programme wscript.exe et l'appel ressemble à ceci :
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
Enfin, je peux créer des rapports automatisés. Le processus sera alors masqué pour les utilisateurs connectés.

Conclusion
Nous n'avons parcouru que très rapidement les fonctions d'automation d'Operations Manager 2007. Tout ceci n'est qu'un avant-goût de ce que vous pouvez demander à Windows PowerShell pour l'administration Operations Manager.
J'aimerais remercier toutes les personnes mentionnées dans cet article ainsi que Pete Zerger, fondateur de SystemCenterForum org.et MVP MOM, pour leur aide précieuse.

Marco Shaw est analyste systèmes informatiques pour une entreprise de télécommunications canadienne. Il travaille dans le secteur informatique depuis plus de 10 ans et a récemment reçu la récompense MVP Windows PowerShell. Marco est également directeur adjoint du nouveau site Web communautaire PowerShell à l'adresse powershellcommunity org. Vous trouverez son blog à l'adresse marcoshaw.blogspot.com.


Internet Information Services
Montée en charge des applications ASP.NET : Principaux enseignements
Richard Campbell
En un coup d'œil :
  • Importance de la collaboration entre le service de développement et le service informatique
  • Les principales stratégies de montée en charge
  • Partage des connaissances entre les équipes
  • Définition d'un ensemble de connaissances de base

Sommaire
Principes de base de la montée en charge
La rencontre des grands esprits
Informations que l'équipe réseau doit obtenir de l'équipe de développement
Informations que l'équipe de développement doit obtenir de l'équipe réseau
Retour à la montée en charge
Branle-bas de combat
Dans ma vie de consultant, toutes les montées en charge d'application ASP.NET fructueuses sur lesquelles j'ai travaillé ont été l'aboutissement d'un effort de collaboration entre les développeurs (qui ont créé l'application) et les administrateurs réseau (qui l'utilisent). Malheureusement, il n'est pas toujours évident, au début du
cycle de vie d'une application, que cette collaboration est essentielle. Par conséquent, je n'ai presque jamais l'occasion d'être impliqué au début du cycle de vie d'une application mais seulement lorsque les problèmes commencent à se manifester.
La vérité est qu'aucune application n'évolue efficacement à la première tentative car il est impossible de faire correctement du premier coup. Pour bien faire monter en charge une application, vous devez comprendre comment elle a été construite et comment fonctionne l'environnement d'exploitation dans lequel elle s'exécute. En d'autres termes, vous avez besoin d'obtenir des informations tant auprès de l'équipe de développement que de l'équipe réseau. Sans partage de connaissances, vous ne réussirez pas.

Principes de base de la montée en charge
Avant de plonger dans le vif du sujet, voyons tout d'abord ce qui est nécessaire pour faire monter en charge une application ASP.NET. Deux stratégies fondamentales sont généralement utilisées : la spécialisation et la distribution. La plupart des montées en charge d'applications ASP.NET de grande ampleur appliquent les deux stratégies. De plus, toutes les astuces qui vous aideront à faire monter en charge votre application ASP.NET se classent dans l'une ou l'autre stratégie.
La spécialisation implique la séparation d'éléments de l'application de sorte qu'ils puissent monter en charge de façon indépendante. Par exemple, vous pouvez créer des serveurs d'images dédiés au lieu d'utiliser les serveurs qui affichent les pages ASP.NET. La configuration optimale d'un serveur d'images est entièrement différente de celle d'un serveur ASP.NET. En outre, en séparant vos requêtes d'images du reste des applications, vous pouvez utiliser des ressources de tiers pour servir les images. La même approche peut s'appliquer à d'autres fichiers de ressources.
La distribution, en revanche, implique l'extension symétrique de l'application sur plusieurs serveurs qui forment généralement une batterie de serveurs Web. Les applications ASP.NET conviennent particulièrement à la distribution parce que chaque requête de page individuelle est relativement petite, et les interactions d'un utilisateur donné dépendent largement des autres utilisateurs. La distribution est véritablement la manifestation de la stratégie de « montée en charge horizontale », où plusieurs serveurs de performances moyennes fonctionnent ensemble pour servir les utilisateurs, plutôt que de la stratégie de « montée en charge verticale » au sein de laquelle un seul gros serveur effectue tout le travail.
La combinaison de la spécialisation et de la distribution accroît l'efficacité car elle permet de distribuer uniquement les éléments de l'application qui ont besoin de performances supplémentaires. Par exemple, si vous avez créé des serveurs d'images spécialisés mais que le service d'images n'est toujours pas adéquat, vous pouvez ajouter des serveurs d'images au lieu d'ajouter des serveurs pour l'ensemble de l'application. Il est important de garder ces stratégies à l'esprit lorsque vous vous efforcez d'améliorer les performances et l'évolutivité de votre application ASP.NET.

La rencontre des grands esprits
À un moment du cycle de vie de chaque application ASP.NET, les développeurs et le personnel réseau/personnel informatique doivent se rencontrer. Avec un peu de chance, cette rencontre interviendra avant le déploiement de l'application, mais parfois, elle a lieu en pleine crise, par exemple lorsque l'application s'exécute parfaitement dans l'environnement de test mais fonctionne au ralenti une fois expédiée aux utilisateurs. (C'est à ce moment qu'on fait appel à des consultants tels que moi).
Lorsque les développeurs et les responsables réseau se rencontrent, leur principal objectif est d'échanger des informations. Les développeurs ont une connaissance approfondie de l'application, tandis que le personnel réseau connaît parfaitement l'environnement d'exploitation. Chaque groupe doit comprendre les données que possède l'autre, et plus leur rencontre intervient à un stade précoce du cycle de vie de l'application, mieux cela vaut.
Cette rencontre ne doit pas avoir lieu pour la première fois pendant une crise. Si les deux équipes ne communiquent pas, il sera très difficile de savoir pourquoi l'application ne fonctionne pas correctement. En outre, il est trop simple d'adopter une position défensive et de décréter que le problème concerne uniquement l'autre équipe. Ce n'est jamais vrai. Les deux parties doivent invariablement collaborer pour résoudre un problème un tant soit peu complexe.
Toutefois, même lorsque les conditions sont bonnes, la réunion peut donner lieu à des difficultés. Celles que j'organise commencent généralement avec le personnel réseau d'un côté et les développeurs de l'autre. Ils se dévisagent. Pour lancer la conversation, je définis l'objectif de la réunion, à savoir un échange de connaissances. Peu importe qui est le premier à prendre la parole. Je commencerai par définir les informations que l'équipe réseau doit obtenir de l'équipe de développement.

Informations que l'équipe réseau doit obtenir de l'équipe de développement
Chaque application ASP.NET a ses propres particularités, mais certains éléments clés s'appliquent à tous les cas. Le fichier web.config est l'un de ceux-là (voir la figure 1). Web.config est un point d'intersection entre l'équipe de développement et l'équipe réseau. Il est configuré parfois par les développeurs et parfois par le personnel réseau. Le contenu de web.config impose des limites au matériel et à la configuration réseau et affecte directement le fonctionnement de l'application. L'examen en détail de chaque aspect du fichier web.config pourrait aisément faire l'objet d'un livre entier ; ce qu'il faut comprendre, c'est que les deux groupes doivent étudier le fichier web.config et se mettre d'accord sur ce que signifie la configuration qu'il représente, ainsi que sur l'impact qu'auront les divers paramètres sur l'application et sur l'environnement.
Figure 1 Fichier web.config de base présentant des paramètres d'application et la configuration de messages d'erreur personnalisés (Cliquez sur l'image pour l'agrandir)
Par exemple, la section <authorization> de web.config spécifie comment les utilisateurs seront authentifiés dans l'application et définit ainsi une dépendance. Si l'application utilise l'authentification Windows®, elle peut dépendre d'Active Directory®. Si elle utilise l'authentification basée sur les formulaires, la dépendance se trouve sur une banque de données de comptes utilisateur. Cette question mérite certainement une petite conversation.
La section <customErrors> est importante parce qu'elle a un effet sur la façon dont l'échec est vu par les utilisateurs. Ce paramètre n'est pas complexe, mais il est préférable d'en discuter afin de comprendre la nature des pages d'erreur. Au début du cycle de collaboration, il n'y a probablement pas de page d'erreur personnalisée, ce qui mérite également d'être discuté.
La section <appSettings> de web.config peut être particulièrement significative. C'est généralement là que les développeurs placent les valeurs globales telles que les chaînes de connexion pour les bases de données. Il s'agit d'une grande source de dépendances et d'un élément clé de la planification pour le basculement, la migration, etc. Mais comme la section <appSettings> est entièrement personnalisée, elle peut contenir pratiquement n'importe quoi et la compréhension de son contenu peut nécessiter beaucoup d'explications. Les orphelins (des valeurs qui ne sont utilisées nulle part dans l'application) sont souvent laissés dans cette section.
Même si vos développeurs n'utilisent pas <appSettings>, l'équipe réseau ou d'exploitation peuvent souhaiter l'utiliser ; en effet, le regroupement de toutes les chaînes de connexion de base de données dans cette section constitue une façon efficace de créer une stratégie de basculement simple. Si le serveur de base de données meurt, une chaîne de remplacement pointant vers un serveur de base de données différent peut être insérée. Si vous exploitez cette opportunité au début du cycle de développement, vous renforcez la fiabilité et la facilité de gestion de l'application.
Enfin, vous devez noter une valeur de web.config absolument essentielle pour la montée en charge : il s'agit de la balise <sessionState>, qui détermine l'emplacement où les données de session seront stockées pour l'application. Par défaut, ces données sont stockées « InProc », c'est-à-dire dans l'espace de processus de l'application ASP.NET. Si les données de session sont configurées in-process, cela signifie que tout équilibrage de la charge doit être « permanent » ; un utilisateur donné doit toujours être redirigé vers le même serveur, là où résident les données de session. Ce sujet doit faire l'objet d'une importante conversation entre les développeurs et l'équipe réseau parce qu'il influe directement sur la montée en charge et le basculement. En abordant ce point dès le début, vous éviterez de nombreux problèmes lorsque vous essayerez de déboguer l'application.
Lorsque la conversation en vient à l'état de session, il est facile d'enchaîner sur les exigences en matière d'équilibrage de la charge de l'application en général. Certains environnements possèdent un matériel d'équilibrage de la charge dédié avec des fonctionnalités spécifiques, mais si l'application ne peut pas contrôler ces fonctionnalités, ces dernières ne serviront pas à grand-chose. J'ai rencontré des cas où l'équilibrage de la charge matériel était utilisé avec une application ASP.NET qui avait des données de session in-process, ce qui a donné lieu à des pertes de sessions occasionnelles sans aucune explication. Cela avait l'air d'un bogue dans l'application, mais il s'agissait en fait d'une erreur de configuration.
L'équipe réseau doit absolument obtenir des développeurs des informations détaillées sur les schémas d’équilibrage de la charge qui fonctionneront pour l'application. Cette conversation doit être véritablement bilatérale et doit déterminer quels schémas d’équilibrage de la charge sont disponibles et lesquels l'application peut tolérer. L'un des principaux avantages d'organiser cette conversation dès le début du cycle de vie de l'application réside dans le fait qu'il est possible de prévoir à l'avance de passer à un schéma d’équilibrage de la charge sans affinité et out-of-process.
Lorsqu'une application ASP.NET sera prête à être déployée (ou en sera au déploiement initial), l'équipe de développement aura une bonne idée des parties de l'application qui sont rapides et de celles qui sont lentes. Chose plus importante, elle pourra prévoir les goulots d'étranglement ou les points de crise potentiels dans le système. Si l'équipe réseau/exploitation est avertie de ces goulots d'étranglement, elle peut se préparer à les affronter et peut-être même les éviter.
Par exemple, j'ai une fois travaillé avec une application qui avait un énorme processus de chargement de données tous les soirs, moment où cette application était inactive. Les développeurs avaient créé le mécanisme de chargement de données, l'avaient testé et avaient compris comment il fonctionnait. Ils savaient qu'il soumettait la base de données à beaucoup de contraintes, mais il était efficace et constituait une bonne façon de résoudre le problème.
Toutefois, ils n'ont jamais informé l'équipe réseau de la création de ce processus ni du fait qu'il devait s'exécuter à 01h00, c'est-à-dire exactement au moment où les sauvegardes de la base de données étaient exécutées. La base de données restait en ligne, mais elle s'exécutait beaucoup plus lentement pendant la sauvegarde car toutes les transactions envoyées à la base de données étaient retenues dans le journal des transactions.
Ce n'est que lorsque le chargement et la sauvegarde simultanés des données a provoqué un manque d'espace disque au niveau du journal des transactions de la base de données que le conflit a été identifié. Le problème a été résolu en reportant le lancement du chargement des données à 03h00, mais seulement après plusieurs jours de crise.
En discutant de ces problèmes de charge de travail de votre application au moment opportun, vous pouvez peut éviter des tas de problèmes en cours de route.

Informations que l'équipe de développement doit obtenir de l'équipe réseau
Mon point de départ préféré pour la partie de la réunion où l'équipe réseau explique son environnement à l'équipe de développement est le diagramme du réseau. Bien trop souvent, les développeurs voient le réseau comme il est illustré par la figure 2, c'est-à-dire sans aucun réseau, juste des serveurs Web, des navigateurs et Internet.
Figure 2 La vision simple du réseau du développeur (Cliquez sur l'image pour l'agrandir)
La réalité est, bien sûr, beaucoup plus complexe. Un diagramme comme celui de la figure 3 est plus proche de la vérité, bien qu'il soit lui aussi simplifié. Lorsque vous regardez la figure 3, des questions vous viennent immédiatement à l'esprit, telles que « Comment les utilisateurs VPN (Réseau privé virtuel) utilisent-ils l'application » ou « Quelle est la différence en termes d'authentification entre un utilisateur interne et un utilisateur public », et ainsi de suite.
Figure 3 Le vrai réseau que les développeurs doivent comprendre (Cliquez sur l'image pour l'agrandir)
Bien sûr, un diagramme du réseau à lui seul ne suffit pas. Il est également important d'expliquer le réseau en détail parce qu'il est impossible de savoir, juste en regardant un diagramme, quels éléments auront un effet sur l'application. Vous devez expliquer le processus de connexion réel d'un utilisateur public, d'un utilisateur VPN et d'un utilisateur interne. En abordant les diverses règles de pare-feu qui existent, surtout dans les architectures réseau de type DMZ plus complexes, vous soulèverez par là-même les problèmes qui peuvent se poser à l'application.
Bien sûr, il serait avantageux de tenir toutes ces discussions avant le déploiement de l'application ou même avant le début de son développement. Mais quoi qu'il en soit, cette discussion doit avoir lieu, et il est essentiel que tous ceux qui sont réunis autour de la table comprennent le diagramme du réseau tout entier.
La mise en réseau est également l'arène des modèles de basculement et de redondance, mais sans une certaine prise en charge logicielle ou au moins une certaine connaissance du comportement, ces modèles fonctionnent rarement comme prévu. Une discussion détaillée des divers scénarios de défaillance doit avoir lieu. Si le clustering est en place sur la base de données, cela affectera le code lié à l'accès à la base de données. Par exemple, les requêtes peuvent-elles effectuer une nouvelle tentative après un changement de serveur ? Si un site redondant est disponible, comment les données seront-elles répliquées sur le site ? Comment s'effectue le passage d'un site à l'autre en cas de basculement ?
Là aussi, il est préférable d'en discuter à un stade précoce du cycle de vie, mais mieux vaut tard que jamais : toutes les personnes concernées par l'application doivent savoir comment fonctionnent ces choses. Il n'y a rien de plus frustrant qu'une solution de basculement qui ne fonctionne pas lorsqu'on en a besoin.
Enfin, il existe une autre ressource réseau clé qui doit être partagée : les journaux de production. Il est recommandé de toujours mettre les journaux de production à la disposition de l'équipe de développement. L'équipe réseau ne le fait pas en général, préférant qu'on les lui demande le cas échéant. Je ne pense pas que cette attitude soit adéquate. Il est beaucoup plus efficace de donner aux développeurs la possibilité de récupérer les journaux eux-mêmes, par exemple à partir d'un site de sauvegarde.
Les journaux de production sont essentiels durant une crise. Ils sont souvent la meilleure (et la seule) source d'informations empiriques réelles sur ce qui s'est passé. Ils sont également précieux dans des circonstances plus ordinaires. Lorsque les développeurs ont un accès régulier aux journaux de production, ils peuvent les utiliser pour voir comment une nouvelle fonctionnalité se comporte. Il s'agit d'un bon moyen de découvrir si votre fonctionnalité ne fait pas ce qu'elle doit faire et de résoudre le problème avant qu'il ne cause une crise. Si tout le monde a accès aux journaux, il est possible de réagir aux problèmes plus rapidement et de les résoudre plus tôt.

Retour à la montée en charge
La réunion entre l'équipe réseau et les développeurs vise avant tout à comprendre l'étendue des problèmes liés à la montée en charge d'une application ASP.NET. L'environnement réel dans lequel l'application fonctionne affecte directement le fonctionnement du code exécuté par l'application. Toutes les stratégies liées à la montée en charge auront un impact sur le comportement du code dans l'environnement. L'application d'une stratégie de spécialisation telle que la séparation des parties SSL de l'application peut nécessiter des modifications de l'environnement de mise en réseau et probablement des modifications des serveurs eux-mêmes.
Même une modification apparemment centrée sur le code telle que l'utilisation de la mise en cache peut influer sur l'environnement. Cela est dû au fait que lorsque vous ajoutez la mise en cache des données à votre application ASP.NET, vous diminuez le nombre d'appels de base de données en échange d'une utilisation accrue de la mémoire. Vous risquez donc de devoir augmenter le nombre de serveurs ASP.NET dont vous avez besoin ou augmenter le nombre de recyclages de thread de travail sur les serveurs, ce qui déclencherait des événements du côté de la surveillance réseau.
La montée en charge de votre application ASP.NET a un impact à la fois sur l'équipe réseau et sur les développeurs ; il est donc sage de faire participer ces deux groupes au processus de prise de décision. Souvent, cette collaboration produira des solutions originales qui ne pourraient pas être découvertes si les deux équipes travaillaient indépendamment l'une de l'autre. Par exemple, l'équipe réseau pourrait être au courant de l'existence dans l'entreprise de solutions matérielles pouvant aider les développeurs à atteindre les objectifs de performances et de montée en charge. C'est à travers une discussion détaillée de l'application et de l'environnement que ces opportunités seront dévoilées.

Branle-bas de combat
Ressources pour la montée en charge d'applications ASP.NET

  • Développement d'applications ASP.NET hautes performances
  • Comment : Faire monter en charge les applications .NET
  • Comment : Ajuster et améliorer les performances d'applications créées sur .NET Framework
  • Implémentation d'une architecture évolutive
  • Optimisation des performances IIS
  • Stratégies de montée en charge des applications ASP.NET
Une crise en pleine montée en charge n'est pas nécessairement une mauvaise chose ; en fait, elle entraîne souvent des conséquences positives puisqu'elle est provoquée par un nombre excessif d'utilisateurs qui veulent exécuter votre application, ce qui, à son tour, prouve la qualité de votre application ! Vous devez, toutefois, veiller à ce qu'elle fonctionne parfaitement.
Parfois les crises de montée en charge sont provoquées par un autre événement, par exemple le fait que votre entreprise organise une promotion ou le fait que vous fassiez l'objet d'un billet de blog ou qu'un site de réseau social ait dirigé énormément de personnes vers votre site Web d'un seul coup. Tout d'un coup, vous devez vous mobiliser pour maintenir l'exécution de l'application. Comme vous le savez probablement, il est préférable de vous entraîner à faire face à ce type de scénario avant qu'il ne se produise. Et une démonstration de la façon dont la collaboration peut aider une organisation à surmonter cette crise est la meilleure façon de conclure votre réunion entre l'équipe de développeurs et l'équipe réseau.
La première question à poser dans cette situation est : « Comment détectons-nous que le site est en train de succomber à la charge » ? Bien trop souvent, la réponse est : « Nous recevons un appel du Directeur technique ». Si le premier signe d'un problème au niveau de votre site Web est un appel provenant de l'extérieur, vous avez un gros problème ! Un bon système de vérification devrait pouvoir vous avertir de tels problèmes avant que le téléphone ne sonne. Il n'empêchera pas le téléphone de sonner, mais il vous donnera au moins le temps de préparer votre répondre. Ce n'est pas en répondant « Ah bon ? » au directeur technique que vous serez promu au sein de l'entreprise !
Question suivante : Qui est appelé en premier ? Qui réagit à l'événement ? Souvent, c'est un membre de l'équipe réseau qui est averti en premier, et cette personne risque de manquer d'expérience ; vous devez donc mettre en place un bon plan de promotion des problèmes. Qui est appelé ensuite ? La difficulté consiste à effectuer un diagnostic rapide et précis pour identifier le problème auquel vous êtes confronté. Une panne du réseau est une chose, mais un problème de montée en charge est quelque chose de complètement différent. En cas de problème de montée en charge, il est recommandé de faire appel à un membre de l'équipe de développement dès le départ.
Toutes les personnes mobilisées doivent disposer de bonnes informations, et il est donc essentiel qu'elles bénéficient de droits d'accès adéquats. L'objectif est de disséminer autant d'informations que possible afin qu'un diagnostic efficace puisse être établi, lequel devrait au bout du compte déterminer l'étendue de la solution.
Souvent, si la seule réponse est d'écrire du code, l'événement sera terminé avant même que le code ne soit écrit. Bien sûr, l'événement doit être noté afin d'aider à déterminer les priorités de développement à l'avenir, mais il n'est pas raisonnable (ou recommandé) d'essayer d'écrire un tas de code et de le mettre en production sans avoir procédé à des tests minutieux. Règle numéro un de n'importe quel combat : ne pas envenimer les choses.
Dans le cas d'un problème de montée en charge, la solution consiste parfois à attendre qu'il disparaisse de lui-même. Il s'agit quand même d'une décision qui doit être prise.
En même temps, la mise en place de plans de secours implique la possibilité d'appliquer différentes techniques rapidement. La participation des équipes réseau et de développement à un problème de montée en charge contribue souvent à le résoudre rapidement, peut-être même suffisamment rapidement pour encore accroître le succès de cet événement promotionnel !
En conclusion, la leçon retenue par l'équipe réseau est qu'une application ASP.NET performante et hautement évolutive est le résultat d'une collaboration réussie entre les personnes qui créent l'application et celles qui la déploient et l'exécutent.
La collaboration étant inévitable, il est donc préférable d'organiser les réunions d'équipes au début du cycle de vie pour partager les informations. L'objectif des réunions est de comprendre et de s'accorder sur tous les éléments de l'application, sur ce qu'elle fait, sur la façon dont elle fonctionne, les éléments dont elle dépend, son comportement sous la charge et la façon dont elle gère les problèmes qui se présentent au fil du temps.
Lorsque cette collaboration est vraiment efficace, elle se traduit par une entreprise plus agile, capable de réagir rapidement en cas de problèmes et de définir clairement les objectifs nécessaires au succès de l'application à l'avenir.

Richard Campbell est directeur régional de Microsoft, MVP ASP.NET et coanimateur de .NET Rocks, le débat audio sur Internet destiné aux développeurs .NET (dotnetrocks.com). Il a travaillé pendant de nombreuses années en tant que consultant spécialisé dans les performances et l'évolutivité d'ASP.NET, et est également l'un des cofondateurs de Strangeloop Networks.


Le mot du rédacteur en chef En direct de Tech•Ed
Joshua Hoffman

Je suis toujours un peu embarrassé lorsque je m'installe à mon bureau pour rédiger Le mot du rédacteur en chef chaque mois. Il n'est généralement pas difficile de penser à un sujet à traiter, car il y a toujours beaucoup de choses intéressantes à raconter. La difficulté réside dans le fait que Le mot du rédacteur en chef doit être rédigé six semaines avant de pouvoir être lue (en partie pour que nous ayons le temps d'imprimer le magazine, mais surtout pour que les réviseurs aient tout le temps nécessaire pour corriger toutes mes erreurs). Contrairement aux blogs où il est possible de réagir à quelque chose immédiatement, il n'est pas facile de présenter des « nouvelles » dans ce magazine parce qu'elles ne seront plus fraîches lorsque vous les lirez.
Me voici pourtant à Tech•Ed 2008, dans la ville ensoleillée d'Orlando, et cet événement est actuellement l'événement le plus important de notre monde. Et tant pis si, au moment où vous lisez cet article, son contenu n'est plus d'actualité !
Tech•Ed est un événement passionnant pour nous pour plusieurs raisons. En premier lieu, c'est l'une des rares fois durant l'année où nous avons l'occasion de voir tant de nos lecteurs (et même nos auteurs) en personne ! Nous apprécions la messagerie électronique, la messagerie instantanée et les appels téléphoniques pendant l'année, mais rien ne vaut toutes les idées et conversations intéressantes que génère la congrégation de tant de gens.
Tech•Ed constitue également une bonne occasion de jeter un regard sur l'année à venir. Les dirigeants seront là à essayer de définir la stratégie globale, ce qui ne manquera pas de susciter beaucoup d'intérêt. Nous entendrons beaucoup parler des nouvelles directions dans la virtualisation, de la nouvelle génération du Web, de concepts révolutionnaires dans la gestion des systèmes, et bien d'autres choses.
En ce qui me concerne, toutefois, je m'intéresse davantage aux menus détails. Mark Russinovich, un collègue technicien à Microsoft qui contribue à l'élaboration de notre magazine, parlera de la redéfinition des limites de la sécurité. Steve Riley, qui contribue également à l'élaboration de notre magazine, parlera de la disparition des limites des réseaux, un concept particulièrement passionnant et innovant ! Enfin, Mark Minasi, Romi Mahajan, Dharmesh Godha et moi organiserons une discussion sur la « consumérisation » de l'informatique.
Je vous expliquerai également ce que vous devez faire si vous voulez écrire pour TechNet Magazine, sujet que j'ai eu le plaisir de traiter au cours des dernières années et qui a inspiré de nombreux nouveaux auteurs. Au moment où vous me lirez, les diapos de mon discours seront publiées sur notre blog, blogs.technet.com/tnmag. N'hésitez surtout pas à y jeter un coup d'œil. Qui sait ? Peut-être que vous assisterez à Tech•Ed l'année prochaine en tant qu'auteur !
Et n'oublions pas toutes les fêtes qui se déroulent à Tech•Ed. Elles sont tout aussi intéressantes !
—Joshua Hoffman

Merci aux experts techniques Microsoft suivants : Sunil Agarwal, Eric Charran, Trina Gorman, Sanjeev Nair, Isaac Roybal, Jez Sadler, Roger Sprague, Stefan Stranger, Kevin Sullivan, Jim Truher, Alan von Weltin, Michael Walsh et Buck Woody.


Lettres Les lecteurs ont la parole

Types de contenu SharePoint
Je recherche des informations détaillées sur l'utilisation des types de contenu dans Microsoft® SharePoint®. Où puis-je trouver ces informations ?
—E.A.

Le blog de l'équipe Microsoft SharePoint Products and Technologies (disponible à l'adresse blogs.msdn.com/sharepoint) est bonne source d'information, et Pav Cherny a écrit un article sur la standardisation de la gestion des données avec les types de contenu personnalisé que vous trouverez à l'adresse technet.microsoft.com/magazine/cc194408. Un livre blanc intéressant sur la gestion de métadonnées d'entreprise est disponible à l'adresse technet.microsoft.com/library/cc262729.
Vous pourriez également consulter blog d'Andrew May à l'adresse blogs.msdn.com/andrew_may. Andrew est programmeur/rédacteur chez Microsoft et est responsable de la rédaction de la documentation développeur pour les fonctionnalités de gestion du contenu d'entreprise dans Windows® SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007. Il publie des billets de blog sur les types de contenu et offre des posters d'illustrations techniques qui traitent des types de contenu et qui expliquent les aspects les plus complexes de la gestion du contenu d'entreprise dans un environnement SharePoint.

La sécurité à un niveau supérieur
J'ai adoré l'article « Le grand débat : La sécurité par l'obscurité » (juin 2008, technet.microsoft.com/magazine/cc510319). Cependant, j'étais un peu déçu du fait que l'article entier se soit concentré uniquement sur le changement du nom d'administration. Je suis en gros d'accord avec Roger Grimes et Aaron Margosis en ce qui concerne le débat sur le nom d'administration parce qu'il est vrai que c'est mieux que rien et que cela ne crée pas de grosses difficultés de gestion. Toutefois, il existe de nombreuses autres difficultés, plus complexes. Celle qui concerne les partages d’administration a été mentionnée mais n'a pas été bien développée par le groupe, or elle provoque de sérieux problème de gestion lorsque les partages sont bloqués.
J'aimerais également voir ce groupe débattre des avantages et inconvénients des tentatives de « réduction de la surface d'attaque ». La réduction de la surface d'attaque est une légère variante de la sécurité par l'obscurité dans la mesure l'essentiel de ce dont les gens se débarrassent généralement est lié à la divulgation de l'emplacement ou de l'identité. Par exemple, plusieurs de mes clients se sont débarrassés d'IPv6 au nom de la sécurité par l'obscurité. La désinstallation des services est souvent exécutée comme les opérations des médecins médiévaux : on ferme les yeux, on y va et on espère que le malade ne meurt pas.
—Shelly B.

Nous sommes complètement d'accord avec vous sur la question de la concentration sur la modification du nom d'administration. Les brouillons précédents comprenaient de nombreux autres exemples, mais l'article aurait comporté plus de 20 pages si nous ne l'avions pas raccourci ! Nous avons donc choisi de nous concentrer sur un exemple, et la question du compte administratif semblait celle qui était le plus souvent mentionnée. Ne vous pas s'inquiétez pas, toutefois : nous avons déjà commencé à pousser les auteurs à écrire d'autres articles sur ce sujet dans un avenir proche.

Pas assez obscur
« Le grand débat : La sécurité par l'obscurité » était un bon article. À ce propos, j'ai retenu deux choses. Tout d'abord, je crois que tant que le retour sur investissement (ROI) de l'obscurité est suffisamment élevé, l'obscurité est une bonne chose. Ensuite, je me suis rendu compte qu'une grande partie de la sécurité informatique est généralement toujours dotée d'un composant d'obscurité.
Prenez les mots de passe, par exemple. Nous les avons rendus de plus en plus obscurs au fil du temps. Au départ, nous n'avions pas besoin de mot de passe sur la plupart des PC. Ensuite, avec la connexion des ordinateurs, un mot de passe simple était suffisant. À mesure que la connectivité prenait de l'ampleur, un mot de passe d'au moins huit caractères est devenu important. Mais cela ne suffit plus et nous sommes passés aux caractères mélangés, puis aux phrases clés, et ainsi de suite. Je vous parie que nos vieilles protections obscures continueront à ne pas être suffisamment obscures.
—Tom B.

Merci, Tom, pour vos commentaires perspicaces. Il sera fascinant de voir la direction dans laquelle ira cette tendance, surtout à mesure que les concepts de sécurité tels que l'authentification multifacteur (cartes à puce plus mots de passe, par exemple) deviennent de plus en plus courants.

Posters TechNet Magazine
J'aimerais obtenir les posters Microsoft qui ont été inclus dans certains numéros de TechNet Magazine pour les développeurs de mon entreprise. Pourriez-vous m'indiquer comment les acheter ?
—Helen G.

Les trois posters disponibles sont : Microsoft Exchange Server 2007 Component Architecture, Windows Server® 2008 Active Directory® Feature Components et Windows Server 2008 Feature Components. Vous pouvez les acheter en appelant le 800-444-4881 pour les États-Unis et le Canada et le 785-838-7500 pour tout autre pays.


Boîte à outils Nouveaux produits pour les professionnels de l’informatique
Greg Steen

Contrôlez vos serveurs
PA Server Monitor Pro
poweradmin.com/servermonitor
Vous avez besoin de garder un œil sur tous les composants de votre infrastructure. Il est indispensable de savoir que quelque chose cloche avant que vos utilisateurs finaux ne s'en aperçoivent pour assurer le contrôle et la communication sur les dommages. Un outil qui vous aidera à garder un œil sur votre infrastructure de serveur est PA Server Monitor Professional Edition de Power Admin LLC.
Les premiers pas avec PA Server Monitor sont relativement simples, surtout grâce au processus de configuration intelligent intégré à l'application, capable de découvrir des ordinateurs sur votre LAN et configurer automatiquement pour chacun une série de moniteurs. Si vous ne souhaitez pas réaliser tout le processus de découverte, vous pouvez importer une liste d'ordinateurs pour lesquels vous voulez configurer les vérifications du moniteur. Et une fois que vous avez configuré un ordinateur, vous pouvez exporter cette configuration via l'interface GUI pour la réutiliser comme modèle pour les autres ordinateurs ou comme sauvegarde au cas où une réinstallation serait nécessaire.
PA Server Monitor offre 18 moniteurs différents que vous pouvez attribuer à chacun de vos serveurs. Ces moniteurs incluent des vérifications standard, comme la surveillance d'espace disque, les erreurs du journal des événements, l'exécution de scripts d'accès à distance, les modifications de fichier et de répertoire, l'utilisation de l'UC et de la mémoire, les réponses de protocole ICMP (ping) et l'état de service Windows®.
Il existe plusieurs autres moniteurs particulièrement pratiques, notamment la surveillance du port TCP, qui peut vérifier l'état fondamental des ports et envoyer un texte de commande et vérifier sa réponse par rapport à une valeur prédéterminée. La surveillance du fichier journal peut vérifier dans un fichier journal la présence d'un événement de texte que vous pouvez définir comme expression régulière ou texte simple. Un moniteur de quotas de répertoires peut vous aider à garantir que les utilisateurs finaux ne dépassent pas leurs limites et il informera par message électronique les utilisateurs lorsqu'ils dépassent des quotas. Vous pouvez contrôler l'exécution de script pour les tâches personnalisées que vous voulez exécuter. Et enfin, vous pouvez utiliser la surveillance de l'âge des fichiers pour observer votre file de courrier et vous assurer qu'elle n'est pas en cours de sauvegarde.
Après avoir défini un moniteur pour un serveur, vous devez définir une action à réaliser si le seuil du moniteur est atteint. PA Server Monitor fournit 15 actions intégrées, concernant notamment le courrier électronique, le journal des événements, les boîtes de message, les fichiers journaux, le redémarrage des services, le SNPP (Simple Network Paging Protocol) et des scripts personnalisés pour des actions personnalisées. En définissant des actions, vous pouvez déterminer également une chaîne d'escalade d'actions, qui exécutera des actions supplémentaires si le moniteur reste à un état d'erreur plus longtemps qu'un délai spécifié. Par exemple, vous pourriez configurer une action pour d'abord redémarrer votre site Web automatiquement. Ensuite, si la vérification échoue au bout d'encore cinq minutes, un message électronique est envoyé à votre système portable pour vous informer de l'état du site.
Au fil du temps, vous aurez probablement besoin de voir les statistiques sur vos moniteurs configurés. PA Server Monitor possède des fonctionnalités de rapport intégrées pour vous aider à transmettre les informations à ceux qui en ont besoin. Les rapports intégrés incluent un résumé de serveur qui affiche les statistiques et l'état d'un serveur particulier, un résumé général qui vous fournit une ligne d'informations sur chacun de vos ordinateurs contrôlés et un mappage d'état graphique qui présente les indicateurs d'état pour les installations dispersées sur le plan géographique. Les rapports sont générés en HTML pour permettre un accès avec un navigateur Web, ce qui agrémente votre centre d'opérations. Par ailleurs, vous pouvez produire également des rapports ad hoc avec des graphiques et des tableaux simples ou les exporter vers un fichier CSV pour les utiliser ultérieurement. Les rapports peuvent également être planifiés, ce qui vous permet de faire en sorte que l'application vous envoie directement et automatiquement par message électronique les dernières statistiques de vos serveurs à intervalles réguliers.
PA Server Monitor est sans agent. L'un des avantages est que vous pouvez démarrer rapidement si le contexte de service de l'application dispose d'assez de privilèges pour se connecter aux machines de votre réseau afin de s'exécuter via Windows Management Instrumentation (WMI) et d'autres services administratifs d'accès à distance, comme l'appel de procédure distante (RPC). L'un des inconvénients, cependant, est le niveau de compte élevé dont vous avez besoin pour vous connecter aux ordinateurs distants. Bien sûr, il existe d'autres types de moniteurs de protocole de serveur, y compris HTTP et SMTP, qui ne nécessitent pas d'autorisations élevées.
Un autre inconvénient potentiel est que la connexion à des ordinateurs par le biais d'une infrastructure et d'une topologie de réseau complexes et dispersées peut être difficile et dépendra de l'approbation du domaine et du réseau. Donc au final, le fait que cette approche sans agent fonctionne pour votre environnement dépend de la disposition de votre infrastructure et de ce que vous prévoyez exactement de faire avec votre solution de surveillance de serveur.
Prix : 99 USD (vente directe) pour 20 moniteurs actifs ou 349 USD (vente directe) pour 100 moniteurs actifs.
Gardez l'œil sur vos serveurs avec PA Server Monitor Professional Edition (cliquez sur l'image pour l'agrandir)

Nettoyez les fichiers dupliqués
dupeGuru
hardcoded.net/dupeguru
Si vous travaillez avec des utilisateurs finaux ou que vous gérez un espace disque utilisateur partagé, vous avez sans doute remarqué que l'espace d'utilisateur devient très désordonné au fil du temps. Ceci est souvent dû au fait qu'un seul utilisateur (ou même plusieurs) enregistre le même fichier à plusieurs emplacements. Pour vous aider à consolider et à nettoyer cet espace utilisateur, un système de recherche de duplications peut s'avérer indispensable. Pour cela, dupeGuru de Hardcoded Software est une bonne solution.
Cet outil analyse votre dossier ou lecteur cible pour y rechercher les doublons, en observant les noms et le contenu des fichiers. Mais dupeGuru va au-delà de la comparaison basique de chaînes en utilisant un algorithme de correspondance approximative pour rechercher des doublons qui pourraient ne pas être détectés autrement. Une fois que vos doublons sont marqués, vous pouvez choisir de les envoyer à la corbeille, de les supprimer définitivement, de les transférer vers un autre dossier ou de faire en sorte que l'application par défaut les ouvre pour les vérifier une dernière fois. Vous pouvez les exporter au format XHTML pour consulter les résultats plus tard.
Dans les préférences, vous pouvez déterminer le niveau de filtrage de noms de fichiers et de contenu lors de l'analyse des fichiers. Ceci peut augmenter le nombre de doublons détectés, mais également la probabilité de faux positifs. dupeGuru a également la capacité de marquer tous les doublons qui contiennent un mot particulier dans leur nom de fichier. C'est très utile pour trouver tous les fichiers « Copie de » accidentellement créés par vos utilisateurs et les dossiers vides nommés « Nouveau dossier » éparpillés dans vos répertoires.
Des versions sont disponibles pour Windows 2000 et versions ultérieures, et pour Mac OS X. Si vous cherchez à réduire le nombre de doublons dans vos fichiers musicaux ou vos photos, des versions adaptées, nommées respectivement dupeGuru ME et dupeGuru PE, valent un coup d'œil.
Prix : 19,95 USD (vente directe)
Nettoyez les fichiers dupliqués avec dupeGuru (cliquez sur l'image pour l'agrandir)

Gardez un œil sur votre environnement
pt360 Tool Suite PRO
packettrap.com
Il peut être très avantageux d'avoir une interface unique qui vous permet d'afficher et de gérer un ensemble d'outils de surveillance et de gestion du réseau. Outre le gain de temps (et d'espace de bureau), une suite intégrée peut faciliter le partage de données entre différents outils de surveillance tout en vous permettant d'examiner de nombreux moniteurs, ce qui vous offre tout de suite un aperçu plus complet de l'état de votre infrastructure.
Si ceci vous intéresse, allez voir pt360 Tool Suite PRO de PacketTrap Networks. Cette application offre une interface utilisateur intégrée pour les outils PacketTrap Networks, avec en plus des capacités de centralisation et de rapports consolidés. Vous pouvez créer et organiser votre vue d'outils dans un tableau de bord personnalisé pour accéder immédiatement à vos outils et aux informations d'état d'infrastructure les plus utilisés. Le tableau de bord de pt360 peut également s'afficher en mode plein écran. C'est pratique dans votre centre d'opérations, car il permet à chaque membre de l'équipe de jeter un coup d'œil à un écran et de voir rapidement l'état des ressources réseau et serveur. L'application prend en charge plusieurs tableaux de bord, donc vous pouvez créer divers affichages dans votre environnement, selon vos besoins.
Pour configurer un tableau de bord, sélectionnez simplement différents gadgets dans une liste déroulante et cliquez sur chaque gadget pour le configurer. Les gadgets sont groupés en cinq catégories (Application, Réseau, Périphériques, Disponibilité et Autre) et se basent sur le protocole SNMP et sur WMI pour contrôler vos serveurs, vos applications et vos périphériques réseau. Les gadgets d'application ont trait à Active Directory®, Microsoft® Exchange Server et SQL Server® et fournissent également un outil de navigateur. Les gadgets de réseau vous donnent des informations sur les interfaces de périphérique et fournissent des vues sur les 10 principales valeurs de moyennes de pertes de paquets, de latences les plus élevées et d'utilisations d'interface par les clients. Les gadgets de périphériques fournissent des indicateurs de performances de l'UC et d'utilisation de la mémoire, d'espace disque disponible, de listings de volume, d'utilisation d'interface de réseau et bien plus encore. Ils sont intéressants pour garder un œil sur la façon dont vos serveurs fonctionnent en temps réel via leurs requêtes WMI configurables. Les moniteurs de disponibilité affichent la durée de fonctionnement sous forme de graphique, d'indicateur, de texte ou de liste pour vos ordinateurs. Enfin, la section Autre possède une grande horloge numérique.
Outre le tableau de bord, la suite d'outils pt360 vous offre des outils de mise en réseau. Par exemple, vous bénéficiez de Cisco Configurator. Il vous permet d'archiver, de modifier, de charger, de télécharger et de comparer les fichiers de configuration de votre équipement Cisco. Vous recevez également trois différents outils d'analyse ping : l'un vous donne une vue de tableau triable, un autre un affichage graphique et le troisième vous permet d'analyser et de balayer rapidement un groupe d'adresses IP. Les autres types d'outils d'analyse à votre disposition incluent un scanneur d'adresse MAC, un outil d'analyse de port, un scanneur SNMP et un outil d'analyse WMI.
La suite d'outils peut servir également de serveur syslog et envoyer, recevoir, consigner et afficher des messages syslog depuis et vers n'importe quel périphérique sur votre réseau prenant en charge syslog. L'affichage prend également en charge le filtrage, donc vous pouvez isoler rapidement des messages problématiques, ce qui accélère le processus de dépannage.
La suite fonctionne comme un serveur TFTP (Trivial File Transfer Protocol), ce qui vous permet de déplacer rapidement des fichiers depuis et vers des périphériques dans le réseau. Les autres outils incluent des capacités de routage de suivi, Whois et Wake-on-LAN. Bien sûr, puisque c'est une solution de gestion centralisée avec des connexions à vos hôtes via WMI et SNMP, la façon dont la suite enregistre ses informations d'identification pour la connexion est critique. Heureusement, la suite utilise un magasin crypté d'informations d'identification AES (Advanced Encryption Standard) de 256 bits (AES) dans lequel vous pouvez ajouter, mettre à jour et supprimer les informations requises pour contrôler votre infrastructure.
Prix : 999 USD (vente directe) pour une licence unique.
Figure 36 Surveillez vos systèmes avec pt360 Tool Suite PRO

Gérez l'utilisation du disque
TreeSize Professional
jam-software.com/treesize/index.shtml
« Qu'est-ce qui occupe tout l'espace disque sur ce serveur ! » Ce cri vous paraît-il familier ? Votre application de surveillance vient de vous envoyer un message vous informant que votre système vient d'atteindre un seuil d'espace disque faible. D'accord, alors comment faire pour nettoyer cette machine, pourriez-vous vous demander. Et comment juger rapidement le meilleur coupable à la sentence « MAJ-Suppr. » (C'est le raccourci rapide pour ne pas passer par la corbeille.) Un outil pouvant vous aider dans votre quête de la lumière dans votre moniteur d'hôte est TreeSize Professional de JAM Software.
L'application s'exécute sous Windows 2000 et versions ultérieures pour les versions 32 et 64 bits de Windows, et elle vous donne des détails sur les fichiers qui occupent l'espace sur vos lecteurs. Il vous suffit de sélectionner le lecteur à interroger et l'application balaie la structure de dossiers automatiquement. Une fois cette opération terminée, vous avez accès à sept vues différentes du lecteur. La première est un graphique, qui vous offre trois graphiques différents à traiter : un graphique à secteurs, un graphique à barres et un graphique à boîte de taille relative. Chacun de ces graphiques vous permet d'accéder aux différents dossiers pour vous permettre d'identifier rapidement les objets encombrants. Vous pouvez personnaliser également les couleurs et le style des graphiques.
Ensuite vient une vue détaillée affichant les fichiers sous forme de tableaux triables et, dans cette vue, vous pouvez choisir un certain nombre de colonnes différentes à afficher. Les choix les plus notables parmi les utilisateurs sont notamment l'auteur de fichiers Microsoft Office, la taille moyenne de fichiers dans un dossier, le pourcentage du répertoire de parent occupé par ce fichier ou ce dossier et les liens réels.
La vue des extensions indique quels types de fichiers prennent le plus d'espace dans chaque répertoire lorsque vous accédez aux dossiers. La vue des utilisateurs présente la vue composite du volume d'espace qu'un utilisateur ou les fichiers du compte système occupent, ce qui est essentiel pour vous aider à isoler les utilisateurs posant problème. La vue des âges des fichiers vous propose une vue graphique des pourcentages de fichiers qui ont été modifiés, créés ou ouverts au cours du dernier jour, mois ou de la dernière année (selon la fenêtre de temps voulue), ce qui vous permet d'identifier les anciens fichiers qui peuvent être archivés ou supprimés sans problème. Il y a ensuite une vue Top 100, qui identifie les 100 plus gros fichiers sur le lecteur. Enfin, l'affichage d'historique fournit les modèles d'utilisation sur le lecteur au fil du temps.
Chacune des sept vues peut être imprimée, enregistrée et copiée dans le presse-papiers pour être utilisée ultérieurement. En outre, TreeSize accélère les tâches de maintenance de nettoyage courantes via la barre d'outils en vous permettant d'isoler rapidement les plus grands fichiers, les plus vieux fichiers, les fichiers temporaires, les fichiers de cache Internet et les fichiers dupliqués avec la capacité de recherche de fichiers. TreeSize Professional peut également balayer le réseau via les partages UNC, mais cela pose d'importants problèmes de performances en raison de la charge réseau que cela implique.
L'application prend également en charge un mode de ligne de commande. C'est très pratique pour la planification et les opérations de nuit. Vous pouvez créer également une analyse de tâche planifiée, en la configurant pour analyser un chemin et pour produire une série de rapports selon un calendrier standard. Ceci est utile pour contrôler l'espace partagé des utilisateurs chaque nuit et pour surveiller de près comment l'espace disque est utilisé.
Si vous vous demandez comment il est possible que tout votre téraoctet d'espace utilisateur ait déjà été englouti, peut-être que TreeSize peut vous aider à voir comment votre espace disque est utilisé et à commencer à le gérer plus efficacement.
Prix : 49,95 USD (vente directe) pour une licence unique.
Gérez l'utilisation du disque avec TreeSize Professional (cliquez sur l'image pour l'agrandir)

Greg Steen est un professionnel de l’informatique, dynamique et enthousiaste. Il est constamment à la recherche d’outils innovants destinés à faciliter les opérations, l'assurance qualité et le développement pour les professionnels de l’informatique.


Forum aux questions SQL Partitionnement, contrôles de cohérence et plus encore
Paul S. Randal

Q J'ai attaché accidentellement une base de données de production à un serveur SQL Server® 2005. Maintenant, je souhaite l'attacher au serveur correct, qui exécute SQL Server 2000. J'ai essayé de détacher simplement la base de données et de l'attacher au serveur SQL Server 2000, puis j'ai essayé de faire la même chose en effectuant une sauvegarde et une restauration, mais aucune de ces opérations n'a résolu le problème. Pourquoi cela ne fonctionne-t-il pas sur mon serveur SQL Server 2000 ? Celle-ci est la seule copie de la base de données dont je dispose.
R La première chose à noter ici est l'importance d'avoir des copies de secours. Les administrateurs de bases de données pensent habituellement n'avoir besoin de copies de sauvegarde que pour la restauration suite à une corruption ou un incident de grande ampleur. Mais le problème que vous avez rencontré est beaucoup moins évident : un problème est survenu lors d'une mise à jour, mais dans ce cas-là, la mise à jour en question à été effectuée par erreur. Il n'est reste pas moins que vous devriez toujours disposer d'une copie de sauvegarde récente des bases de données entières au cas où il arrive quelque chose à votre base de données.
Une mise à jour, qu'elle soit intentionnelle ou accidentelle, est une opération à sens unique. Il est donc très difficile d'en inverser les effets. Lorsque la mise à jour concerne les versions d'un serveur SQL, une série d'étapes de mise à jour est exécutée sur la base de données. Chaque étape implique d'ordinaire certaines modifications physiques à la base de données et chaque étape augmente le numéro de version de la base de données.
Par exemple, une des modifications majeures exécutées lors de la mise à jour d'un serveur SQL Server 2000 vers un serveur SQL Server 2005 concerne la structure des catalogue de système de la base de données (souvent appelés métadonnées de base de données ou tables de système). Ce catalogue contient différentes métadonnées sur les tables, les index, les colonnes, les allocations et autres détails relatifs à la structure relationnelle et physique de la base de données.
Au fur et à mesure que ces mises à jour sont effectuées, le numéro de version des bases de données augmente. Par exemple, les bases de données SQL Server 7.0 ont la version numéro 515, les bases de données SQL Server 2000 la version numéro 539 et les bases de données SQL Server 2005 la version numéro 611 (ou 612 si la fonction Vardecimal est activée). Ceci permet à SQL Server de savoir quelle est la dernière étape de mise à jour effectuée sur la base de données.
Certaines versions de SQL Server ne peuvent pas lire les bases de données mises à jour aux versions plus récentes de SQL Server (par exemple, SQL Server 2000 ne peut pas lire une base de données mise à jour à la version SQL Server 2005). Ceci est dû au fait que les anciennes versions n'ont pas le code requis pour interpréter les structures et la disposition de base de données mises à jour. Le problème de votre base de données, mise à jour vers la version SQL Server 2005 : il devient impossible de l'attacher au serveur SQL Server 2000.
En l'absence d'une copie de secours complète de la base de données, votre seule option est d'exporter toutes les données de la base de données mise à jour et de les retransférer vers une nouvelle base de données SQL Server 2000. Du moment que vous n'avez pas utilisé les nouvelles fonctions de SQL Server 2005, vous pouvez scripter la structure de la base de donnée, créer la base de données sur le serveur SQL Server 2000, puis exporter/importer les données.
Pour scripter la base de données à partir du serveur SQL Server 2005, vous pouvez utiliser l'Explorateur d'objets dans SQL Server Management Studio (cliquez avec le bouton droit sur la base de données, sélectionnez Tâches puis l'option Générer des scripts). L'assistant est explicite et génère un script permettant de créer tous les objets, les index, les contraintes, les déclencheurs, et ainsi de suite.
Q Récemment, nous avons reconçu notre schéma afin de pouvoir utiliser la partition de tables sur la table principale car on nous a dit que cela optimise les performances. La base de données est enregistrée sur un seul lecteur de 120 Go et la table se trouve dans un seul groupe de fichiers. Il n'y a pas de fenêtres défilantes, seulement de nouvelles partitions ajoutées toutes les semaines. Toutes les données doivent être disponibles en ligne. La plupart de nos requêtes traitent les données d'une seule semaine et il n'y en a que quelques unes qui concernent l'année précédente. Ceci semble plus facile à faire dans un groupe de fichiers unique. Est-ce correct ou y a-t-il autre chose à savoir ?
R Bien qu'il semble plus facile d'utiliser un groupe de fichiers unique, il est improbable qu'un tel partitionnement vous apporte des bénéfices. Le partitionnement se justifie essentiellement lorsque l'on souhaite accroître l'efficacité de la maintenance des bases de données et améliorer la disponibilité des données en cas d'incident majeur. De plus, le partitionnement vous permet de créer un schéma qui offre des gains de performance.
L'exemple type de partitionnement est une table des ventes avec 12 partitions, chacune représentant un mois de données de vente de l'année précédente. À la fin du mois, la partition la plus ancienne est désactivée (et archivée ou supprimée) et une nouvelle partition activée. Ce sont les fenêtres défilantes que vous mentionniez. La partition du mois en cours est en lecture/écriture et les mois précédents sont en lecture seule. Chaque partition est enregistrée dans un groupe de fichiers séparé. Ce schéma offre tous les avantages du partitionnement, mais ne s'adapte pas forcément à toutes les circonstances.
Ma femme, Kimberly, a proposé une variante du schéma ci-dessus permettant une indexation plus efficace. Imaginez que l'on fractionne la table de vente en deux tables : l'une contenant la partition en lecture/écrite, l'autre les 11 partitions en lecture seule, avec une vue partitionnée des deux tables.
Dans ce cas, la table en lecture/écriture présente un nombre réduit d'index et la table en lecture seule un plus grand nombre d'index, ce qui permet de prendre en charge des requêtes de rapport. Ceci accroît remarquablement l'efficacité du langage de manipulation des données (DML) sur les données en lecture/écriture. En effet, il ne doit plus gérer autant d'index non mis en cluster.
De plus, les requêtes sur les données en lecture/écriture n'ont pas à traiter les données en lecture seule. La suppression des partitions dans les plans de requête de SQL Server 2005 n'est pas parfaite, surtout en présence de prédicats complexes, mais cet aspect a été remarquablement amélioré dans SQL Server 2008. Pour plus d'informations à ce sujet, voir sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93.
Pour mieux vous illustrer mes propos, j'expliquerai quelques unes des fonctions activées par le partitionnement sur des groupes de fichiers multiples.
Disponibilité partielle de bases de données Il s'agit de l'aptitude d'une base de données à être en ligne et accessible en cas de restauration suite à un incident majeur pourvu que le groupe de fichiers primaire soit en ligne. Si vous avez un seul groupe de fichiers, pendant la restauration, la base de données entière est hors service. Si les données sont distribuées sur des groupes de fichiers multiples, seuls les groupes de fichiers endommagés seront hors ligne pendant la restauration. Dans ce cas, votre application pourra peut-être continuer à fonctionner.
Restauration fragmentaire Ce schéma est semblable à la disponibilité partielle de bases de données. Avec un seul groupe de fichiers, l'unité de restauration est constituée d'une page unique ou de la base de données entière. Avec des groupes de fichiers multiples, vous pouvez restaurer un groupe de fichiers unique. Les bases de données seront alors partiellement disponibles.
Maintenance des bases de données partitionnées Les deux schémas de partitionnement décrits ci-dessus vous permettent d'effectuer une suppression de fragmentation d'index par partition, même si toutes les partitions se trouvent dans un groupe de fichiers unique. Mais avec un groupe de fichiers unique, vous ne pourrez plus effectuer les contrôles de cohérence par groupe de fichiers, ce qui peut réduire considérablement la quantité de données que le contrôle de cohérence des bases de données (DBCC) doit traiter (et, donc, la quantité de ressources de processeur et E/S utilisées).
Pour simplifier, alors que vous pouvez avoir plusieurs partitions dans le même groupe de fichiers, avoir un mappage 1-1 entre partitions et groupes de fichiers présente de nombreux avantages.
Q Récemment, l'un de nos serveurs de bases de données haut de gammes nous a fait une frayeur : une carte de mémoire défectueuse provoquait des altérations. Nous avons découvert ces altérations lorsque des données aléatoires ont commencé à s'afficher dans notre application. Nous avons exécuté DBCC CHECKDB et identifié toutes sortes d'altérations. Malheureusement, ces altérations se trouvaient même dans nos copies de secours. Nous avons, donc, dû éliminer manuellement les données altérées.
Pour résumer, nous avons dû remplacer le matériel défectueux et activer le contrôle de pagination. Nous souhaiterions exécuter des contrôles de cohérence réguliers, mais nous disposons d'une fenêtre de maintenance réduite et il faut longtemps pour contrôler notre base de données 2.4To. Que pouvons-nous faire ?
R La question « Comment effectuer des contrôles de cohérence et autres opérations de maintenance sur une base de données très volumineuse (VLDB) ? » se présente de plus en plus souvent. De nombreux administrateurs de données abandonnent lorsqu'ils découvrent que le DBCC CHECKDB prend plus de temps que leur fenêtre de maintenance ne le permet. (Dans certains cas, la base de données est utilisée 24h/24, 7j/7et il est impossible de trouver une plage horaire appropriée et suffisante pendant laquelle les ressources du processeur et des E/S pourraient être dédiées à l'exécution du DBCC CHECKDB).
Sans laisser tomber et abandonner l'exécution des vérifications de cohérence (ce que je déconseille fortement), il existe quatre méthodes qui pourraient vous permettre d'exécuter des vérifications de cohérence. J'ai personnellement aidé certains utilisateurs à utiliser ces quatre méthodes.
Utiliser l'option WITH PHYSICAL_ONLY du DBCC CHECKDB Un DBCC CHECKDB habituel exécute plusieurs vérifications de cohérence logiques et occupe considérablement le processeur (puisqu'il s'agit essentiellement l'une opération dépendante du processeur). L'utilisation de l'option WITH PHYSICAL_ONLY se limite à exécuter les contrôles de cohérence de bitmap d'allocation très rapides, puis à lire et auditer chacune des pages allouées dans la base de données, en forçant le test des sommes de contrôle de page présentes sur les pages à tester. Le DBCC CHECKDB devient alors une opération dépendante des E/S, ce qui réduit considérablement son temps d'exécution (en fait, la vitesse d'exécution peut être doublée par rapport à un DBCC CHECKDB complet, ce qui correspond à un gain de temps remarquable).
Diviser la charge de travail du contrôle de cohérence Ceci signifie subdiviser les tables de la base de données en groupes de dimensions semblables (l'approche la plus facile consiste à subdiviser en fonction des numéros de page) et utiliser les commandes de DBCC CHECKTABLE pour exécuter un contrôle de cohérence de toutes les tables dans un groupe unique tous les soirs. Ainsi, avec, par exemple, sept groupes, si l'on contrôle un groupe par nuit et que l'on exécute un DBCC CHECKALLOC et DBCC CHECKCATALOG une fois par semaine, il est possible d'exécuter l'équivalent d'un DBCC CHECKDB sur une semaine.
Utiliser le partitionnement de table avec des groupes de fichiers multiples Il est possible de subdiviser les tables les plus grandes des bases de données très volumineuses en plusieurs groupes de fichiers. Un schéma de vérification de cohérence possible est l'exécution quotidienne d'un DBCC CHECKFILEGROUP sur le groupe de fichiers contenant la partition en lecture/écriture et d'un DBCC CHECKFILEGROUPs par semaine sur les groupes de fichiers contenant les partitions en lecture seule. La logique est que les données en lecture seule sont complètement sauvegardées et qu'elles ne sont pas utilisées dans le traitement de tous les jours. Par conséquent, il n'est pas nécessaire d'exécuter de vérifications de cohérence fréquentes, l'altération de ces données n'étant pas critique.
Décharger les vérifications de cohérence sur un autre serveur Cette option implique la restauration des copies de secours régulières et complètes des banques de données sur un autre serveur et l'exécution du DBCC CHECKDB sur ce serveur. Évidemment, ceci décharge complètement la charge de travail de la vérification de cohérence du serveur de production. Cependant, l'inconvénient est que, si une altération est identifiée, il faudra exécuter une vérification de cohérence sur le serveur de production. Mais ceci ne devrait arriver que très rarement.
Comme vous pouvez le voir, les administrateurs de bases de données disposent de nombreuses possibilités pour exécuter les vérifications de cohérences sur une base de données très volumineuse tout en réduisant la charge supplémentaire nécessaire à l'exécution d'un DBCC CHECKDB complet. Comme je l'ai déjà dit, j'ai moi-même aidé des utilisateurs à utiliser ces quatre méthodes. Je suis convaincu que ces options résoudront vos problèmes aussi.
Conseil : Utiliser des déclencheurs pour implémenter une logique côté serveur
Dans certains cas, vous devez implémenter une logique côté serveur avec des déclencheurs. Mais il y a des pièges dont vous devez être conscient. Voici quelques unes des choses que vous ne devez pas oublier.
  • Les déclencheurs sont activés par instruction, pas par ligne. Ceci dit, veillez à placer la logique additionnelle à l'intérieur de votre logique de déclenchement de sorte à pouvoir gérer aussi bien les cas où plusieurs lignes sont affectées par l'instruction que celui où aucune ligne n'est affectée (les déclencheurs sont activés par instruction même si aucune ligne n'est affectée). Les données affectées sont contenues dans des tables virtuelles pour les instructions de langage de manipulation des données. Ces tables peuvent être jointes, ce qui vous permet de travailler avec les données.
  • Les déclencheurs s'exécutent de manière synchrone dans votre transaction. Souvenez-vous de ceci à chaque fois que vous souhaitez appeler une application externe ou accéder à une ressource externe, et que le temps de réaction risque d'être trop long. Par exemple, si vous activez une instruction de mise à jour pour une table et qu'un déclencheur est activé pendant cette action, la transaction (le caractère implicite de l'instruction de mise à jour) ne se terminera pas tant que la logique du déclencheur ne sera pas terminée. Si l'application ou le processus externe renvoie un code d'erreur, le serveur SQL Server risque d'annuler la transaction et de restaurer votre transaction (en fonction de la gestion de l'erreur implémentée et du code d'erreur). Donc, si vous devez exécuter une opération externe au sein du déclencheur et que celle-ci n'est pas critique pour la transaction (ou ne doit pas être exécutée dans la même étendue), vous devriez l'attribuer à un autre processus et récupérer les données de manière asynchrone. SQL Server 2005 a introduit le SQL Server Service Broker, qui permet d'effectuer ce type d'opérations de manière asynchrone.
  • Toute erreur provoquée par une instruction au sein d'un déclencheur est très difficile à identifier. Si plusieurs tables sont impliquées dans la transaction, n'oubliez pas d'inspecter les déclencheurs en cas d'erreur et d'implémenter une gestion appropriée des erreurs. Si vous modifiez le schéma dans votre base de données, veillez également à suivre la logique de déclencheur. Dans le cas contraire, un petit déclencheur risque d'affecter de manière considérable la stabilité et les performances générales. Vous pouvez vérifier la plupart des implications liées aux modifications de schéma à l'aide de Visual Studio® pour les professionnels des bases de données. Pour cela, exécutez des contrôles de schéma automatiques lors de l'édition du projet ainsi que des analyses de code statiques pour identifier des incohérences de type de données.
—Jens K. Suessmeyer, consultant en base de données chez Microsoft

Paul S. Randal est directeur général de SQLskills.com et MVP SQL Server. Il a travaillé sur le moteur de stockage de données de SQL Server chez Microsoft de 1999 à 2007. Paul a écrit DBCC CHECKDB/repair for SQL Server 2005 et était responsable du Core Storage Engine pendant le développement de SQL Server 2008. Expert de la récupération après incident, de la haute disponibilité et de la maintenance de base de données, Paul présente fréquemment des conférences. Vous trouverez son blog à l'adresse SQLskills.com/blogs/paul.


Coup de projecteur sur les utilitaires Utilitaire de nettoyage de Windows Installer
Lance Whitney

Vous tentez de désinstaller ou de mettre à jour une application sur l'un des PC de votre environnement, mais votre commande ne s'exécute pas. À la place, une erreur vous indique que l'application ne peut pas être désinstallée ou mise à jour. Ce scénario vous semble familier ? Dans ce cas, vous vous êtes sûrement déjà demandé quelle est la cause de ce problème.
Les logiciels installés à l'aide de la technologie Microsoft® Windows® Installer (MSI) écrivent certains fichiers et paramètres de registre. Si l'un de ces fichiers ou paramètres est manquant ou endommagé, vous ne pouvez pas supprimer, mettre à jour ou même réinstaller le programme. La solution dans ce cas est de supprimer toutes les informations de Windows Installer pour pouvoir réinstaller le programme proprement. Microsoft vous offre gratuitement l'utilitaire de nettoyage de Windows Installer dans ce but.
L'utilitaire de nettoyage Windows Installer supprime tous les fichiers et paramètres de registre associés à une configuration Windows Installer d'un programme. Il est important de noter que l'outil ne supprime pas les fichiers d'installation du programme ou les paramètres de registre proprement dits. Il ne remplace pas non plus la commande Ajout/Suppression de programmes.
Vous avez recours à cet utilitaire si vous ne pouvez pas désinstaller ou mettre à jour une application à l'aide de la commande Ajout/Suppression de programmes ou d'autres méthodes. En supprimant les informations de Windows Installer, vous serez en mesure de réinstaller l'application. Vous pouvez alors laisser le programme installé tel quel, le mettre à jour ou le supprimer.
L'utilitaire de nettoyage de Windows Installer affiche une liste de toutes les applications Windows Installer sur le PC. (cliquez sur l'image pour l'agrandir)
Certains parmi vous connaissent le programme de ligne de commande msizap de Microsoft, qui supprime les données Windows Installer d'un programme. Et bien, cette commande est toujours utilisée ici : L'utilitaire de nettoyage de Windows Installer est tout simplement une interface conviviale de msizap qui élimine la manipulation des options de ligne de commande.
Après avoir installé l'utilitaire, un sous-répertoire nommé Windows Installer Clean Up (Nettoyage Windows Installer) s'affiche dans Program Files. Ce sous-répertoire contient trois fichiers : msicuu.exe, msizap.exe et readme.txt. Le fichier msicuu.exe présente une liste de toutes applications Windows Installer sur le PC, vous permettant de sélectionner, désélectionner et supprimer des applications. Ce programme transmet ensuite vos sélections à la commande msizap.exe, qui supprime les informations Windows Installer des applications sélectionnées.
Pour exécuter l'outil de nettoyage de Windows Installer, accédez au menu Démarrer | Tous les programmes et recherchez le dossier. Cliquez ensuite sur le raccourci Windows Installer. Une liste de toutes les applications Windows Installer sur le PC s'affiche (comme le montre la capture d'écran). Sélectionnez l'application qui vous concerne, puis cliquez sur le bouton Supprimer. Cette application est alors supprimée de la base de données Windows Installer. Vous pouvez désormais réinstaller correctement.
Notez qu'après avoir exécuté l'utilitaire de nettoyage, l'application ne s'affiche plus dans la liste Ajout/Suppression de programmes. Par conséquent, si vous voulez supprimer l'application définitivement, vous devez tout d'abord la réinstaller. L'utilitaire de nettoyage de Windows Installer fonctionne uniquement avec des logiciels qui utilisent la technologie Windows Installer, en général des installations empaquetées sous forme de fichiers MSI.
Finalement, n'oubliez pas que vous devez être connecté en tant qu'administrateur pour exécuter l'utilitaire de nettoyage de Windows Installer. L'outil est compatible avec toutes les versions 32 bits et 64 bits de Windows. Pour plus d'informations sur l'utilitaire et pour télécharger le logiciel, accédez au site support.microsoft.com/kb/290301.

Lance Whitney est consultant en informatique, formateur et rédacteur technique. Il a passé un nombre d'heures incalculable à affiner des postes de travail et serveurs Windows. Journaliste de formation, il s'est reconverti à l'informatique il y a 15 ans.


Au cœur de SharePoint Dépannage de l'intégration de messagerie
Pav Cherny

Téléchargement du code disponible à l'adresse SharePoint2008_08.exe (416 Ko)
Sommaire
Approche de dépannage générale
Architecture de messagerie SharePoint
Obtention des informations de diagnostic
Transfert de messages sortants
Transfert de messages entrants
Gestion d'annuaire
Conclusion
Dans un environnement SharePoint bien conçu, les informaticiens n'ont pas besoin de changer leurs habitudes de communication ou de travail pour collaborer. Au lieu de devoir vérifier manuellement les sites de collaboration, SharePoint peut délivrer des documents et d'autres informations, comme les alertes et les rappels, directement dans leurs boîtes aux lettres.
Les utilisateurs peuvent également participer aux flux de travail en répondant à ces messages ou en envoyant de nouveaux éléments sous forme de messages électroniques à des bibliothèques et des listes de documents.
Cependant, l'intégration de SharePoint® dans un environnement de messagerie sécurisé présente de nombreux défis et elle offre une opportunité à des composants non SharePoint d'influer sur la collaboration basée sur SharePoint. Le défi est d'isoler et d'éliminer efficacement les causes initiales de problèmes dans l'environnement intégré où qu'ils apparaissent.
Dans cet article, j'aborde l'intégration de messagerie SharePoint basée sur une stratégie de dépannage éprouvée qui fournit des résultats rapides. L'idée est de localiser efficacement l'emplacement problématique puis de déterminer des étapes de dépannage plus détaillées et ciblées.
Dans une grande entreprise, cette investigation par phases peut nécessiter de transmettre le problème à un autre spécialiste après une analyse initiale, surtout si le problème est lié à des composants autres que SharePoint. D'un autre côté, dans les petites et moyennes entreprises, il n'est pas rare qu'un seul administrateur informatique doive dépanner tous les systèmes impliqués directement, ce qui met encore plus en évidence le besoin d'avoir une approche structurée.
Pour garder cet article pratique, j'utilise un environnement de test avec Active Directory®, Exchange Server 2007 et WSS 3.0. Les instructions détaillées pour créer cet environnement de test, de même que les outils de dépannage abordés dans cet article, dans le matériel associé, sont disponibles dans la section Téléchargements de code du site Web TechNet Magazine.

Approche de dépannage générale
Le dépannage de l'intégration de messagerie SharePoint nécessite une approche extrêmement structurée, peut-être même plus que dans d'autres scénarios d'interopérabilité. Plusieurs facteurs compliquent cette tâche.
Bien sûr, vous devez travailler avec des technologies complexes, et pendant que vous luttez avec les problèmes de transfert de messages, les conversions de format de message, les aspects de sécurité et les problèmes de gestion d'annuaire, vous découvrirez que certains messages d'erreur de SharePoint peuvent être troublants. Les groupes de discussion Internet sont pleins de threads de discussion non résolus et des suggestions qui vous peuvent vous entraîner sur la mauvaise piste, comme exécuter toutes les applications Web sous l'identité du pool d'applications pour l'Administration centrale de SharePoint pour assurer le travail d'intégration de messagerie.
Mais il y a également des aspects positifs. SharePoint est très flexible. En fait, il peut vous fournir des informations de dépannage détaillées si vous savez où regarder. Avec quelques scripts basiques, vous pouvez améliorer considérablement l'efficacité de votre dépannage.
Le premier objectif du dépannage est de comprendre le problème auquel vous êtes confronté. Vous avez besoin d'identifier où se situe le problème et quels composants il implique. Vous pourriez également essayer de reproduire le problème dans différentes configurations de système et étudier les journaux d'événements Windows® et les fichiers journaux texte. Mais ceci peut être difficile car certains problèmes ne se produisent que de manière sporadique. Ceci dit, mieux vous pourrez reproduire un problème, plus vite vous pourrez identifier et éliminer sa cause initiale. Autre objectif important, souvent négligé, est de décrire toutes les modifications de configuration et les correctifs et de s'assurer qu'ils sont appliqués sur tous les systèmes concernés dans l'environnement, ainsi que sur tous les serveurs principaux dans une batterie de serveurs Web.

Architecture de messagerie SharePoint
Chaque fois que vous êtes confronté à un problème lié à l'intégration de messagerie, il est judicieux de prendre d'abord sa tasse de café ou de thé et de vérifier l'architecture d'intégration de messagerie SharePoint avant de s'engager dans des opérations de dépannage. Sinon vous pourriez finir par régler le mauvais problème ou réparer le mauvais composant. Par exemple, une erreur « Accès refusé » qui vous empêche de créer un objet de contact dans Active Directory n'est pas nécessairement le signe qu'il faut modifier les autorisations d'accès dans Active Directory, comme vous le verrez plus tard.
Dans tous les cas, il est essentiel de comprendre le rôle de chaque composant impliqué dans l'intégration de messagerie et l'interaction des différents composants. Si vous regardez la figure 1, vous verrez les composants importants dans un scénario de connectivité SharePoint-Exchange, ils seront détaillés dans les sections suivantes.
Figure 1 Architecture d'intégration de messagerie SharePoint (cliquez sur l'image pour l'agrandir)

Obtention des informations de diagnostic
L'un des éléments les plus importants pour le dépannage est des informations de diagnostic fiables. Le grand classique de toujours est le journal des événements Windows. Entre autres choses, vous pouvez contrôler le niveau d'écriture de SharePoint dans le journal des événements Windows sur les serveurs Web en utilisant Administration centrale de SharePoint (sur la page Opérations, sous Journalisation et création de rapports, cliquez sur Journalisation des diagnostics). Vous pouvez spécifier l'événement le moins critique à consigner dans le journal des événements et le journal de suivi. Le journal de suivi (situé par défaut sous %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) est très utile si vous cherchez des informations de bas niveau, mais il peut se remplir très rapidement. Donc utilisez cette fonctionnalité avec parcimonie.
Une autre façon d'obtenir des informations de diagnostic consiste à activer le débogage pour l'application Web concernée en configurant le fichier web.config correspondant, comme présenté dans le fichier Web Application Config.pdf du matériel associé. SharePoint affiche des informations de suivi détaillées directement dans l'interface utilisateur. L'un des avantages de cette approche est que vous pouvez voir les informations d'erreur pertinentes sans devoir analyser des mégaoctets de données de suivi. L'un des inconvénients est que vous devez modifier la configuration système de votre application Web. N'oubliez pas de sauvegarder le fichier web.config original puis de revenir à la configuration d'origine une fois le dépannage terminé.
Vous pouvez configurer également le service SMTP pour écrire des informations détaillées de processus dans le journal du protocole SMTP (dans le Gestionnaire des services Internet, sélectionnez la case Activer l'enregistrement dans le journal dans l'onglet Général). Assurez-vous que vous installez le module Journal ODBC avec la fonctionnalité Service SMTP, comme indiqué dans SharePoint Messaging Integration.pdf du matériel associé, même si vous n'avez pas l'intention d'utiliser le Journal ODBC. Sinon, le service SMTP n'écrira pas le journal de protocole. Par défaut, le journal de protocole SMTP est situé dans %SystemRoot%\System32\LogFiles\SmtpSvc1. C'est un fichier texte qui vous permet d'analyser en détail la communication SMTP et de déterminer si un message a quitté le serveur SharePoint.
Sur le serveur de transport Hub qui communique avec le service SMTP, vous pouvez activer également la journalisation de protocole dans Connecteur d'envoi et Connecteur de réception (voir SharePoint Messaging Integration.pdf). Vous pouvez utiliser différents autres outils pour suivre les chemins que prennent les messages dans l'environnement Exchange Server 2007 à travers les serveurs de transport Hub et les serveurs de Boîte aux lettres, tels que Suivi de messages, Afficheur des files d'attente et Suivi du pipeline. Si vous voulez des informations détaillées pour le dépannage de problèmes de flux de messages Exchange Server 2007, consultez la rubrique « Problèmes relatifs au transport et aux flux de messagerie » à l'adresse go.microsoft.com/fwlink/?LinkID=120145.
Sur les contrôleurs de domaine Active Directory, vous pouvez collecter des informations de dépannage détaillées en activant la journalisation des diagnostics pour Accès à l'annuaire et d'autres catégories en configurant les entrées de registre correspondantes sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Une valeur 0x0 pour une catégorie signifie que seuls les événements critiques sont enregistrés tandis qu'une valeur 0x5 représente tous les événements, y compris les informations de débogage. L'utilisation d'un niveau de journalisation supérieur à 0x3 peut dégrader les performances du serveur et remplir rapidement le journal des événements Windows. Lors des opérations normales, toutes les valeurs devraient être définies sur 0x0.
La collecte d'informations de diagnostic détaillées sur les serveurs SharePoint, Exchange et Active Directory dans une situation de dépannage peut vous aider à situer un point problématique rapidement et de manière fiable. Des outils de dépannage supplémentaires, comme les outils TCP/IP (ping, tracert, telnet, et ainsi de suite) et le Moniteur réseau, peuvent également s'avérer pratiques, car la majeure partie de la communication entre ces systèmes a lieu par le biais du réseau informatique. Microsoft® Network Monitor 3.1 est disponible à l'adresse go.microsoft.com/fwlink/?LinkId=120143.

Transfert de messages sortants
Ressources
  • Site Web des technologies et produits SharePoint
  • TechCenter Windows SharePoint Services
  • Centre de développement Windows SharePoint Services
  • Blog de l'équipe Produits et technologies Microsoft SharePoint
Équipé des journaux d'événements, journaux de suivi, journaux de protocole, journaux de suivi de messages et traces réseau, je suis fin prêt à dépanner l'intégration de messagerie SharePoint. Commençons par la partie facile : le transfert de messages sortants. SharePoint prend en charge le transfert de messages sortants dans différentes configurations et ne nécessite pas de service SMTP local sur les serveurs Web. Cependant, dans un scénario complet d'intégration de messagerie, c'est la configuration recommandée pour utiliser le service SMTP local. La figure 2 présente les composants clé du scénario.
Figure 2 Transfert de messages sortants (cliquez sur l'image pour l'agrandir)
Ce scénario de messagerie comprend quatre étapes : SharePoint doit transférer le message au service SMTP, le service SMTP doit traiter le message, le serveur de transport Hub doit recevoir le message, et Exchange Server 2007 doit transférer le message à sa destination finale.
Si SharePoint ne peut pas transférer le message au service SMTP, vous recevrez généralement une erreur dans l'interface utilisateur, par exemple une notification qu'un message électronique ne peut pas être envoyé. La cause peut en être que le service SMTP ne fonctionne pas. Ou peut-être que le journal SMTP de protocole vous dit que le service SMTP a refusé la tentative d'envoi avec le code d'erreur 550 (Action demandée non exécutée : boîte aux lettres non disponible), qui indique que le problème se situe au niveau du service SMTP.
Pour vérifier que le problème ne vient pas de SharePoint, vous pouvez utiliser un script de base (voir SMTP.VB dans le matériel associé) pour envoyer un message test via SMTP avec les mêmes informations d'expéditeur et de destinataire. Si c'est un problème de service SMTP, le script échouera. En fait, ce script pourrait vous donner de précieux indices sur la cause initiale du problème, ce que SharePoint ne révèle malheureusement pas même avec le débogage activé, comme illustré à la figure 3.
Figure 3 Impossible de relayer des messages (cliquez sur l'image pour l'agrandir)
En accordant au serveur Web les autorisations de relais dans la configuration de service SMTP et en redémarrant le service SMTP, vous pouvez résoudre le problème d'envoi de messages de SharePoint. Maintenant le message peut atteindre le service SMTP, et la question importante suivante est de savoir si le service SMTP route le message au serveur de transport Hub.
Si le message reste dans le dossier de file d'attente, le service SMTP est incapable de contacter le serveur de transport Hub. La raison en est soit que le service de Transport Microsoft Exchange ne s'exécute pas, soit un problème de communication ou de configuration du réseau. En utilisant le client Telnet, vous pouvez vérifier rapidement et facilement si vous pouvez vous connecter au port de destination d'un Connecteur de réception configuré pour la communication interne.
Ceci n'est pas nécessairement le port TCP 25. En fait, si le service SMTP utilise ce port, vous pouvez transférer les messages au Connecteur de réception par défaut pour les serveurs de transport Hub, qui est configuré de manière à bloquer les envois de messages anonymes. Dans ce cas, vous verrez un fichier de message dans le dossier de dépôt. (Le service Minuteur de Windows SharePoint Services doit être arrêté, sinon, le message disparaît au bout de quelques secondes). Le fichier de message est une notification d'état de remise indiquant que le message a été refusé avec le « Code de diagnostic : smtp;530 5.7.1 Le client n'est pas authentifié ».
Pour résoudre ce problème, vous devez créer un Connecteur de réception dédié pour vos serveurs SharePoint. Parce que vos serveurs SharePoint sont des systèmes internes, choisissez l'option d'authentification Sécurisé de l'extérieur. De cette façon, vous n'avez pas besoin d'accorder des droits étendus au compte ANONYMOUS LOGON (Ouverture de session anonyme). Envisagez également d'utiliser IPSec pour protéger la communication entre les serveurs SharePoint et le serveur de transport Hub.
Si les messages quittent le dossier de file d'attente SMTP et que les journaux de protocole SMTP sur le serveur SharePoint et sur le serveur de transport Hub (vérifiez le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indiquent un transfert de messages réussi, vous pouvez considérer que le travail est fait, à condition que Exchange Server 2007 puisse router le message vers la destination. Comme nous l'avons dit précédemment, utilisez les outils de dépannage de flux des messages inclus dans Exchange Server 2007 pour examiner les problèmes si des messages n'atteignent pas les destinataires Exchange voulus. Notez que des informations de destinataire incorrectes, des filtres antispam et des restrictions de taille de message peuvent empêcher une remise finale à ce stade.

Transfert de messages entrants
Dans le sens inverse, le transfert de messages est légèrement plus compliqué parce que les problèmes potentiels sont plus subtils. Par exemple, la documentation produit de SharePoint recommande la configuration d'enregistrements MX dans DNS pour les domaines de messagerie électronique de SharePoint, ce qui est un bon moyen de mal acheminer les messages dans une organisation Exchange.
Exchange Server 2007 utilise des Connecteurs d'envoi avec les espaces d'adresse associés pour transférer les messages. Il peut router vos messages SharePoint vers des serveurs de transport Edge pour le transfert via Internet bien que vos serveurs SharePoint soient internes. Pour le transfert de messages interne, utilisez plutôt des Connecteurs d'envoi avec des espaces d'adresse détaillés et spécifiez vos serveurs SharePoint exécutant le service SMTP comme étant des hôtes intelligents dans la configuration de connecteur (voir le fichier SharePoint Messaging Integration.pdf dans le téléchargement associé). L'établissement d'une topologie de routage bien définie avec des serveurs de tête de pont dédiés permet un transfert de messages fiable d'Exchange à SharePoint.
Pour vérifier que les messages arrivent à vos serveurs SharePoint, arrêtez le service Minuteur de Windows SharePoint Services. Les messages s'accumuleront dans le dossier Drop parce que c'est le service Minuteur qui traite les messages et place les fichiers joint dans les bibliothèques de documents associées avec les adresses de messagerie de destinataire, comme indiqué dans la figure 4. Si les messages n'arrivent pas dans le dossier Drop, utilisez l'Afficheur des files d'attente sur votre serveur de transport Hub pour voir si Exchange achemine les messages correctement. Examinez alors les problèmes de communication réseau qui pourraient empêcher le serveur de transport Hub de communiquer avec le service SMTP sur le serveur SharePoint.
Figure 4 Transfert de messages entrants (cliquez sur l'image pour l'agrandir)
Lorsque vous redémarrez le service Minuteur, vous devez voir les éléments de messages disparaître du dossier de dépôt. Cependant, si les pièces jointes de messages ne finissent pas comme documents dans les bibliothèques de destination bien que SharePoint indique que le traitement de message à réussi dans le journal d'événements Windows, cela signifie que Exchange a envoyé les messages au format RTF d'Exchange. Pour analyser ce problème, arrêtez le service Minuteur de nouveau, envoyez un autre message avec une pièce jointe à partir de votre client Outlook®, puis ouvrez le message dans le Bloc-notes une fois qu'il est arrivé dans le dossier de dépôt. Cherchez maintenant la chaîne « winmail.dat ». Si vous la trouvez, Exchange Server envoie les messages dans le mauvais format.
SharePoint exige le codage des pièces jointes de messages au format MIME ou UUENCODE. En outre, SharePoint n'affiche pas de problèmes liés à winmail.dat dans le journal des événements Windows (voir la figure 5). Les fichiers joints ne s'afficheront simplement pas dans la bibliothèque de documents. Utilisez le Bloc-notes comme outil de dépannage et corrigez le problème de mise en forme en configurant une définition de Domaine distant dans la Console de gestion Exchange pour le domaine de messagerie électronique SharePoint. Dans l'onglet Format du message d'origine envoyé comme pièce jointe à l'état de journal, sous Format RTF Exchange, sélectionnez Never use (Ne jamais utiliser).
Figure 5 Traitement de message Winmail.dat (cliquez sur l'image pour l'agrandir)

Gestion d'annuaire
L'un des événements les plus utiles du service Minuteur est l'événement 6873, qui déclare qu'une erreur est survenue pendant le traitement d'un fichier de message électronique entrant à cause d'un alias inconnu. Ceci survient si un utilisateur Exchange spécifie une adresse de messagerie SharePoint inexacte en envoyant des messages, par exemple une bibliothèque de documents qui n'existe pas.
Vous pouvez corriger ce problème en configurant le Service de gestion d'annuaire dans les paramètres de message électronique Entrants dans Administration centrale de SharePoint pour créer des objets de destinataire pour les bibliothèques de documents activés par message dans Active Directory. Les utilisateurs Exchange peuvent alors facilement sélectionner ces objets de destinataire avec les informations d'adresse correctes dans le carnet d'adresses.
Sachez toutefois que vous ouvrez maintenant une toute nouvelle boîte de vers de dépannage. Le Service de gestion d'annuaire échoue dans une configuration de système sécurisé fondée sur le principe du moindre privilège parce que cette fonctionnalité a des exigences d'autorisation élevée sur le serveur Web. En outre, la documentation produit (comme technet.microsoft.com/library/cc262947.aspx) exagère un peu la situation lorsqu'elle suggère que vous accordiez au pool d'application Administration centrale le droit « Créer, supprimer et gérer les comptes utilisateur » dans l'UO que vous avez spécifiée pour les objets de destinataire SharePoint dans Active Directory.
Le Service de gestion d'annuaire crée les objets de contact et de groupe, et, ainsi, le compte de pool d'applications Administration centrale nécessite un contrôle total sur les objets de contact et de groupe de cette UO, mais il n'a pas besoin d'autorisations administratives pour les comptes utilisateur. Si vous configurez le Service de gestion d'annuaire dans une batterie de serveurs Web, comme présenté, et que vous essayez d'activer par message une bibliothèque de documents, il y a de très fortes chances pour que vous rencontriez une erreur « Accès refusé ».
L'information d'erreur indique des problèmes d'autorisation Active Directory, et que les administrateurs SharePoint sont prompts à attribuer le contrôle total à Tout le monde sur l'UO SharePoint. Cependant, non seulement ceci affaiblit la sécurité d'Active Directory, mais cela ne résout absolument pas le problème.
Le dépannage structuré nécessite que vous localisiez d'abord le point problématique et que vous appliquiez alors des modifications ciblées de la configuration. Si vous suivez cette approche et que vous vérifiez le journal des événements Windows sur le contrôleur de domaine, que peut-être vous suivez la communication réseau en utilisant le Moniteur réseau, vous pourrez découvrir que SharePoint n'accède pas à Active Directory lorsque ce problème survient. Il est donc peu probable que les modifications de configuration d'Active Directory répareront le problème. Le problème survient sur le serveur SharePoint.
Malheureusement il est incroyablement difficile d'obtenir des informations plus utiles sur ce problème d'autorisation. SharePoint n'enregistre pas d'informations supplémentaires dans le journal des événements Windows. Cependant, si vous activez le débogage de SharePoint, vous pouvez voir la pile d'appels (comme à la figure 6), ce qui suggère que le Service de gestion d'annuaire utilise la méthode CreateContact d'un service Web SharePoint. Le SDK SharePoint vous dira qu'il s'agit du service Web d'intégration de messagerie électronique (<WSS_server>:<admin_port>/_Vti_bin/SharepointEmailWS.asmx).
Figure 6 Sortie de débogage
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Observons SharepointEmailWS.asmx dans un navigateur Web pour voir la liste des opérations prises en charge. Vous pouvez voir la méthode CreateContact, et un clic sur le lien de CreateContact révèle les messages SOAP que vous devez envoyer à ce service Web si vous voulez créer un contact dans Active Directory. C'est génial, parce que maintenant vous pouvez créer un outil de dépannage basé sur script (voir SharepointEmailWS.Vb dans le matériel associé) pour travailler hors de l'interface utilisateur SharePoint, ce qui permet de facilement spécifier différents comptes utilisateur pendant les exécutions de test. La figure 7 montre les informations retournées si vous exécutez ce script sous le compte de pool d'applications Administration centrale (à gauche) et sous le compte Administrateur SharePoint (à droite).
Figure 7 Deux erreurs « Accès refusé » différentes (cliquez sur l'image pour l'agrandir)
Les messages d'erreur diffèrent ! Les deux messages indiquent que l'accès est refusé, mais l'erreur sur la gauche indique un problème de traitement et l'erreur de droit non. Donc quelle est la différence entre les comptes de pool d'applications et le compte Administrateur de SharePoint ?
L'Administrateur SharePoint est un administrateur local sur le serveur SharePoint tandis que les comptes de pool d'applications ne le sont pas. L'ajout de comptes de pool d'applications de votre application de Web au groupe d'administrateurs locaux et le redémarrage du serveur Web résolvent le problème, mais ce n'est pas une excellente nouvelle. Je considère que l'exécution de comptes de pool d'applications avec des privilèges d'administrateur sur les serveurs Web de production est inacceptable.
Pourquoi un compte de pool d'applications a-t-il besoin de ces autorisations élevées ? Une fois encore, le script peut révéler la réponse. Si vous accordez à tous les utilisateurs les autorisations d'administrateur local sur votre serveur Web à des fins de test, vous découvrirez que les comptes de pool d'applications peuvent utiliser le service Web d'intégration de messagerie électronique alors que l'accès reste refusé pour tous les autres comptes, y compris les administrateurs SharePoint. Ceci signifie que le service Web d'intégration de messagerie électronique utilise la configuration de pool d'applications comme base pour les décisions de contrôle d'accès.
La configuration de pool d'applications fait partie de la métabase IIS (ou le fichier applicationHost.config dans IIS 7.0), et l'accès à la métabase est limité aux administrateurs locaux par défaut. Heureusement il est possible d'accorder à des comptes non-administrateurs l'accès à la métabase en utilisant l'explorateur de métabase incluse dans les outils du Kit de ressources IIS 6.0. Dans IIS 7.0, il est encore plus facile d'accorder le contrôle total au fichier applicationHost.config : exécutez simplement les commandes suivantes :
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
Pour résumer, pour créer des objets de contact dans Active Directory, le pool d'applications Administration centrale a besoin d'un contrôle total sur les objets de contact et de groupe dans l'UO cible. Et les comptes de pool des applications Web nécessitent l'accès total à la métabase sur les serveurs SharePoint dans la batterie de serveurs Web. Maintenant vous êtes prêt à créer des objets de contact en utilisant l'interface utilisateur de SharePoint.
Mais attendez, ce n'est pas tout ! La création d'objets de destinataire dans Active Directory n'est que la moitié de l'histoire de l'intégration d'annuaire. L'autre moitié est la production d'attributs de destinataire liés à Exchange et la mise à jour des carnets d'adresses basés sur serveur. Par exemple, si vous mettez à jour la liste d'adresses globale sur votre serveur Exchange en utilisant la commande Exchange Management Shell Update-GlobalAddressList « Liste d'adresses globale par défaut », vous pourrez détecter les objets de destinataire récemment créés pour les bibliothèques de documents SharePoint dans le carnet d'adresses Outlook. Mais l'envoi de messages à ces destinataires ont pour résultat des rapports de non-remise à cause des informations d'adresse inexactes, comme illustré dans la figure 8.
Figure 8 Message de non-remise à une bibliothèque de documents (cliquez sur l'image pour l'agrandir)
L'acronyme IMCEAEX désigne l'adresse encapsulée de Internet Mail Connector pour Exchange (Internet Mail Connector Encapsulated Address for Exchange). Il indique une adresse de destinataire non-Exchange encapsulée dans un format que l'ancienne version d'Internet Mail Connector peut traiter. Mais nous parlons d'Exchange Server 2007 et de connecteurs d'envoi SMTP natifs de nos jours.
Le fait est que le service Web d'intégration de messagerie de SharePoint n'écrit pas les attributs d'adresse dont Exchange Server 2007 a besoin pour le transfert de messages. Il écrit seulement les attributs prénom, nom de famille, nom d'affichage et adresse cible (et, facultativement, msExchRequireAuthToSendTo). Mais il ne définit pas le surnom de messagerie, ou les adresses DN Exchange héritées ou proxy, et il n'associe pas l'objet de destinataire à une stratégie de destinataire Exchange.
Pour résoudre ce problème, utilisez l'applet de commande Get-Mailbox dans le Shell de gestion Exchange pour obtenir tous les objets de destinataire avec une adresse cible pointant vers le domaine de messagerie électronique SharePoint. Et canalisez la sortie vers l'applet de commande Set-MailContact pour activer les stratégies de destinataire Exchange, comme suit :
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
Ou bien, utilisez comme alternative la console de gestion Exchange et sélectionnez la case « Mettre à jour auto. les adresses selon la stratégie d'adresse de messagerie » dans les propriétés de l'objet de contact.

WSS 3.0 et MOSS 2007 prennent directement en charge l'intégration de messagerie complète pour activer les alertes et les notifications, les flux de travail et les envois de document par message électronique. Bien qu'il ne soit pas facile de configurer les systèmes correctement, l'intégration de messages peut augmenter la productivité des employés. Vous devez vous assurer que les transferts de messages entrants et sortants fonctionnent correctement. Vous devez vous assurer également que l'intégration d'annuaire fonctionne.
Les messages d'erreur de SharePoint ne sont pas toujours intuitifs ou instructifs. Cependant, je vous ai montré des moyens d'aller au fond des problèmes d'intégration, localiser les causes initiales et les éliminer de manière fiable sans devoir mettre en péril la sécurité sur vos serveurs SharePoint.

Pav Cherny est un expert informatique et auteur spécialisé dans les technologies Microsoft pour la collaboration et la communication unifiée. Ses publications incluent des livres blancs, des manuels de produits et des livres avec un intérêt particulier pour les opérations informatiques et l'administration système. Pav est le président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.


Windows PowerShell Un aperçu furtif de la gestion à distance de la version 2.0
Don Jones

Cette rubrique est basée sur une version préliminaire de Windows PowerShell. Toutes les informations contenues dans le présent document sont susceptibles d’être modifiées.

Sommaire
Deux types d'accès distant
Synchrone - Asynchrone
Espaces d'exécution réutilisables
Accès à distance de type entrance
L'application qui tue dans 2.0
Avez-vous eu la possibilité d'essayer le tout dernier CTP de Windows PowerShell 2.0 ? La dernière version, CTP2, a encore amélioré la gestion à distance et maintenant il est grand temps de commencer à se familiariser avec ses nouvelles fonctionnalités. Avant que je ne commence les explications, vous pouvez
télécharger la nouvelle version depuis go.microsoft.com/fwlink/?LinkID=119707.
Premièrement, permettez-moi de clarifier quelques détails importants. Un CTP est un code pré-bêta que Microsoft fournit pour que des utilisateurs passionnés comme moi puissent se faire une idée de ce que Microsoft souhaite réaliser avec la nouvelle version d'une application. Chaque jalon de CTP ou drop (comme ils sont appelés dans le secteur) peut être complètement différent des drops précédents. Ceci est dû au fait que l'équipe de développement rassemble des commentaires, les étudie minutieusement et modifie l'application en fonction des commentaires des utilisateurs. Cette méthode présente de nombreux avantages et fournit des informations importantes concernant votre utilisation du CTP.
Une vidéo
Don Jones illustre les nouvelles fonctionnalités de gestion à distance dans le CTP2 de Windows PowerShell 2.0.

L'avantage est que, lorsque vous utilisez le CTP, vous pouvez envoyer des commentaires (via le site Web connect.microsoft.com) et que l'équipe de développement peut encore agir sur la base de ces commentaires ! Si vous attendez la bêta ou, pire, la version Release Candidate, il sera beaucoup plus difficile d'intégrer vos commentaires. Pendant le CTP, quoi qu'il arrive, l'équipe peut encore apporter des modifications de grande envergure si cela est nécessaire.
J'en arrive donc à ma mise en garde. Le CTP n'est pas prêt pour la production. Certes, le CTP2 de Windows PowerShell™ 2.0 est peut-être l'un des codes préliminaires les plus stables que vous ayez vus, mais n'oubliez pas que le prochain drop de CTP sera peut-être une application complètement différente. Donc, ne commencez pas à vous appuyer sur le CTP2 : la prochaine version sera peut-être complètement différente et vous devrez tout recommencer depuis le début.
Notez que le CTP ne peut pas être installé parallèlement à Windows PowerShell 1.0. Pour une configuration idéale, Microsoft® .NET Framework 3.5 devrait également être installé sur le système. Ceci permet, en effet, d'activer toutes les fonctions additionnelles. Autrement dit, certaines fonctions seront limitées.
Par ailleurs, puisque le CTP est un code très précoce, Microsoft a mis l'accent, jusque là, sur le fonctionnement de l'application avec les derniers systèmes d'exploitation, c'est-à-dire Windows Vista® et Windows Server® 2008. Si le CTP est actuellement compatible avec votre système d'exploitation, le code final ne le sera peut-être pas. On ne se penche sur le backporting que plus tard dans le cycle de développement.

Deux types d'accès distant
Dans le monde de la gestion à distance, vous trouvez habituellement deux types d'accès à distance : l'entrance et la sortance. L'accès à distance de type entrance comprend des administrateurs multiples qui effectuent des connexions Secure Shell à un serveur unique. Windows PowerShell est conçu pour permettre cela de manière sûre et partitionnée de sorte que, par exemple, une entreprise d'hébergement Exchange Server puisse offrir à ses clients un accès administratif à leurs portions de serveur. L'accès à distance de type entrance offre un accès à distance sûr et interactif à la copie de Windows PowerShell (version 2.0 uniquement !) installée sur un serveur distant.
On parle d'accès à distance de type sortance lorsque vous transmettez, en une fois, une série de commandes à un groupe entier de serveurs distants. Les commandes « sortent » de votre poste de travail pour atteindre le groupe de serveurs en parallèle. Les commandes s'exécutent sur chaque serveur et les résultats sont renvoyés à votre poste de travail (sous la forme d'objets Windows PowerShell) de sorte que vous pouvez les revoir et les utiliser pour travailler. Windows PowerShell prend en charge deux technologies fondamentales pour l'accès à distance de type sortance : l'infrastructure de gestion Windows® (WMI) et la gestion à distance Windows (WinRM), qui étaient d'abord inclus dans Windows Server 2008 et qui ont ensuite été mis à jour dans le CTP Windows PowerShell 2.0.

Synchrone - Asynchrone
En fait, même Windows PowerShell 1.0 offrait quelques fonctionnalités de sortance de base, qui étaient liées à l'infrastructure de gestion Windows. Par exemple, vous pouviez créer facilement un tableau de noms d'ordinateurs et, ensuite, récupérer, à partir de chaque nom, une classe WMI :
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
Exécuter des méthodes (telles qu'un redémarrage d'ordinateur) demandait un peu plus de travail puisque la version 1.0 n'offrait pas de moyen d'exécuter les méthodes WMI en bloc. Mais cela a changé dans la version 2.0 du CTP grâce à l'applet de commande Invoke-WmiMethod :
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
Toutefois, cette technique présente un problème. Il s'agit d'une technique synchrone, ce qui signifie que chaque ordinateur est contacté séparément et que vous devez attendre la fin de chaque commande avant d'en exécuter d'autres. Mais le CTP introduit un nouveau concept : les tâches en arrière-plan. Ceci permet d'exécuter des commandes de ce type en arrière-plan. Pour simplifier, vous pouvez exécuter une tâche en arrière-plan en ajoutant tout simplement le paramètre –AsJob :
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
Vous pouvez consulter l'état de la tâche en exécutant Get-PSJob et afficher les résultats finaux de la tâche en exécutant Receive-PSJob. (Je me pencherai sur les détails de l'administration des tâches dans un prochain article). Toutefois, l'applet de commande Invoke-Command offre de meilleures possibilités d'exécution des commandes en arrière-plan, comme ceci :
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
il effectue une transmission de type push de la commande Get-WmiObject à chaque ordinateur spécifié, puis il l'exécute localement. L'exécution est généralement beaucoup plus rapide et ne doit pas s'appuyer sur les connexions d'appel de procédure distante (RPC) de WMI. En effet, Invoke-Command utilise WinRM, qui utilise les ports 80 ou 443 par défaut. Ces ports facilitent la navigation des pare-feu et sont entièrement configurables. Invoke-Command prend également en charge des paramètres additionnels pour des informations d'identification alternatives et la limitation, ce qui vous permet de cibler des centaines d'ordinateurs bien que seuls quelques uns tournent en parallèle. Ceci vous permet d'éviter les surcharges excessives et l'encombrement.

Instances d'exécution réutilisables
Si vous planifiez d'administrer à distance une série donnée d'ordinateurs et cela avec une certaine fréquence, vous devez considérer l'utilisation d'instances d'exécution réutilisables plutôt que de simples listes de noms d'ordinateur. Dans Windows PowerShell, une instance d'exécution n'est qu'une instance du moteur Shell, qu'elle soit exécutée localement, sur votre ordinateur sous la forme d'une fenêtre de console Shell ou en arrière-plan, sur un ordinateur distant. Le démarrage d'un espace d'exploitation à distance est une opération simple :
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Puisque les espaces d'exploitation utilisent WinRM, ils utilisent donc le port 80 (ou 443, si vous spécifiez le paramètre UseSSL) par défaut. Ces ports peuvent également accepter des informations d'identification alternatives, etc. Si vous récupérez les objets d'espaces d'exploitation résultants, vous pouvez les transmettre à la commande Invoke-Command. Windows PowerShell effectue alors une transmission de type push de la commande aux ordinateurs sur lesquels ces instances d'exploitation existent :
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
L'avantage est que les instances d'exploitation restent actives aussi longtemps que le Shell est ouvert. Donc, vous pouvez les réutiliser pour des commandes additionnelles.

Accès à distance de type entrance
Les instances d'exploitation sont également essentielles pour l'accès à distance de type entrance. Par exemple, la figure 1 montre que j'ai créé une instance d'exploitation sur un ordinateur distant, que j'ai récupéré une référence à cet espace d'exploitation et qu'ensuite, j'ai utilisé l'applet de commande Push-Runspace pour activer l'espace d'exploitation. À ce stade, j'exécute des commandes sur l'ordinateur distant, un peu comme SSH ou d'autres utilitaires Remote Shell me permettraient de le faire. L'exécution de Pop-Runspace ramène mon instance d'exploitation d'origine « locale » et l'invite Shell me permet de savoir où je suis à tout moment.
Figure 1 Utiliser un espace d'exploitation pour exécuter des commandes sur un ordinateur distant (cliquez sur l'image pour l'agrandir)
La séquence exacte de commandes que j'ai exécutée est comme suit :
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
Cette technique est appelée entrance parce que plusieurs administrations peuvent ouvrir des espaces d'exploitation interactives sur le même serveur, au même moment : elles « entrent » de leurs postes de travail individuels sur le serveur. Un nouveau modèle de sécurité dans Windows PowerShell 2.0 vous permet de créer des Shells et des applets de commande limités. De cette manière, toutes les administrations sont limitées et ne peuvent donc pas apporter de modifications globales. Chacune est limitée à sa propre zone de Shell. (Ces nouvelles techniques de sécurité requièrent un développement logiciel personnalisé dans un langage ciblé .NET Framework. Ceci n'entre pas dans le cadre de la rubrique Windows PowerShell, mais il est intéressant de savoir que ces fonctions existent).

L'application qui tue dans 2.0
Le CTP Windows PowerShell 2.0 offre une liste étonnante de nouvelles fonctions. À mon avis, l'accès à distance est une application qui tue. Chaque administrateur dans pratiquement n'importe quel environnement peut en bénéficier.
Vous devriez vous familiariser avec ces fonctions afin de pouvoir envoyer vos suggestions à l'équipe produit. Voulez-vous que les ports par défaut de WinRM soient administrés via la Stratégie de groupe ? Les applets de commande devraient-ils fonctionner différemment ? Y a-t-il des problèmes de performance ? WinRM est-il facile à configurer ? Vous pouvez avoir une influence en envoyant des suggestions à connect.microsoft.com ou en partageant vos commentaires avec les lauréats de la récompense MVP, dont je fais partie (pour me contacter, envoyez vos commentaires aux forums sur ScriptingAnswers.com). Alors, participez à la création de l'application qui tue pour la prochaine génération de Windows PowerShell !
Applet de commande du mois Select-Object
Essayez ça ! Get-Service | ConvertTo-HTML | Out-File Services.htm. Maintenant, contrôlez le fichier HTML résultant dans votre navigateur Web. Il y a pas mal d'informations, n'est-ce pas ? Si seulement il y avait une façon de les trier en sélectionnant les informations qui vous intéressent ! Et bien, c'est précisément ce que Select-Object peut faire pour vous. Imaginons, par exemple que vous souhaitiez une liste de noms de services et leur état actuel. Vous pouvez utiliser ceci : Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.
Mais n'oubliez pas que Select-Object élimine l'objet original (dans ce cas, services) et génère un objet personnalisé (littéralement un type d'objet PSCustom), qui contient uniquement les propriétés que vous avez spécifiées. Les fonctionnalités de l'objet original ne seront plus accessibles, donc vous souhaiterez probablement garder Select-Object à la fin de votre pipeline et travailler avec l'objet original aussi longtemps que possible.

Don Jones est coauteur de Windows PowerShell v2.0 : TFM. Il est aussi le formateur de la formation dirigée « Special Forces » de ScriptingAnswers.com (scriptinganswers.com/training.asp). Vous pouvez le contacter à l'adresse suivante : jeepdon@mac.com.


Hé, vous le scripteur ! La voie Express
Les scripteurs Microsoft

Au cours des derniers mois, l'un des Scripteurs a eu l'occasion d'essayer quelque chose de nouveau ici, dans la région de Seattle. Il s'agit d'un programme testé dans diverses villes des États-Unis et appelé péage électronique. Cependant, dans l'état de Washington, il est connu sous le nom de Good to Go!
Il fonctionne comme suit : Vous payez pour obtenir un périphérique électronique qui s'attache à votre pare-brise. Vous ouvrez également un compte sur lequel vous mettez une petite somme d'argent. Chaque fois que vous passez sous l'un des périphériques de contrôle de l'autoroute, une somme d'argent est automatiquement prélevée sur votre compte. En fait, vous payez pour le droit de conduire sur l'autoroute sans avoir à vous arrêter à une cabine de péage.
Dans de nombreux endroits où des péages ont été mis en place, les personnes qui utilisent le covoiturage sont souvent exemptées de cette taxe. Cependant, ce qui est intéressant avec le système Good to Go!, c'est qu'il ne fonctionne que sur la voie réservée au covoiturage. À quoi cela peut-il servir, demandez-vous ? Pourquoi vous casser la tête mettre en place un système de covoiturage si vous devez de toute façon payer ? En fait, vous ne payez pas. Ce système ne fait payer que les conducteurs qui utilisent la voie de covoiturage lorsqu'ils sont seuls dans leur voiture. La raison évidente de vouloir emprunter cette voie est qu'elle est généralement moins encombrée ; parfois, elle est la seule voie où les voitures bougent !
Comme nous l'avons mentionné, ce système est un système expérimental pour le moment, bien que des milliers de personnes y aient déjà adhéré. Il existe de nombreuses personnes dans la région de Seattle qui sont prêtes à payer pour prendre la voie express afin d'arriver rapidement à destination.
Dans l'article de ce mois-ci, nous autres Scripteurs avons décidé de faire une petite expérience de notre cru. Nous avons décidé de vous montrer une voie expresse appelée Microsoft® Visual Basic® Express Edition. Nous commencerons par vous dire que l'un des aspects les plus chouettes de cette voie, c'est qu'elle est gratuite : aucun droit de passage à payer quel que soit l'usage que vous faites des informations, le nombre de personnes qui utilisent ces informations ou le moment auquel elles sont utilisées. Pas mal, non ? Bien sûr, vous pouvez penser qu'il y a un petit prix à payer, en ce sens que vous devez apprendre de nouvelles choses, mais les avantages que vous en retirerez en valent la peine.
Avant de continuer, nous voulons signaler que nous savons que nous sortons quelque peu de nos limites habituelles. En général, les produits Visual Studio® tels que Visual Basic et Visual C#® sont des sujets qui doivent être traités par MSDN® Magazine, et pas TechNet Magazine. Toutefois, vu que MSDN et TechNet semblent de plus en plus destinés à former une seule grande famille dysfonc..., heu... harmonieuse, nous espérons qu'on nous pardonnera, pour une fois, d'être sortis des rangs. En outre, bien que nous parlions de travailler avec ce qui est traditionnellement considéré comme un outil de développeurs, nous parlons toujours aux administrateurs systèmes Windows®. Restez avec nous quelques instants de plus et vous comprendrez bientôt ce que nous voulons dire !
La première chose à faire pour suivre notre raisonnement est d'installer Visual Basic. Non, non, attendez. Inutile de protester que vous ne l'avez pas ou que vous ne pouvez pas vous le permettre ! Microsoft propose une édition Express de Visual Basic que vous pouvez télécharger gratuitement sur microsoft.com/express/download.
Nous n'entrerons pas dans les détails sur la façon de travailler avec Visual Basic Express. Il existe des didacticiels dans l'Aide, et l'Aide elle-même est très bien conçue. (Difficile à croire, non ?) Ce que nous proposons de faire, c'est de vous montrer comment utiliser Visual Basic Express pour résoudre un problème particulier dans Windows Vista® (bien que cet exemple fonctionne également sur des versions antérieures de Windows). Ensuite, vous pourrez continuer à l'essayer tout seul. Le problème que nous allons résoudre est celui-ci : comment ouvrir une boîte de dialogue d'ouverture de fichier dans Windows Vista ?
Nous avons expliqué comment ouvrir une boîte de dialogue d'ouverture de fichier depuis un script il y a quelques années (voir l'article « Comment afficher aux utilisateurs une boîte de dialogue de sélection de fichiers ? » à l'adresse microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx). Cet article a été publié en janvier 2005, bien avant la commercialisation de Windows Vista. La solution utilise le contrôle ActiveX® UserAccounts.CommonDialog pour ouvrir une boîte de dialogue d'ouverture de fichier qui vous permet de rechercher un fichier à ouvrir. Malheureusement, ce contrôle a été supprimé de Windows à partir de Windows Vista, ce qui signifie que cette solution ne fonctionnera pas sur les nouveaux systèmes. (Non, personne ne nous a demandés si c'était une bonne idée). Cela signifie que, autant que nous le sachions, il n'est pas possible d'ouvrir une boîte de dialogue d'ouverture de fichier à l'aide de VBScript. Par conséquent, au lieu d'écrire un script, nous utiliserons Visual Basic pour écrire une application. L'une des choses que fera cette application sera d'ouvrir une boîte de dialogue d'ouverture de fichier.
Hé oui, l'exemple que nous sommes sur le point de vous montrer crée une application complète dans Visual Basic. Cela peut sembler un peu effrayant au premier abord, mais vous verrez qu'en utilisant Visual Basic Express, une application complète peut être aussi facile à écrire qu'un script. Cette application consistera en une fenêtre, ou un formulaire, vous permettant de cliquer sur un bouton ouvrant une boîte de dialogue d'ouverture de fichier. Vous pouvez alors sélectionner des fichiers texte dans cette boîte de dialogue, et notre application lira ces fichiers et affichera du contenu sélectionné dans le formulaire.
Bon, allons-y ! Nous commençons par ouvrir Visual Basic Express. La première chose à faire est de créer un nouveau projet en sélectionnant Nouveau projet dans le menu Fichier. Nous affichons ainsi la boîte de dialogue Nouveau projet. (Notez que si vous utilisez une version Visual Basic Express antérieure à 2008, vous verrez qu'il existe quelques différences mineures par rapport à ce que nous vous présentons ici). Nous allons créer une application Windows Forms. Vous devez donc sélectionner le modèle d'application Windows Forms et taper le nom que vous voulez donner à votre projet. Nous avons appelé le nôtre ReadFiles, comme vous pouvez le voir à la figure 1.
Figure 1 Création d'un nouveau projet dans Visual Basic (Cliquez sur l'image pour l'agrandir)
Lorsque le projet est créé pour la première fois, il fournit automatiquement un nouveau formulaire à utiliser. L'application que nous allons créer présentera à l'utilisateur un formulaire qui ressemble à celui de la figure 2. Comme nous l'avons mentionné, le formulaire inclut un bouton qui, lorsque vous cliquez dessus, affichera la boîte de dialogue d'ouverture de fichier, ouverte sur le dossier C:\Scripts. L'utilisateur pourra sélectionner un ou plusieurs fichiers texte n'importe où dans le système de fichiers. L'application lira alors la première ligne de chaque fichier texte sélectionné et affiche les résultats dans la zone de liste du formulaire. (Si cela vous semble familier, cela signifie que vous avez probablement participé à la catégorie Débutants des Jeux de script 2008 : microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx.)
Figure 2 Le formulaire ReadFiles qui sera présenté aux utilisateurs
Pour créer notre formulaire, nous devons faire glisser des contrôles de la Boîte à outils au formulaire de projet. Par défaut, la Boîte à outils est ouverte sur le côté gauche de la fenêtre Visual Basic. (Si la Boîte à outils n'est pas ouverte, cliquez sur le bouton Boîte à outils, sur le côté gauche de l'espace de travail Visual Basic et développez Tous les Windows Forms). Cliquez sur Button dans la Boîte à outils et faites glissez la souris sur le formulaire pour créer le bouton à la taille que vous voulez. Pour ajouter une étiquette au bouton, cliquez sur le bouton que vous venez d'ajouter au formulaire et tapez l'étiquette de votre choix. (Vous pouvez choisir de modifier la propriété Text dans la boîte de dialogue Propriétés, par défaut sur le côté inférieur droit de l'espace de travail Visual Basic). Nous avons appelé notre bouton Browse for Files (Rechercher des fichiers). Ensuite, cliquez sur ListBox puis cliquez à nouveau sur le formulaire et faites glisser la souris pour créer la zone de liste. Nous utiliserons la zone de liste pour afficher les lignes que nous lisons dans les fichiers texte.
C'est tout ce que nous devons faire pour créer notre formulaire. Passons maintenant à la partie la plus amusante : nous devons faire en sorte qu'il se passe quelque chose lorsque nous cliquons sur le bouton. Commencez par double-cliquer sur le contrôle Button du formulaire. Vous ouvrez ainsi un éditeur de code avec une nouvelle sous-routine déjà créée pour vous, la sous-routine Button1_Click :
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
Elle s'exécutera à chaque fois que vous cliquez sur le bouton de notre formulaire. Comme vous pouvez le voir, cette sous-routine est vide pour le moment ; nous devons ajouter le code qui dira à l'application ce qu'elle doit faire lorsque vous cliquez sur le bouton. Mais que voulons-nous qu'elle fasse, au juste ? Hé bien, nous voulons tout d'abord faire ce que nous avons promis de vous montrer au début de cet article : ouvrir une boîte de dialogue d'ouverture de fichier. Comme c'est très souvent le cas avec Visual Basic, nous utiliserons Microsoft .NET Framework pour effectuer cette opération.
Nous commençons par ajouter quelques instructions Imports au-dessus de la sous-routine :
Imports System
Imports System.IO
Ces instructions spécifient des espaces de noms .NET Framework. Comme nous utiliserons des classes qui se trouvent dans ces espaces de noms, nous les importons ici afin de pouvoir nous référer simplement aux classes que nous voulons. Notez que nous vous avons dit d'insérer ces instructions au-dessus de la sous-routine. Les instructions Imports sont globales, ce qui signifie qu'elles ne peuvent pas entrer dans une sous-routine ou une fonction ; elles doivent être à l'extérieur, toute seules.
Dans VBScript, à moins d'ajouter l'instruction Option Explicit en haut de votre script, vous n'avez pas besoin de déclarer explicitement les variables. Dans Visual Basic, l'instruction est automatiquement ajoutée, donc vous devez déclarer toutes vos variables. Nous aurons besoin d'une variable qui renfermera une référence à l'objet OpenFileDialog (qui représente justement juste la boîte de dialogue d'ouverture de fichier) :
Dim dlg As Windows.Forms.OpenFileDialog
Maintenant que nous avons déclaré (Dim-ed) une variable de type OpenFileDialog, nous pouvons créer une nouvelle instance de cet objet comme suit :
dlg = New OpenFileDialog()
Cependant, nous n'avons toujours pas affiché la boîte de dialogue. Tout d'abord, nous devons définir certaines propriétés :
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
La propriété Multiselect spécifie si l'utilisateur sera autorisé à sélectionner plusieurs fichiers dans la boîte de dialogue d'ouverture de fichier. Nous voulons que l'utilisateur puisse effectuer cette opération, et nous définissons donc cette propriété sur True. Nous définissons la propriété InitialDirectory sur C:\Scripts. Si vous ne définissez pas cette propriété, la boîte de dialogue s'ouvrira sur le répertoire principal de l'ordinateur.
Enfin et surtout, nous définissons la propriété Filter :
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Ici, nous filtrons les fichiers que la boîte de dialogue affichera à l'utilisateur. Nous leur montrerons uniquement les fichiers .txt. Une fois définies, ces propriétés, nous donneront une boîte de dialogue d'ouverture de fichier qui ressemble à la figure 3.
Figure 3 La boîte de dialogue Ouvrir affichant seulement les fichiers texte (Cliquez sur l'image pour l'agrandir)
Il est temps maintenant d'afficher la boîte de dialogue. Pour ce faire, nous utilisons la méthode ShowDialog :
dlg.ShowDialog()
La méthode ShowDialog renvoie une valeur indiquant si l'utilisateur a cliqué sur Ouvrir pour ouvrir les fichiers sélectionnés ou sur Annuler pour congédier la boîte de dialogue. S'il clique sur Annuler, nous ne voulons rien faire. Avant de continuer, nous appelons donc ShowDialog dans une instruction If pour nous assurer qu'il clique sur Ouvrir :
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
Oui, oui, nous savons que nous avons coché la propriété OK au lieu de la propriété Open ! Dans les coulisses, le bouton Ouvrir est en fait le même que le bouton OK ; c'est simplement qu'il est beaucoup plus logique d'afficher Ouvrir à l'utilisateur.
À présent, nous devons savoir quel(s) fichier(s) l'utilisateur a sélectionné(s) dans la boîte de dialogue. Les noms de fichiers sont contenus dans la propriété FileNames de l'objet OpenFileDialog ; nous configurons donc une boucle For Each pour lire les noms de fichiers contenus dans cette propriété :
For Each strName In dlg.FileNames
Oups ! Nous avons oublié de déclarer strName :
Dim strName As String
Maintenant, nous devons ouvrir chacun de ces fichiers et les lire. Nous effectuons cette opération dans Visual Basic à l'aide d'un bloc Using :
Using sr As StreamReader = File.OpenText(strName)
Un bloc Using n'est pas une chose à laquelle les scripteurs VBScript sont habitués, puisqu'il n'en existe pas dans VBScript. Visual Basic gère légèrement mieux (d'accord, beaucoup mieux dans de nombreux cas) les ressources système que VBScript. L'intérêt d'une instruction Using est qu'elle nous permet de nous assurer que les ressources système sont libérées lorsque nous quittons le bloc. Dans ce cas, nous nous assurons juste que nous ne conservons pas le contenu des fichiers et de gros blocs de mémoire.
Tout cela semble un peu compliqué, mais, en fait, il suffit de considérer cette instruction comme une instruction Set. Nous ne faisons que créer une instance d'un nouvel objet, en l'occurrence un objet StreamReader, et lui attribuer le flux de texte renvoyé depuis la méthode File.OpenText. Remarquez que nous transmettons à OpenText le nom du fichier que nous voulons ouvrir, c'est-à-dire le fichier de notre collection FileNames sur lequel nous effectuons actuellement une boucle.
Notre variable StreamReader, sr, renferme donc le contenu du fichier. Il nous faut maintenant une autre variable :
Dim strLine As String
Nous utiliserons cette variable pour enregistrer la première ligne du fichier texte que nous venons d'ouvrir :
strLine = sr.ReadLine()
Nous lisons la première ligne du fichier en appelant la méthode ReadLine sur notre objet StreamReader. (N'oubliez pas que l'objet StreamReader renferme le contenu de notre fichier). Nous enregistrons cette ligne de texte dans la variable strLine.
Maintenant, nous appelons tout simplement la méthode Add sur notre objet ListBox pour ajouter cette ligne à notre zone de liste :
ListBox1.Items.Add(strLine)
Pour cet exemple, tout ce que nous voulons, c'est la première ligne du fichier afin de pouvoir fermer notre StreamReader (nous ne voulons plus garder la totalité du texte de notre fichier) et fermer notre bloc Using :
sr.Close()
End Using
Après cela, nous effectuons une boucle pour trouver le fichier suivant qui a été sélectionné dans la boîte de dialogue d'ouverture de fichier, et ce jusqu'à ce que nous ayons lu tous les fichiers sélectionnés et ajouté toutes les lignes à la zone de liste. Notre code complet ressemble à la figure 4.
Figure 4 Code ReadFiles complet
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
Et voilà ! Nous vous avions bien dit qu'il n'était pas plus difficile de créer une application qu'un script.
Vous pouvez tester votre application en appuyant sur F5 (ou sur le bouton Démarrer le débogage de la barre d'outils Déboguer). Lorsque vous cliquez sur le bouton et sélectionnez un ou plusieurs fichiers dans la boîte de dialogue d'ouverture de fichier, vous devriez obtenir quelque chose qui ressemble à la figure 5.
Figure 5 Les premières lignes des fichiers sélectionnés affichées dans la zone de liste
Lorsque votre application s'exécute convenablement, sélectionnez Générer ReadFiles (ou le votre nom de votre projet quel qu'il soit) dans le menu Générer. Vous créez ainsi un fichier .exe appelé ReadFiles.exe que vous pouvez exécuter comme toute autre application et que vous pouvez distribuer à vos utilisateurs.
Nous nous rendons compte que cette voie peut ne pas avoir semblé « expresse » pour l'utilisation de la boîte de dialogue d'ouverture de fichier. Cependant, si vous considérez le fait que vous ne pouvez pas du tout le faire en écrivant un script depuis Windows Vista, l'écriture d'une simple application peut n'être qu'un petit prix à payer. C'est comme la somme d'argent que vous devez payer sur l'autoroute pour aller quelque part : ça ne vous plaît pas trop, mais ça vous permet d'arriver à destination !
Un autre avantage lié à l'utilisation de Visual Basic pour une telle opération réside dans le fait que vous avez maintenant commencé à utiliser un outil plus puissant que VBScript, ce qui vous permet de créer aisément des applications dotées d'une interface utilisateur attrayante. Un avantage énorme ! Les administrateurs système trouveront en outre une multitude d'autres usages à Visual Basic.
Et n'oubliez pas ceci : vous n'avez pas besoin de repasser votre permis de conduire pour utiliser la voie payante ; vous devez juste vous habituer au fait que les voitures qui sont devant vous avancent ! Parallèlement, si vous connaissez VBScript, vous n'avez pas besoin d'apprendre un langage entièrement nouveau pour utiliser Visual Basic. Il vous suffit de vous habituer au fait que vous pouvez faire beaucoup plus avec.
Les scripts embrouillés du Dr. Scripto
Le défi mensuel qui teste non seulement votre capacité à résoudre des énigmes, mais également vos compétences d'écriture de scripts.

Août 2008 : Alphabet de script
Dans le casse-tête de ce mois-ci, vous devez insérer les lettres A à Z dans les espaces vides pour révéler un mot en rapport avec l'écriture de scripts. Chaque lettre (A à Z) doit être utilisée seulement une fois, et les lettres n'apparaissent pas dans l'ordre alphabétique. La lettre insérée pourrait constituer le début du mot, le milieu ou la fin. Par exemple, dans la première ligne, nous avons inséré la lettre C pour compléter le mot SCRIPT :

RÉPONSE :
Les scripts embrouillés du Dr. Scripto
Réponse : Alphabet de script, août 2008

Les scripteurs 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.


Histoires de Bureau Services de déploiement Windows 101
Wes Miller

Sommaire
WDS dans Windows Server 2003
WDS dans Windows Server 2008
Faire un choix
Considérations
Mise en route WDS
Images de capture
Capture 101
Migration d'images
Installation sans assistance
Dans l'article du mois dernier, j'ai examiné l'historique des outils de déploiement PXE de Microsoft. Ce mois-ci, j'examine les services de déploiement Windows, notamment les versions fournies avec Windows Server 2003 et la version mise à jour fournie avec Windows Server.
2008. Après cela, je vous dirai comment devenir opérationnel avec WDS.
Vous pouvez concevoir WDS comme les services d'installation à distance (RIS) réécrits. Bien que tous deux partagent des composants clés et que la version de WDS de Windows Server® 2003 comporte un mode hérité fonctionnellement identique à RIS, l'infrastructure de WDS en mode natif et dans 50% du mode mixte est toute nouvelle.

WDS dans Windows Server 2003
Windows Vista® a été lancé en même temps que WDS. Cette étape était nécessaire car la configuration de Windows Vista avait été complètement reconçue dans l'architecture de format d'image WIM de Windows®. Cela rendait RIS incapable de déployer Windows Vista (et donc, Windows Server 2008). WDS a été mis à disposition comme un téléchargement hors bande pour les utilisateurs exécutant Windows Server 2003 SP1. Avec SP2, WDS a complètement remplacé RIS.
Vous devez vous rappeler que, puisque WDS dans Windows Server 2003 possède une compatibilité descendante totale, vous n'avez pas besoin de passer en mode natif lors de l'installation de WDS sur vos systèmes Windows Server 2003 SP2. Vous pouvez continuer à exécuter en mode hérité, (s'exécutant fonctionnellement comme un serveur RIS) ou en mode mixte, pour permettre l'initialisation de WDS ou de RIS.
WDS ne se limite pas au déploiement de Windows Vista et Windows Server 2008 : en mode natif ou dans la moitié native du mode mixte, WDS présente plusieurs autres fonctionnalités. Au lieu d'utiliser le moteur d'installation en mode noyau de Windows et l'installation traditionnelle abordés le mois dernier (technet.microsoft.com/magazine/cc645015), WDS utilise Windows PE comme environnement de préinstallation de démarrage et déploie des images WIM au lieu d'utiliser les installations RISetup ou RIPrep. Le déploiement est ainsi plus rapide, facile et fiable.
De plus, beaucoup des restrictions mentionnées le mois dernier (par exemple la nécessité d'utiliser des caractères ANSI) disparaît, car Windows PE est capable d'afficher les mêmes jeux de caractères qu'une installation complète de Windows.
Par ailleurs, WDS comporte plusieurs outils que RIS n'offrait pas, un composant logiciel enfichable MMC (Microsoft® Management Console) pour simplifier la gestion et un outil de configuration de ligne de commande complet avec des fonctionnalités au-delà de celles de RIS.
Les modes Hérité et Mixte permettant de déployer les images RISetup et RIPrep de Windows, vous devez garder à l'esprit ce qui suit. Par le passé, RIS a utilisé un composant appelé SIS de stockage d’instance simple pour optimiser le stockage d'images sur disque. SIS, fourni par la suite comme composant de Windows Storage Server 2003, utilisait un service appelé Groveler qui s'exécutait en arrière-plan sur les serveurs RIS (et WDS), recherchant des fichiers identiques. Si la taille et le hachage des fichiers correspondent, SIS enregistre une copie dans son dossier de stockage commun et crée un lien vers chaque version originale trouvée.
SIS est conçu pour un impact minimal sur l'utilisation du processeur tout en permettant de réaliser une importante économie de stockage. Ce concept a été utilisé tout d'abord par RIS, puis globalement sur la plate-forme Windows Server. Mais SIS n'est plus utilisé pour WDS.
WDS sur Windows Server 2003 en mode natif (et toujours sur Windows Server 2008) utilise des images WIM pour l'installation. Il dispose donc de sa propre compression et, ce qui est plus important, de son modèle de stockage à instance unique, et par conséquent, n'utilise pas SIS. Le magasin d'image remplace le modèle de stockage utilisé par RIS avec une nouvelle conception WIM pour WDS. Des informations supplémentaires sur SIS sont disponibles à l'adresse go.microsoft.com/fwlink/?LinkId=120302.

WDS dans Windows Server 2008
Dans Windows Server 2008, WDS est devenu un sur-ensemble et un sous-ensemble de la fonctionnalité dans Windows Server 2003. Il peut désormais déployer des images via la multidiffusion en mode autonome, à l'aide du serveur de transport, d'un nouveau serveur TFTP (Trivial File Transfer Protocol) doté de meilleures performances, de la prise en charge de systèmes x64 EFI (Extensible Firmware Interface) et de rapport amélioré des métriques d'installation. J'aborderai ces thèmes dans la rubrique du mois prochain.
Vous devez noter qu'une fonctionnalité de WDS dans Windows Server 2003 a disparu dans Windows Server 2008 : la prise en charge de l'installation héritée. La capacité de déployer des images RISetup/RIPrep ou d'utiliser le sélecteur du système d'exploitation RIS hérité pour démarrer l'installation n'est plus disponible.

Choix
L'une des questions les plus fréquentes que l'on me pose depuis le lancement de Windows Server 2008 est la suivante : « Quelle version de WDS dois-je utiliser ? ». La réponse dépend de si vous déployez des versions préliminaires de Windows Vista et, le cas échéant, si vous êtes prêt à faire la transition des images RISetup et/ou RIPrep à l'utilisation explicite d'une installation WIM.
WDS, même dans Windows Server 2008, est capable de déployer Windows jusqu'à Windows 2000 dans une image WIM (et peut le faire en utilisant la multidiffusion). Par conséquent, la transition de RIS à WDS immédiate, et penser à Windows Server 2008 dans votre infrastructure (et la migration d'images RIS à WDS) suivie d'une migration vers WDS dans Windows Server 2008 peut vous sembler logique.
Vous pouvez également migrer de RIS à WDS sur votre système Windows Server 2003, ce qui se fait essentiellement lorsque vous installez SP2 et passer aux images WDS. Il suffit alors d'une mise à niveau à WDS Windows Server 2008.
Il ne s'agit pas du modèle que je recommande, toutefois. Comme avec de nombreuses versions de Windows Server antérieures à 2008, Microsoft recommande de migrer (au lieu de mettre à niveau sur place) d'une version de Windows Server à une autre.
Et comme déjà mentionné, la prise en compte des versions x64 de Windows Server 2008 semble plus logique dans votre infrastructure que les versions x64 de Windows Server 2003. Si vous effectuez cette transition, l'exécution d'une migration serveur à serveur de WDS sur Windows Server 2003 vers Windows Server 2008 sera relativement facile et beaucoup plus fiable comparée à une mise à niveau sur place.

Considérations
Tenez compte des considérations suivantes lors du déploiement de WDS. Notez qu'il n'existe aucune nouvelle exigence pour WDS (RIS prenant en compte des éléments similaires), mais vous voudrez en tenir compte pour la création d'un serveur WDS unique ou d'une infrastructure entière :
Privilèges Deux éléments principaux à garder à l'esprit lors de la gestion d'un serveur WDS. Vous devez autoriser un serveur WDS dans Active Directory® tout comme vous l'avez fait avec RIS. Pour cela, vous devez être un administrateur de domaine dans le domaine racine de la forêt, un administrateur d'entreprise ou disposer des privilèges appropriés. Vous devez également être un administrateur de domaine pour gérer votre serveur WDS, et, bien sûr, vous devez être un administrateur du serveur WDS
Virtualisation Lors de l'exécution sur une instance de Windows Server 2003 ou Windows Server 2008 virtualisée sous Microsoft Virtual PC ou Virtual Server et de la communication avec un client PC sur la même installation de Virtual PC ou Virtual Server, une situation compétitive peut survenir, débutant au démarrage de PXE et résultant en un client très lent ou potentiellement bloqué. Il est recommandé de virtualiser les clients ou les serveurs, mais pas les deux (surtout sur le même système hôte). Personnellement, je ne recommande pas de virtualiser un serveur WDS pour la production, notamment en raison de la remarque suivante.
Autres services WDS, tout comme RIS, ne fonctionne pas toujours correctement avec les autres services de production. En particulier, j'ai noté des problèmes avec RIS/WDS lors de l'exécution sur un système de production qui exécute également Microsoft Exchange Server, Systems Management Server (SMS) et System Center Configuration Manager (SCCM).
En général, je recommande que WDS soit le seul rôle sur votre serveur si vous l'utilisez pour la production pour quelques clients uniquement. Cela ne s'applique pas uniquement à WDS : vous devez réfléchir soigneusement si vous devez mélanger des rôles de produits serveur Windows et les tester avant le déploiement.
Liaisons lentes ou à latence élevée Comme avec RIS, WDS n'est pas conçu pour l'utilisation sur une connexion bas débit ou à forte latence, telles qu'un lien satellite. La négociation PXE peut s'avérer problématique et le téléchargement d'images difficile ou impossible.

Mise en route WDS
Plus d'informations sur WDS

  • Guide pas à pas pour WDS dans Windows Server 2003
  • Guide pas à pas des Services de déploiement Windows (Windows Server 2008)
  • Déploiement et gestion de la mise à jour de WDS sur Windows Server 2003
  • Documentation pour les Services de déploiement Windows dans Windows Server 2008
  • Références techniques : Services de déploiement Windows (Windows Server 2008)
Pour commencer, vous devez décider si vous allez utiliser WDS sur Windows Server 2003 ou Windows Server 2008. Si vous utilisez Windows Server 2003, je recommande de commencer avec SP2, qui contient WDS en natif comme composant facultatif (remplaçant RIS), au lieu d'utiliser SP1 et le téléchargement facultatif précédemment disponible de WDS inclus dans le kit d’installation automatisée de Windows (Windows AIK).
Pour les deux versions de Windows Server, vous voudrez créer votre système de serveur. Vous devez utiliser une carte d'interface réseau (NIC) haute qualité, de 100 Mbits/s ou plus. N'utilisez pas l'association NIC, car l'infrastructure PXE de WDS peut s'avérer problématique. Notez que si vous utilisez Windows Server 2008, vous pouvez installer WDS sur Server Core ou l'installation complète de Windows Server 2008.
WDS est installé sur Windows Server 2003 comme composant facultatif (tout comme RIS précédemment). Vous pouvez l'installer pendant l'installation du système d'exploitation ou après en exécutant la commande Ajouter/Supprimer des programmes | Ajouter/Supprimer des composants Windows (ou en exécutant sysocmgr.exe depuis la ligne de commande). WDS est installé dans Windows Server 2008 en tant que rôle et peut être installé via l'assistant de configuration initiale (cliquez sur Ajouter des rôles | Suivant | et sélectionnez Services de déploiement Windows), via Server Manager (Gestionnaire de serveur) (mêmes étapes que pour l'assistant de configuration initiale) ou via la ligne de commande en exécutant la commande ServerManagerCmd –install WDS.
Une fois WDS installé, vous devez le configurer. Dans votre menu Démarrer de Windows, accédez à Outils d'administration et sélectionnez Services de déploiement Windows. Au démarrage de MMC, cliquez avec le bouton droit de la souris sur votre serveur et sélectionnez Configurer le serveur dans le menu pour lancer l'assistant de configuration.
Si vous installez sur Windows Server 2003 et que vous mettez à niveau un serveur RIS existant, vous voudrez spécifier le répertoire RemoteInstall existant pour mettre à niveau l'installation héritée sur le mode mixte. Dans cette situation, vous devez vous assurer que le répertoire RemoteInstall ne se trouve pas sur la partition du système, car les performances en souffriraient.
La figure 1 montre la console WDS sur Windows Server 2008 avant la fin de l'exécution de l'assistant de configuration. La figure 2 montre la page de bienvenue de l'assistant de configuration WDS sur Windows Server 2008. La figure 3 montre l'étape de configuration PXE de l'assistant de configuration WDS. Au cours de cette étape, vous pouvez spécifier si le serveur doit répondre à n'importe quel client (utile pour la création initiale), répondre aux ordinateurs clients connus (déjà prédéfinis dans Active Directory) ou répondre à tous les clients (et s'il doit facultativement retenir tous les clients inconnus pour permettre à un administrateur de choisir une ligne de conduite appropriée).
Figure 1 WDS installé mais pas encore configuré
Figure 2 Assistant de configuration WDS
Figure 3 Choix d'une stratégie de réponse pour le serveur PXE
La figure 4 montre un serveur WDS entièrement configuré sur Windows Server 2008 (sans images installées) avec sa page de propriétés ouverte. Si vous utilisez un serveur qui est déjà un serveur DHCP, assurez-vous de définir l'option DHCP 60 sur PXEClient et WDS sur Ne pas écouter sur le port 67. Cela permettra à votre serveur WDS d'ignorer une étape lors du processus de découverte PXE (comme expliqué dans l'article du mois dernier).
Figure 4 Serveur WDS entièrement configuré sur Windows Server 2008
Une fois l'assistant terminé, vous pouvez ajouter de nouvelles images. Deux types d'images peuvent être ajoutés à un serveur WDS s'exécutant en mode mixte ou natif :
  • Images de démarrage : images contenant Windows PE 2.x, généralement copiées du DVD d'installation de Windows Server 2008 ou Windows Vista SP1. Notez que vous voudrez utiliser le fichier Sources\Boot.wim de Windows Server 2008 pour vos images de démarrage (même si vous déployez Windows Vista ou un système d'exploitation hérité) si vous utilisez la multidiffusion. Les images de démarrage contiennent en général Windows PE, Windows Setup.exe et d'autres dépendances.
  • Images d’installation : images de système d'exploitation Windows, en général, le fichier \Sources\Install.wim de Windows Vista ou Windows Server 2008.
Les étapes d'ajout d'une image de démarrage ou d'installation par défaut, sont presque les mêmes. Vous commencez chaque processus en cliquant avec le bouton droit de la souris sur le type d'image et en choisissant d'ajouter une image de ce type.
Pour une image d'installation, vous devez spécifier un nom pour le groupe d'images (étant donné qu'un WIM par défaut sur le DVD de Windows contient plus d'un type de système d'exploitation). Accédez ensuite au fichier boot.wim ou install.wim approprié à ajouter et cliquez sur Ouvrir. Pour les images d'installation, vous pouvez alors décocher les images de volume (les images du système d'exploitation) que vous ne voulez pas ajouter au serveur WDS. Finalement, vous pouvez installer les clients PXE à l'aide de ces images par défaut.

Images de capture
Pour créer des images de système d'exploitation personnalisées, vous devez créer une image de capture, c'est-à-dire, une image Windows PE qui est conçue pour vous permettre de capturer un système Windows comme image WIM. Le plus simple est d'utiliser une image boot.wim installée précédemment.
Cliquez avec le bouton droit de la souris sur l'image, puis cliquez sur l'option de création de capture d'image. Spécifiez le nom et la description pour votre image, ainsi que l'emplacement d'enregistrement d'une copie locale du fichier .wim en cas de problèmes de connectivité au réseau lors du déploiement de l'image de capture. Suivez les étapes de l'assistant jusqu'à la fin, puis cliquez sur Terminer.
Ensuite, cliquez avec le bouton droit de la souris sur le dossier des images de démarrage dans le MMC de WDS et cliquez sur Ajouter une image de démarrage. Comme précédemment, suivez les instructions de l'assistant. Lorsque vous avez terminé, vous pouvez capturer une image d'installation Windows.

Capture 101
Avant de capturer l'image d'un système d'exploitation, vous devez, bien sûr, installer Windows et vous assurer qu'il inclut toutes les applications, personnalisations et mises à jour souhaitées. Vous devez ensuite exécuter Sysprep sur votre système. Vous ne pouvez capturer des images d'installation Windows qu'à partir de systèmes préparés avec Sysprep. Vous devez spécifier un emplacement local valide pour l'enregistrement de la nouvelle image (pour éviter l'altération potentielle) et une extension de fichier *.wim.
Une fois le système configuré et la version correcte du fichier sysprep.exe copiée dans le système, vous devez suivre ces étapes :
  1. À partir de l’invite de commande sur l'ordinateur de référence, passez au répertoire où se trouve le fichier sysprep.exe.
  2. Démarrez Sysprep (vous pouvez également le démarrer en double-cliquant sur le fichier sysprep.exe et en spécifiant des options manuellement). Sur les ordinateurs exécutant Windows Vista ou Windows Server 2008, exécutez la commande sysprep /oobe /generalize /reboot. Sur les ordinateurs exécutant des versions précédentes de Windows, exécutez sysprep -mini –reseal –reboot.
  3. Au redémarrage de l'ordinateur, PXE démarre (le processus peut varier selon le système client).
  4. Dans le menu de démarrage, sélectionnez votre image de capture, puis cliquez sur Suivant.
  5. Choisissez le lecteur et le nom et description de l'image.
  6. Comme mentionné, uniquement les systèmes sur lesquels sysprep a été exécuté sont visibles. Ceci est à dessein et vous ne pouvez pas le contourner.
  7. Cliquez sur Parcourir et accédez au dossier local dans lequel vous souhaitez enregistrer l'image d'installation capturée. Vous pouvez choisir un périphérique réseau connecté.
  8. Sélectionnez Télécharger l'image sur un serveur de déploiement.
  9. Entrez le nom du serveur WDS, puis cliquez sur le bouton de connexion.
10. Dans la liste de groupe d'images, sélectionnez le groupe d'images d'enregistrement de l'image, puis cliquez sur Terminer.
Cette image est maintenant prête au déploiement depuis votre serveur WDS. Les vétérans de RIS ont peut-être remarqué que je n'ai pas capturé cette image Windows en temps réel. WDS requiert que le système capturé soit hors ligne.
RIPrep, dans RIS, pouvait capturer (plus précisément, l'exigeait) un système en ligne. Ce processus était extrêmement fragile. Je pense que vous trouverez le processus de capture WDS relativement facile et certainement plus robuste.

Migration d'image
Si vous avez déjà utilisé RIS, vous devez disposer de quelques images sur votre ordinateur. Pour les images RISetup (une installation par script), cela se termine ici. Vous pouvez, toutefois, migrer des images RIPrep vers des images WIM WDS. En fait, WDS vous permet de migrer les images via WDSUtil (j'aborderai ceci plus en détails dans l'article du mois prochain).
Je recommande généralement de ne faire ceci que si vous avez investi beaucoup de temps dans une image que vous ne voulez pas perdre. Le processus fonctionne relativement bien, mais j'ai entendu parler d'erreurs lors de la conversion, ce qui signifie que vous devez recréer l'image de toutes pièces.

Installation sans assistance
Lorsque vous créez une image comme indiqué, vous obtenez une image qui peut être installée manuellement. Pour une installation plus automatisée ou entièrement automatisée, vous devez utiliser deux fichiers d'installation sans assistance. WDS requiert un fichier de réponse (unattend.xml, enregistré dans le répertoire \RemoteInstall\WDSClientUnattend sur votre serveur WDS) pour automatiser le processus d'installation WDS. Le second fichier est une image de fichier sans assistance. Pour Windows Vista ou version ultérieure, il s'agit d'un fichier unattend.xml. Pour les images Windows précédentes, il s'agit d'un fichier sysprep.inf qui se trouve dans une structure de répertoire $OEM$ ou dans \Unattend dans le répertoire de chaque image. Ce fichier permet d'automatiser l'installation de Windows une fois WDS terminé.
Pour créer le fichier sans assistance de WDS, créez un fichier unattend.xml pour WDS avec Windows AIK. Copiez ce fichier dans le répertoire RemoteInstall ou dans un sous-répertoire. Cliquez avec le bouton droit de la souris sur l'image d'installation pour laquelle vous voulez utiliser le fichier sans assistance, puis cliquez sur le bouton des propriétés. Dans l'onglet Client, sélectionnez l'option d'installation sans assistance et indiquez le fichier unattend.xml spécifié précédemment.
Pour créer le fichier sans assistance de l'image des images pré-Windows Vista, copiez le fichier sysprep.inf dans le répertoire $OEM$ de l'image (par exemple, D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. Pour les images Windows Vista, spécifiez l'image à associer, cliquez sur le bouton de propriétés, puis, dans l'onglet d'options générales, cliquez sur l'option d'installation de l'image sans assistance. Spécifiez ensuite le fichier unattend.xml à utiliser pour l'installation.
Nous en sommes à mi-chemin. Cette rubrique vous permettra de devenir opérationnel avec WDS. Le mois prochain, j'entrerai plus en détails dans l'utilitaire WDSUtil, les magasins d'images et la multidiffusion. Puis, je conclurai la série par un examen détaillé du comment et pourquoi vous devriez envisager de créer une solution de déploiement personnalisée sur WDS. En attendant, reportez-vous à l'encadré « Plus d'informations sur WDS » qui accompagne cet article.

Wes Miller est responsable de produit technique pour CoreTrace (www.CoreTrace.com) à Austin au Texas. Il travaillait auparavant chez Winternals Software et comme responsable de programme pour Microsoft. Vous pouvez contacter Wes à l’adresse suivante : technet@getwired.com.


Vigilance sécurité Mots de passe et cartes de crédit, deuxième partie
Jesper M. Johansson

Sommaire
Processus d'ouverture de session pseudo-multifacteur
Le problème des compléments de navigateur
L'authentificateur ne doit jamais changer
Vers des mots de passe moins sûrs
Contournement de l'ouverture de session pseudo-multifacteur
Les problèmes des mots de passe compromis
Quelques points positifs
Tromper les utilisateurs avec un mirage de sécurité
Ouvrir ou ne pas ouvrir
Fournir des communications sécurisées
Question de confidentialité
Bienvenue dans la deuxième des trois parties de ma série d'articles sur la façon dont, lorsqu'il s'agit de problèmes de sécurité, l'industrie informatique perturbe les consommateurs plus qu'elle ne les aide. Dans l'édition de juillet 2008 de TechNet Magazine, j'ai décrit des conseils de sécurité inefficaces et inexacts ainsi que des flux de travail d'ouverture de session déroutants. (Si vous n'avez pas encore lu la Partie 1, vous la trouverez
à l'adresse technet.microsoft.com/magazine/cc626076.). J'y expliquais à quel point des conseils en sécurité extrêmement courants bien qu'inadaptés et des flux de travail d'ouverture de session incorrects semaient la confusion chez les consommateurs et minaient leurs efforts pour protéger leurs informations personnelles.
Dans cette édition, je poursuis cette discussion avec de nouveaux exemples pratiques issus du monde de la sécurité des particuliers. La dernière partie de cette série, qui inclura un « appel aux armes » destiné aux professionnels de la sécurité du monde entier, paraîtra dans la prochaine édition de TechNet Magazine.

Processus d'ouverture de session pseudo-multifacteur
Au mois d'octobre 2005, le FFIEC (Federal Financial Institutions Examination Council) a publié ses consignes « Authentication in an Internet Banking Environment » (Authentification dans un environnement bancaire sur Internet)(voir www.ffiec.gov/press/pr101205.htm). Le calendrier pour sa mise en œuvre était de seulement 14 mois et les institutions financières américaines ont commencé à se démener pour essayer de trouver comment respecter ces nouvelles consignes.
La plupart des institutions n'ont pas tenu ce calendrier. Bon nombre des institutions qui ont finalement respecté les directives y sont parvenues grâce à des mesures qui n'ont d'autre but que de respecter les consignes. En d'autres termes, les institutions ont pris des mesures qui n'améliorent absolument pas la sécurité des clients (ce sont simplement des pratiques de « comédie sécuritaire »). Parmi les exemples de solutions inutiles, celles qui tentent de créer une authentification multifacteur sans être réellement multifacteur figurent parmi les plus intéressantes.
Considérons par exemple la technologie qui mesure la cadence de frappe lorsqu'un utilisateur tape son mot de passe. Utilisée sur un site Web, cette solution présente une boîte de dialogue d'ouverture de session qui ressemble en tous points à l'ancienne. Cette boîte de dialogue, cependant, est maintenant un objet Adobe Flash.
L'objet Flash enregistre la cadence de frappe de l'utilisateur, notamment les caractéristiques de temps de pression sur les touches et de temps entre les frappes de touche. Ces données sont envoyées au site Web avec le mot de passe, où elles sont comparées aux valeurs stockées. Tant que les données de cadence de frappe restent dans une certaine variance des données stockées, et que le mot de passe correspond, l'ouverture de session est acceptée. L'idée générale est que ceci permet au site d'utiliser une méthode d'authentification pseudo-biométrique, sans devoir installer de matériel tiers sur le client.
J'appellerai ceci l'authentification pseudo-multifacteur. Il ne s'agit pas d'une véritable authentification multifacteur, qui mesure deux des facteurs canoniques suivants ou plus :
  • Quelque chose que l'utilisateur a (comme une carte à puce)
  • Quelque chose que l'utilisateur sait (comme un mot de passe)
  • Quelque chose l'utilisateur est (comme une empreinte digitale)
Au lieu d'inclure plusieurs facteurs dans le processus d'authentification, l'authentification pseudo-multifacteur lit plusieurs paramètres à partir d'un facteur unique : le mot de passe. Il utilise alors ces paramètres supplémentaires pour faire des déductions sur quelque chose que l'utilisateur est.
La technologie utilisée pour l'authentification pseudo-multifacteur souffre de nombreuses failles. Considérées ensemble, ces failles rendent la technologie largement inefficace pour la résolution des problèmes de sécurité qu'elle prétend résoudre.

Le problème des compléments de navigateur
Les systèmes d'authentification pseudo-multifacteur s'appuient sur des compléments de navigateur pour fournir le traitement côté client sophistiqué dont ils ont besoin. Tout logiciel, bien sûr, contient des bogues, et certains de ces bogues causent des vulnérabilités. Ces vulnérabilités deviennent un vrai problème lorsque le logiciel est difficile à mettre à jour et que l'utilisateur ne sait même pas si une mise à jour a été installée.
Les compléments de navigateur présentent malheureusement ces deux caractéristiques : ils sont difficiles à mettre à jour et ne fournissent pas à l'utilisateur d'informations suffisantes pour déterminer si la version installée est à jour. Par conséquent, l'utilisateur doit exposer sur Internet un morceau de logiciel qui ne serait peut-être pas nécessaire autrement.
Dans certains cas, l'actualisation d'un complément nécessitera des visites régulières sur son site Web pour le téléchargement des mises à jour. Il va sans dire qu'il est peu probable que cela arrive pour la plupart des utilisateurs. Tout système nécessitant qu'un utilisateur final expose à Internet un logiciel supplémentaire non apparenté simplement pour fournir une fonctionnalité de sécurité doit faire l'objet d'une réflexion poussée.

L'authentificateur ne doit jamais changer
Le facteur « quelque chose que vous êtes » a une particularité, peut-être même un défaut, qui n'affecte pas les deux autres facteurs. Tandis que vous pouvez modifier les mots de passe (quelque chose que vous savez) et fabriquer de nouveaux jetons de sécurité (quelque chose que vous avez), le nombre d'authentificateurs biométriques que vous pouvez utiliser est assez limité. Dans le cas des empreintes digitales, par exemple, vous en avez dix, généralement pour la vie. Et si vous perdez un de ces « codes » dans un accident, vous ne pourrez généralement pas le remplacer.
Examinons à présent comment ceci s'applique à l'exemple d'ouverture de session pseudo-multifacteur. La mesure collectée sous forme d'élément d'un autre facteur ne peut pas être facilement remplacée ou modifiée. Bien sûr, lorsque le mot de passe change, la façon dont l'utilisateur le tape change, mais sa façon générale d'appuyer sur les touches du clavier ne change pas. C'est exactement ce sur quoi repose cette technique. Si ces mesures étaient compromises, il pourrait être possible de les synthétiser. Tout au moins, un attaquant peut capturer ces mesures et les rejouer.

Vers des mots de passe moins sûrs
Il est tout à fait judicieux d'utiliser des mots de passe longs et de modifier vos mots de passe fréquemment. Et, comme je l'ai expliqué dans la première partie de cette série, il est également recommandé (contrairement à ce que d'aucuns conseillent) d'enregistrer vos mots de passe, de façon sécurisée, bien sûr. Cependant, ces pratiques ne sont pas favorables à la saisie manuelle de votre mot de passe. Un mot de passe long est plus difficile à taper, et un mot de passe enregistré est bien plus utile lorsque vous pouvez le copier et le coller. L'une des meilleures façons de tenir à jour une centaine de mots de passe ou plus consiste à utiliser un utilitaire logiciel tel que Password Safe (disponible sur le site sourceforge.net/projects/passwordsafe). Ce type d'outil vous permet de générer des mots de passe entièrement aléatoires, de les enregistrer sous une forme chiffrée et de les coller dans les boîtes de dialogue d'ouverture de session. En fait, avec ce type d'outil, vous n'avez pas même besoin de connaître votre mot de passe.
Mais voilà où le bât blesse : vous ne pouvez pas mesurer la cadence de frappe si l'utilisateur ne tape pas le mot de passe. Et si vous devez taper le mot de passe dans un objet qui mesure la cadence de frappe, cette technique de gestion des mots de passe commence à montrer ses faiblesses. En effet, il n'est pas simple de taper correctement d'un mot de passe de 15 caractères entièrement aléatoires. Les utilisateurs choisiront donc généralement de simplifier leurs mots de passe lorsqu'ils seront confrontés à ce type de système. Pourtant, un mot de passe de 15 caractères entièrement aléatoires est à lui seul beaucoup plus sûr qu'un mot de passe plus court associé à un système d'authentification pseudo-multifacteur.
En fait, l'authentification pseudo-multifacteur, implémentée de façon exclusive, oblige les utilisateurs à utiliser des mots de passe moins sûrs. Malheureusement, comme vous le verrez bientôt, la prise en charge des utilisateurs qui utilisent des techniques de gestion des mots de passe correctes annule pratiquement tout avantage offert par les systèmes d'authentification pseudo-multifacteur.

Contournement de l'ouverture de session pseudo-multifacteur
Même si un site implémente l'authentification pseudo-multifacteur, il toujours doit prendre en charge une façon de contourner ce système. Tout d'abord, peu de sites peuvent demander à tous leurs utilisateurs d'installer une technologie d'une « quarte partie » pour pouvoir accéder au site. Certains utilisateurs (certains auteurs de TechNet Magazine, par exemple) refuseront toujours d'installer ce type de logiciel.
Ensuite, la cadence de frappe peut varier pour de nombreuses raisons et les sites doivent par conséquent s'adapter à cette donnée. Par exemple, imaginons qu'un utilisateur se foule le poignet et que sa cadence de frappe change temporairement. Comment alors accédera-t-il au site si celui-ci analyse sa cadence et pense qu'une autre personne essaie de se connecter avec ses informations d'identification ? Si la blessure était permanente, l'utilisateur pourrait réinitialiser la valeur de cadence stockée. Cependant, dans le cas d'une blessure temporaire, l'utilisateur ne voudra probablement pas réinitialiser la valeur stockée, et supposera que sa cadence de frappe reviendra bientôt à peu près à ce qu'elle était au début.
Enfin, tous les utilisateurs ne sont pas capables d'utiliser les systèmes d'authentification pseudo-multifacteur. Par exemple, une personne handicapée qui interagit avec l'ordinateur par une interface de reconnaissance vocale ne pourra peut-être pas renseigner la boîte de dialogue, selon qu'elle empêche ou non la saisie par programmation. Dans ce cas, un système alternatif prenant en charge les utilisateurs handicapés sera probablement exigé par la loi.
La façon la plus simple et la plus directe de s'adapter à tous ces scénarios consiste à prendre parallèlement en charge l'authentification par mot de passe standard.

Les problèmes des mots de passe compromis
Les systèmes d'authentification pseudo-multifacteur sont supposés répondre à divers problèmes liés à l'authentification par mot de passe. Toutefois, ces systèmes ne parviennent pas à apporter une réponse à toutes les façons dont les mots de passe peuvent être compromis. Il existe cinq méthodes principales permettant de compromettre les systèmes basés sur l'authentification par mot de passe, où « compromettre » signifie qu'un attaquant obtient et utilise le mot de passe d'un autre utilisateur :
  • Déduction d'un mot de passe
  • Enregistreurs de frappe
  • Attaques par phishing
  • Interrogation de l'utilisateur
  • Pénétration dans un système stockant tout ou partie d'un mot de passe
La déduction de mot de passe n'est plus une méthode d'attaque très courante pour les criminels ; elle a été considérablement éclipsée par les enregistreurs de frappe et le phishing. La déduction de mot de passe n'est en outre atténuée que partiellement par l'authentification pseudo-multifacteur. Une approche conventionnelle de la déduction de mot de passe a peu de chances de fonctionner contre un système d'authentification pseudo-multifacteur puisque l'attaquant doit deviner le mot de passe et la cadence de frappe. Bien qu'il soit théoriquement possible de synthétiser les caractéristiques de frappe, il est rarement nécessaire de le faire parce que les véritables données peuvent généralement être capturées par une attaque par phishing ou un enregistreur de frappe. Par ailleurs, si le système fournit également une interface d'ouverture de session par mot de passe standard uniquement, il suffit à l'attaquant d'utiliser ce système pour deviner le mot de passe.
Qui plus est, les attaques par déduction du mot de passe sont largement mises en échec par les mots de passe forts. Si nous pouvons apprendre aux utilisateurs à utiliser des mots de passe plus forts, éventuellement à l'aide d'outils, l'authentification pseudo-multifacteur devient inutile. (Au contraire, les mots de passe simples qui sont généralement utilisés avec les systèmes d'authentification pseudo-multifacteur font en fait de la déduction de mot de passe une approche plus viable.) Ainsi, l'intérêt qu'on pourrait trouver ici à atténuer les attaques par déduction de mot de passe n'existe vraiment que si la mise en œuvre ne prend pas en charge les ouvertures de session par mot de passe uniquement. Et, comme je l'ai dit, ceci n'est pour ainsi dire jamais possible. En d'autres termes, si les utilisateurs utilisent des mots de passe plus faibles en présence de systèmes d'authentification pseudo-multifacteur, la déduction de mot de passe peut redevenir une méthode d'attaque viable ; l'authentification pseudo-multifacteur réduirait ainsi la sécurité, au lieu de l'augmenter. Il est nécessaire d'étudier davantage cette question.
L'authentification pseudo-multifacteur ne résout pas non plus le problème des enregistreurs de frappe. Je ne connais pas d'enregistreur de frappe qui soit couramment utilisé aujourd'hui pour capturer la cadence de frappe, mais cela ne veut absolument pas dire qu'aucun n'a jamais été conçu. Un enregistreur de frappe est un élément matériel placé entre le clavier et l'ordinateur, ou un logiciel qui capture les frappes. Dans les deux cas, l'enregistreur dispose d'un accès complet à toutes les données utilisées par la solution d'authentification pseudo-multifacteur.
En fait, l'enregistreur de frappe peut même accéder à plus de données dans la mesure où une solution d'authentification s'exécute en mode utilisateur tandis qu'un enregistreur de frappe se trouve à un niveau bien inférieur. Sans un chemin approuvé entre le clavier et l'objet Web utilisé pour capturer le mot de passe, il est impossible d'empêcher ce type de compromission. Si les solutions d'authentification pseudo-multifacteur deviennent suffisamment courantes, vous pouvez être certain que quelqu'un créera un tel enregistreur de frappe.
De même, les attaques par phishing ne sont pas mises en échec par l'authentification pseudo-multifacteur. Au lieu d'utiliser juste un faux écran d'ouverture de session, l'attaquant peut utiliser un objet Flash pour capturer le mot de passe ainsi que la cadence de frappe.
Certes, l'authentification pseudo-multifacteur peut être utile dans certains scénarios où la technique de l'attaquant lui permettra seulement de connaître le mot de passe de l'utilisateur. Par exemple, la façon la plus simple d'obtenir le mot de passe d'un utilisateur consiste à le lui demander. Malheureusement, ceci s'est révélé être une technique efficace, que ce soit en demandant aux gens directement, par téléphone ou par des messages de phishing.
Bien sûr, demander à un utilisateur sa cadence de frappe sera extrêmement moins efficace. De même, si une base de données de mots de passe d'une entreprise est compromise, l'attaquant n'aura probablement accès qu'aux mots de passe. Mais une fois encore, ces attaques ne seront atténuées que si le système ne fournit pas l'authentification standard par mot de passe uniquement.
Je dois également attirer votre attention sur le fait que si la base de données de mots de passe même est compromise, cela signifie que l'attaquant a probablement compromis le système beaucoup plus profondément encore qu'il ne le serait possible avec un seul mot de passe de compte utilisateur normal, ou même plusieurs. Par conséquent, il est relativement vain de tenter d'atténuer ce qu'un attaquant en possession d'une base de données de mots de passe peut faire.

Quelques points positifs
Pour être juste, je dois admettre que l'authentification pseudo-multifacteur peut aider à résoudre certains problèmes (à supposer que le système ne fournit pas l'option d'ouverture de session standard par mot de passe uniquement). Par exemple, elle peut être utilisée pour empêcher le partage de mot de passe. Cependant, ceci peut être un inconvénient pour les systèmes où il est légitime que plusieurs utilisateurs partagent des comptes, par exemple des comptes en banque communs.
En outre, une boîte de dialogue de connexion interactive correctement construite (pas une connexion à un site Web) pourrait forcer un utilisateur à franchir des étapes d'authentification supplémentaires si sa cadence de frappe ne correspondait pas. Ceci peut fournir une sécurité supplémentaire contre un compte compromis dans un environnement extrêmement sensible.

Tromper les utilisateurs avec un mirage de sécurité
L'une des meilleures façons de semer la confusion dans l'esprit des utilisateurs consiste à fournir des indications de sécurité inexactes. La plus courante est probablement l'image de cadenas affichée sur une page Web, comme illustré à la figure 1. Cette page va même jusqu'à afficher le mot « Secure » près du cadenas.
Figure 1 Exemple d'abus de l'icône de cadenas, une tendance préoccupante (Cliquez sur l'image pour l'agrandir)
Comme vous le savez sûrement, la simple présence d'une image de cadenas et du mot « Secure » sur une page n'en fait pas une page sécurisée. Pourtant, et c'est d'ailleurs très inquiétant, la pratique est courante, même parmi les sites Web de très bonne réputation, qui sont les plus ciblés. Par conséquent, de nombreux utilisateurs sont conditionnés à rechercher ces indicateurs visuels de sécurité dans le corps de la page Web au lieu de regarder là où ces indicateurs ont effectivement un sens : dans la barre d'adresse. (Le Wiki de contexte de sécurité Web W3C contient une entrée sur ce problème et est disponible à l'adresse w3.org/2006/WSC/wiki/PadlockIconMisuse.)
Il est malheureux qu'il y ait toujours autant d'exemples de cet usage inapproprié. La recherche a montré que les utilisateurs sont incapables d'identifier les sites Web malveillants même lorsque les certificats sont très évidents (voir www.usablesecurity.org/papers/jackson.pdf). Tout dépend de la capacité de distinguer facilement le faux du vrai, même lorsque vous ne disposez pas du vrai pour comparer. Ceci demande des connaissances ; le mirage de sécurité qui plane sur les pages Web freine le développement de cette compétence car les utilisateurs sont conduits vers la mauvaise information.
Une variante particulièrement dérangeante de ce problème est illustrée à la figure 2. Ici, la page qui affiche les informations n'est en fait pas sécurisée. Si vous regardez la barre d'adresses, vous voyez la mention « http » indiquant le protocole. Ce site utilise une technique d'optimisation très commune : au lieu de chiffrer la page contenant le formulaire d'ouverture de session, seul l'envoi du formulaire est chiffré. La connexion est sécurisée, comme la page le dit, si vous supposez que « sécurisé » est synonyme de « chiffré ». Cependant (et ceci est extrêmement important), l'utilisateur n'a aucun moyen de vérifier où les informations d'identification sont envoyées avant qu'elles le soient ! Le site n'affiche pas de certificat authentifiant le site à l'utilisateur avant que le formulaire ne soit envoyé. Il s'agit d'un jeu de confiance, comme se laisser tomber en arrière en pensant que la personne derrière vous vous rattrapera. Au moment où le formulaire est envoyé, les dommages sont peut-être déjà faits.
Figure 2 Mirage de sécurité sur une page non sécurisée (Cliquez sur l'image pour l'agrandir)
Le protocole SSL (Secure Sockets Layer), qui fournit la sécurité dans HTTPS, sert deux objectifs importants. D'abord, il authentifie le serveur à l'utilisateur. Ensuite, il fournit un mécanisme simple pour négocier une clé de chiffrement de session pouvant être utilisée entre le client et le serveur.
Lorsque seul l'envoi du formulaire est chiffré, le premier objectif, et le plus important, n'est pas atteint. Les sites employant cette optimisation utilisent SSL uniquement comme un moyen de négocier les clés. Ironiquement, ils pourraient le faire simplement en employant un protocole de négociation de clés standard, évitant ainsi le coût et le traitement du protocole SSL.
Le site illustré à la figure 2 n'est pas seul en son genre. De nombreux sites fournissent la protection SSL uniquement pour l'envoi d'un formulaire, pas pour le formulaire lui-même. Ce site particulier, cependant, présente une caractéristique encore plus troublante. Si vous tapez https://www.<site>.com (notez l'indicateur https sécurisé) dans la barre d'adresse du navigateur, le site vous redirigera vers sa version non-SSL ! Même si vous essayez d'inspecter un certificat avant d'envoyer vos informations d'identification au site, le site refuse de vous afficher le certificat.
Tous les sites ne sont pas aussi mal conçus, mais de nombreux sites le sont. Et deux des plus grandes sociétés émettrices de cartes de crédit aux États-Unis comptent parmi les coupables. En fait, parmi les trois grandes sociétés émettrices de cartes de crédit que j'utilise, seul American Express fournit un certificat sur le formulaire d'ouverture de session. American Express redirige même les requêtes HTTP vers HTTPS. Bien joué !
Une dernière réflexion concernant le mirage de sécurité et l'absence de certificats sur le formulaire d'ouverture de session. Vous pouvez vous demander pourquoi un site ferait cela. Simplement par souci d'économie. La présentation de certificats nécessite le chiffrement de la page, et le chiffrement de la page génère une charge de traitement. Cette charge de traitement signifie qu'un plus grand nombre d'ordinateurs sont nécessaires pour assurer la même charge de travail. Et plus d'ordinateurs coûtent plus d'argent. Malheureusement, lorsqu'il s'agit de choisir entre protéger les informations personnelles des clients et augmenter les profits, beaucoup d'organisations optent pour la hausse des profits.

Ouvrir ou ne pas ouvrir
Récemment, j'ai reçu un étonnant message électronique de ma société d'assurance maladie. Quiconque a utilisé un ordinateur au cours des 10 dernières années sait qu'il ne doit jamais ouvrir de pièces les jointes d'un message non sollicité. Imaginez donc ma surprise lorsque j'ai reçu le message illustré à la figure 3.
Figure 3 Message électronique contenant une « pièce jointe sécurisée » (Cliquez sur l'image pour l'agrandir)
Apparemment j'avais posé une question sur le site Web de la société d'assurance maladie (ce que j'avais eu le temps d'oublier lorsque le message suspect est arrivé). Voici comment la société d'assurance répondait. Au début, j'ai pensé que c'était une manœuvre de phishing astucieuse. Quand je me suis rendu compte c'était un message légitime, les poils ont commencé à se dresser sur ma nuque.
La toute première instruction est de double-cliquer sur la pièce jointe pour commencer à décrypter le message. La communauté des spécialistes de la sécurité et les administrateurs informatiques au sens large ont passé les 10 dernières années à essayer d'apprendre aux gens à ne PAS double-cliquer sur les pièces jointes. Sur ce, une entreprise arrive (permettez-moi de préciser que mon prestataire de soins de santé n'est pas la seule organisation utilisant cette approche) et dit que je dois cliquer sur la pièce jointe pour ma sécurité. Comment l'utilisateur doit-il agir dans cette situation ? Quel comportement apprend-il ou désapprend-il ?
Ensuite, j'ai utilisé la fonctionnalité d'aperçu de Microsoft® Office Outlook® 2007 pour l'afficher. Comme vous pouvez le voir dans la Figure 4, Outlook a supposé que ce message pouvait être une attaque et m'a conseillé de ne pas l'ouvrir !
Figure 4 Outlook 2007 considère le document sécurisé comme hostile (Cliquez sur l'image pour l'agrandir)
Il est à la fois ironique et triste qu'une société d'assurance maladie viole les vérifications de sécurité les plus élémentaires utilisées dans le client de messagerie le plus populaire au monde. Dans la mesure où cette entreprise n'a même pas pris la peine de tester sa nouvelle solution de sécurité avec Outlook, je dois me demander ce qu'elle fait d'autre dans le but de protéger mes informations personnelles. Ou, pour être plus direct, quelles autres solutions sont implémentées par l'entreprise dans le seul but d'éviter d'être accusée de ne pas protéger suffisamment les informations confidentielles de ses clients ? Cela ressemble à la comédie sécuritaire jouée par les institutions financières. Dans ce cas, je pense que l'objectif principal de la solution est d'éviter les accusations, pas de protéger les clients.
J'ai voulu voir ce que la pièce jointe était vraiment. Elle s'est avérée être un objet de contrôle ActiveX®. Pour voir la pièce jointe, j'ai dû l'ouvrir dans Internet Explorer® et installer l'objet. J'ai alors vu s'afficher l'écran rassurant illustré à la figure 5. Comme vous pouvez le voir, les concepteurs ont fait beaucoup d'efforts pour donner au message l'aspect d'une enveloppe postale conventionnelle ; elle porte même un tampon stipulant que l'enveloppe est fiable.
Figure 5 Le document Secure affiche une enveloppe estampillée « Trusted » (Fiable) (Cliquez sur l'image pour l'agrandir)
Ce type de technologie est préoccupant pour de nombreuses raisons. Premièrement, il renforce un très mauvais comportement de la part de l'utilisateur : l'ouverture de pièces jointes non sollicitées. Deuxièmement, dans le message lui-même, il donne de très mauvais conseils en recommandant de configurer le système pour toujours ouvrir des pièces jointes sans invite. Troisièmement, vu les messages contradictoires de l'ordinateur, où le message électronique dit qu'il est fiable et Outlook dit qu'il ne l'est pas, le message paraît très suspect. Enfin, la vraie pièce jointe contient un mirage de sécurité sans importance pour convaincre l'utilisateur qu'elle est effectivement fiable. Si l'utilisateur apprend à faire confiance à ces types de messages, il n'y a plus qu'un petit pas à franchir avant l'approbation de messages malveillants d'un aspect similaire.

Fournir des communications sécurisées
Certes, le problème que cette technologie prétend combattre est très important. Communiquer avec les clients de façon fiable est difficile. Cependant, cette solution particulière est trop sophistiquée. Elle sèmera probablement la confusion chez le client et mènera potentiellement au résultat opposé à ce qu'elle visait : la compromission du système du client.
Les sites Web les mieux conçus utilisent maintenant un « centre de messages ». Dans cette conception, lorsque l'entreprise a besoin de communiquer avec le client, il envoie un message électronique disant quelque chose comme : « Vous avez un message dans le centre de messages. Veuillez vous rende sur notre site Web, ouvrir une session et cliquer sur le lien Centre de messages pour afficher le message ». Une entreprise reçoit des points de bonus si elle utilise S/MIME (Secure Multipurpose Internet Mail Extensions) pour signer tous les messages électroniques présentés aux clients, de sorte que l'utilisateur puisse authentifier la source. Il y a un autre bonus si le texte n'inclut pas d'éléments « Cliquez sur ce lien » dans le message électronique. L'utilisateur doit taper l'URL de l'entreprise manuellement pour garantir qu'il accède au site prévu.
Avec un centre de messages et un message signé, une entreprise peut emprunter un chemin fiable pour communiquer avec le client. Tout ce que le client voit pendant le flux de travail de message est authentifié, et l'entreprise ne favorise pas de mauvaises pratiques en termes de sécurité.

Question de confidentialité
J'ai passé les deux premières parties de cette série à décrire comment les professionnels de la sécurité rendent en fait un mauvais service aux utilisateurs. C'est notre travail de maintenir la sécurité. Mais beaucoup des décisions prises et des solutions implémentées créent une confusion chez les utilisateurs, en leur apprenant à faire de mauvais choix et en leur donnant un sens de la sécurité erroné. Nous ne devons pas submerger les utilisateurs par ces idées contradictoires.
Comme je l'ai dit auparavant, pour la majorité des utilisateurs, la sécurité consiste simplement à protéger les mots de passe et les numéros de carte de crédit. Ils veulent que la technologie fonctionne et soit digne de confiance. Malheureusement, ils doivent prendre des décisions, et il est de notre devoir d'assurer qu'ils le fassent en toute connaissance de cause.
Dans la dernière partie de cette série, j'expliquerai comment certaines des technologies les plus importantes accessibles au grand public ne remplissent pas toutes les attentes. Je présenterai également mon appel aux armes. N'oubliez donc pas de lire également l'édition de septembre 2008 de Vigilance sécurité.

Jesper M. Johansson est architecte de logiciels, chargé des problèmes de sécurité logicielle et contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en gestion des systèmes d'information, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.


Informatique durable Filtrage du greenwashing
Dave Ohara

Sommaire
L'utilité des chiffres
Mesure de la consommation d'énergie
Facteur de puissance
Mesure en production
Microsoft Enterprise Engineering Center
Conclusion
Il existe un nombre impressionnant de produits et de solutions commercialisés comme étant écologiques, sources d'économie d'énergie, plus efficaces, etc. Ce tapage publicitaire crée la confusion, et il est difficile de savoir exactement quels sont les produits réellement écologiques disponibles sur le marché. Même après avoir évalué les spécifications de divers produits, il est difficile, voire impossible, pour un professionnel de l'informatique
de déterminer quel équipement devrait être utilisé lorsque l'impact sur l'environnement est une préoccupation majeure. Lors des démonstrations qui vous sont proposées, de grosses économies d'énergie sont toujours mises en évidence, ce qui vous pousse à conclure que le retour sur investissement (ROI) justifie plus facilement la mise à niveau. Après tout, les économies d'énergie devraient réduire le coût total de possession.
La tendance des entreprises de tout genre à déclarer leurs produits « écologiques » et à exploiter l'intérêt actuel suscité par les solutions dites vertes a conduit au concept de « greenwashing », qui fait référence à la promesse d'avantages écologiques exagérés. Quelle est donc la vérité sur les économies d'énergie ? Les économies ne sont pas aussi claires que, par exemple, si vous installez des ampoules à économie d'énergie chez vous.
À mesure que l'intérêt suscité par les efforts de l'informatique durable augmente et que le marché des produits informatiques écologiques se développe, beaucoup de personnes et d'organisations brûlent toutes les étapes pour déployer des ordinateurs de bureau, des ordinateurs portables et des serveurs à hautes performances énergétiques et utilisent la virtualisation pour réduire la consommation d'énergie. Pourtant, peu d'organisations organisent des audits d'énergie pour déterminer les véritables avantages des produits qu'elles ont achetés.
L'idéal serait de mesurer activement ces avantages dans votre environnement de production, mais un tel scénario peut également coûter cher. Si vous n'êtes pas prêt à effectuer des dans l'environnement de production, vous pouvez toujours commencer par organiser votre audit d'énergie au début du processus, dans vos laboratoires de performances et d'évaluation. (La plupart des entreprises possèdent un laboratoire ou un groupe chargé de tester et d'évaluer l'équipement avant de l'acheter). Durant l'audit, vous pouvez ajouter les performances énergétiques parmi vos critères de test et tenir compte des résultats lorsque vous prenez vos décisions d'achat, au lieu de faire confiance aux statistiques fournies par les fabricants. Ainsi, tout en testant, vous créez votre propre base de données sur la consommation d'énergie des appareils. Vous pouvez alors ignorer le greenwashing et déterminer vous-même ce qui fonctionne.
Bien sûr, je dois préciser que si vous voulez des chiffres extrêmement précis sur l'exploitation à votre charge réelle, vous devrez organiser un suivi dans votre environnement de production. Plus tôt vous commencerez à surveiller votre environnement de production, mieux votre entreprise et son chiffre d'affaires se porteront. Ce processus sera essentiel à votre succès à long terme.

L'utilité des chiffres
Dans une situation idéale, des tests indépendants évalueraient les performances par watt des périphériques matériels sous des charges utilisateur réalistes. Toutefois, le secteur informatique n'en est qu'à ses premiers pas dans le domaine du développement et du déploiement de tels tests. Ceux qui sont actuellement disponibles, tels que les tests d'évaluation de performances SPEC, n'en sont qu'à leurs balbutiements. Nous ne savons pas exactement si ces tests d'énergie seront efficaces une fois qu'ils seront prêts, mais, comme avec n'importe quel test, les fabricants apprendront à modifier leurs équipements pour obtenir des résultats de test optimaux.
Les professionnels de l'informatique expérimentés ont appris à remettre en question les tests de laboratoires. Et tout comme les fabricants automobiles envoient leurs meilleures voitures pour les essais routiers, les fournisseurs informatiques veilleront à envoyer leurs meilleurs équipements pour les tests de consommation énergétique.
Imaginez des tests de virtualisation utilisés pour comparer un groupe de serveurs sur-configurés qui n'ont fait l'objet d'aucune consolidation pour démontrer les avantages de la virtualisation. Les fournisseurs omettent de mentionner des problèmes tels que les phénomènes de rebond potentiels des projets d'économies d'énergie comme la virtualisation. Il s'agit essentiellement de situations où l'efficacité énergétique réduit les coûts, ce qui entraîne une augmentation de la demande et donc une augmentation de l'utilisation et de la consommation d'énergie. Lorsque vous voyez une solution telle que la virtualisation commercialisée comme la réponse aux problèmes d'économie d'énergie, vous devriez vous méfier. Vous devriez attendre de voir comment tous les éléments coopèrent et la nature des effets secondaires avec le temps.
Mais alors, comment découvrir la bonne voie pour votre organisation ? Les consultants qui sont prêts à effectuer des évaluations contre rétribution ne manquent pas. Toutefois, cette approche présente des inconvénients majeurs. Voulez-vous vraiment transmettre l'expertise de l'efficacité à quelqu'un qui ne fait pas partie de votre organisation ? Souhaitez-vous vraiment dépendre d'un consultant dont l'objectif est de maintenir un contrat à long terme avec vous et de créer une dépendance à ses services ?
Vous pourriez faire de ces évaluations un énorme projet et faire participer des dizaines de personnes afin de déterminer votre stratégie de durabilité environnementale. Évitez la tentation de choisir un point au hasard dans votre environnement et de commencer à mesurer. Bien qu'elle parte d'une bonne intention, cette approche n'a aucun sens car il s'agit d'une action aléatoire. Vous devez établir la vérité sur votre consommation d'énergie et sur la façon dont vous pouvez faire des économies.

Mesure de la consommation d'énergie
Vous devez trouver une nouvelle façon d'envisager ce qui fonctionne. Les professionnels de l'informatique savent qu'un périphérique ne fonctionne pas, par exemple, lorsqu'un service tombe en panne. Mais qu'en est-il d'un équipement qui ne fonctionne pas correctement sur le plan de la consommation d'énergie ? Ce type de défaillance passe généralement inaperçu car la plupart des organisations ne disposent pas de données concernant leur efficacité énergétique de référence.
Comment obtenir ces chiffres ? Certaines personnes suggèrent la nécessité de nommer un tsar de l'énergie. Cette approche nécessite toutefois une personne possédant des connaissances techniques avancées en matière de consommation d'énergie, qui soit capable de comprendre et de naviguer dans l'organisation de l'entreprise. Une méthode plus simple consiste à ajouter des outils de mesure de l'énergie aux fonctions existantes dans les laboratoires de performances.
Il existe toute une gamme d'appareils servant à mesurer l'énergie. Malheureusement, il n'existe pas encore d'appareil parfait pour un laboratoire de performances informatique. Au bas de la gamme, vous pouvez essayer un Watts Up Pro. Il s'agit d'un périphérique USB qui mesure l'énergie en ligne pour 120V. Vous pouvez également utiliser Smart-Watt, un périphérique de consommation réseau avec une plage de tension de 100 à 240V et d'intensité de 15 à 30 ampères. Les périphériques Smart-Watt sont également disponibles avec des capteurs de température et d'humidité pour mesurer les facteurs environnementaux. Il y a également les appareils d'analyse électrique industriels, tels que le testeur Extech 380801 et les pinces ampèremétriques Fluke 345. Vous ne devriez avoir aucun problème à trouver de tels appareils pour répondre aux besoins de vos tests de laboratoire.

Facteur de puissance
Si vous êtes novice dans le domaine de la mesure électrique, il est important que vous compreniez le concept de facteur de puissance. Le facteur de puissance d'un système électrique à courant alternatif est défini comme le rapport puissance réelle/puissance apparente, et s'exprime en chiffres allant de 0 et 1. La puissance réelle (watts) est la capacité du circuit à exécuter le travail. La puissance apparente (VA) est le produit du courant et de la tension sur le circuit.
Vous vous demandez probablement en quoi ceci est important. Jetez un coup d’œil à la figure 1. La photo montre un appareil de contrôle de la consommation d'énergie de Smart Works utilisé pour comparer l'efficacité énergétique d'un portable, d'une ampoule et d'un condensateur. Une ampoule a une charge de 50 watts et 50 VA, pour un facteur de puissance de 1. Un condensateur avec une charge capacitive pure crée une charge de 2 watts et 193 VA, pour un facteur de puissance de 0,01. Le portable utilise 22 watts de puissance mais affiche 48 VA, pour un facteur de puissance de 0,47. Le faible facteur de puissance du portable est dû à une mauvaise conception de l'alimentation, qui a probablement fait les frais d'une politique de réduction des coûts industriels.
Figure 1 Consommation d'énergie d'un portable, d'une ampoule et d'un condensateur (Cliquez sur l'image pour l'agrandir)
Vu l'intérêt actuel pour l'efficacité énergétique, les fournisseurs cherchent désormais à améliorer les performances de l'alimentation dans des conditions attendues. Si vous comparez le facteur de puissance d'un équipement existant à celui d'un nouvel équipement, vous remarquerez probablement qu'il est possible de récupérer une certaine capacité énergétique simplement en choisissant des solutions dotées de sources d'alimentation plus efficaces et de facteurs de puissance plus élevés.

Mesure en production
L'objectif de la mesure des résultats dans le laboratoire de performances est de prédire les performances dans l'environnement de production. Le problème de la mesure de la consommation énergétique en production réside dans le coût requis pour mesurer tous les périphériques. Toutefois, l'une des stratégies de réduction du coût lié à la mesure de la consommation énergétique en production consiste à mesurer au niveau de l'unité de distribution d'alimentation (PDU) et d'établir la moyenne des chiffres de plusieurs d'équipements. La figure 2 montre un exemple de relevé de consommation énergétique pris depuis une PDU avec plusieurs éléments d'un même équipement sur une unité. Étant donné que la consommation moyenne par serveur peut être calculée, ces évaluations vous fournissent des chiffres liés à la consommation d'énergie de production.
Figure 2 Mesure à l'unité de distribution d'alimentation (Cliquez sur l'image pour l'agrandir)
À chaque mesure d'un élément d'équipement, les informations sur la consommation électrique doivent être intégrées à votre base de données de gestion de la configuration. Si cette opération est trop difficile, vous pouvez créer votre propre base de données ou au moins une feuille de calcul Excel® qui répertorie les périphériques et leur consommation électrique. À mesure que vous accumulez des périphériques, vous pouvez noter les chiffres que d'autres utiliseront pour établir une évaluation globale de la capacité énergétique. N'oubliez pas qu'un nouveau serveur à faible consommation d'énergie utilisera plus de la moitié de sa charge lorsqu'il est inactif par rapport à sa période d'utilisation maximale. En outre, si vous avez de vieux serveurs exécutant des solutions obsolètes, ils utiliseront de grandes quantités d'énergie même lorsqu'ils sont inactifs. Ils constituent l'une des cibles les plus faciles pour la récupération de capacité énergétique.
Si vous voulez poursuivre vos efforts d'amélioration, la prochaine étape consistera à calculer l'énergie par rack utilisée dans votre centre de données. Vous devez aussi bien connaître vos capacités énergétique et de refroidissement lorsque que vous modifiez l'environnement. Au fil du temps, vous commencerez à considérer vos équipements en termes de besoins énergétiques et non uniquement en termes de l'espace qu'ils nécessitent. L'espace est un concept simple : il est statique et visuel. Les professionnels de l'informatique sont toujours prêts à discuter des serveurs 1U, 2U et 4U, mais si vous commencez à parler de serveurs de 200 watts par rapport aux serveurs de 450 watts, vous constaterez que ces mêmes informaticiens se sentent moins à l'aise dans la conversation. Il s'agit là d'un nouveau langage pour l'équipement informatique, une chose évidente dans les centres de données d'aujourd'hui. Beaucoup d'entre eux ont suffisamment d'espace pour des équipements supplémentaires bien qu'ils aient atteint leurs capacités énergétiques maximales.

Microsoft Enterprise Engineering Center
Le Microsoft Enterprise Engineering Center (EEC) a récemment ajouté des fonctionnalités de mesure de la consommation électrique à son installation. Situé sur le campus de l'entreprise Microsoft à Redmond, Washington, l'EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) est un terrain d'essai ultra moderne pour les environnements informatiques les plus complexes.
Doté de plus de 40 millions de dollars d'équipements matériels et de réseau (voir la figure 3), l'EEC peut traiter les recréations les plus complexes des vrais environnements de production d'entreprise. Le groupe s'est associé avec d'importants fournisseurs de solutions de mise en réseau, de stockage et de client/serveur pour offrir une variété de technologies d'avant-garde et de plates-formes héritées. L'objectif est de garantir que chaque test renvoie une image précise de l'environnement actuel du client. Le dernier service développé à l'EEC consiste à établir un rapport sur la consommation énergétique des solutions afin de fournir un test d'évaluation des performances par watt.
Figure 3 L'une des nombreuses rangées du laboratoire de l'EEC (Cliquez sur l'image pour l'agrandir)
Au cours des dernières années, l'EEC a vu de nombreux opérateurs de centres de données se retrouver à court d'énergie et de refroidissement pour leurs équipements. Les équipements de pointe s'accompagnent souvent d'une densité d'énergie élevée qui exerce plus de contraintes sur les installations. Le personnel de l'EEC n'a pas tardé à connaître les coûts et le temps nécessaires pour mettre à niveau l'infrastructure d'alimentation et de refroidissement. Pour fonctionner d'une manière plus efficace et être plus rentable, l'EEC a donc ajouté la possibilité de mesurer la consommation électrique par périphérique.
Certains des outils et des équipements utilisés par l'EEC n'étaient pas encore commercialisés au moment de la rédaction de cet article. Étant donné qu'il s'agit d'une nouvelle solution, l'EEC continuera de développer de meilleures techniques en collaborant avec les clients, les fournisseurs et les équipes de développement de Microsoft. L'EEC partage les méthodes qu'il a développées directement avec les clients afin d'obtenir leurs premières impressions, ce qui permet à ces derniers de créer leurs propres tests d'évaluation.
Et n'allez pas en déduire que les résultats seront évidents. L'EEC a partagé certains des résultats intéressants que le groupe a constatés lors de l'utilisation des fonctionnalités de contrôle de la consommation électrique dans ses laboratoires de performances :
  1. 1. La mise hors tension d'un périphérique ne réduit pas nécessairement autant la consommation d'énergie qu'on pourrait s'y attendre (voir la figure 4). Dans un cas concernant un serveur matériel, l'EEC a découvert un périphérique qui consommait 100 watts lorsqu'il était hors tension mais toujours branché. Ceci a étonné de nombreuses personnes, et l'EEC a examiné l'installation plusieurs fois. Le centre a finalement utilisé un thermomètre infrarouge pour mesurer la température d'arrivée et de sortie et a constaté que le périphérique consommait effectivement 100 watts lorsqu'il était hors tension.
  2. Les logiciels peuvent avoir un impact considérable sur la consommation électrique. Sur des commutateurs réseau identiques, avec des configurations matérielles et BIOS identiques, l'exécution de divers logiciels de mise en réseau a montré des différences de consommation électrique de 21 %. Les solutions haut de gamme ayant davantage de processus et fonctionnalités activés tels que les outils de sécurité et de surveillance utilisent souvent plus d'énergie que leurs homologues de bas de gamme.
  3. Dans les scénarios de virtualisation, l'EEC a mesuré la consommation par rapport à l'utilisation d'E/S et l'utilisation du processeur pour déterminer les moments où un équipement donné optimisait ses performances par watt. L'EEC a trouvé qu'une concentration étroite sur l'utilisation du processeur pouvait mener à une situation où trop de machines virtuelles étaient chargées sur une machine physique, ce qui se traduit par une baisse des performances par watt globales.
  4. Les périphériques à haute densité, comme on s'y attendait, sont plus exposés aux problèmes d'alimentation et refroidissement. Lorsque vous déployez des systèmes à haute densité, vous devez consulter le personnel responsable de l'alimentation et du refroidissement des équipements dès que possible. Ces périphériques peuvent être de bons candidats pour être dotés de leurs propres appareils de contrôle de la consommation électrique en production si vous savez que l'environnement sera soumis à des contraintes au niveau de l'alimentation.
  5. Les sources d'alimentation doubles peuvent consommer beaucoup plus d'énergie que les sources simples.
  6. Des équipements d'apparence identique et dotés de configurations identiques peuvent avoir des taux de consommation électrique très différents. Les différences observées étaient suffisamment importantes pour obliger le personnel de l'EEC à vérifier à nouveau que les configurations étaient bien identiques.
  7. Les indications de consommation en watts figurant sur l'étiquette du produit ne reflètent pas les véritables chiffres de consommation ; ils représentent la puissance nominale des sources d'alimentation.
  8. Le maintien d'une base de données de tests de consommation énergétique et des résultats par périphérique et sous-composant est essentiel pour l'enregistrement des informations et la comparaison des données.
  9. Différentes configurations de quantités équivalentes de RAM utilisent différentes quantités d'énergie. En général, un nombre inférieur de barrettes DIMM consommera moins d'énergie, par exemple, 4 barrettes DIMM de 2 Go par rapport à 8 barrettes DIMM de 1 Go. Certains cas ont toutefois été constatés où un nombre inférieur de barrettes DIMM consommait davantage d'énergie.
Figure 4 Comparaison de la consommation électrique sous / hors tension (Cliquez sur l'image pour l'agrandir)

Conclusion
En ajoutant la capacité de mesurer la consommation électrique dans vos laboratoires de performances, vous pouvez commencer à accumuler votre propre base de données de consommation énergétique par périphérique avec des chiffres précis pour vos charges réelles. Lorsque vous déployez ces solutions, vous devez effectuer un audit des résultats sous forme de système de retour en boucle fermée pour déterminer l'exactitude de vos tests en laboratoire de performances. Comme l'a appris l'EEC en exécutant ses propres tests de mesure, certains détails réellement intéressants peuvent vous aider à filtrer le greenwashing et à découvrir la vérité.
Cette méthode de mesure en laboratoire de performances poussera le marché en général à commencer à identifier les produits qui permettent véritablement d'effectuer des économies d'énergie. Avec le temps, les fabricants constateront qu'il est nécessaire de fournir des données plus précises sur leurs allégations en matière d'économie d'énergie. De même, les professionnels de l'informatique commenceront à utiliser les watts par périphérique comme critère d'achat. Cela doit devenir une pratique courante, surtout pour les entreprises qui achètent de grandes quantités de serveurs. Vous pouvez montrer la voie aujourd'hui même en commençant à considérer l'énergie comme l'une de vos plus précieuses ressources informatiques.
Garder le centre de données au frais
Le refroidissement des centres de données présente un potentiel énorme en matière de réduction de la consommation énergétique. Il étonnant de voir la quantité de chaleur générée dans un centre de données et la quantité d'énergie utilisée pour refroidir le matériel. Mais si vous voulez bien gérer votre stratégie de refroidissement, résoudre les problèmes et développer des solutions de refroidissement plus efficaces, vous aurez besoin d'une solution de contrôle de la température. Considérons la solution utilisée par les centres de données Microsoft.
Microsoft Research a créé un réseau de capteurs de température pour les centres de données, qui permet d'améliorer le contrôle de la température et d'évaluer les améliorations apportées au refroidissement. Par exemple, un centre de données Microsoft évaluait l'efficacité du placement de rideaux d'air en fin d'allée pour améliorer la séparation de l'air chaud et de l'air froid. Une fois les rideaux installés, certains serveurs ont commencé à émettre des alertes de surchauffe. Naturellement, les techniciens ont alors augmenté le flux d'air du système de refroidissement pour refroidir l'air. À leur surprise, cependant, d'autres serveurs se sont mis à émettre des alertes de surchauffe, et tous ces serveurs étaient au bas du rack, généralement l'endroit le plus frais d'un système de refroidissement surélevé.
Grâce au réseau de capteurs, les techniciens ont pu confirmer que les racks étaient plus frais vers le haut et plus chauds en bas. Ils n'ont pas tardé à déduire que cet air chaud provenait de l'allée chaude située entre le bas du rack et le plancher, résultat du principe de Bernoulli. Ils ont pu régler facilement le problème de surchauffe en scellant le bas du rack et en réduisant la vitesse du flux d'air.
C'est justement ce genre de données que l'EEC recueille et analyse lorsqu'il effectue des tests de performances. Ainsi, l'EEC a récemment informé Microsoft Research qu'il était prêt à effectuer un test de déploiement. En une journée, le système a été déployé à 10 racks et l'installation a été faite en une heure. L'EEC peut maintenant étudier et mieux comprendre les problèmes de refroidissement et leur relation avec les performances du matériel.
Bien sûr, la surveillance à elle seule ne constitue pas une solution. Le vrai gain réside dans votre capacité à localiser les problèmes à résoudre, à effectuer les modifications nécessaires et à évaluer diverses solutions pour déterminer si elles offrent les résultats que vous espériez. L'important est d'éviter d'être pris au dépourvu lorsque votre nouvelle solution de refroidissement provoque soudainement une surchauffe dans vos racks.

Dave Ohara compte 26 années d'expérience en technologie. Il collabore maintenant avec plusieurs entreprises qui mettent en œuvre des initiatives écologiques.


Sur le terrain IMAP sauve le monde
R'ykandar Korra'ti

Il arrive parfois que les solutions à de petits nouveaux problèmes résolvent de gros problèmes déjà existants. En voici un exemple.
L'hiver dernier, notre administrateur Web a acheté un MacBook. Elle n'avait utilisé jusque là que Windows®, mais dispose maintenant de deux systèmes d'exploitation : OS X et Windows XP sur une machine virtuelle pour synchroniser ses périphériques Windows Mobile® et exécuter d'autres petites tâches.
Elle avait besoin d'accéder à toutes ses archives de messagerie sur les deux systèmes d'exploitation. Mais elle ne souhaitait pas exécuter Entourage sur le Mac. Elle préférait exécuter Mail.app, le client de messagerie électronique inclus dans le système d'exploitation OS X. Incidemment, elle a tout conservé dans le magasin local de son ordinateur portable sans mise en miroir. Mon rôle : faire fonctionner tout cela.
Les archives doivent êtres accessibles partout. Cela présentait le petit problème mentionné auparavant, car tout, y compris Exchange Server, Microsoft® Office Outlook® et Mail, utilise IMAP4. IMAP4 est un protocole de messagerie permettant de contrôler les magasins de messages sur serveur des clients légers. Ce protocole offre moins de fonctionnalités que les utilisateurs d'Exchange ne le souhaitent, mais il fonctionne (voir Comment ça marche : IMAP4 dans le numéro de mars/avril 2008 de TechNet Magazine sur le site technet.microsoft.com/magazine/cc161016).
Il suffit de modifier quelques paramètres pour définir IMAP4 par-dessus SSL en ligne, de copier tous ses dossiers locaux sur le serveur et d'utiliser la commande ping ! Elle peut accéder au courrier sur tous les clients et conserver à jour ses périphériques Windows Mobile. Le problème est résolu.
Mais il est difficile de proposer une solution simple à un problème potentiellement complexe. Vous avez tendance à compliquer la situation sans le vouloir et à ne plus vous y retrouver.
Notre petit fournisseur de services Internet exécute Windows, OS X, Mac OS, Linux et même un ancien système AmigaOS. Il y a longtemps, nous hébergions les forums Usenet et UUCP sur ce système Amiga. Il permettait de créer des archives stockées au format RFC-733/AmigaUUCP. Nous avons également des archives de messagerie Microsoft Mail (format .mmf), ainsi que d'autres formats d'archive UNIX anciens (format .mbox). Elles sont là tout simplement, et nous ne trouvons pas le temps de résoudre cette situation.
Ce scénario nous amène au second souci de notre article, la devise constante : Ne jamais effacer ce qui ne peut être remplacé.
Nous avons abordé les archives Microsoft Mail en premier. Outlook ne peut pas importer les fichiers .mmf depuis longtemps. Mais, avec la mise à niveau des clients au cours des années, nous avons conservé au moins une licence de chaque produit ancien, pour plus de sécurité. Par conséquent, notre liste de licences représente une chronologie de Microsoft Corporation. Vous avez besoin de MS-DOS® ? OS/2 1.31 ? Microsoft Mail ? Office 95 ? Pas de problème ! Vous voulez la version en anglais ou en français ?
Outlook 2000 était capable d'importer le format .mmf, mais la prise en charge d'IMAP n'était pas satisfaisante et supprimait parfois les données d'en-tête. Il ne pouvait pas non plus communiquer avec IMAP4 et les serveurs Exchange simultanément. Cela était ennuyeux, mais pas critique. Il fallait importer les fichiers .mmf via Outlook 2000, passer à la mise à niveau de notre licence Outlook 2003 conservée, et après quelques heures de glisser-déplacer, vous disposiez d'archives de 15 ans en ligne et visibles partout. De même pour les fichiers .mbox, lancez un serveur IMAP compatible mbox sur une machine Linux et placez les archives au format .mbox dans son répertoire de travail. Utilisez ensuite la prise en charge IMAP d'Outlook pour vous connecter et copier des dossiers vers le serveur de production de votre choix.
Les archives Amiga, d'autre part, exigeaient l'écriture d'un petit fichier de code C pour convertir les en-têtes RFC-733 au format RFC-822, abandonner les anciens séparateurs de message de style SysV et récupérer les données de la ligne De. C'est le prix à payer lorsque les problèmes ne sont pas résolus. Une fois le problème résolu, le format .mbox a remplacé le format AmigaUUCP. De plus, avec Outlook IMAP4 dans même répertoire de travail, le courrier est résolu et les pièces jointes sont empaquetées correctement.
Nous disposons maintenant d'archives remontant à 1990 en ligne dans un format unifié, et nous recherchons d'autres archives... simplement parce que nous le pouvons. Est-ce la bonne chose à faire ?

R'ykandar Korra'ti, administratrice d'un fournisseur d'accès Internet coopératif, habite près de Seattle avec Anna, son amie. Ancienne collaboratrice de Microsoft où elle contribuait à l'expédition des produits commandés en ligne, elle écrit des articles techniques lorsqu'elle ne compose pas de chansons. Les agents de réservation peuvent la joindre à l'adresse suivante : darako@murkworks.net.


La vie secrète de Windows Hommage au passé
Raymond Chen

Un de mes collègues a récupéré une machine Alpha AXP dans un placard poussiéreux. En démarrant le système, il a découvert qu'il exécutait une version 64 bits Windows® de début 2000. Comment est-ce possible ?
Il se trouve que j'avais l'une de ces machines dans mon bureau en ce temps-là. À son apogée, cette machine était une force de la nature. Elle était de la taille d'un petit réfrigérateur et faisait à peu près autant de bruit qu'un aspirateur. Il contenait quatre (rendez-vous compte, quatre !) processeurs Alpha AXP, chacun exécutant un étonnant 400 MHz. Il avait un gigaoctet de RAM et treize gigaoctets d'espace disque, répartis sur une douzaine de lecteurs Fast SCSI. Ceci peut sembler faible aujourd'hui, mais dans les années 90, ces machines Alpha AXP faisaient l'envie de tous et faisaient grimper votre cote de popularité à la cantine.
En 1999, lorsque Compaq a annoncé qu'il ne prendrait plus en charge Windows sur l'Alpha AXP, beaucoup de systèmes Alpha AXP ont été brusquement laissés sans tâches officielles. Certaines de ces machines, cependant, ont été utilisées pour des tâches non officielles. J'ai utilisé mon système Alpha AXP pour indexer tout le code source de Windows. Vous pouvez vous imaginer à quel point il peut être pratique pour un programmeur de pouvoir identifier tous les appelants d'une fonction en quelques secondes ou situer le code source d'une fonction ou d'une boîte de dialogue qui apparaît dans un suivi de débogage.
Mais même pour la simple tâche d'indexation du code source de Windows, l'Alpha AXP a vite été éclipsé par les machines de classe x86. Celles-ci étaient meilleur marché et plus rapides, elles offraient plus d'espace disque et plus de mémoire. Donc pour cette raison, mon ordinateur a bientôt rejoint ses frères oubliés. On a supposé que la fin de la prise en charge pour l'Alpha AXP avait signé la fin de ces machines, mais alors il leur a été donné une opportunité de sortir dans une aura de gloire, en rendant leur dernier souffle au service de la nouvelle génération.
Le projet Windows 64 bits était déjà bien avancé et des processeurs de 64 bits à l'étude, seul l'Alpha AXP était disponible sous forme physique. L'Intel Itanium était toujours en développement et ne fonctionnait qu'en simulateur et l'architecture AMD64 n'avait même pas encore été inventée. Par conséquent, Windows 64 bits a été développé à ses débuts sur l'Alpha AXP.
Lorsque Compaq a annoncé qu'ils ne prendraient plus en charge Windows sur l'Alpha AXP, tous ces ordinateurs Alpha AXP auparavant utilisés pour le développement et le test de Windows 2000 32 bits ont été réaffectés et ont commencé une vie secrète comme ordinateurs de test pour un système d'exploitation 64 bits qui n'apparaîtrait jamais sous cette forme. L'Alpha AXP était simplement une plate-forme de validation technique.
Les ordinateurs Alpha AXP ont bien tenu leur rôle, en offrant à l'équipe Windows 64 bits un vrai matériel de travail au lieu de devoir exécuter le système d'exploitation sur un simulateur Itanium. (Vous pouvez vous imaginer à quel point ça pouvait être lent.) Bien sûr, l'Alpha AXP n'était pas le matériel cible final, mais il était d'une grande aide. Et lorsque les UC Itanium physiques ont fait leur apparition, la niche qu'occupaient les Alpha AXP a disparu et ils ont de nouveau été mis à la retraite dans des placards poussiéreux.
Mes amis qui travaillent aux archives de Microsoft ont sorti mon vieux et fidèle Alpha AXP du fond de son placard pour cette photo, pour poser avec l'un des produits qui ont aidé à tout rendre possible : l'édition 64 bits de Microsoft Windows Server® 2003. Et oui en effet, c'est la poussière originale.

Le site Web de 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 préférerait ne pas être remisé dans un placard poussiéreux.