 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Administration de Windows

Ce mois-ci, Mark Russinovich pénètre dans le noyau de Windows Vista pour expliquer les nouveaux algorithmes de mesure de performance des threads et des processus afin que vous ayez une idée plus claire de la façon dont le temps de votre processeur est utilisé. Il aborde également le Service Planificateur de classes multimédias qui fournit aux utilisateurs une lecture plus homogène en gérant mieux les tâches en arrière-plan comme les anti-virus et les indexations de contenu.

Ce mois-ci, nous examinerons également les fonctionnalités de délégation dans les modèles d'Active Directory et de stratégie de groupe de Windows Vista, afin que vous puissiez optimiser la stratégie de groupe encore mieux qu'auparavant. Et, bien entendu, toutes nos rubriques habituelles sont présentes ce mois-ci, y compris The Cable Guy, The Scripting Guys et Windows Confidential.
FONCTIONNALITÉS
Administration de Windows Dans le noyau de Windows Vista : 1ère partie

Avec Windows Vista, les modifications du noyau du système d'exploitation apportent des améliorations dans beaucoup de domaines, qui vont de la gestion de la mémoire jusqu'à la fiabilité et la sécurité. Nous démarrons cette série avec une étude sur la façon dont le noyau améliore les processus, les threads et les E/S.

Mark Russinovich Délégation d'autorisation dans Active Directory

Implémenter une délégation dans Active Directory peut améliorer la sécurité et simplifier les tâches de gestion. S'y mettre est plus facile que vous le croyez. Voici quelques modèles simples de délégation qui fonctionneront dans la plupart des infrastructures informatiques avec très peu de modifications.

Joel Yoker et Rob Campbell Plongée dans les nouveaux modèles de stratégie de groupe de Windows Vista

Windows Vista apporte des modifications importantes aux modèles de stratégie de groupe. Découvrez tout ce que vous voulez savoir sur le nouveau format, dénommé ADMX et comment ces évolutions vont améliorer l'administration des configurations de systèmes.

Darren Mar-Elia Votre guide de dépannage de la stratégie de groupe

Aller au fond des problèmes de stratégie de groupe peut être un processus difficile, mais si vous comprenez comment la stratégie de groupe fonctionne et où les problèmes peuvent se présenter, les choses deviennent plus faciles. Cet aperçu général vous permettra de résoudre les problèmes de stratégie de groupe tel un vrai sorcier.

Derek Melber Surveillance d'Active Directory avec MOM

Les packs d'administration de Microsoft Operations Manager 2005 vous permettent de surveiller plus efficacement votre infrastructure informatique. Découvrez comment ces cinq packs d'administration peuvent vous aider à surveiller la santé, la sécurité et la fiabilité de votre environnement Active Directory.

John Hann Le jeu dans un environnement sécurisé

Si vous êtes occupé au travail ou absorbé par un jeu à la maison, l'exécution avec un compte aux droits limités comporte de nombreux avantages en termes de sécurité. Malheureusement, certains jeux ne fonctionnent pas lorsque ils ne sont pas exécutés à partir d'un compte administrateur. Examinons quelques problèmes courants et leurs solutions.

Matt Clapham
COLONNES
Le mot du rédacteur en chef

En coulisses

Joshua Trupin Toolbox

Nouveaux produits pour les professionnels de l'informatique

Greg Steen Forum aux questions sur SQL

Taille de la base de données, mise en miroir, transactions marquées et plus encore

Par Nancy Michell Coup de projecteur sur les utilitaires

Group Policy Inventory

Greg Steen Le petit câbleur

Prise en charge de la qualité de service (QoS) dans Windows

Joseph Davies 		Windows PowerShell

Écriture de scripts une ligne à la fois

Don Jones Hé, vous le Scripteur !

La chasse aux voitures... et le XML

Les scripteurs Microsoft Vigilance sécurité

Déploiement d'EFS : 1ère partie

John Morello Histoires de Bureau

Extension de Windows PE

Wes Miller Sur le terrain

Déconnexion sauvage

R'ykandar Korra'ti La vie secrète de Windows

Un bienfait « discutable »

Raymond Chen


 Administration de Windows: Dans le noyau de Windows&#160;Vista&#160;: Partie&#160;1
Administration de Windows Mark Russinovich

Dans le noyau de Windows Vista : Partie 1
Vue d'ensemble:
  • Priorité et planification des threads
  • Liens symboliques basés sur des fichiers
  • Annulation d'opérations E/S

Ce document est le premier d'une série s'intéressant aux nouveautés du noyau de Windows Vista. Dans ce numéro, j'aborderai les modifications des zones de processus, des threads et des E/S. Les articles futurs couvriront la gestion de mémoire, le démarrage et l'arrêt, la fiabilité et la récupération ainsi que la sécurité.
La portée de cet article s'étend uniquement aux modifications apportées au noyau de Windows Vista™, et plus particulièrement à Ntoskrnl.exe et aux composants qui lui sont étroitement associés. N'oubliez pas que beaucoup d'autres modifications significatives apportées à Windows Vista ne concernent pas le noyau lui-même et ne seront donc pas abordées. Ceci concerne les améliorations apportées à l'interpréteur de commandes (comme l'intégration de desktop search), la mise en réseau (comme la nouvelle pile IPv6 et le pare-feu bidirectionnel) et les modèles de graphiques de prochaine génération (tels qu'Aero™ Glass, Windows® Presentation Foundation, le Gestionnaire de fenêtres du Bureau et le nouveau modèle de pilote d'affichage graphique). Les nouvelles infrastructures de pilote en mode utilisateur et en mode noyau de Windows (UMDF et KMDF) ne sont pas non plus couvertes puisqu'elles sont rétro-installables sur les versions précédentes de Windows.

Comptage des cycles microprocesseur
Windows Vista intègre plusieurs améliorations des processus et des threads parmi lesquelles l'utilisation du compteur de cycles microprocesseur pour une meilleure allocation processeur et le nouveau Service Planificateur de classes multimédias (MMCSS) qui aide les applications multimédias à offrir une lecture dépourvue de problème.
Toutes les versions de Windows NT® jusqu'à, et y compris, Windows Vista programment une routine d'interruption du temporisateur d'intervalles qui s'exécute environ toutes les 10 à 15 ms (millisecondes), selon la plate-forme matérielle. La routine examine le thread qu'elle a interrompu et met à jour les statistiques d'utilisation du processeur du thread comme si ce thread s'était exécuté pendant tout l'intervalle alors qu'il se pourrait en fait que le thread ait commencé à s'exécuter juste avant la fin de l'intervalle. De plus, il se pourrait que le processeur ait été techniquement attribué au thread mais que celui-ci n'ait pas eu l'occasion de s'exécuter parce que les routines d'interruption logicielle et matérielle se sont exécutées à la place.
Alors que la gestion du temps basée sur horloge convient à des outils de diagnostic qui signalent l'utilisation du processeur de thread et de processus, l'utilisation de cette méthode par le planificateur de threads peut causer une allocation processeur injustifiée. Par défaut, sur les versions client de Windows, les threads sont autorisés à s'exécuter pendant deux tic-tac d'horloge au maximum (6 s'ils sont au premier plan). Cependant, le thread peut ne pratiquement pas obtenir de temps sur le processeur ou jusqu'à 6 tics tacs (18 s'il est au premier plan) en fonction de son comportement et du reste de l'activité sur le système.
La figure 1 illustre les situations injustifiées qui peuvent survenir lorsque deux threads dotés de la même priorité sont prêts à s'exécuter en même temps. Le thread A s'exécute jusqu'à l'expiration du prochain intervalle de tranche horaire alors que le planificateur suppose qu'il s'est exécuté pendant tout l'intervalle et décide que son tour est fini. En outre, le thread A se voit attribuer à tort la responsabilité de l'interruption survenue pendant son tour. À l'intervalle suivant, le planificateur choisit le thread B pour prendre la relève et celui-ci s'exécute pendant tout l'intervalle.
Figure 1 Planification injuste des threads
Figure 1 Planification injuste des threads
Dans Windows Vista, le planificateur utilise le registre du compteur de cycles des processeurs modernes pour déterminer précisément combien des cycles microprocesseur un thread exécute. En estimant combien de cycles le processeur peut exécuter dans un intervalle d'horloge, il peut distribuer plus précisément les tours sur le processeur. De plus, le planificateur de Windows Vista ne comptabilise pas les interruptions d'exécution au détriment du tour du thread. Ceci signifie que sur Windows Vista un thread obtiendra toujours au moins son tour sur le processeur et jamais plus d'un intervalle d'horloge supplémentaire d'exécution, ce qui assure plus de justesse et un comportement plus déterministe des applications. La figure 2 illustre la façon dont Windows Vista répond au scénario présenté dans la figure 1 en donnant aux deux threads au moins un intervalle de tranche d'heure d'exécution.
Figure 2 Planification basée sur cycles de Windows Vista
Figure 2 Planification basée sur cycles de Windows Vista
L'encadré « Observation de l'utilisation du processeur par les processus » explique comment vous pouvez vous-même surveiller l'utilisation des cycles microprocesseur grâce à l'utilitaire Process Explorer.

Service Planificateur de tâches multimédias
Les utilisateurs attendent des applications multimédias, y compris des lecteurs de musique et de vidéo, qu'ils leur assurent une expérience de lecture continue. Cependant, les demandes adressées au processeur par d'autres applications s'exécutant simultanément, par exemple l'antivirus, l'indexation de contenu ou même le client de courrier, peuvent provoquer des accrocs déplaisants. Pour assurer une meilleure expérience de lecture, Windows Vista introduit MMCSS pour gérer les priorités des threads multimédias en matière de processeur.
Une application multimédia comme le Lecteur Windows Media® 11 s'enregistre auprès de MMCSS en utilisant les nouvelles API qui indiquent ses caractéristiques multimédias, lesquelles doivent correspondre à l'une de celles répertoriées par nom sous la clé de registre suivante :
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figure A Affichage du temps processeur et des cycles Delta dans Process Explorer (Cliquer sur l'image pour la réduire)
Figure A Affichage du temps processeur et des cycles Delta dans Process Explorer
Figure A Affichage du temps processeur et des cycles Delta dans Process Explorer (Cliquer sur l'image pour l'agrandir)

Figure 3 Définition de tâche audio du Planificateur de tâches multimédias
Figure 3 Définition de tâche audio du Planificateur de tâches multimédias (Cliquer sur l'image pour la réduire)
Figure 3 Définition de tâche audio du Planificateur de tâches multimédias
Figure 3 Définition de tâche audio du Planificateur de tâches multimédias (Cliquer sur l'image pour l'agrandir)
MMCSS, qui est implémenté dans %SystemRoot%\System32\Mmcss.dll et qui s'exécute dans un processus Hôte de service (Svchost.exe), a un thread de gestion des priorités qui s'exécute à la priorité 27. (Dans Windows, les priorités de thread vont de 0 à 31.) Ce thread rehausse la priorité des threads multimédias inscrits dans la plage associée à la valeur Catégorie de planification de leur clé de registre de tâche telle qu'elle est présentée dans la figure 4. Dans Windows, les priorités de thread de niveau 16 et supérieur se situent dans la plage de priorité en temps réel et sont plus élevées que tous les autres threads sur un système (à l'exception des threads de travail du gestionnaire de mémoire du noyau qui s'exécutent aux priorités 28 et 29). Seuls les comptes d'administrateur, comme le compte Système local dans lequel MMCSS s'exécute, disposent du privilège de pouvoir augmenter la priorité qui est requis pour définir les priorités de thread en temps réel.
Figure 4 Priorités de threads MMCSS (Close Figure 4)

Catégorie de planification | Priorité de thread augmentée
Élevée | 23-26
Moyenne | 16-23
Lorsque vous lisez un fichier audio, le Lecteur Windows Media enregistre des threads de tâches audio et, lorsque vous lisez une vidéo, il enregistre des threads de tâche de lecture. Le service MMCSS augmente tous threads ayant indiqué qu'ils livrent un flux en même temps lorsqu'ils s'exécutent dans le processus qui possède la fenêtre de premier plan et que leur valeur BackgroundOnly est définie sur true dans leur clé de définition de la tâche.
Mais si MMCSS veut aider les threads multimédias à obtenir le temps processeur dont ils ont besoin, il veut également s'assurer que les autres threads obtiennent au moins une certaine quantité de temps processeur pour que le système et les autres applications restent réactives. MMCSS réserve donc un pourcentage de temps processeur, spécifié dans la valeur de registre suivante, aux autres activités :
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
Par défaut, ce pourcentage est de 20 pourcent. MMCSS contrôle l'utilisation du processeur pour s'assurer que les threads multimédias ne sont pas augmentés pour plus de 8 ms sur une période de 10 ms si les autres threads ont besoin du processeur. Pour écarter les threads multimédias pendant les 2 ms restantes, le planificateur ramène leurs priorités dans la plage de 1 à 7.
Vous pouvez voir comment MMCSS augmente la priorité des threads en lisant l'encadré « Comment MMCSS augmente la priorité ».

Liens symboliques basés sur des fichiers
Parmi les modifications apportées aux E/S dans Windows Vista figurent des liens symboliques basés sur les fichiers, un traitement plus efficace de l'achèvement des E/S, une prise en charge complète de l'annulation des E/S et la hiérarchisation des E/S.
Une fonctionnalité du système de fichiers qui, de l'avis de beaucoup, manquait dans NTFS figure enfin dans Windows Vista, à savoir le lien symbolique sur fichier (ou « soft link » comme l'appelle Unix). La version Windows 2000 de NTFS avait introduit des liens symboliques sur répertoire, appelés jonctions de répertoires, qui permettent de créer un répertoire pointant vers un répertoire différent, mais jusqu'à la version Windows Vista, NTFS ne prenait en charge que les liens réels pour les fichiers.
L'une des différences majeures intervenues dans la façon dont Windows résout les liens symboliques et les jonctions de répertoires concerne le lieu où s'effectue le traitement. Windows traite les liens symboliques sur le système local, même lorsqu'ils référencent un emplacement sur un serveur de fichiers à distance. Windows traite directement les jonctions de répertoires qui référencent un serveur de fichiers à distance sur le serveur lui-même. Les liens symboliques sur un serveur peuvent donc faire référence à des emplacements seulement accessibles depuis un client, comme d'autres volumes de clients, alors que les jonctions de répertoires ne le peuvent pas. Pour répondre à ceci, Windows Vista prend en charge le nouveau type de lien symbolique pour les fichiers et les répertoires.
Beaucoup de commandes de système de fichiers ont été mises à jour pour comprendre les implications des liens symboliques. Par exemple, la commande Delete sait qu'elle ne doit pas suivre les liens, ce qui aurait pour résultat la suppression de la cible, mais qu'il faut supprimer le lien à la place. Cependant, toutes les applications n'étant pas en mesure de traiter correctement les liens symboliques, la création d'un lien symbolique requiert le nouveau privilège Créer des liens symboliques qui, par défaut, n'appartient qu'aux administrateurs.
Vous pouvez créer un lien symbolique à partir d'une invite de commande avec la commande Mklink. La commande de répertoire incorporée à l'invite de commande identifie un lien symbolique en le marquant comme <SYMLINK> et en affichant la cible entre crochets, ainsi que l'illustre la figure 5. L'explorateur Windows reconnaît également les liens symboliques et les affiche avec la flèche de raccourci. Vous pouvez voir la cible d'un lien dans l'explorateur en ajoutant la colonne Cible du lien à la fenêtre de navigation.Observation des augmentations de priorité MMCSS
Pour observer l'augmentation des threads que le service MMCSS applique aux threads du lecteur Windows Media, vous pouvez lire une vidéo ou un clip audio, exécuter l'Analyseur de performances, configurer le paramètre d'échelle de diagramme sur 31 (la priorité de thread la plus élevée de Windows) et ajouter le compteur Priorité actuelle à toutes les instances des objets de thread du lecteur Windows Media (Wmplayer.exe) à l'affichage. Un ou plusieurs threads s'exécuteront à la priorité 21.
Figure B Augmentation de la priorité des threads pour le lecteur Windows Media
Figure B Augmentation de la priorité des threads pour le lecteur Windows Media (Cliquer sur l'image pour la réduire)
Figure B Augmentation de la priorité des threads pour le lecteur Windows Media
Figure B Augmentation de la priorité des threads pour le lecteur Windows Media (Cliquer sur l'image pour l'agrandir)

Figure 5 Utilisation de Mklink pour créer un lien symbolique
Figure 5 Utilisation de Mklink pour créer un lien symbolique (Cliquer sur l'image pour la réduire)
Figure 5 Utilisation de Mklink pour créer un lien symbolique
Figure 5 Utilisation de Mklink pour créer un lien symbolique (Cliquer sur l'image pour l'agrandir)

Terminaison et annulation des E/S
Plusieurs modifications du système E/S peuvent améliorer les performances des applications serveur. Ces applications utilisent habituellement un objet de synchronisation appelé un port de terminaison pour attendre la terminaison des requêtes E/S asynchrones. Avant Windows Vista, lorsqu'une telle E/S se terminait, le thread qui avait émis l'E/S exécutait le travail de terminaison E/S. Cela faisait commuter le processus auquel appartenait le thread et interrompait tout ce qui se passait d'autre. Ensuite le système E/S mettait à jour l'état du port de terminaison pour activer un thread qui attendait qu'il change.
Sur Windows Vista, le traitement de la terminaison E/S n'est pas nécessairement exécuté par le thread qui a émis l'E/S mais plutôt par celui qui attend que le port de terminaison l'active. Cette modification relativement mineure évite la planification de thread inutiles et les commutations de contexte qui peuvent dégrader les performances globales du système et de l'application. Pour améliorer encore plus les performances, un serveur peut récupérer les résultats d'opérations E/S multiples depuis une terminaison dans une requête, ce qui évite les transitions vers le mode noyau.
Du point de vue d'un utilisateur final, la modification la plus notable dans le système E/S est probablement la prise en charge par Windows Vista de l'annulation des opérations E/S synchrones. S'il vous est déjà arrivé d'exécuter la commande Net View ou de tenter d'accéder à un partage d'un système distant hors ligne utilisant Windows XP ou Windows Server® 2003, vous avez été confronté à des problèmes avec des opérations E/S qui ne peuvent pas être annulées : l'explorateur de commandes ou fichiers ne répondra pas avant l'expiration du délai d'attente réseau. Une application n'a pas d'autre choix qu'attendre que l'opération échoue parce quelle ne peut en aucune façon informer le pilote de périphérique exécutant l'E/S qu'elle ne s'intéresse plus à l'E/S.
Dans Windows Vista, la plupart des opérations E/S peuvent être annulées, y compris l'E/S d'ouverture de fichier qu'utilisent Net View et l'explorateur. Les applications doivent être mises à jour pour répondre aux requêtes d'annulation d'E/S de l'utilisateur final. Cependant, beaucoup des utilitaires de Windows Vista qui interagissent avec les périphériques ayant des délais disposent de la prise en charge nécessaire. Par exemple, les dialogues d'ouverture de fichier et d'enregistrement utilisés par pratiquement toutes les applications Windows, y compris les applications tierces, activent désormais leur bouton Annuler lors d'une tentative d'affichage du contenu d'un dossier. La commande Net annule également son E/S synchrone lorsque vous appuyez sur les touches Ctrl+C.
Vous pouvez consulter les avantages de l'annulation d'E/S en ouvrant une invite de commande sur Windows Vista et en saisissant :
net view (\\nonexistentmachine)
La commande attendra pendant que Windows tente de contacter le système inexistant, mais vous pouvez taper Ctrl+C pour y mettre fin. Dans Windows XP, Ctrl+C n'a pas d'effet et la commande ne réapparaît pas tant que l'opération réseau n'expire pas.
Un autre type d'E/S ayant causé des problèmes aux utilisateurs dans les versions précédentes de Windows est celui que les pilotes de périphériques n'annulaient pas convenablement parce qu'il n'y avait pas de façon facile pour eux de savoir qu'ils devaient le faire. S'il vous est arrivé de terminer un processus mais d'avoir continué à le voir dans les outils d'affichage de processus, vous avez été témoin d'une situation dans laquelle le pilote de périphérique n'a pas répondu à un arrêt de processus et à une annulation d'E/S émis par le processus qui n'était pas terminé. Windows ne peut pas procéder au nettoyage de processus final tant que toutes les E/S du processus ne se sont pas terminées ou n'ont pas été annulées. Dans Windows Vista, les pilotes de périphériques peuvent facilement s'inscrire pour recevoir des notifications d'arrêts de processus et, de ce fait, la plupart des problèmes de processus impossibles à stopper ont disparu.

Priorité d'E/S
Bien que Windows ait toujours pris en charge la définition de priorités pour l'utilisation du processeur, il n'incluait pas le concept de priorité d'E/S. Sans la priorité d'E/S, les activités d'arrière-plan telles que l'indexation de la recherche, l'analyse des virus et la défragmentation de disque peuvent fortement influer sur la réactivité des opérations de premier plan. Un utilisateur qui lance une application ou ouvre un document alors qu'un autre processus exécute une E/S de disque, par exemple, est confronté à des retards parce que la tâche de premier plan attend l'accès au disque. La même interférence affecte également la lecture en continu de contenus multimédias, comme des chansons, depuis un disque dur.
Windows Vista introduit deux nouveaux types de définitions de priorité d'E/S afin d'aider les opérations E/S de premier plan à obtenir la préférence : priorité sur les opérations E/S individuelles et les réservations de bande passante d'E/S. Le système E/S de Windows Vista inclut en interne la prise en charge de cinq priorités d'E/S, ainsi que l'illustre la figure 6, mais seules quatre de ces priorités sont utilisées (les versions futures de Windows pourront prendre en charge une priorité Élevée).
Figure 6 Priorités d'E/S dans Windows Vista (Close Figure 6)

Priorité d'E/S | Utilisation
Critique | Gestionnaire de mémoire
Élevée | Inutilisée
Normale | Priorité par défaut
Faible | Priorité de tâche par défaut
Très faible | Activité d'arrière-plan
La priorité par défaut de l'E/S est Moyenne alors que le gestionnaire de mémoire utilise une priorité Critique lorsque il veut écrire des données de mémoire impropres sur le disque alors qu'il reste peu de mémoire, afin de libérer de la place dans la mémoire RAM pour d'autres données et codes. Le Planificateur de tâches de Windows attribue une priorité d'E/S Faible aux tâches ayant une priorité de tâche par défaut. La priorité spécifiée par les applications écrites pour Windows Vista qui exécutent le traitement d'arrière-plan est Très faible. Toutes les opérations d'arrière-plan de Windows Vista, y compris l'analyse de Windows Defender et l'indexation de Windows Search, utilisent une priorité d'E/S Très faible.Voir un exemple de priorité d'E/S Très faible
Le moniteur de traitement, un système de fichiers en temps réel et utilitaire de contrôle de registre de Sysinternals, recueille des informations détaillées pour les opérations de lecture et d'écriture du système de fichiers, y compris leurs priorités d'E/S dans Windows Vista. La ligne soulignée montre un exemple d'une E/S de priorité Très faible qui a été émise par SuperFetch (j'aborderai ce sujet dans mon prochain article).
Figure C Voir une priorité d'E/S Très faible dans le moniteur de traitement
Figure C Voir une priorité d'E/S Très faible dans le moniteur de traitement (Cliquer sur l'image pour la réduire)
Figure C Voir une priorité d'E/S Très faible dans le moniteur de traitement
Figure C Voir une priorité d'E/S Très faible dans le moniteur de traitement (Cliquer sur l'image pour l'agrandir)

Le pilote de périphérique de classe du système de stockage (%SystemRoot%\System32\Classpnp.sys) applique les priorités d'E/S qui s'appliquent automatiquement aux E/S dirigées vers la plupart des périphériques de stockage. Les pilotes de classe et autres pilotes de stockage insèrent les E/S Moyennes devant celles dont la priorité est Faible et Très faible dans leurs files d'attente, mais ils émettent chaque seconde au moins une E/S Faible ou Très faible en attente afin que les processus d'arrière-plan puissent progresser. Les données lues à l'aide d'E/S de priorité Très faible incitent également le gestionnaire de cache à écrire immédiatement les modifications sur le disque au lieu de le faire plus tard et à contourner sa logique de lecture anticipée pour les opérations de lecture qui, sans cela, liraient de façon prioritaire depuis le fichier en cours d'accès. Examinez l'encadré « Voir un exemple de priorité d'E/S Très faible » si vous recherchez un exemple de priorité d'E/S Très faible utilisant l'utilitaire Moniteur de traitement.
La prise en charge de la réservation de bande passante dans Windows Vista est utile pour les applications de lecteur de médias. Le lecteur Windows Media l'utilise, ainsi que les augmentations de priorité de MMCSS, pour offrir une lecture pratiquement sans accroc des contenus locaux. Une application de lecteur multimédia demande au système d'E/S de lui garantir la capacité de lire des données à un taux spécifié. Si le périphérique peut livrer des données au taux demandé et que les réservations existantes le permettent, il suggère à l'application à quelle vitesse elle doit émettre les E/S et de quelle taille les E/S doivent être. Le système E/S n'entretiendra pas autres E/S à moins qu'il soit en mesure de satisfaire les exigences d'applications qui ont fait des réservations sur le périphérique de stockage cible.
Une dernière modification apportée au système E/S et liée à la taille des opérations E/S mérite d'être évoquée. Depuis la première version de Windows NT, le gestionnaire de mémoire et le système E/S ont limité à 64 Ko la quantité de données traitées par une requête E/S de stockage individuelle. Ainsi, même si une application émet une requête E/S beaucoup plus importante, celle-ci est décomposée en requêtes individuelles d'une taille maximale de 64 Ko. Chaque E/S est soumis à un temps de traitement pour les transitions vers le mode noyau et l'établissement d'un transfert d'E/S sur le périphérique de stockage. Dans Windows Vista, les tailles de requête E/S de stockage ne sont donc plus plafonnées. Plusieurs composants du mode utilisateur de Windows Vista ont été modifiés pour profiter de la prise en charge d'E/S plus importantes, notamment la fonctionnalité de copie de l'explorateur et la commande Copy de l'invite de commande, qui émettent maintenant des E/S de 1 Mo.

À venir
Vous venez de découvrir deux domaines dans lesquels le noyau de Windows Vista a été amélioré. Vous pouvez retrouver d'autres informations détaillées dans la prochaine édition de mon livre Windows Internals (rédigé en collaboration avec David Salomon) qui devrait paraître en même temps que la prochaine version de Windows Server, nom de code « Longhorn ». Dans mon prochain article, je continuerai à vous présenter le nouveau noyau en abordant la gestion de mémoire ainsi que le démarrage et l'arrêt du système.

Mark Russinovich est technicien dans le service responsable des plateformes et services chez Microsoft. Coauteur de l'ouvrage intitulé Microsoft Windows Internals (Microsoft Press, 2004), il participe fréquemment à des conférences pour informaticiens et développeurs. Il a rejoint récemment rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé la société Sysinternals qui a publié les utilitaires Process Explorer, Filemon et Regmon.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 Administration de Windows: D&#233;l&#233;gation d'autorisation dans Active&#160;Directory
Administration de Windows Joel Yoker and Rob Campbell

Délégation d'autorisation dans Active Directory
Vue d'ensemble:
  • Définition des rôles administratifs
  • Développement d'un modèle d'unité d'organisation et de groupe de sécurité
  • Utilisation des comptes secondaires
  • Outils de délégation des droits

Les fonctionnalités de délégation d'Active Directory sont très puissantes, répondent à plusieurs problèmes de sécurité et simplifient les tâches de gestion. En délégant convenablement les droits dans Active
Directory®,vous pouvez appliquer des rôles spécifiés au sein de l'environnement, limiter l'impact et la probabilité d'erreurs administratives et appliquer le principe de moindre privilège à l'échelle de votre infrastructure. Pourtant, un grand nombre des organisations qui s'appuient sur Active Directory n'exploitent pas encore son pouvoir de délégation. Ceci est en partie dû au fait qu'à première vue, le développement d'un modèle de délégation Active Directory pour votre entreprise semble assez complexe. Si la plus grande difficulté consiste à développer un modèle de délégation qui réponde aux besoins uniques de votre organisation, la vérité est qu'il existe des modèles très simples qui peuvent être appliqués à la plupart des infrastructures informatiques avec un minimum de modifications.
Bien que chaque environnement soit différent à tel ou tel égard, la réalité est que la plupart des grandes entreprises présentent de nombreuses similitudes et sont confrontées aux mêmes défis informatiques. Par exemple, beaucoup d'organisations sont divisées en régions géographiques, ont évolué à partir d'équipes d'ingénierie informatique ou de support opérationnel distinctes et comportent des divisions indépendantes. En outre, un grand nombre d'organisations doivent faire face à des problèmes tels que la promotion des privilèges, les abus de compte de service et la « confiance ».
La confiance est un terme intéressant et qui sert souvent à justifier la présence de plusieurs forêts Active Directory. Les problèmes de confiance ont souvent pour origine la capacité d'une division ou d'une région à avoir un impact majeur sur la disponibilité des systèmes d'une autre division ou région. Il est courant que les niveaux de compétences diffèrent d'un pays à l'autre et que les connaissances approfondies de systèmes spécifiques requises pour le support d'une région ou d'une division particulière soient absentes. De ce fait, les divisions ne veulent généralement pas renoncer à leurs droits administratifs au profit d'un groupe centralisé.
Pendant ce temps, pour n'importe quelle mise en œuvre d'Active Directory, les administrateurs doivent définir les règles d'engagement pour les applications qui utilisent l'infrastructure Active Directory. Malheureusement, une approche courante, souvent citée dans les guides d'installation d'applications, consiste à ériger un compte de service en membre du groupe Administrateurs de domaine. Le problème avec cette approche est que ces comptes de service sont essentiellement des comptes génériques. En accordant des droits d'administrateur de domaine à ces comptes, vous soumettez l'environnement informatique à une menace significative. Les comptes de service sont facilement victimes d'une utilisation inappropriée de la part d'administrateurs malveillants ou négligents. Ils peuvent également être mis à profit par des personnes malveillantes qui exploitent les problèmes de sécurité sous-jacents dans une application.
Bien que ces difficultés puissent sembler insurmontables, elles constituent un scénario idéal pour l'implémentation d'un modèle de délégation Active Directory. Le développement d'un modèle de délégation est un processus de conception itératif et nous vous suggérons de suivre ces étapes :
  1. Définissez les rôles administratifs informatiques au sein de votre organisation.
  2. Développez un modèle d'unité d'organisation et de groupe de sécurité.
  3. Établissez des comptes secondaires pour les administrateurs informatiques.
  4. Déléguez les droits.
Examinons ces étapes plus en détail.

Définition des rôles
Le processus de définition des rôles repose sur une compréhension détaillée de l'administration des services et de l'administration des données. Ces concepts sont les pierres angulaires de tout modèle de délégation Active Directory.
Essentiellement, l'administration des services consiste à gérer les composants d'infrastructure de services d'annuaire critiques tels que les serveurs Exchange et les contrôleurs de domaines. L'administration de données est la gestion d'objets, tels que les boîtes aux lettres et les comptes d'utilisateur, qui résident au sein de ces services. Dans Active Directory, les administrateurs de services sont en fait responsables de la livraison et de la disponibilité de services d'annuaire tandis que les administrateurs de données gèrent les comptes d'utilisateur et de serveur, les groupes et les autres ressources de domaine.
Active Directory prend en charge la délégation d'autorisation granulaire par le biais d'unités d'organisation (UO). Les UO peuvent fréquemment être adaptées pour offrir le même niveau d'autorisation que celui dont disposent les administrateurs dans les modèles de services d'annuaire ou de domaine existants. Mais il importe de comprendre que certaines fonctions ne peuvent tout simplement pas être déléguées et doivent être gérées par un seul un groupe ou entité de confiance.
L'analyse des tâches revêt également une importance critique. Vous devez savoir quelles tâches Active Directory sont exécutées par les administrateurs et comment ces tâches sont mappées aux rôles. Par exemple, la création d'un site Active Directory est une tâche d'administration de service alors que la modification de l'appartenance au groupe de sécurité fait généralement partie de l'administration des données. Chaque tâche doit être évaluée selon sa fréquence, son importance et sa difficulté. Ce sont là des aspects vitaux de la définition des tâches parce qu'ils déterminent si un droit doit ou non être délégué. Les tâches qui sont exécutées de façon routinière, présentent un risque limité et sont très faciles à exécuter font d'excellentes candidates pour la délégation. En revanche, les tâches qui sont rarement exécutées, ont un grand impact dans toute l'organisation et nécessitent des niveaux élevés de compétences sont ne devraient pas être déléguées. Pour ces tâches, il convient plutôt de recourir à la promotion (en élevant temporairement un compte au rôle requis ou en réaffectant la tâche).
Dans la mesure où les grandes organisations partagent un grand nombre de caractéristiques, on peut raisonnablement supposer qu'un modèle de délégation commun puisse être implémenté. Dans le cadre de cet article, nous allons vous présenter une série de rôles définis qui activent les fonctionnalités de gestion tout en respectant les limites organisationnelles et en essayant de limiter les problèmes de confiance (par exemple, la disponibilité des actifs nécessaires à l'échelle de l'entreprise tels que les contrôleurs de domaine). Il convient de noter que ce modèle n'est qu'un exemple : c'est un excellent point de départ pour débattre des rôles dans votre organisation, mais vous ne devez pas envisager de suivre ces conseils à la lettre.
Quelques rôles sont déjà définis par Active Directory et d'autres doivent être entièrement créés pour compléter le modèle de délégation. Parmi la gamme de rôles qui conviendraient à un grand nombre d'environnements Active Directory, citons d'une part les Administrateurs d'entreprise, les Administrateurs de domaine et les Administrateurs de niveau 4 pour l'administration des services, et de l'autre les Administrateurs de niveau 3, les Administrateurs régionaux, les Administrateurs de niveau 2 et les Administrateurs de niveau 1 pour l'administration des données. Consultez la figure 1 pour obtenir une liste de ces rôles et de leurs responsabilités.
Figure 1 Define Roles and Responsibilities (en anglais) (Close Figure 1)

Administrateurs de services | Description
Administrateurs d'entreprise | Responsables de l'administration des services au niveau supérieur à l'échelle de l'entreprise. Ne doivent pas contenir de membres permanents.
Administrateurs de domaine | Responsables de l'administration des services au niveau supérieur à l'échelle du domaine. Ne doivent contenir qu'un nombre limité et facile à gérer d'administrateurs de confiance.
Administrateurs de niveau 4 | Responsables de l'administration des services à l'échelle du domaine. Ne se voient accorder que les droits nécessaires à la gestion des services requis. Font office de point de promotion pour les administrateurs de données.
Administrateurs de données | Description
Administrateurs de niveau 1 | Responsables de la gestion générale des objets d'annuaire. Exécutent des tâches telles que la réinitialisation des mots de passe, la modification des propriétés des comptes d'utilisateur, etc.
Administrateurs de niveau 2 | Responsables de la création et/ou de la suppression sélectives de comptes d'utilisateur et de comptes d'ordinateur pour leur région ou organisation.
Administrateurs régionaux | Responsables de la gestion de leur structure d'UO locale. Ont l'autorisation de créer la plupart des objets dans leur UO.
Administrateurs de niveau 3 | Responsables de la gestion de tous les administrateurs de données. Assurent le support technique interne de niveau supérieur et servent de point de promotion pour tous les administrateurs régionaux.

Administrateurs de services
Regardons plus en détails les rôles d'administrateurs de services. Les administrateurs de services gèrent les composants d'infrastructure critiques et tous les administrateurs qui appartiennent à cette catégorie bénéficient de privilèges extrêmement élevés. Par conséquent, une stratégie de moindre privilège, qui veut que seuls les jeux d'autorisations nécessaires à l'exécution des tâches requises soient accordés, est fortement recommandée dans ce cas.
Les termes Administrateurs d'entreprise et Administrateurs de domaine Active Directory couvrent deux groupes d'administrateurs spéciaux dont le contexte de sécurité est requis pour des fonctions critiques dans l'annuaire. Ces groupes (Administrateurs d'entreprise et Administrateurs de domaine) sont responsables de l'administration des services au plus haut niveau. Pour limiter les risques inhérents aux groupes disposant de privilèges si élevés, nous vous conseillons de limiter fortement l'appartenance à ces groupes. En fait, les groupes Administrateurs d'entreprise ne devraient pas avoir de membres permanents et les groupes Administrateurs de domaine ne devraient compter qu'un nombre réduit et facilement gérable d'individus de confiance qui travaillent à plein temps pour l'organisation.
Lorsque des tâches d'administration d'entreprise telles que l'autorisation d'un serveur DHCP ou la création d'un site Active Directory doivent être exécutées, les Administrateurs de domaine du domaine racine de la forêt Active Directory peuvent promouvoir des privilèges en gérant l'appartenance au groupe Administrateurs d'entreprise. Ces privilèges ne doivent être accordés que pour de courtes périodes de temps afin d'éviter la création de membres permanents dans le groupe Administrateurs d'entreprise. Bien sûr, tous les membres d'un groupe Administrateurs de domaine d'une forêt Active Directory donnée doivent jouir de la même confiance.
La désactivation ou la paralysie de ces rôles prédéfinis représente un piège courant dans lequel tombent la plupart des organisations lorsqu'elles développent un modèle de délégation. La modification des rôles par défaut peut avoir des résultats imprévisibles et rien ne garantit que les révisions de service pack ou les mises à niveau de produits conserveront ces paramètres. De plus, ce type de modification crée un environnement qui n'est pas pris en charge hors de l'organisation. Une approche pratique consiste à utiliser les groupes et les rôles prédéfinis mais à en limiter l'appartenance. En agissant ainsi, vous devrez probablement créer de nouveaux rôles pour les administrateurs qui s'appuyaient précédemment sur l'appartenance à des groupes tels qu'Administrateurs de domaine.
Administrateurs de niveau 4 Le groupe Administrateurs de niveau 4 doit être composé d'administrateurs de services centralisés qui assurent la prise en charge de tous les services d'entreprise. Dans la mesure où il s'agit d'un rôle créé, les autorisations d'accès au service d'annuaire et au système peuvent être adaptées aux exigences spécifiques de votre organisation. Même si les membres de ce groupe sont des administrateurs de services, ils peuvent aussi occasionnellement exécuter des tâches de gestion des données à l'échelle de la forêt. Comme il existe de nombreuses classes de systèmes et différents domaines de responsabilité, les rôles de niveau 4 sont répartis en plusieurs sous-groupes dans l'annuaire. Par exemple, des groupes de niveau 4 distincts doivent être créés pour assurer une gestion discrète de systèmes spécifiques tels que les serveurs Exchange. Ce groupe fait également office de point de promotion pour les administrateurs de données.
Si les individus souhaitent souvent bénéficier de l'appartenance au groupe Administrateurs de domaine, c'est notamment parce qu'ils veulent obtenir des droits administratifs sur chaque système d'un domaine donné. Pour que ces administrateurs de services ouvrent leurs sessions dans un mode de moindre privilège, l'astuce consiste à accorder le contrôle des serveurs d'entreprise aux Administrateurs de niveau 4 sans en faire des Administrateurs de domaine. Afin d'empêcher la promotion des privilèges, les Administrateurs de niveau 4 ne doivent pas être autorisés à appartenir au groupe BUILTIN\Administrators sur les contrôleurs de domaine puisque ce groupe dispose, sur le service d'annuaire, de nombreux droits sous-jacents qui ne peuvent pas être séparés. Par exemple, un membre du groupe BUILTIN\Administrators d'un domaine donné peut gérer l'appartenance au groupe Administrateurs de domaine, ce qui permet aux membres de promouvoir les privilèges sans que s'exerce aucun contrôle ni équilibrage.
Souvenons-nous de la règle selon laquelle il ne faut pas paralyser les autorisations par défaut : ce risque peut être réduit en faisant des groupes de niveau 4 des membres imbriqués dans les groupes de domaine prédéfinis Opérateurs de serveur et Administrateurs de DNS. Ceci permet une gestion locale des contrôleurs de domaine tout en limitant la capacité des Administrateurs de niveau 4 à promouvoir des privilèges. Pour la plupart des systèmes (hormis les des contrôleurs de domaine, les serveurs de certificats, etc.), il conviendrait que le groupe Administrateurs de niveau 4 soit fait membre du groupe Administrateurs locaux. L'automatisatoin de l'appartenance aux groupes locaux imbriqués peut être obtenue avec la fonctionnalité Groupes restreints de la stratégie de groupe.

Administrateurs de données
Étudions maintenant les rôles d'administration de données. Ceux-ci doivent être conçus avec des droits cumulatifs, ce qui signifie qu'un administrateur de niveau 2 doit disposer de tous les droits d'un administrateur de niveau 1 ainsi que de quelques privilèges supplémentaires, et ainsi de suite. C'est pour cette raison que nous étudierons ces groupes en partant du groupe de plus bas niveau.
Administrateurs de niveau 1 Le groupe Administrateurs de niveau 1 doit s'occuper de la gestion générale des objets de répertoire précédemment créés. Ce groupe est destiné aux administrateurs ayant reçu la formation la moins poussée ou à ceux qui effectuent des tâches isolées, par exemple les réinitialisations de mots de passe. Accordez à ce groupe, dans son unité d'organisation, le droit de modifier les propriétés des comptes d'utilisateur, de réinitialiser les mots de passe des comptes d'utilisateur, de déverrouiller des comptes, d'activer et désactiver les comptes d'utilisateur, d'ajouter et de réinitialiser des comptes d'ordinateur poste de travail et de modifier l'appartenance à un objet de groupe pour les groupes non administrateurs.
Administrateurs de niveau 2 Ce groupe doit permettre la gestion et la création sélectives d'objets en autorisant uniquement la création d'objets pouvant être gérés par des administrateurs de niveau 1. (Par exemple, les groupes de sécurité peuvent uniquement être créés dans l'UO de groupes). Les administrateurs de niveau 2 peuvent ajouter et peuvent modifier les comptes d'administrateur de niveau 1, ajouter, modifier et supprimer des comptes utilisateur pour une UO, supprimer les objets Ordinateur poste de travail et enfin ajouter, modifier et supprimer les objets Serveur, Contact et Dossier Partagé.
Administrateurs régionaux Les droits de ce groupe sont exclusivement limités à la structure d'UO régionale. Cependant, ces administrateurs ne peuvent pas gérer les autres structures d'UO régionales du répertoire. Les comptes d'administrateurs régionaux doivent être considérés comme étant extrêmement privilégiés et, par conséquent, ces comptes sont enregistrés dans une hiérarchie d'UO séparée et gérés par les administrateurs de services du groupe Administrateurs de niveau 4. Les administrateurs régionaux sont autorisés à créer la plupart des objets sans restriction dans leur structure d'UO (une exception notable étant la création d'autres unités d'organisation), ce qui fait naître le risque supplémentaire que soient créés des objets ne pouvant pas être gérés par les niveaux inférieurs.
Administrateurs de niveau 3 De nombreuses organisations possèdent un support technique centralisé ou de niveau supérieur. Ce rôle remplit la liste d'administrateurs de données, constituant un groupe d'administrateurs de données au-dessus de tous les administrateurs régionaux. Les droits ne sont pas délégués aux groupes se trouvant spécifiquement dans le répertoire. En fait, ils sont établis par l'intermédiaire de l'appartenance imbriquée dans chaque groupe d'administrateurs régionaux. Cette approche fournit un point de promotion au niveau supérieur pour tous administrateurs de données, ainsi qu'un point d'entrée permettant de remonter les problèmes vers les groupes d'administration de services.

Élaboration d'un modèle d'UO et de groupe de sécurité
Une fois les rôles définis dans l'organisation, un modèle d'UO et de groupe de sécurité doit être défini. Il existe deux raisons principales pour créer une UO dans Active Directory : la délégation de droits et la création d'un point où les objets de stratégie de groupe peuvent être liés. Les UO définissent une étendue de la gestion dans le répertoire et peuvent être utilisées pour imposer des droits à des objets à divers niveaux. Par conséquent, la façon dont vous choisissez de déléguer l'autorisation doit jouer un rôle déterminant dans la manière dont vous implémentez votre structure d'UO.
Ceci étant établi, une UO de niveau supérieur (ou une série d'UO) devrait être directement créée en-dessous du domaine pour loger tous les objets. Cette UO a pour objectif spécifique de définir l'étendue de la gestion du niveau le plus élevé pour les administrateurs de niveau 4. La création d'une UO de premier supérieur, permet de faire démarrer explicitement les droits sur le service de répertoire au niveau de l'UO plutôt qu'au niveau du domaine. La délégation depuis une UO de niveau supérieur plutôt que depuis le domaine réduit le risque que des utilisateurs aient la possibilité de promouvoir des privilèges en manipulant les groupes de domaine prédéfinis mentionnés précédemment.
En-dessous des UO de niveau supérieur, vous devez créer des hiérarchies de sous-UO distinctes pour représenter chaque région ou chaque division disposant d'une équipe de gestion des données discrète. Chaque sous-UO régionale doit avoir une hiérarchie d'UO commune et non extensible pour la gestion des objets de répertoire. L'uniformité est essentielle à la gestion continue puisqu'une bonne partie de la délégation des droits sera automatisée. Il ne s'agit pas d'une mince affaire puisque chaque région peut désirer des UO uniques. Mais les administrateurs informatiques doivent maintenir leur position et, si une extension est nécessaire pour une région, la structure de sous-UO doit être étendue pour toutes les régions. Ceci peut tout d'abord sembler difficile, mais si l'organisation fournit un logement générique pour les objets, les situations isolées ont tendance à progressivement trouver leur place.
Finalement, créez des sous-groupes d'administration et des comptes séparés (un groupe Administrateurs de niveau 1, Administrateurs de niveau 2 et Administrateurs régionaux pour chaque hiérarchie de sous-UO) pour supprimer la capacité des administrateurs à promouvoir leurs privilèges. L'enregistrement de ces comptes dans des UO séparées permet la restriction de la gestion à leur niveau ou à un niveau inférieur. Ainsi, si tous les comptes Administrateurs de niveau 1 et le groupe de sécurité associé résident dans une UO où ils ne disposent d'aucun droit, les administrateurs ne pourront pas détourner d'autres comptes d'administrateur ni promouvoir les privilèges d'autres administrateurs jusqu'à leur niveau. Tout membre du groupe Administrateurs de domaine peut, par exemple, transformer n'importe quel autre compte utilisateur du domaine en un administrateur de domaine. Cependant, avec ce modèle d'UO en place, ce risque est réduit. La figure 2 présente un exemple de structure d'UO associée à des groupes de sécurité.
Figure 2 Structure d'UO et groupes de sécurité associés
Figure 2 Structure d'UO et groupes de sécurité associés

Établissement de comptes secondaires
Si l'on veut obtenir un modèle de délégation réussi, la clé du succès consiste à appliquer le principe de moindre privilège. Dans la pratique, cela signifie qu'une entité de sécurité dot uniquement pouvoir exécuter les tâches requises pour son rôle donné et rien plus. Malheureusement, beaucoup d'administrateurs informatiques utilisent la même entité de sécurité pour l'administration du répertoire et pour les tâches quotidiennes comme la navigation sur le Web et la lecture des messages électroniques. L'existence de comptes séparés réduit la probabilité qu'un administrateur d'un niveau n'endommage le service d'annuaire par erreur ou ne soit victime d'une attaque livrée par l'intermédiaire d'applications quotidiennes mais ciblant l'administrateur d'annuaire.
Pour accomplir ceci sans que l'utilisateur ne soit obligé de se déconnecter et de se reconnecter, utilisez le service d'ouverture de session secondaire (Runas.exe). Celui-ci autorise les utilisateurs à promouvoir leurs privilèges en fournissant une autre série d'informations d'identification lors de l'exécution de scripts ou d'exécutables sur les serveurs et les postes de travail.
Bien que le concept d'utilisation de comptes à moindres privilèges soit relativement simple, les organisations ont parfois des difficultés à le mettre en place car, en matière d'informatique, les vieilles habitudes sont difficiles à changer. Si l'on souhaite empêcher que des comptes privilégiés soient utilisés lors des tâches quotidiennes, une approche directe consiste à ne pas fournir d'accès au courrier à ces comptes dans Exchange Server et à appliquer cette méthode par le biais par la stratégie administrative de l'organisation. Cette approche relativement simple réduit de manière significative la probabilité que de tels comptes soient utilisés pour des tâches non administratives de routine.

Délégation de droits
L'étape finale dans le développement d'un modèle de délégation est la délégation des droits elle-même dans Active Directory. Elle implique la manipulation des entrées de contrôle d'accès (ACE) et des listes de contrôle d'accès (ACL) sur les données enregistrées dans l'annuaire. Les ACL placées sur les conteneurs Active Directory, définissent les objets qui peuvent être créés et leur mode de gestion. La délégation des droits concerne des opérations fondamentales sur les objets, telles que la possibilité d'afficher un objet, de créer un objet enfant d'une classe spécifiée ou de lire des informations sur les attributs et la sécurité pour les objets d'une classe spécifiée. Outre ces opérations fondamentales, Active Directory définit des autorisations étendues qui activent des opérations telles que Envoyer sous forme de et Gérer la topologie de la réplication.
Au cours des étapes précédentes, nous avons abordé la création de groupes de sécurité qui se mappent sur des rôles organisationnels définis. Cela signifie que pour chaque rôle, il existe un groupe de sécurité associé par structure de sous-UO. Pour implémenter le modèle de délégation, ces groupes doivent se voir attribuer des autorisations sur les objets de l'annuaire. À ce stade du processus, vous ne voulez pas réinventer la roue et créer un environnement extrêmement personnalisé. Essayez plutôt d'exploiter des groupes et des droits prédéfinis lorsque cela est possible. Disons qu'un rôle particulier doit gérer les enregistrements DNS pour la forêt. N'essayez pas de déléguer des droits sur les conteneurs et contextes d'attribution de noms apparentés au DNS intégré à Active Directory. Contentez-vous plutôt d'exploiter le groupe BUILTIN\lDNS Admins du domaine. En outre, les droits d'utilisateur et les autres autorisations peuvent être étendus via la stratégie de groupe pour fournir les droits supplémentaires requis pour gérer une classe spécifique de système en fonction d'un rôle donné.
Si vous attribuez des autorisations en utilisant la délégation, vous devez limiter voire complètement éliminer l'utilisation d'entrées de contrôle d'accès Refuser dans l'annuaire. Celles-ci peuvent se révéler complexes quand il s'agit de les dépanner. Une meilleure approche consiste à utiliser des ACE autorisées explicites pour accorder des droits aux groupes personnalisés représentant vos rôles. Rappelez-vous que les rôles définis par l'utilisateur, tels que les Administrateurs de niveau 4, ne disposeront que des droits explicites définis par ce rôle.
L'héritage est essentiel à la sécurité d'Active Directory et définit la façon dont une LCA particulière s'applique aux objets présents dans un conteneur ou sous-conteneur donné. Soyez toujours spécifique sur l'étendue de l'héritage en vous assurant que les ACE héréditaires sont appliquées aussi près des objets cibles que possible. Les autorisations de refus pouvant être héritées appliquées à l'objet parent précéderont toute autorisation de refus pouvant être héritée appliquée à l'objet grand-parent, ce qui constitue l'une des principales raisons pour lesquelles les entrées de contrôle d'accès Refuser ne sont pas recommandées pour la délégation pratique. De plus, les autorisations pouvant être héritées ne peuvent pas remplacer une ACE explicite sur un objet. C'est pourquoi il est conseillé de limiter ou de supprimer la capacité des administrateurs de niveau à modifier la liste de contrôle d'accès discrétionnaire (en supprimant le privilège de DACL d'écriture) sur les objets d'annuaire. (Notez que le créateur de l'objet dispose implicitement de ces droits). La règle de base est que si un administrateur a la capacité de modifier le DACL sur un objet, il le fera probablement. Ne laissez pas se perdre tout le travail fourni par votre organisation pour créer son modèle de délégation en introduisant des choix et des erreurs potentielles d'administration.
Il existe plusieurs outils dont vous devrez apprendre à vous servir convenablement pour implémenter un modèle de délégation Active Directory. Pour la plupart des grandes organisations, l'utilisation de l'Assistant Délégation intégré pour attribuer des autorisations dans l'annuaire représente une tâche imposante comportant de nombreuses possibilités d'erreurs d'administration. Il vaut plutôt mieux toujours recourir à l'automatisation pour s'assurer que le modèle de délégation est bien documenté, qu'il peut être pris en charge et qu'il offre une option de récupération au cas où les paramètres seraient perdus ou modifiés par inadvertance.
Le principal outil requis pour implémenter la délégation est DSACLS.EXE, un outil de ligne de commande utilisé pour manipuler les ACL de service d'annuaire sur les objets. Cet outil permet également de spécifier les indicateurs d'héritage d'un DACL sur l'objet parent. (Les indicateurs d'héritage incluent cet objet et ses sous-objets, les sous-objets uniquement et propagent les autorisations pouvant être héritées sur un niveau seulement). Les commandes DSACLS échoueront au final si un indicateur d'héritage est déterminé de façon incorrecte. Il est essentiel de procéder à des tests lorsque l'on utilise cet outil. Voici un exemple de syntaxe DSACLS pour déléguer la capacité de créer des objets Ordinateur dans l'UO de démonstration cible :
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
Le DSACLS est sensible à la casse en ce qui concerne les types d'objets. Cela signifie que si vous tentez de déléguer des autorisations pour la classe d'objet « cn = Ordinateur » la classe d'objet sur « cn = ordinateur » ne fonctionnera pas (voir la figure 3).
Figure 3 Erreurs due au non respect de la casse
Figure 3 Erreurs due au non respect de la casse (Cliquer sur l'image pour la réduire)
Figure 3 Erreurs due au non respect de la casse
Figure 3 Erreurs due au non respect de la casse (Cliquer sur l'image pour l'agrandir)
Un jeu de droits spécifique est requis pour la création de certains objets. Ceci est causé par les attributs « doit contenir » et « peut contenir » sur les objets. La meilleure métaphore que j'ai entendue pour expliquer ce concept est le modèle du hamburger. Les hamburgers doivent contenir un steak haché et un petit pain pour être considérés comme des hamburgers. Ils s'agit là des attributs « doit contenir » de la classe d'objet Hamburger. Les éléments tels que les condiments, le ketchup, la laitue et autres correspondent aux attributs « peut contenir ». Si nous voulions étendre la classe d'objet afin de définir un cheeseburger, nous ajouterions du fromage à la liste des attributs « doit contenir ».
Les objets utilisateurs fonctionnent de la même façon. Supposons que nous voulions suivre ce modèle pour créer des objets utilisateurs utilisant la syntaxe DSACLS suivante :
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
L'administrateur serait confronté à plusieurs erreurs pendant la création de l'objet utilisateur. Nous devons accorder les privilèges nécessaires pour définir les attributs requis sur l'objet utilisateur, y compris la définition du mot de passe. Ceci est illustré dans la syntaxe DSACLS supplémentaire suivante.
Pour la première étape, accordez le privilège d'écrire des attributs « doit contenir » en accordant les autorisations Lecture générique/Écriture générique à tous attributs de la classe d'utilisateur :
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Pour l'étape suivante, accordez l'autorisation étendue de modifier le mot de passe :
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Pour l'étape finale, accordez l'autorisation Propriété de lecture et Propriété d'écriture pour l'attribut Dernier changement de mot de passe :
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Une fois que les autorisations correctes auront été déléguées, les rôles définis seront limités à la seule gestion des classes d'objets définies dans le DACL du conteneur. Revenons à l'exemple d'objet Ordinateur précédent. Le menu contextuel dans Utilisateur et Ordinateurs d'Active Directory limite la liste de nouveaux objets qui peuvent être créés par l'utilisateur auquel ces droits sont délégués (voir la liste limitée dans la figure 4).
Figure 4 Liste de nouveaux objets restreinte
Figure 4 Liste de nouveaux objets restreinte
Le DSACLS peut également être automatisé pour permettre un déploiement complexe des droits. Voici certaines des commandes DSACLS qui peuvent être utilisées pour déléguer les droits permettant de manipuler des attributs d'adresse communs par-dessus les objets d'utilisateur dans un conteneur donné :
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Les exemples de ce type sont courants pour la plupart de modèles de délégation et peuvent être utilisés avec les rôles précédemment définis.
Un autre outil utilisé pour implémenter la délégation est DSREVOKE.EXE, qui autorise les administrateurs à localiser et à supprimer les droits délégués pour des entités de sécurité spécifiques sur les objets de l'annuaire. Bien que cet outil puisse être très utile, il est spécifique aux entités de sécurité et n'évalue pas l'appartenance imbriquée dans les groupes de sécurité.
Outre ces outils de ligne de commande, nous vous recommandons aussi d'utiliser l'Attribution de droits d'utilisateur et les Groupes restreints avec la stratégie de groupe. Comme nous l'avons vu précédemment, l'attribution de droits d'utilisateur permet aux administrateurs informatiques d'étendre ou de supprimer des droits de bas niveau (tel que le droit à accéder à un système à distance et à le faire redémarrer) pour divers groupes d'utilisateurs sur des systèmes cibles spécifiques. Les groupes restreints peuvent être utilisés pour spécifier et appliquer l'appartenance aux groupes et domaines locaux au sein de la forêt. Ensemble, ces outils vous fournissent tout ce dont vous avez besoin pour automatiser et implémenter un modèle de délégation Active Directory.

Résumé
Bien que la tâche consistant à développer un modèle de délégation Active Directory puisse sembler complexe, la vérité est que des modèles très simples peuvent être appliqués à la plupart des infrastructures informatiques. L'une des étapes les plus importantes du déploiement d'un modèle de délégation pratique consiste à définir des rôles clairs. Vous devez veiller à ce que le nombre de rôles définis demeure assez limité et facile à gérer. Trouver le juste équilibre n'est pas aisé : si vous avez trop de rôles, certains ne seront pas utilisés alors que si vous n'en créez pas assez, vous ne pourrez pas séparer les rôles.
Souvenez-vous, lorsque vous définissez des tâches, qu'il faut les classer par fréquence, importance et difficulté. Une fois vous aurez défini ces rôles, développez une série de cas d'usage qui vous aideront à identifier ce que chaque rôle peut ou ne peut pas faire et à automatiser le processus de test. Ces cas d'usage bien préparés vous aideront à expliquer ces rôles aux parties prenantes dans votre organisation et limiteront les surprises dues aux erreurs d'automatisation.
Enfin, il est toujours judicieux d'adopter une approche pratique lorsque l'on développe un modèle de délégation. Rappelez-vous que simplicité est synonyme de prise en charge et qu'un modèle de délégation viable se rentabilisera de lui-même en contrôlant les droits administratifs au sein de votre environnement Active Directory.
Ressources supplémentaires
  • Considérations relatives à la conception d'une délégation d'administration dans Active Directory
  • Best Practices for Delegating Active Directory Administration (en anglais)

Joel Yoker est consultant senior dans l'équipe Microsoft Federal. Joel et Robe s'emploient tous deux à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.
Rob Campbell est spécialiste technique senior dans l'équipe Microsoft Federal. Joel et Robe s'emploient tous deux à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.


 Administration de Windows: Plong&#233;e dans les nouveaux mod&#232;les de strat&#233;gie de groupe de Windows&#160;Vista
Administration de Windows Darren Mar-Elia

Plongée dans les nouveaux modèles de stratégie de groupe de Windows Vista
Vue d'ensemble:
  • Au cœur d'ADMX
  • Modification de fichiers ADMX
  • Différence entre les fichiers ADM et les fichiers ADMX
  • Création d'un magasin central

Avant Windows Vista, les valeurs de registre que vous pouviez déterminer dans la stratégie de groupe étaient gérées par des fichiers ADM, dont la syntaxe était obscure et propriétaire. Si vous souhaitiez contrôler des valeurs de registre supplémentaires en plus de celles fournies par Microsoft avec les fichiers ADM standard, vous deviez apprendre cette
syntaxe et créer un fichier ADM personnalisé. De plus, ces fichiers ADM étaient enregistrés avec chaque objet de stratégie de groupe (GPO) dans l'environnement Active Directory® et chacun de ces GPO accompagné de ses fichiers ADM était répliqué sur tous les contrôleurs de domaine du domaine.
Avec le lancement de Windows Vista™, Microsoft franchit une étape décisive dans le domaine des modèles de registre basés sur les stratégies de groupe. Windows Vista introduit des modifications majeure au niveau du format du fichier ADM, désormais dénommé ADMX et dans la façon dont ces fichiers sont enregistrés. Dans cet article, j'examinerai le nouveau format ADMX et expliquerai en quoi ces fichiers sont différents d'ADM. J'étudierai également comment l'enregistrement de ces fichiers est géré dans un environnement Windows Vista.

Différences d'ADMX
La plus grande différence entre le nouveau format de fichier ADMX et le vieux format ADM qui existe depuis Windows NT® 4.0 réside dans le fait qu'ADMX a adopté la norme XML pour décrire les paramètres de stratégie de registre. Ce changement est positif pour plusieurs raisons. La première est qu'il existe bien plus d'outils permettant de modifier le XML que pour la syntaxe ADM. La seconde est que, parce que le XML est schématisé, il sera plus facile à terme de générer des outils qui vous aideront à déterminer quelles balises mettre au bon endroit afin de créer un fichier ADMX correct. Le terme « schématisé » signifie que, pour une application donnée du XML telle que le format ADMX, il existe un schéma documenté qui décrit les éléments et les attributs qui sont autorisés et la façon dont ils sont organisés. Nous en étudierons un exemple plus loin dans l'article.
L'autre différence clé entre ADMX et ADM est la séparation de la section de chaînes du fichier ADMX principal, que l'on retrouve dans un fichier ADML propre à la langue. Si vous connaissez les fichiers ADM, vous savez qu'il existe à la fin de chaque fichier une section délimitée avec une balise « [strings] » où vous pouvez attribuer des valeurs aux chaînes de texte que vous voulez afficher lorsque vous utilisez l'éditeur de stratégie de groupe et les modèles d'administration. Par exemple, le texte que vous avez vu en cliquant sur l'onglet Explain (expliquer) d'une stratégie donnée a été enregistré dans cette section de chaînes. Le problème de cette méthode est que, les chaînes ayant été enregistrées dans le fichier ADM, pour utiliser ce fichier ADM dans un système Windows® fonctionnant avec une langue différente, il fallait créer un nouveau fichier ADM avec une section de chaînes pour cette langue.
Cela devenait encore plus compliqué si quelqu'un utilisant, par exemple, la version française de Windows, souhaitait modifier un GPO existant ayant utilisé des ADM anglais. L'administrateur français ne voyait que de l'anglais dans l'éditeur de stratégie de groupe. Windows Vista contourne ce problème en séparant la section [strings] dans un fichier de langue ADM basé sur le XML (XML-based ADM Language ou ADML). Le fichier ADML peut être fourni dans n'importe quelle langue prise en charge et peut être facilement modifié pour prendre en charge une nouvelle langue sans avoir à toucher au fichier ADMX principal qui enregistre les stratégies. Plus important encore, lorsque cet administrateur français modifie un GPO à partir de son poste de travail Windows Vista, l'éditeur de stratégie de groupe détecte que la version française de Windows est utilisée et charge automatiquement les fichiers ADML français pour ce GPO.
Vous pouvez voir tous les fichiers ADMX et ADML fournis avec votre installation de Windows Vista en ouvrant le dossier c:\windows\policydefinitions (voir la figure 1).
Figure 1 Fichiers ADMX dans Windows Vista
Figure 1 Fichiers ADMX dans Windows Vista (Cliquer sur l'image pour la réduire)
Figure 1 Fichiers ADMX dans Windows Vista
Figure 1 Fichiers ADMX dans Windows Vista (Cliquer sur l'image pour l'agrandir)
Notez qu'en haut de la liste de fichiers de la figure 1 figure un dossier appelé en-us. Il s'agit du dossier propre à la langue qui contient les fichiers ADML pour les fichiers ADMX que vous voyez dans ce dossier PolicyDefinitions, en l'occurrence l'anglais américain. Il existe un fichier ADML pour chaque ADMX. Au moment de la rédaction de cet article, Windows Vista contient 132 fichiers ADMX/ADML par défaut. Il s'agit d'une autre grande différence entre Windows Vista et les versions précédentes : les GPO créés sous Windows XP contenaient en principe cinq fichiers ADM, le plus gros étant System.adm, qui contenait les éléments de stratégie pour la plupart des composants Windows contrôlés par les stratégies. Dans Windows Vista, Microsoft a décidé de classer les fichiers ADMX par fonction, ce qui explique leur nombre important. Chaque fichier ADMX gère en général un seul composant de Windows (comme le Panneau de configuration, le Client DNS, l'explorateur Windows et ainsi de suite).

Au cœur de l'ADMX
Le fait que les fichiers ADMX soient écrits en XML constitue une amélioration majeure, comme je l'ai fait remarquer précédemment. Cependant, de nombreux administrateurs ne savent pas écrire le XML, sans parler de comprendre le schéma utilisé par ADMX pour créer des extensions de stratégie. Bien qu'un cours sur la création d'ADMX personnalisés ne soit pas le sujet de cet article, examinons un instant la formation des fichiers ADMX.
Vous pouvez ouvrir un fichier ADMX ou ADML dans n'importe quel éditeur de texte, même le Bloc-notes, mais à moins que votre éditeur ne comprenne la syntaxe XML, il peut ne pas avoir beaucoup de sens. J'utilise Visual Studio® parce que sa fonction IntelliSense® permet de finaliser des éléments particuliers. La figure 2 reproduit les premières lignes de l'un des fichiers ADMX fournis avec Windows Vista.
Figure 2 Un peu de XML dans un fichier ADMX (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
Ceci peut paraître étrange si vous n'êtes pas familier avec le XML, mais un grand nombre de ces éléments XML se retrouvent dans n'importe quel fichier ADMX. L'élément policyNamespaces, par exemple, identifie ce fichier ADMX de façon unique dans l'univers des fichiers ADMX.
Si vous avez créé des fichiers ADM personnalisés dans des versions précédentes de Windows, vous savez qu'il existait une série de balises telles que Category, Policy, ListBox et ActionList qui servaient à définir les paramètres de stratégie devant apparaître dans l'éditeur de stratégie de groupe. Nombre de ces balises n'ont pas changé, ou seulement très peu, dans le format ADMX mais elles paraissent très différentes parce qu'elles sont représentées comme du XML. Par exemple, j'avais écrit un fichier ADM personnalisé permettant d'activer divers types de journalisation dans Windows pour le dépannage des stratégies de groupe. Une section de cet ADM personnalisé est présentée à la figure 3. J'ai converti ce fichier au nouveau format ADMX, présenté à la figure 4.
Figure 4 Un fichier ADM converti en fichier ADMX (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Un fichier ADM personnalisé (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
À bien des égards, cet extrait ADMX est beaucoup plus simple à comprendre que son cousin ADM, car il est plus concis. L'élément de stratégie spécifie ce que fait cette stratégie (journalisation de la redirection de dossiers). Les attributs préfixé avec $(string. sont des références à l'élément de chaîne ADML correspondant. Les attributs key et valuename, évidemment, précisent la clé de registre et la valeur qui sont affectées par cette stratégie. L'élément parentCategory contrôle l'endroit où cette stratégie apparaît dans la hiérarchie du modèle administratif d'éditeur de stratégie de groupe. L'élément supportedOn indique quelle version du système d'exploitation respecte cette stratégie et, enfin, les éléments enabledvalue et disabledvalue spécifient les valeurs incluses dans le registre lorsque cette stratégie est activée ou désactivée.
Il s'agit d'une stratégie d'activation/désactivation assez simple. Comme dans la syntaxe ADM, il est possible de créer des éléments d'interface utilisateur plus complexes dans l'éditeur de stratégie de groupe. Lorsque vous faites cela dans ADMX, la syntaxe devient plus importante et inclut un attribut de présentation qui référence une partie du fichier ADML où les étiquettes de texte de l'élément de l'interface utilisateur peuvent être recherchées. Hormis cela, la syntaxe ADMX n'est pas très compliquée. Ce dont il faut se souvenir, c'est que certains des noms de balise ont changé entre les fichiers ADM et ADMX. Donc, par exemple, en langage ADM vous aviez des balises « edittext » et « listbox ». En ADMX, ces balises sont référencées comme « text » et « list » dans le fichier ADMX. Ces éléments auront des entrées correspondantes dans le fichier ADML qui précisent le texte apparaissant à côté d'elles.
Comme vous le savez peut-être déjà, un administrateur peut charger un fichier ADM (hérité) personnalisé dans l'éditeur d'objet de stratégie de groupe de Windows Vista. Les gens me demandent souvent si Microsoft fournira un utilitaire pour convertir les fichiers ADM personnalisés vers la syntaxe ADMX. En fait, Microsoft s'est associé avec FullArmor Corp. pour publier un outil gratuit dénommé ADMX Migrator. Cet outil fait deux choses. Tout d'abord, il convertit vos vieux fichiers ADM personnalisés au format ADMX (voir à la figure 5 un exemple d'utilisation de l'outil pour convertir my custom gpolog.adm).
Figure 5 ADMX Migrator
Figure 5 ADMX Migrator (Cliquer sur l'image pour la réduire)
Figure 5 ADMX Migrator
Figure 5 ADMX Migrator (Cliquer sur l'image pour l'agrandir)
Ensuite, il fournit un éditeur ADMX qui vous permet de créer de nouveaux fichiers ADMX. Vous pouvez télécharger cet outil à l'adresse go.microsoft.com/fwlink/?LinkID=77409.

Stockage ADMX
L'autre modification notable que je veux aborder est la façon dont les fichiers ADMX et ADML sont enregistrés. Dans les versions de Windows précédant Windows Vista, lors de la modification d'un nouveau GPO, les fichiers ADM étaient automatiquement copiés du poste de travail local sur lequel vous faisiez vos modifications à la partie SYSVOL du GPO sur un contrôleur de domaine se trouvant dans votre domaine Active Directory. Ces ADM étaient ensuite répliqués sur chaque contrôleur du domaine pour chaque GPO créé. Ceci consommait beaucoup de bande passante du réseau et d'espace disque surtout dans des grands environnements ayant des douzaines ou des centaines de GPO. Windows Vista renverse ce processus. Par défaut, lorsque vous créez un GPO basé sur Active Directory à partir d'un poste de travail Windows Vista, les stratégies de modèle administratif qui apparaissent dans l'éditeur de stratégie de groupe sont chargées à partir du dossier c:\windows\policydefinitions de l'ordinateur sur lequel vous modifiez le GPO.
Les fichiers ADMX et ADML ne sont pas copiés sur SYSVOL mais sont uniquement référencés localement. Ceci élimine la charge sur le stockage et le réseau qu'ADM faisait porter à l'environnement de stratégie de groupe. Mais ce n'est pas tout. Windows Vista prend également en charge un magasin central, un référentiel pour les modèles d'administration. Ceci résout le problème du contrôle efficace des fichiers ADMX utilisés pour modifier les GPO, quelle que soit la personne qui les modifie. Il suffit de copier tous les fichiers officiels ADMX et ADML (et tous les fichiers personnalisés que vous avez créés) sur un emplacement du réseau. Par la suite, toute modification de stratégie de groupe effectuée à partir d'un poste de travail Windows Vista référence ces versions du réseau plutôt que chaque version locale. La création d'un magasin central est une tâche aisée qui ne doit être effectuée qu'une seule fois par domaine. Il suffit de suivre les étapes du volet « Creating a Central Store » (Création d'un magasin central).

Résumé
Le nouveau format ADMX de Windows Vista constitue une amélioration évidente par rapport aux fichiers ADM utilisés avec les versions de système d'exploitation précédentes. L'usage du XML fournit une infrastructure plus nette pour modifier et rechercher ces fichiers. Le déplacement de chaînes spécifiques à la langue dans des fichiers séparés rend la modification multilingue des stratégies de groupe plus cohérente et le magasin central élimine la nécessiter d'enregistrer et de mettre à jour tous vos GPO avec des copies des fichiers ADM. Tout ceci démontre l'utilité de la connaissance d'ADMX.
Création d'un magasin central
La création du magasin central est relativement simple. Suivez ces étapes pour en créer un dans votre domaine Active Directory :
Étape 1 Ouvrez l'explorateur et naviguez jusqu'à la partie SYSVOL du contrôleur de domaine de l'émulateur du contrôleur de domaine principal de votre environnement (vous pouvez utiliser n'importe quel contrôleur de domaine mais le propriétaire du rôle du contrôleur de domaine principal se trouve d'habitude là où les modifications de stratégie de groupe sont concentrées).
Étape 2 Développez le dossier des stratégies sous SYSVOL et créez un nouveau dossier que vous appellerez PolicyDefinitions.
Étape 3 Copiez le contenu du dossier C:\windows\policydefinitions de votre poste de travail Windows Vista dans le nouveau dossier PolicyDefinitions, y compris le dossier ADML propre à la langue (par exemple, en-us sur les ordinateurs en anglais américain).
Lorsque les fichiers ADMX et ADML ont été copiés dans le dossier du magasin central, l'éditeur d'objet de stratégie de groupe de Windows Vista commence à y référencer les fichiers et ignore ceux qui sont enregistrés en local !

Darren Mar-Elia est MVP de Microsoft Group Policy, créateur du célèbre site sur la stratégie de groupe, www.gpoguy.com et coauteur de Microsoft Windows Group Policy Guide (Guide de stratégie de groupe Microsoft Windows) (en anglais) (Microsoft Press, 2005) Il est également Directeur technique et fondateur de SDM Software, Inc. Contactez-le à Darren@gpoguy.com.


 Administration de Windows: Votre guide de d&#233;pannage de la strat&#233;gie de groupe
Administration de Windows Derek Melber

Votre guide de dépannage de la stratégie de groupe
Vue d'ensemble:
  • Problèmes courants liés aux objets de stratégie de groupe
  • Règles de stratégie de groupe
  • Dépannage des problèmes liés aux objets de stratégie de groupe
  • Outils de dépannage

Microsoft Active Directory est devenu un composant critique de nombreuses infrastructures informatiques. L'une des fonctions les plus importantes d'Active Directory est la stratégie de groupe, qui permet aux administrateurs de centraliser la gestion des contrôleurs de domaine, des serveurs membres et des postes de travail.
Bien que la stratégie de groupe offre de nombreux avantages, elle présente un petit problème. Elle peut être complexe à concevoir et à implémenter dans une grande entreprise et encore plus problématique à dépanner lorsque quelque chose se dérègle. Dans cet article, j'étudierai la structure de la stratégie de groupe et vous expliquerai comment la dépanner. Au terme de cet article, vous disposerez de toutes les armes nécessaires pour résoudre pratiquement tous les problèmes de stratégie de groupe.

Paramètres posant problème
La stratégie de groupe comporte un grand nombre d'éléments mobiles, surtout en ce qui concerne la façon dont elle s’interface avec la conception globale et la mise en œuvre d'Active Directory®. Lorsque vous tentez de résoudre des problèmes d'accès et de réseau, vous devez toujours inclure Active Directory et les bases de l'implémentation de la stratégie de groupe dans votre recherche de solution. Pour commencer le processus de dépannage, examinons les paramètres de la stratégie de groupe pouvant être mal configurés puis passons aux problèmes plus complexes susceptibles de causer un dysfonctionnement de la stratégie de groupe.
Les paramètres de stratégie de groupe sont vus par les administrateurs d'Active Directory qui utilisent des fichiers de modèle d'administration (fichiers ADM ou ADMX) et l'éditeur d'objet de stratégie de groupe ou GPEdit (lancé en exécutant gpedit.msc). À l'aide de GPEdit, l'administrateur crée les fichiers d'objet de stratégie de groupe (GPO). Les GPO sont configurés pour s'appliquer (ou ne pas s'appliquer) aux ordinateurs et aux utilisateurs de la structure de Active Directory. Ils doivent suivre un certain nombre de règles afin de fonctionner correctement. Examinons-les dès à présent.
Le GPO doit être lié Lorsqu'un nouveau GPO est créé, il peut n'être lié à aucun nœud au sein d'Active Directory. Bien que le GPO puisse être modifié, il n'affectera aucun objet tant qu'il n'est pas lié à un nœud. Pour s'assurer que le GPO est correctement lié, vous pouvez afficher la fenêtre d'information dans la Console de gestion des stratégies de groupe (GPMC) illustrée à la figure 1.
Figure 1 Les liens aux objets de stratégie de groupe sont clairement visibles
Figure 1 Les liens aux objets de stratégie de groupe sont clairement visibles (Cliquer sur l'image pour la réduire)
Figure 1 Les liens aux objets de stratégie de groupe sont clairement visibles
Figure 1 Les liens aux objets de stratégie de groupe sont clairement visibles (Cliquer sur l'image pour l'agrandir)
Le GPO doit cibler le bon objet Comme vous le savez, la stratégie de groupe doit cibler les bons objets dans Active Directory. Cependant, cet aspect est parfois négligé au cours des opérations de dépannage. Il existe deux catégories principales d'GPO : ordinateur et utilisateur. Lorsque vous configurez un GPO, prenez soin de noter s'il concerne objet ordinateur ou un objet utilisateur. Vous pourrez ensuite vérifier que les types d'objet corrects sont placés dans l'Unité d'organisation (l'UO) à laquelle l'GPO est lié.
Les GPO ne s'appliquent pas aux groupes Cela est peut-être regrettable, mais un GPO ne peut pas s'appliquer à un objet de sécurité de groupe Active Directory. Les deux seuls types d'objet pouvant être configurés par un paramètre GPO sont les ordinateurs et les utilisateurs. Les GPO ne peuvent pas configurer un objet via une appartenance à un groupe. Par exemple, si un GPO est lié à l'UO Finance, tel qu'illustré à la figure 2, les seuls objets qui seront affectés par le paramètre sont Derek et Frank. Les paramètres du GPO n'affecteront pas les membres du groupe Commercialisation, quels que soient les membres de ce groupe.
Figure 2 L'UO Finance et les objets qu'elle contient
Figure 2 L'UO Finance et les objets qu'elle contient (Cliquer sur l'image pour la réduire)
Figure 2 L'UO Finance et les objets qu'elle contient
Figure 2 L'UO Finance et les objets qu'elle contient (Cliquer sur l'image pour l'agrandir)
L'objet ciblé doit être sur le chemin du GPO Si vous remarquez qu'un paramètre de GPO n'affecte pas un objet comme il le devrait, cela signifie qu'il existe un paramètre plus important : l'objet doit être dans l'étendue de la gestion (SOM) du GPO. Cela signifie que l'objet doit se trouver sous le nœud auquel le GPO est lié (même un nœud enfant sera suffisant). Par exemple, aucun des objets de l'UO Commercialisation ne sera affecté par un GPO qui est lié à l'UO Finance, comme illustré à la figure 3. Le SOM d'un GPO provient du nœud auquel il est lié, à travers la structure d'Active Directory.
Figure 3 Lorsque les UO sont au même niveau, les GPO ne s'appliquent qu'à l'UO à laquelle ils sont liés.
Figure 3 Lorsque les UO sont au même niveau, les GPO ne s'appliquent qu'à l'UO à laquelle ils sont liés. (Cliquer sur l'image pour la réduire)
Figure 3 Lorsque les UO sont au même niveau, les GPO ne s'appliquent qu'à l'UO à laquelle ils sont liés.
Figure 3 Lorsque les UO sont au même niveau, les GPO ne s'appliquent qu'à l'UO à laquelle ils sont liés. (Cliquer sur l'image pour l'agrandir)
Le GPO doit être activé Lorsqu'un GPO est créé, il n'est pas configuré pour effectuer des modifications sur les objets ciblés. Cependant, il est activé pour les parties ordinateur et utilisateur. Si l'une ou l'autre de ces parties est désactivée, il peut être difficile de le repérer. Donc, lorsque vous dépannez un GPO qui ne s'applique pas, il est judicieux de vérifier si tout ou partie du GPO est désactivée. Pour ce faire, regardez sous Objets de stratégie de groupe | Stratégie de Compte et vérifiez le statut du GPO.
Certains paramètres nécessitent un redémarrage Lorsqu'un paramètre de GPO ne fonctionne pas correctement, cela peut être dû au traitement inhérent des GPO. Lorsque l'actualisation périodique du GPO est déclenchée, elle peut traiter certains des paramètres du GPO, mais pas tous. Aussi, même si vous avez créé un paramètre, il n'est peut-être pas encore effectif. Certains paramètres sont classés comme stratégies de premier plan et ils ne sont appliqués que lorsque l'ordinateur est redémarré ou que l'utilisateur ferme une session puis en ouvre une autre. Il s'agit par exemple des paramètres d'installation de logiciel, de redirection de dossiers et d'application de scripts.

Application de paramètres synchrone et asynchrone
Au sein d'un GPO, vous pouvez configurer comment l'application de stratégie se comporte au moment du démarrage et à l'ouverture de session. Les modifications que vous pouvez apporter pourront fournir un accès immédiat au bureau alors que les stratégies s'appliquent encore, ou il sera vérifié que toutes les stratégies s'appliquent avant que l'utilisateur n'ait accès au bureau. La figure 4 illustre le comportement par défaut de chaque système d'exploitation. Si vous voulez modifier ce comportement, vous pouvez modifier le paramètre de stratégie suivant :
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Traitement par défaut du client (Close Figure 4)

Système d'exploitation | Démarrage | Ouverture de session | Actualisation des stratégies
Windows 2000 | De façon synchrone | De façon synchrone | De façon asynchrone
Windows XP Professionnel | De façon asynchrone | De façon asynchrone | De façon asynchrone
Windows Server 2003 | De façon synchrone | De façon synchrone | De façon asynchrone
La plupart des administrateurs préfèrent avoir une application synchrone de stratégie, pour garantir que toutes les stratégies s'appliquent avant que l'utilisateur ne puisse accéder au bureau. Ceci garantit que tous les paramètres de sécurité et de configuration seront appliqués avant que l'utilisateur ne puisse effectuer le moindre travail. Notez qu'il ne s'agit pas ici de l'état par défaut dans Windows® XP Professionnel, qui a été optimisé pour une vitesse d'ouverture de session accrue.

Modification de l'héritage par défaut
Il existe quatre méthodes différentes permettant de modifier l'héritage par défaut du traitement d'un GPO. Ces options sont puissantes et doivent être utilisées avec précaution car elles peuvent provoquer des changements significatifs du comportement du traitement de la stratégie de groupe. Elles peuvent aussi être très difficiles à dépanner. Les options de modification de l'héritage par défaut incluent les quatre paramètres et configurations suivants :
  • blocage de l'héritage de stratégies
  • application du GPO
  • filtrage par le GPO de la liste de contrôle d'accès (LCA)
  • Filtres WMI (Windows Management Instrumentation)
Ces paramètres devant être utilisés avec modération, il ne devrait pas être difficile de documenter leurs conditions d'utilisation. Pour savoir si ces options sont utilisées, consultez GPMC. Le blocage d'héritage est effectué sur le nœud du domaine ou de l'unité d'organisation (l'UO) dans GPMC. L'application du GPO, le filtrage de la LCA et le filtrage WMI sont définis sur chaque GPO.
Vous pouvez également exécuter la commande Gpresult à partir de l'ordinateur cible pour savoir si l'un de ces paramètres empêche les stratégies de s'appliquer. Pour obtenir une vue plus approfondie du jeu de stratégies appliquées résultant, vous pouvez ajouter le commutateur /v à la commande Gpresult, afin d'obtenir le résultat en clair.

Problèmes de modèle ADM
Lorsque vous tentez de configurer des paramètres dans un GPO situé sous Modèles d'administration, vous travaillez avec des modèles ADM. Outre les modèles ADM fournis avec le système d'exploitation, vous pouvez personnaliser le vôtre pour l'utiliser dans un GPO. Le code du modèle ADM crée les dossiers et les stratégies dans l'éditeur de stratégie de groupe sous le nœud des Modèles d'administration. Cependant, si le modèle ADM est corrompu ou mal configuré, il est tout à fait possible que vous ne puissiez pas voir certains ou tous les paramètres de l'éditeur. Voici quelques autres problèmes dont il convient de se méfier lors de l'utilisation des modèles ADM.
Modèles ADM manquants Lorsque vous modifiez un GPO et constatez qu'il existe des paramètres dans un modèle ADM personnalisé qui ne sont pas visibles dans l'éditeur, vous devez importer le modèle ADM dans le GPO. Pour ce faire, il vous suffit de cliquer avec le bouton droit de la souris sur le nœud des Modèles d'administration dans l'éditeur et de sélectionner Ajout/Suppression de modèles.
Préférences manquantes Il existe deux types de paramètres pouvant être créés dans un GPO personnalisé : Préférences et Stratégies. Les stratégies sont des paramètres par défaut de Microsoft qui appartiennent tous à une des quatre sous-clés du registre, chacune se terminant par le mot « Policies ». Les préférences sont des modifications de registre « à l'ancienne » qui ne relèvent pas d'une des quatre sous-clés et qui sont difficiles à inverser une fois configurées. Ces préférences ne sont pas visibles dans l'éditeur par défaut. Vous devez les activer pour qu'elles soient visibles, ce qui est possible via le menu Affichage de la barre d'outils. À partir de ce menu, sélectionnez Filtrage, puis cochez la case « Afficher uniquement les paramètres de stratégie pouvant être entièrement gérés ». Ceci affichera immédiatement les préférences configurées dans les modèles ADM personnalisés qui ont été importés.

Outils pratiques
Il existe une multitude d'outils disponibles destinés à vous aider à dépister vos problèmes de stratégie de groupe. Certains d'entre eux sont intégrés dans le système d'exploitation et d'autres peuvent être téléchargés et installés. J'aborderai ensuite les outils appropriés afin que vous puissiez choisir celui qui conviendra à votre tâche.
Dcgpofix Il arriver que vous l'un des deux GPO par défaut vous pose problème : Stratégie de domaine par défaut et Stratégie des contrôleurs de domaine par défaut. Si l'un des GPO (ou les deux) est corrompu à un niveau trop profond de la configuration où vous ne pouvez pas le réparer, ou si vous rencontrez un autre problème inconnu, vous pouvez utiliser l'outil dcgpofix pour ramener les GPO à l'état par défaut. Cet outil est inclus dans Windows Server® 2003.Vous ne devez pas l'exécuter sur un contrôleur de domaine Windows 2000 ; utilisez plutôt Recreatedefpol dans ce cas. Souvenez-vous, lorsque vous utilisez cet outil, vous perdez tous vos paramètres personnalisés.
Recreatedefpol Cet outil est similaire à Dcgpofix, mais réservé aux serveurs Windows 2000. Il peut remettre les deux GPO par défaut à leur état initial. Cet outil doit être seulement utilisé dans une situation de reprise après sinistre et non pour la maintenance de routine des GPO. Vous pouvez télécharger cet outil.
Observateur d'événements L'observateur d'événements contient de nombreuses d'informations concernant la stratégie de groupe. Malheureusement, il est nécessaire de consulter tous les fichiers journaux pour trouver des entrées pour la stratégie de groupe. Vous y trouverez des entrées se rapportant à l'application des stratégies, à la réplication des stratégies et à l'actualisation des stratégies, toutes informations pouvant être utiles lors du dépistage d'un problème. Les journaux d'événements ne contiennent pas toujours beaucoup d'informations sur les erreurs de stratégie de groupe spécifiques, mais souvenez-vous que vous pouvez toujours effectuer des recherches dans Technet si vous trouvez des erreurs que vous ne pouvez pas identifier.
Gpresult Cet outil peut uniquement être exécuté localement sur l'ordinateur cible, mais il fournit des informations sur le jeu de stratégies résultant, les GPO bloqués, les autorisations relatives aux GPO et bien plus encore. L'utilisation de la commande avec le commutateur /v permet d'afficher un grand nombre d'informations sur les GPO qui affectent l'ordinateur et sur les comptes utilisateur relatifs à l'ouverture de session actuelle.
Gpupdate Si vous implémentez de nouveaux paramètres de GPO ou que vous essayez de vérifier que tout le traitement des GPO a été effectué, vous pouvez utiliser l'outil Gpupdate. Il s'agit d'un outil de ligne de commande fourni avec le système d'exploitation (Windows XP et versions supérieures). Lorsqu'il est exécuté, il déclenche une actualisation en arrière-plan qui applique tous les paramètres du GPO qui obéissent à ce type d'actualisation. Si vous ajoutez le commutateur /force, il applique à nouveau tous les paramètres du GPO, même s'il n'y a pas eu de modification du GPO depuis la dernière actualisation. L'exécution de cette commande préalablement à l'exécution de la commande Gpresult constitue une méthode de dépistage des problèmes de GPO très efficace.
Gpotool Puisque les GPO sont répliqués à partir du contrôleur de domaine d'où les modifications de GPO sont originaires vers tous les autres contrôleurs de domaine, il existe un risque que la réplication échoue ou ne converge pas efficacement. Un échec de la réplication peut se traduire par un manque de cohérence ou une application incorrecte des modifications sur les ordinateurs cibles. Les outils tels que Gpresult et RSOP peuvent vous aider à déterminer ce que les GPO ont appliqué, mais cet outil, Gpotool, peut vous aider à déterminer si les GPO de chaque contrôleur de domaine sont cohérents. L'outil fait partie du Kit de ressources Windows Server 2003 disponible à l'adresse go.microsoft.com/fwlink/?LinkId=77613.
Replmon En dépannant la réplication de GPO d'un contrôleur de domaine à un autre, il est important de savoir quels outils vous pouvez utiliser pour vous aider à faire fonctionner la réplication. Puisqu'un GPO se compose de deux parties qui doivent être répliquées, il y a deux parties qui doivent être traitées. La première, qui représente le contenu de SYSVOL sur chaque contrôleur de domaine, est contrôlée par le service de réplication de fichier (FRS). Il n'y a pas grand-chose que vous puissiez faire pour contrôler cette réplication, hormis désactiver puis réactiver le service pour déclencher un intervalle de réplication. L'autre partie du GPO, qui est enregistrée dans Active Directory, est contrôlée par la réplication d'Active Directory. Cette réplication peut être contrôlée entre les contrôleurs de domaine du même site d'Active Directory à l'aide des sites et services d'Active Directory. Cependant, si vous devez déclencher une réplication entre les contrôleurs de domaine de différents sites d'Active Directory, vous devez utiliser un outil tel que Replmon. Replmon peut forcer la réplication de la base de données d'Active Directory au-delà des limites du site, alors que les sites et services d'Active Directory ne le peuvent pas. Donc, lorsque vous êtes confronté à un problème de cohérence dans les informations de la stratégie de groupe, qui est enregistrée dans Active Directory, vous pouvez utiliser Replmon pour déclencher un processus de réplication afin que ces informations soient envoyées sur chaque contrôleur de domaine. Replmon fait partie du Kit de ressources et des outils de support de Windows XP. Vous pouvez le télécharger à l'adresse go.microsoft.com/fwlink/?LinkId=77614.
RSOP À l'instar de l'outil de ligne de commande Gpresult, RSOP fournit une interface graphique permettant d'examiner les paramètres appliqués par tous les GPO. RSOP.MSC est un outil intégré pour Windows XP Professionnel et Windows Server 2003. Cet outil vous fournit un résultat de tous les paramètres de stratégie appliqués dans un format similaire à celui de l'éditeur d'objets de stratégie de groupe, comme illustré à a figure 5.
Figure 5 Outil Jeu de stratégies résultant
Figure 5 Outil Jeu de stratégies résultant

Conclusion
Le dépannage de la stratégie de groupe n'est pas la tâche la plus simple qui soit. En fait, comme cet article le montre, la stratégie de groupe peut être relativement complexe. Lorsque vous vous y intéressez en vue de résoudre un problème, vous devez comprendre l'architecture fondamentale et le traitement général propres à la stratégie de groupe. Vous devez également comprendre le processus de mise à jour, de réplication, de traitement et d'application des GPO. Si vous avez une bonne maîtrise de tous ces concepts, le dépannage d'un problème de stratégie de groupe précis devient beaucoup plus facile. En suivant les indications de cet article et en utilisant les outils de façon appropriée, vous serez prêt à gérer tous les problèmes de stratégie de groupe que vous pourrez rencontrer.

Derek Melber est Directeur de la filiale Education, Certification, and Compliance Solutions for DesktopStandard, détenue à 100 % par Microsoft. Derek est coauteur de Microsoft Windows Group Policy Guide (Guide de stratégie de groupe pour Microsoft Windows) (en anglais) (Microsoft Press, 2005). Il a également écrit une série de livres sur les audits de la sécurité de Windows (www.theiia.org). Contactez-le à l'adresse derekm@desktopstandard.com.


 Administration de Windows: Surveillance d’Active&#160;Directory avec MOM
Administration de Windows John Hann

Surveillance d’Active Directory avec MOM
Vue d'ensemble:
  • Packs d'administration pour Active Directory
  • Conseils relatifs à la personnalisation pour MOM
  • Réglage des alertes

Les packs d'administration constituent la force vitale de Microsoft Operations Manager (MOM) 2005, et ce qui différencie ce dernier des autres produits d'administration. MOM utilise des packs d'administration pour réunir des règles, des rapports, des tâches et des vues, et peut limiter sa portée à une application
ou à un service spécifique, par exemple, Active Directory. Les équipes de produits Microsoft créent les packs d'administration pour les applications qu’elles développent, garantissant ainsi que MOM reflète la connaissance approfondie des équipes. De plus, vous pouvez personnaliser les packs d'administration pour les adapter à votre environnement informatique. Vous disposez ainsi de règles qui contrôlent et gèrent le produit en fonction de votre serveur et votre de votre environnement d’application.
Outre un pack d'administration spécifique pour Active Directory®, il existe également une myriade de packs d'administration permettant de mesurer le fonctionnement des services d’annuaire, allant du système d’exploitation Windows Server® au protocole DHCP (Dynamic Host Configuration Protocol), au DNS et au service de réplication de fichiers (FRS). Etudions ces packs d'administration en détail pour mieux comprendre l'administration de bout en bout d’Active Directory que permet MOM.

Pack d'administration pour Microsoft Windows DHCP Service
Le pack d'administration pour Microsoft Windows DHCP Service surveille le service DHCP s’exécutant sur Windows NT®, Windows® 2000 et Windows Server 2003. La surveillance du protocole DHCP permet de détecter les éventuelles difficultés de connexion au réseau des clients. Vous serez également averti de la présence de serveurs DHCP non autorisés s’exécutant dans votre environnement. Le package de téléchargement de ce pack d'administration contient un manuel décrivant les règles et les rapports, et qui permet de surveiller les scénarios et le déploiement. Vous trouverez des manuels et des conseils supplémentaires sur le site Web Technet de MOM 2005 (microsoft.com/technet/prodtechnol/mom/mom2005).
Plus la version de Windows que vous exécutez pour le service DHCP est récente, plus le nombre d’outils et de fonctionnalités fournies par MOM 2005 pour l'administration est élevé. Vous obtiendrez ainsi plus d’informations sur un serveur DHCP Windows Server 2003 que sur un serveur DHCP Windows NT. Par exemple, vous pouvez surveiller les étendues globales d’un serveur DHCP s’exécutant sur Windows Server 2003, alors que le pack d'administration pour Microsoft Windows DHCP Service surveille uniquement les étendues standard sur un serveur DHCP Windows 2000. Vous pouvez exclure des étendues de la surveillance en les excluant des paramètres du script de surveillance.
Comme indiqué précédemment, le pack d'administration pour Microsoft Windows DHCP Service prend en charge les serveurs DHCP s’exécutant sous Windows NT, Windows 2000 Server et Windows Server 2003. Les groupes d’ordinateurs sont alimentés par des formules utilisant la version du système d’exploitation, et ils dépendent de l’hébergement du service DHCP par le serveur.
Le pack d'administration pour Microsoft Windows DHCP Service ne prend pas en charge les configurations à privilèges limités. Le compte d’action d'agent doit être un membre du groupe Administrateurs locaux. La surveillance sans agent est prise en charge, mais les tâches ne le sont pas dans une configuration sans agent. La figure 1 répertorie les rapports disponibles dans le pack d'administration Microsoft Windows DHCP Service.
Figure 1 Rapports du service DHCP (Close Figure 1)

Tous les serveurs DHCP
Tous les serveurs DHCP autorisés
Historique des performances - Longueur de la file d’attente active
Historique des performances - Longueur de la file d’attente de vérification des conflits
Historique des performances - Refus par seconde
Historique des performances - Découvertes par seconde
Historique des performances - Millisecondes par paquet (moyenne)
Historique des performances - Messages négatifs avec accusé de réception par seconde
Historique des performances - Adresses sans étendue
Historique des performances - Adresses avec étendue utilisées
Historique des performances - Adresses sans étendue globale
Historique des performances - Adresses avec étendue globale utilisées
Vous pouvez télécharger le pack d'administration pour Microsoft Windows DHCP Service depuis le site Web suivant : go.microsoft.com/fwlink/?LinkId=79527.

Pack d'administration pour Microsoft Windows Domain Name System (DNS)
Le pack d'administration pour Microsoft Windows Domain Name System (DNS)) surveille le service DNS s’exécutant sous Windows 2000 Server et Windows Server 2003. La surveillance de DNS avec MOM 2005 est essentielle, car elle fait partie intégrante de l'état général de l’implémentation d’Active Directory. Le pack d'administration pour Microsoft Windows Domain Name System (DNS) surveille les problèmes de résolution de noms, les problèmes de base de données et de registre, les événements et erreurs d’exécution, ainsi que les compteurs de performances associés.
Pour Windows 2000 Server, vous devez installer un fournisseur de DNS Windows Management Instrumentation (WMI). En particulier, cela permet au pack d'administration pour Microsoft Windows Domain Name System (DNS) d’interroger l’espace de noms DNS WMI pour obtenir des informations et pour les tests.
Les groupes d’ordinateurs sont alimentés grâce à des formules utilisant le système d’exploitation, et ils permettent de définir si le serveur héberge le service DNS Server pour déterminer l’appartenance à un groupe. Le pack d'administration pour Microsoft Windows Domain Name System (DNS) prend en charge les privilèges limités sous Windows Server 2003 uniquement. Sous Windows 2000, le compte d’action doit être membre du groupe Administrateurs locaux. Sous Windows Server 2003, le compte d’action doit être membre des groupes Utilisateurs et Utilisateurs de l’Analyseur de performances locaux. De plus, le compte d’action doit disposer des autorisations Gérer le journal d’audit et de sécurité (SeSecurityPrivilege) et Permettre l'ouverture d'une session locale (SeInteractiveLogonRight). La figure 2 répertorie les rapports disponibles dans le pack d'administration pour Microsoft Windows Domain Name System (DNS).
Figure 2 Rapports du service DNS (Close Figure 2)

Tous les serveurs DNS Windows
Tous les serveurs DNS Windows par zone
Toutes les zones DNS Windows par serveur
Marcus Oh, MVP pour Microsoft® Systems Management Server (SMS), a développé un script qui teste le serveur DNS en appelant nslookup pour vérifier la capacité de résolution des noms du serveur DNS. Prenez le temps de consulter le contenu de son blog sur la page marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html. Vous souhaiterez sans doute intégrer ce script à votre pack d'administration pour Microsoft Windows Domain Name System (DNS).
Vous pouvez télécharger le pack d'administration pour Microsoft Windows Domain Name Service (DNS) depuis la page Web go.microsoft.com/fwlink/?LinkId=79528.

Pack d'administration pour Microsoft Windows File Replication Service (FRS)
Le pack d'administration pour Microsoft Windows File Replication Service (FRS) surveille le service FRS s’exécutant sous Windows 2000 et Windows Server 2003. Les contrôleurs de domaine utilisent FRS pour répliquer les scripts d’ouverture de session et les informations de stratégie de groupe. Le pack d'administration pour Microsoft Windows File Replication Service (FRS) décrit en détail l'état du service FRS pour chaque contrôleur de domaine.
Le pack d'administration pour Microsoft Windows File Replication Service (FRS) utilise l’outil Ultrasound disponible depuis la page Web go.microsoft.com/fwlink/?LinkId=79529. Cet outil permet de créer un espace de noms WMI pour FRS sur chaque contrôleur de domaine. Notez qu’Ultrasound requiert une base de données et enregistre les informations de l’espace de noms WMI sur chaque contrôleur de domaine pour la surveillance du fonctionnement. À l’aide des informations fournies par Ultrasound, le pack d'administration pour Microsoft Windows File Replication Service (FRS) assure la surveillance des ensembles de répliques, des membres, des connexions, du service FRS lui-même, ainsi que du service du contrôleur d’Ultrasound.
En fait, vous devez installer Ultrasound sur un serveur distinct du serveur d'administration. Les règles Ultrasound produisent des événements et des alertes pour le compte d’autres ordinateurs. Afin que les règles Ultrasound puissent traiter les données correctement, vous devez activer le proxy d’agent dans la console d’administration MOM sur chaque serveur exécutant Ultrasound. La figure 3 répertorie les rapports disponibles dans le pack d'administration pour Microsoft Windows File Replication Service (FRS).
Figure 3 Rapports du service FRS (Close Figure 3)

Ultrasound - Problèmes fréquemment détectés - Connexions les plus problématiques
Ultrasound - Problèmes fréquemment détectés - Membres les plus problématiques
Ultrasound - Problèmes fréquemment détectés - Ensemble de répliques le plus problématique
Ultrasound - Problèmes fréquemment détectés - Résumé
Les groupes d’ordinateurs associés à ce pack d'administration incluent les serveurs Microsoft Ultrasound 1.0, ainsi que les serveurs FRS s’exécutant sous Windows 2000 Server et Windows Server 2003. Les groupes d’ordinateurs sont tous alimentés à l’aide de formules utilisant la version du système d’exploitation et indiquent si le serveur héberge le service FRS pour déterminer l’appartenance au groupe. Le groupe Serveurs Ultrasound est alimenté lorsque vous installez Ultrasound sur un serveur.
Lorsque vous configurez le pack d'administration pour Microsoft Windows File Replication Service (FRS) pour accepter les privilèges réduits, les tâches ne fonctionnent pas, mais les autres fonctionnalités du pack d'administration sont prises en charge. Le compte d’action doit disposer de l’accès en lecture à la base de données Ultrasound et l’autorisation d’exécution pour la procédure stockée GetControllerStatusForMOM001. Le pack d'administration pour Microsoft Windows File Replication Service (FRS) prend en charge la surveillance des ordinateurs sans agent et avec agent.
Vous pouvez télécharger le pack d'administration pour Microsoft Windows File Replication Service (FRS) depuis la page Web: go.microsoft.com/fwlink/?LinkId=79530.

Pack d'administration Windows Server
Le pack d'administration pour le système d'exploitation Microsoft Windows surveille Windows NT 4.0 Server, Windows 2000 Server et Windows Server 2003. Le pack d'administration de système d’exploitation de base crée des rapports de fonctionnement du système d’exploitation pour vos contrôleurs de domaine et surveille les services racines du système. Le pack d’administration fournit des données d'état sur les services Windows principaux, la performance de mémoire et du processeur, ainsi que sur l’espace libre de disque et la latence de disque. Il arrive que les règles de surveillance de ce pack d'administration se chevauchent avec d’autres dans règles abordées dans cet article, mais elles offrent une bonne vue d’ensemble de l'état du contrôleur de domaine.
La figure 4 illustre les rapports disponibles dans le pack d'administration pour le système d'exploitation Microsoft Windows. Comme c'est le cas pour les autres packs d'administration, les groupes d’ordinateurs sont alimentés par des formules qui utilisent la version du système d’exploitation.
Figure 4 Rapports du système d'exploitation de base (Close Figure 4)

Analyse des performances disque
Configuration du système d’exploitation
Performances du système d’exploitation
Arrêt du système d’exploitation par événement
Arrêt du système d’exploitation par serveur
Configuration du stockage du système d’exploitation
Installations de logiciels et d’applications par application
Installations de logiciels et d’applications par instance
Installations de logiciels et d’applications par serveur
Fiabilité - Échecs d’application par application
Fiabilité - Échecs d’application par ordinateur
Fiabilité - Échecs d’application par événement
Fiabilité - Échecs de système d’exploitation par ordinateur
Fiabilité - Échecs de système d’exploitation par événement
Fiabilité - Échecs de système d’exploitation par code d’arrêt
Historique des performances - Historique des performances
Historique des performances - Rapports supplémentaires
Lorsque vous configurez le pack d'administration pour le système d'exploitation Microsoft Windows pour qu’il accepte les privilèges réduits, Windows 2000 exige que le compte d’action soit membre du groupe Administrateurs locaux. Windows Server 2003 exige que le compte d’action soit membre des groupes Utilisateurs et Utilisateurs de l'analyseur de performances locaux, et qu’il dispose des autorisations Gérer les journaux d’audit et de sécurité (SeSecurityPrivilege) et Permettre l’ouverture d’une session locale (SeInteractiveLogonRight). La plupart des fonctions du pack d'administration pour le système d'exploitation Microsoft Windows, à l’exception des tâches, sont prises en charge sur des ordinateurs surveillés sans agent.
Vous pouvez télécharger le pack d'administration pour le système d'exploitation Microsoft Windows depuis la page Web go.microsoft.com/fwlink/?LinkId=79531.

Pack d'administration pour Microsoft Windows Active Directory
Le pack d'administration pour Microsoft Windows Active Directory est très extensif et ses règles couvrent Windows 2000 Server et Windows Server 2003. Le pack d'administration pour Microsoft Windows Active Directory inclut cinq zones de règles : surveillance côté client, surveillance de la fiabilité, surveillance de la réplication et découverte de la topologie, plus des règles couvrant les systèmes d’exploitation Windows 2000 Server et Windows Server 2003. Comme indiqué précédemment, les nouvelles versions de Windows permettent l'utilisation d'un plus grand nombre d'outils et par la même occasion, une surveillance accrue. Par exemple, le pack d'administration prend en charge la surveillance de la fiabilité sur Windows Server 2003, mais non sur Windows 2000.
Le pack d'administration pour Microsoft Windows Active Directory crée plusieurs groupes utilisés pour appliquer des règles aux ordinateurs spécifiques. Les règles de surveillance côté client utilisent le groupe Surveillance côté client Active Directory. C’est dans ce groupe que vous placez les ordinateurs disposant de l’agent MOM installé pour surveiller et gérer ces règles. J’ai placé quelques ordinateurs de bureau disposant de la licence de l’agent dans ce groupe, ainsi que quelques serveurs Exchange. Exchange Server utilise énormément Active Directory et sera le premier indicateur d'un problème en latent. Les ordinateurs de bureau du groupe peuvent vous aider à évaluer l’expérience utilisateur final. Les règles de surveillance côté client utilisent des scripts pour tester la connectivité aux contrôleurs de domaine. Ceux-ci les interrogent via le protocole LDAP, et signalent les échecs. Il est important de noter que vous ne pouvez appliquer les règles de surveillance côté client qu’aux ordinateurs gérés par un agent dont la fonction de proxy est activée, mais qui ne sont pas des contrôleurs de domaine.
Les règles de surveillance de la fiabilité utilisent le groupe Surveillance de la fiabilité Active Directory. C'est dans ce groupe que vous placez les ordinateurs Windows Servers 2003 pour tester la fiabilité. Windows Servers 2003 inclut un espace de noms WMI pour la surveillance de la fiabilité. Un script est utilisé par ces règles pour interroger l’espace de noms WMI. Lorsque des erreurs de fiabilité avec d’autres domaines sont détectées, ces règles vous alertent.
De nombreuses règles du pack d'administration pour Microsoft Windows Active Directory s’appliquent à Windows 2000 Server ou Windows Server 2003. Ces règles définissent les différences d’implémentation d’Active Directory entre les deux systèmes d’exploitation. Cependant, vous trouverez la plupart des fonctions du pack d'administration pour Microsoft Windows Active Directory dans les règles combinées des deux systèmes d’exploitation. Certaines de ces règles incluent des scripts permettent de tester la connectivité entre les contrôleurs de domaine en vérifiant les détendeurs de rôle FSMO (Flexible Single-Master Operation) et la taille de la base de données de l’arborescence d’information d’annuaire (DIT) et en validant le traitement de la stratégie de groupe, l’inspection du vérificateur de cohérence de la connaissance (KCC ) et le test du service de messagerie intersites.
La surveillance de la réplication est la pièce maîtresse du pack d'administration pour Microsoft Windows Active Directory. Deux groupes, Collecte des données de latence de la réplication Active Directory - Sources et Collecte des données de latence de la réplication Active Directory - Cibles sont en place pour vous permettre de configurer les contrôleurs de domaine utilisés uniquement pour signaler les événements de la de la réplication. La latence de la réplication est calculée pour chaque membre des groupes de collecte de données. Les compteurs de performances sont alimentés avec la durée de la réplication des mises à jour sur chaque membre du groupe. La latence de la réplication à l'échelle de l'entreprise est calculée et signalée (et des alertes sont générées) si les seuils définis sont dépassés. Notez que vous devez installer un espace de noms WMI pour la surveillance de la réplication sur Windows 2000 Server.
La découverte de topologie dans le pack d'administration pour Microsoft Windows Active Directory est utilisée pour créer des diagrammes de votre implémentation. Ces diagrammes utiles peuvent être exportés vers Microsoft Office Visio®. Les diagrammes sont créés en temps réel par MOM de sorte que vous pouvez obtenir une version à jour en quelques secondes.
Dans les vues de diagrammes de la Console de l’opérateur MOM 2005, trois diagrammes du pack d'administration pour Microsoft Windows Active Directory sont disponibles. Le diagramme Objets de connexions cassées (figure 5) affiche les connexions présentant un état d’erreur. Ce diagramme peut être vierge s’il n’existe pas d’erreur de connexion.
Figure 5 Les connexions cassées apparaissent en surbrillance dans la vue de diagramme.
Figure 5 Les connexions cassées apparaissent en surbrillance dans la vue de diagramme.
Le diagramme Objets de connexion met en surbrillance les connexions entre les DC. Le diagramme Liaisons entre sites affiche chaque site Active Directory, encapsulant les contrôleurs de domaine appropriés dans ce site et liaisons entre les sites connectés.
Les diagrammes créés par MOM pour ces vues étant dynamiques, vous pouvez les exporter vers Visio pour les modifier et les personnaliser facilement. Par exemple, la figure 6 illustre le diagramme Liaisons entre sites en cours de modification dans Visio.
Figure 6 Modification d’un diagramme Liaisons entre sites dans Visio
Figure 6 Modification d’un diagramme Liaisons entre sites dans Visio (Cliquer sur l'image pour la réduire)
Figure 6 Modification d’un diagramme Liaisons entre sites dans Visio
Figure 6 Modification d’un diagramme Liaisons entre sites dans Visio (Cliquer sur l'image pour l'agrandir)
La figure 7 répertorie les rapports disponibles dans le pack d'administration pour Microsoft Windows Active Directory. Les groupes d’ordinateurs associés à ce pack d'administration apparaissent à la figure 8. Comme vous pouvez le constater, les groupes d’ordinateurs Active Directory sont alimentés par l’appartenance explicite. Les groupes d’ordinateurs Windows sont alimentés selon la version du système d’exploitation et que la machine est un contrôleur de domaine.
Figure 8 Groupes d’ordinateurs (Close Figure 8)

Surveillance côté client Active Directory
Données de latence de la réplication Active Directory
Collecte - Sources
Données de latence de la réplication Active Directory
Collecte - Cibles
Surveillance de la fiabilité Active Directory
Contrôleurs de domaine Windows 2000 Server
Contrôleurs de domaine Windows Server 2003
Figure 7 Rapports Active Directory (Close Figure 7)

Contrôleur de domaine AD
Détenteurs de rôle AD
Objets de connexion de la réplication AD
Liaisons entre sites de réplication AD
Espace disque des contrôleurs de domaine AD
Modifications de domaine AD
Échecs d’authentification de compte d’ordinateur AD
Bande passante de la réplication AD
Latence de la réplication AD
Le pack d'administration pour Microsoft Windows Active Directory peut être configuré pour les privilèges limités sur les contrôleurs de domaine de Windows Server 2003. Le pack d'administration ne prend pas en charge la surveillance sans agent. Sous Windows 2000 Server, le compte d’action d’agent doit se trouver dans le groupe Administrateurs du domaine ou Administrateurs locaux. Le compte d’action d’agent sur les contrôleurs de domaine Windows Server 2003 doivent disposer d’autorisations supplémentaires pour être configuré pour des privilèges limités, et doivent notamment être membres des groupes Utilisateurs et Utilisateurs de l’analyseur de performances, avoir accès aux journaux d’événements et bénéficier des privilèges SeSecurityPrivilege, SeAuditPrivilege et SeInteractiveLogonRight. En outre, les accès suivants sont requis : accès complet au conteneur CN=MomLatencyMonitors dans Active Directory pour la surveillance de la réplication, accès en lecture aux annuaires contenant la base de données et les fichiers journaux NTDS.dit et accès en lecture aux clés de registre suivantes :
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Si vous surveillez la fiabilité dans Windows Server 2003, notez que le script AD Monitor Trusts requiert que le compte d’action d’agent dispose de l’appartenance aux groupes Administrateurs de domaine ou Administrateurs.
Vous pouvez télécharger le pack d'administration pour Microsoft Windows Active Directory sur la page go.microsoft.com/fwlink/?LinkId=79540.

Personnalisation de MOM pour Active Directory
Le pack d'administration pour Microsoft Windows Active Directory doit être configuré sans quoi les alertes satureront votre console. Le moment le plus bruyant pour le pack d'administration pour Microsoft Windows Active Directory survient au redémarrage d’un contrôleur de domaine, car toutes les alertes se déclenchent. Malheureusement, il est difficile d’arrêter cette procédure. La meilleure solution consiste à utiliser le mode maintenance de MOM pour contrôler les alertes pendant les périodes de maintenance prévues. Le but du mode maintenance est de résoudre automatiquement les alertes pour les contrôleurs de domaine afin d’éviter la saturation de la console.
Veillez à configurer le groupe Surveillance côté client Active Directory en plaçant des ordinateurs clients et des serveurs appropriés dans le groupe. Les règles associées à ce groupe vous aident à déterminer l'état de vos FSMO et leur connectivité.
Certaines règles de performances utilisent des seuils pour relier les FSMO, et les protocoles et requêtes LDAP, PING et DNS pour vérifier la connectivité. Ces règles se trouvent dans les règles de performances disponibles d’Active Directory. Vous devez personnaliser les seuils utilisés par ces règles en définissant la gravité d’alerte. Par exemple, les liaisons FSMO utilisent des valeurs d’attribut en secondes. Les règles de performances de chaque rôle FSMO utilisent cette méthodologie de création d’alerte.
Il est important de comprendre comment les paramètres Détermination de la gravité d'alerte pour une règle d'état fonctionnent. La boîte de dialogue utilise les conditions If-Else pour la valeur d’attribut et définit la gravité d’alerte en conséquence (voir la figure 9). Lorsque la règle relève le compteur de performances Dernière liaison créé par le script Op Master Response, elle effectue une comparaison avec les seuils conditionnels définis par ces règles. Vous devez configurer ces niveaux d’alerte pour votre environnement.
Figure 9 Définition des règles de gravité d’alerte
Figure 9 Définition des règles de gravité d’alerte (Cliquer sur l'image pour la réduire)
Figure 9 Définition des règles de gravité d’alerte
Figure 9 Définition des règles de gravité d’alerte (Cliquer sur l'image pour l'agrandir)
Rappelez-vous de la planification de la réplication pour chaque contrôleur de domaine. Si un contrôleur de domaine donné a une planification différente des autres, il modifiera les résultats de latence de la réplication et vous forcera à définir des seuils plus élevés. Vous devez définir les paramètres des scripts de réplication en fonction des besoins de votre environnement. Il est important de noter que lorsqu’un contrôleur de domaine est arrêté ou que des problèmes de réplication se produisent, tous les autres contrôleurs de domaine de ces groupes peuvent signaler un échec de la réplication pour ce contrôleur de domaine, même s’il ne s’agit pas d’un partenaire de réplication direct. Ainsi, même si vous placez le contrôleur de domaine fautif en mode maintenance, les autres contrôleurs de domaine peuvent signaler les échecs de réplication.
Vous devez concentrer tous vos efforts sur la surveillance de la réplication pour optimiser le pack d'administration pour Microsoft Windows Active Directory. Il est recommandé d'exécuter le pack d'administration dans votre environnement pendant deux semaines pour vérifier sa procédure d’alerte. Lorsque vous voyez une tendance se développer, utilisez les rapports pour définir les latences et régler les seuils en conséquence.
Pour terminer, vous trouverez de nombreux conseils utiles auprès du service Alert Tuning Solution Accelerator.

Perspectives
MOM 2005 et le pack d'administration pour Microsoft Windows Active Directory vous permettent de surveiller de manière efficace l’implémentation d’Active Directory dans votre organisation. Avec les packs d'administration pour Microsoft Windows Active Directory, Microsoft Windows DHCP Service, Microsoft Windows Domain Name System (DNS), Microsoft Windows File Replication Service (FRS) et le système d’exploitation Microsoft Windows, vous pouvez mieux surveiller la plupart des aspects de votre infrastructure, en protégeant le fonctionnement de l’infrastructure d’Active Directory, ainsi que de vos utilisateurs. L’utilisation des nombreuses données recueillies dans votre data warehouse de rapport vous permet d'analyser vos performances et données d’événement afin de planifier la capacité et de déterminer des tendances en matière de performances.
Pour obtenir les packs d'administration que j’ai abordés dans cet article, ainsi que bien d’autres, reportez-vous au Catalogue des packs d'administration.
La prochaine mise à jour du pack d'administration pour Microsoft Windows Active Directory contiendra tous les correctifs habituels et des améliorations de certains seuils. Les nouvelles fonctionnalités planifiées pour la prochaine version du produit, appelée System Center Operations Manager 2007, sont des plus intéressantes, notamment la possibilité de surveiller plusieurs forêts depuis un seul groupe de configuration, de définir des groupes de contrôleurs de domaine (chacun avec sa propre latence de réplication prévue parmi d’autres groupes) et de surveiller les contrôleurs de domaine s’exécutant sur la prochaine version de Windows Server. Pour plus d'informations, consultez le site Web de MOM à l’adresse microsoft.com/mom.

John Hann travaille sur MOM depuis MOM 2000 et est MVP MOM depuis 2004. Il contribue à MyITForum.com, MOMCommunity.com et LearnMOM.com. Vous pouvez le contacter par l’intermédiaire de son blog.


 Administration de Windows: Le jeu dans un environnement s&#233;curis&#233;
Administration de Windows Matt Clapham

Le jeu dans un environnement sécurisé
Vue d'ensemble:
  • Écriture dans les dossiers protégés et les clés de registre
  • Copier les défaillances de protection
  • Problèmes de pare-feu
  • Problèmes des clients d'entreprise

Le jour, je travaille comme gestionnaire de programme de sécurité chez Microsoft. J'écris également assez souvent sur la sécurité pour Technet Magazine. Il va sans dire que je prends la sécurité très au sérieux. Mais j'ai également d'autres centres
intérêts. Pendant mes heures de loisir, j'adore jouer à des jeux fonctionnant sous Windows®. Je suis surtout amateur de jeux de tir subjectifs, de simulateurs, de jeux de rôles et de jeux de stratégie en temps réel. Mais il y a un petit problème. Comme mes amis Jesper Johansson et Aaron Margosis, je refuse de fonctionner avec des privilèges d'administrateur sauf lorsque c'est absolument nécessaire. Je fais ceci en partie pour m'assurer que je ne suis pas « 0wn3d » dans un jeu de réseau qu'en raison de mon manque de compétences et non parce que quelqu'un me bombarde avec un rootkit pour ralentir ma visée (voir l'avis de saturation de la mémoire tampon de Quake 3 dans l'encadré « Ressources »).
J'en suis tellement convaincu que souvent je renonce à essayer une nouveauté à priori passionnante (voir la figure 1). Si je ne peux pas exécuter un jeu sous mon compte d'utilisateur limité (LUA) sur un client appartenant au domaine Small Business Server (SBS) après l'avoir installé et mis à jour sous un compte administrateur, je le supprime sans tarder. Il n'y a pas d'excuse pour une conception aussi médiocre et je ne manque pas de jeux parmi lesquels choisir. J'admets que ceci peut sembler être une position extrême, mais je suis catégorique sur ce point. Ceci étant, je ne suis pas contre l'idée de résoudre quelques faiblesses mineures si elles permettent d'obtenir en retour un temps de jeu de qualité et c'est de cela que je vais vous parler maintenant. Donc, permettez-moi de partager certains problèmes liés aux jeux que j'ai rencontrés et les solutions efficaces que j'ai utilisées. Pour avoir un résumé succinct des pratiques d'excellence, reportez-vous à l'encadré « Conseils pour jouer sous un compte d'utilisateur limité ».
Figure 1 Problème d'accès au fichier lors d'une mise à jour manuelle
Figure 1 Problème d'accès au fichier lors d'une mise à jour manuelle (Cliquer sur l'image pour la réduire)
Figure 1 Problème d'accès au fichier lors d'une mise à jour manuelle
Figure 1 Problème d'accès au fichier lors d'une mise à jour manuelle (Cliquer sur l'image pour l'agrandir)

Problèmes courants
Le problème du privilège n'est pas nouveau. De nombreux jeux ainsi que d'autres types de programme ont besoin de privilèges d'administrateur pour fonctionner correctement. Jetez un coup d'œil sur l'article de la Base de connaissances « Certains programmes ne fonctionnent pas correctement si vous ouvrez une session à l'aide d'un compte d'utilisateur limité » (voir support.microsoft.com/kb/307091). Il dresse la liste de presque 200 jeux et applications qui présentent des problèmes lorsqu'ils sont exécutés avec un compte limité et cette liste inclut quelques programmes de Microsoft.
Soyons clairs : je ne considère pas que l'exigence de privilèges d'administrateur pour installer ou mettre (manuellement) à jour un jeu soit un problème. Ceci est généralement nécessaire et le sera jusqu'à ce que nous ayons la possibilité de faire des installations par utilisateur de façon routinière sous Windows. Ce jour viendra bientôt, mais nous n'y sommes pas encore tout à fait. Cependant, une fois qu'un jeu est installé et mis à jour, il doit pouvoir être utilisé par n'importe quel utilisateur du système, même un utilisateur n'ayant que des privilèges limités.
Tentative d'écriture dans les dossiers protégés et les clés de registre Le problème le plus courant que j'ai jamais vu est lorsqu'un jeu s'interrompt au lancement ou en cours d'exécution parce qu'il essaie d'écrire sur des dossiers ou des clés de registre protégés (fréquents dans beaucoup d'applications conçues pour Windows). Par défaut, seuls les administrateurs (et les très dénigrés utilisateurs avec pouvoir) peuvent écrire dans certains dossiers (tel que %PROGRAMFILES%) et les ruches de registre (comme HKEY_LOCAL_MACHINE). Les erreurs qui en découlent sont relativement évidentes : « Error 42 : Can't write log files to C:\Program Files\CoolGamesInc\NewestFPS\Logs\ » (Erreur 42 : impossible d'écrire des fichiers journaux dans C:\Program Files\CoolGamesInc\NewestFPS\Logs\) ou « Game not installed properly, reinstall and restart » (jeu mal installé, le réinstaller et redémarrer). J'ai vu également des exemples en cours de jeu, tels que des messages d'erreur qui apparaissent lorsque j'enregistre ma progression. Quelquefois, les auteurs des jeux prennent au moins le soin d'alerter l'utilisateur que le jeu a besoin du privilège d'administrateur pour fonctionner, comme je l'ai constaté avec Age of Mythology®. Les jeux en ligne massivement multijoueurs (MMOG) ont souvent des problèmes de privilège puisqu'ils se mettent à jour fréquemment et que l'auto-mise à jour est plus délicate à résoudre techniquement. Lorsque j'ai essayé la version d'essai d'EVE Online, j'ai remarqué qu'elle était pénalisée d'une part par le placement de fichiers journaux dans des endroits inappropriés et d'autre part parce qu'elle essayait de mettre à jour ses propres données de contenu de jeu dans le dossier d'installation.
Protection contre la copie provoquant une interruption La seconde raison la plus courante de l'échec du lancement des jeux est lorsque la protection contre la copie intégrée au jeu (ou toute autre fonction anti-piratage) ne fonctionne pas sous un compte utilisateur limité. Cela peut venir du fait que le pilote n'a pas démarré correctement ou qu'un service d'arrière-plan n'est pas lancé. La représentation la plus commune que j'ai vue de ce problème est que le jeu demande à l'utilisateur d'insérer un disque, même lorsque le média requis est déjà dans le lecteur. J'ai également vu des jeux indiquer que les droits d'administrateur sont nécessaires au motif douteux que seuls des administrateurs savent exécuter correctement la vérification de la protection contre la copie. Les pires cas envoient un message d'erreur mal conçu et absurde qui n'a aucune référence sur le site de support du jeu.
Échec de la demande d'une exception de pare-feu Les jeux multijoueurs auxquels on peut jouer sur un réseau local ou sur Internet sont très courants. Windows XP Service Pack 2 (SP2) a ajouté un message d'avertissement qui indique à l'utilisateur que des applications tentent d'écouter sur le réseau. Ceci m'amène à un autre problème courant que j'ai observé : Les jeux qui ont besoin d'une exception de pare-feu mais ne demandent pas d'ajouter cette exception au moment de l'installation. Puisque les utilisateurs limités ne peuvent pas changer la configuration du pare-feu, il ne peut être remédié à cet avertissement (voir la figure 1) sans un travail de configuration fait par un administrateur. Pire encore, parfois le problème n'est pas évident, puisque l'avertissement apparaît dans le shell Windows et non dans l'interface du jeu. En fait, bien souvent on ne voit le message d'erreur qu'une fois que l'on a quitté le jeu.
Figure 2 Lorsque les paramètres du pare-feu gâchent tout le plaisir
Figure 2 Lorsque les paramètres du pare-feu gâchent tout le plaisir (Cliquer sur l'image pour la réduire)
Figure 2 Lorsque les paramètres du pare-feu gâchent tout le plaisir
Figure 2 Lorsque les paramètres du pare-feu gâchent tout le plaisir (Cliquer sur l'image pour l'agrandir)
Problèmes des clients d'entreprise J'ai trouvé un autre problème qui n'est pas directement apparenté à l'exécution sous un compte d'utilisateur limité, mais qu'il est néanmoins intéressant d'aborder. Je fais fonctionner mon environnement informatique à domicile comme s'il s'agissait d'une petite entreprise (je n'entrerai pas trop dans les détails ici, mais vous pouvez consulter l'articleMaster Your Domain: Build a Corporate Network at Home » (en anglais) que Jesper Johansson et moi avons écrit pour le numéro d'octobre 2006 de Technet Magazine. En utilisant SBS 2003 (R2), j'ai installé un domaine Windows complet avec un dossier Mes documents qui est redirigé vers un partage de serveur. C'est comme cela que j'ai découvert le dernier problème le plus fréquent que j'aborderai : Les jeux qui ne savent pas gérer les clients d'entreprise.
J'ai remarqué un double inconvénient sur Age of Empires® III (AoE3). Il est à porter au crédit de l'équipe de développement que le jeu démarre et fonctionne correctement avec un utilisateur limité. Cependant, j'ai remarqué que les scénarios se chargeaient lentement en raison de la quantité importante de données de journalisation écrites sur le réseau. De plus, AoE3 perdait ma configuration, mes jeux enregistrés et ma progression à chaque fois que je quittais le jeu. Les fichiers étaient manifestement bien là dans le dossier Mes documents, mais le jeu ne les chargeait pas. Cela a été une vraie déception, surtout si l'on considère à quel point AoE3 est devenu compatible avec les LUA par rapport aux titres précédents de la série.
J'ai vu un jeu qui reconnaît au moins les problèmes de client d'entreprise. Lorsque j'ai essayé Fable®: The Lost Chapters™, le jeu a été suffisamment prévenant pour me dire que les dossiers Mes documents n'étaient pas pris en charge, puis il s'est gracieusement arrêté. Je rends grâce à l'équipe de développement pour avoir su reconnaître un scénario non pris en charge et l'avoir écarté. Cependant, il m'a semblé un peu bizarre que le jeu fasse de tels efforts pour arrêter l'utilisateur, étant donné qu'il s'agissait seulement de placer quelques mégaoctets de données dans le dossier Mes documents.

Solutions simples
J'ai vu ces problèmes maintes et maintes fois sur plus de jeux que je peux me rappeler. Heureusement, la plupart ont des solutions commodes. Mon correctif préféré est de laisser complètement tomber le jeu et de passer à un titre compatible LUA du même genre, publié par un autre éditeur. Mais cela peut sembler un peu extrême. Ce n'est pas certes pas la meilleure solution lorsque j'ai dépensé 46 euros pour un nouveau titre que je ne peux pas rendre parce que la boîte est déjà ouverte. Voyons donc les façons de réparer les jeux que je possède déjà.Conseils pour jouer sous un compte limité
  • Passez à Windows Vista.
  • Essayez le jeu en mode démonstration avant de l'acheter. Ceci vous permettra probablement de découvrir tous les problèmes de LUA existant dans la version complète.
  • Vérifiez la liste de programmes connus pour avoir des problèmes à s'exécuter sous un LUA ().
  • Recherchez des jeux comportant le logo Conçu pour Windows.
  • Mettez le jeu à jour après l'installation et avant de l'exécuter en tant qu'utilisateur limité.
  • Lorsque vous avez un jeu qui ne fonctionne pas sous un utilisateur limité, transmettez vos inquiétudes à l'éditeur et au service d'assistance technique de l'éditeur.
  • Si nécessaire, utilisez un compte local d'utilisateur avec pouvoir.

Correction des problèmes de protection contre la copie Tout d'abord, occupons-nous du problème de pilote de protection contre la copie. Les systèmes de protection contre la copie sont faits pour durer, mais cela ne signifie pas qu'ils doivent empêcher des non administrateurs de faire fonctionner les jeux ! La plupart des jeux utilisent le mécanisme de protection de copie SafeDisc de Macrovision, lequel installe un pilote qui vérifie que le disque de jeu est un original. Par défaut, le pilote est configuré pour démarrer à la demande (une fonction que les utilisateurs limités ne sont pas autorisés à effectuer). Microsoft et Macrovision ont distribué des correctifs, mais j'ai trouvé une autre solution :
  1. Ouvrez le Gestionnaire de périphériques en utilisant un compte administrateur.
  2. Allez au menu Affichage et sélectionnez Afficher les périphériques cachés.
  3. Développez le nœud Pilotes non Plug-and-Play.
  4. Ouvrez les propriétés pour le pilote Sécurité ou SecDrv (voir la
    Figure 3 Permettre à la protection de s'effectuer correctement (Cliquer sur l'image pour la réduire)
Figure 3 Permettre à la protection de s'effectuer correctement
Figure 3 Permettre à la protection de s'effectuer correctement (Cliquer sur l'image pour l'agrandir)
Puisque le pilote se lance maintenant lorsque l'ordinateur démarre, il est prêt lorsque l'utilisateur insère le disque pour lancer le jeu.
Résoudre les problèmes de système de fichiers et d'accès aux registres La présomption d'accès sans contrainte à n'importe quelle partie du système de fichiers ou du registre est un problème commun à de nombreux programmes actuels ou d'héritage et pas uniquement aux jeux. L'articleProblèmes de privilèges : détection et correction des bogues LUA » traite de façon plus détaillée les solutions aux différents problèmes qui ont amené à exiger des privilèges d'administrateur (voir ).
Les problèmes d'accès peuvent être un peu difficiles à dépister, mais une fois que l'ensemble requis de fichiers, de dossiers et de clés de registre est cerné, élargir les listes de contrôle d'accès (LCA) pour autoriser les utilisateurs limités à exécuter le jeu est assez simple. J'ai surtout eu du succès avec la méthode suivante :
  1. Récupérez les versions les plus récentes de Filemon et Regmon de microsoft.com/technet/sysinternals.
  2. Exécutez les outils comme administrateur et utilisez-les pour commencer à garnir les journaux.
  3. Jouez au jeu pendant quelques minutes en tant qu'administrateur, en exécutant les tâches les plus communes (commencer une nouvelle campagne, enregistrer un jeu, héberger un jeu de réseau et ainsi de suite).
  4. Filtrez les résultats de Filemon et Regmon pour vous concentrer sur les accès à partir du jeu testé.
  5. Élargissez les LCA autant qu'il est nécessaire sur les dossiers et clés de registre concernés.
  6. Exécutez le jeu en tant que non administrateur pour vous assurer qu'il fonctionne bien maintenant.
Un mot de prudence sur l'élargissement des LCA : ne les ouvrez pas trop grand (comme Everyone£Full Control [tout le monde £ contrôle total]) ou à un niveau trop élevé (comme HKEY_CLASSES_ROOT). Il vaut également mieux éviter de modifier les permissions des dossiers système comme %SYSTEMROOT% et %PROGRAMFILES % pour éviter de modifier complètement Windows ou de laisser le système dans un état non sécurisé.
Une autre solution potentielle est d'exécuter le jeu en tant qu'utilisateur avec pouvoir local système. Ce n'est pas le choix que je préfère, mais en utilisant un compte qui est local sur ce système, l'étendue de l'impact est au moins limitée à un seul poste de travail, si quelque chose se passe mal. J'ai constaté que cette correction fonctionne pour la plupart des jeux qui ne semblent bien fonctionner que sous un compte administrateur.
À part cela, je trouve que faire fonctionner brièvement le jeu en tant qu'administrateur est une façon pratique pour qu'il se mette à jour lui-même. Donc, en général j'exécute le jeu en tant qu'administrateur, j'invoque son option de mise à jour, puis je quitte le jeu et je retourne à mon compte utilisateur limité pour lancer le jeu lui-même. (Il est utile de mentionner que Windows Vista™ permet aux utilisateurs limités de mettre à jour les applications, à condition que le correctif soit signé par l'éditeur original).
Windows Vista aide également les jeux et les autres applications à résoudre les problèmes d'accès aux fichiers et aux registres. Par défaut, les programmes exécutés par des utilisateurs limités ont des shims de virtualisation activés qui redirigent les accès aux fichiers et aux registres mal dirigés vers un cache propre à l'utilisateur. J'ai vu personnellement des jeux conçus à l'ère Windows 9x, (par exemple, The Neverhood) qui ne fonctionnent pas correctement sous Windows XP (en raison de problèmes d'autorisation), mais qui fonctionnent parfaitement sous Windows Vista avec les shims par défaut. J'ai hâte de pouvoir tester d'autres jeux problématiques sous Windows Vista, mais mon pressentiment est que j'aurai du mal à trouver un jeu qui ne fonctionnera pas correctement avec les shims de Windows Vista.
Résoudre les problèmes de pare-feu. Le problème de pare-feu est mieux résolu au moment de la première installation du jeu. Cependant, lorsque l'installation de jeu n'est pas assez performante pour demander et configurer les mises au point du pare-feu, voici une méthode qui fonctionne bien :
  1. Ouvrez une session en tant qu'administrateur.
  2. Ouvrez le Panneau de configuration du pare-feu Windows.
  3. Choisissez d'ajouter un programme à la liste d'exception du pare-feu.
  4. Sélectionnez le jeu dans la liste ou parcourez l'explorateur pour trouver l'exécutable du jeu lorsque vous y êtes invité.
En ajoutant l'exécutable du jeu à l'exception du pare-feu, je m'assure que le jeu aura un accès autorisé à tous les ports dont il a besoin pour fonctionner correctement. Il s'ensuit un grand carnage !
Résolution des problèmes de clients d'entreprise Les problèmes que les jeux rencontrent sur les clients d'entreprise finiront par disparaître. La quantité de ménages équipés de plusieurs ordinateurs et branchés en haut débit augmente et une communauté croissante d'utilisateurs utilise un SBS à la maison. Mais pour le moment, une solution est toujours attendue.
Dans mon cas particulier, j'ai constaté qu'une LUA locale sur le système contournait le problème de redirection de Mes documents. Les deux jeux, Age of Empires III et Fable: The Lost Chapters fonctionnent parfaitement avec un utilisateur limité aussi longtemps que le dossier Mes documents n'est pas redirigé vers un dossier du réseau.Ressources
  • Quake 3 Buffer Overflow Advisory (en anglais)
  • Windows Vista Application Development Requirements for User Account Control Compatibility (en anglais)
  • Applying the Principle of Least Privilege to User Accounts on Windows XP (en anglais)
  • Outil LUA Buglight d'Aaron Margosis (en anglais)
  • Standard User Analyzer (en anglais)
  • Master Your Own Domain: Build a Corporate Network at Home (en anglais)
  • Problèmes de privilèges : détection et correction des bogues LUA
  • Certains programmes ne fonctionnent pas correctement si vous ouvrez une session à l'aide d'un compte d'utilisateur limité

Conclusion
Je recommande fortement de fonctionner sous un compte utilisateur limité afin de pouvoir profiter des avantages associés au fait de ne pas s'exécuter en tant qu'administrateur. Il n'est pas toujours facile de jouer dans un monde connecté à l'entreprise, avec un minimum de privilèges, mais c'est loin d'être impossible. Au cours des années, j'ai trouvé de nombreux jeux en tous genres qui fonctionnent correctement sous un compte utilisateur limité. Et j'ai trouvé quelques correctifs qui permettent de faire fonctionner d'autres titres. Pendant ce temps, avec la virtualisation de Windows Vista, des jeux qu'il était impossible de faire fonctionner en tant qu'utilisateur limité sous Windows XP fonctionnent à nouveau.

Matt Claphamgestionnaire de programme de sécurité chez Microsoft, est un participant actif de la communauté informatique et sécurité de Seattle et membre de l'équipe de gestion des risques d'un projet d'incubation en informatique.


 Le mot du r&#233;dacteur en chef: En coulisses
Le mot du rédacteur en chef
En coulisses

WINDOWS VISTA EST PRÊT à avoir un impact majeur sur les services informatiques des entreprises en 2007. Comme l'indique InformationWeek, un récent rapport IDC estime que 100 000 emplois seront créés dans le domaine de l'informatique aux États-Unis cette année, grâce au « bond » de Windows Vista. Environ 90 millions de nouveaux ordinateurs dans le monde entier seront équipés de Windows Vista cette année, et avant la fin de l'année prochaine, 80 % des nouveaux ordinateurs seront fournis avec Windows Vista. Entre-temps, vous devez décider si le moment est venu de déployer ce système d'exploitation dans votre entreprise. Nous pouvons vous aider à prendre cette décision.
Ce mois-ci, Technet Magazine lance un série d'articles qui examinera en détail le centre vital de Windows Vista : le noyau. Il est vrai que Windows Vista est doté de nouvelles fonctionnalités qui amélioreront l'expérience utilisateur, mais si c'était la seule raison de migrer, nous serions méfiants. Le noyau représente le cœur de Windows Vista, et des améliorations très importantes ont été apportées à son fonctionnement.
Mark Russinovich est la personne la mieux placée pour expliquer ces améliorations et décrire le noyau Windows. Windows Internals, qu'il a écrit en collaboration avec David Salomon, est un livre de référence qui doit être lu par tous ceux qui veulent savoir ce qui se passe en coulisses.
Dans ce numéro, Mark nous parle des améliorations apportées à l'allocation processeur qui rendront les applications de bureau plus réactives, puis décrit la façon dont Windows Vista améliore les performances multimédias au niveau du noyau. L'article se penche également sur les importantes modifications apportées au modèle d'E/S de Windows Vista, notamment les liens symboliques basés sur les fichiers, la nouvelle possibilité d'annuler les opérations d'E/S synchrones (la modification la plus importante, à mon avis), et le concept de priorité d'E/S. Ne manquez pas de lire l'article de Mark lorsque vous évaluerez le déploiement de Windows Vista dans votre entreprise.
Bien sûr, les tâches quotidiennes doivent également être prises en compte, mais là aussi, nous pouvons vous aider. Ce numéro aborde plusieurs aspects liés à l'administration de Windows, avec notamment des articles sur la délégation d'autorité dans Active Directory, les nouveaux modèles de stratégie de groupe dans Windows Vista, le dépannage de stratégie de groupe et la surveillance d'Active Directory avec MOM.
Enfin, si vous aimez jouer en ligne sans compromettre la sécurité de votre ordinateur, vous pourrez jeter un coup d'œil sur notre article consacré aux jeux dans un environnement sécurisé. Joindre l'utile à l'agréable, ce n'est pas une mauvaise idée ! £JOSHUA TRUPIN

Remerciements aux experts techniques Microsoft suivants : Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Marquer Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Salomon, Jim Truher, Landy Wang et Andy Zeigler.


 Toolbox: Nouveaux produits pour les professionnels de l'informatique
Toolbox
Nouveaux produits pour les professionnels de l'informatique
Greg Steen

Déplacer vos données
SQL Examiner Bundle
www.sqlaccessories.com
Quel que soit votre rôle dans une organisation (que vous soyez administrateur de base de données, développeur, spécialiste opérationnel ou que vos rôles soient multiples) si vous travaillez avec SQL Server™, vous avez probablement eu à déplacer des données entre des environnements et à faire en sorte que l'intégrité des données et les structures des données restent intactes. Bien sûr, de nombreuses fonctionnalités de réplication et de synchronisation sont intégrées dans SQL Server, mais pour vous assurer que votre base de données AQ correspond exactement à votre base de données de développement, un outil tel que le SQL Examiner Bundle de TulaSoft, qui vous fera gagner du temps et des efforts, peut être très utile.
En quelques clics de souris, l'application peut dénicher les incohérences dans la structure de la base de données ou dans les données elles-mêmes entre deux instances de bases de données. Il vous suffit d'orienter l'application vers les bases de données que vous voulez vérifier et atteindre. Comme son nom le suggère, SQL Examiner Bundle regroupe deux applications : SQL Examiner et SQL Data Examiner. SQL Examiner s'occupe de la structure de vos bases de données, tandis que SQL Data Examiner vérifie toutes les données et met en évidence les différences.
SQL Examiner examinera et comparera tout ce qui se trouve dans vos instances de bases de données, des tableaux aux procédures enregistrées, en passant par les catalogues en texte intégral et les collections de schémas XML. Pour ceux d'entre vous qui utilisent SQL Server 2005, il est également possible de comparer des assemblys CLR (Common Language Runtime). Une fois les bases de données comparées, SQL Examiner vous permet de choisir les objets des bases de données à synchroniser, ainsi que la direction de la synchronisation.
Examinez et comparez vos bases de données avec SQL Examiner
Examinez et comparez vos bases de données avec SQL Examiner (Cliquer sur l'image pour la réduire)
Examinez et comparez vos bases de données avec SQL Examiner
Examinez et comparez vos bases de données avec SQL Examiner (Cliquer sur l'image pour l'agrandir)
Une fonctionnalité vraiment appréciable réside dans le fait que l'application produit le script SQL qui crée un objet et mettra en évidence les différences dans ce script généré entre vos bases de données. Il s'agirait là d'un moyen formidable de mettre en évidence des erreurs après l'échec d'une création de script ou d'une migration de script lors de la construction de la structure de votre base de données cible. (« Oh, c'est là que j'avais laissé mon index en cluster ! ») Vous pouvez exécuter individuellement les scripts générés, enregistrer les scripts pour les exécuter plus tard ou tout simplement cliquer sur le bouton Synchroniser et laisser l'application faire tout le travail pour vous.
Autre fonctionnalité intéressante : l'option d'ajout d'exclusions à la comparaison (par exemple, ignorer les commentaires, les déclencheurs, les index ou les propriétés étendues d'un objet). Après avoir étudié la comparaison des structures, SQL Data Examiner vous permet d'examiner les données pour y trouver d'éventuelles incohérences. Vous pouvez choisir les tableaux que vous souhaitez comparer, voire même des colonnes précises au sein des tableaux spécifiés. Une fois la comparaison des tableaux de données terminée, vous pouvez voir quelles lignes sont identiques, celles qui sont différentes et celles qui sont présentent dans une seule des deux bases de données.
À l'instar de SQL Examiner, SQL Data Examiner vous permet de cliquer sur un bouton pour synchroniser les tableaux. Vous avez également la possibilité de sélectionner les données à transférer ainsi que la direction de ce transfert. Les deux applications vous permettent d'enregistrer votre installation en tant que projet. Vous n'aurez donc pas à recréer les tâches à chaque fois. Chaque application peut être achetée séparément, mais si j'en crois mon expérience, je parie que vous voudrez les deux.
Prix : 299,95 $ pour une licence utilisateur unique.

Rechercher des fichiers dupliqués
zsDuplicateHunter (Professional Edition)
Zizasoft
Si vous êtes impliqué dans la gestion des postes de travail, vous êtes sans doute déjà tombé sur un utilisateur qui « manque d'espace » sur son ordinateur. Après enquête, il s'avère que cet utilisateur réalise une copie de ses documents à chaque fois qu'il leur apporte une modification, bien qu'il y ait un système NAS (Network Attached Storage) sauvegardé permettant à vos utilisateurs de stocker des fichiers. À moins que vous n'ayez un serveur de journaux dans lequel des traitements par lot ont réussi à dupliquer des journaux énormes, ce qui occupe tout l'espace de serveur alloué. zsDuplicateHunter Professional Edition, un système de recherche de duplications basé sur Java qui peut être exécuté sur Windows®, Linux ou MAC OS X, peut résoudre de tels problèmes.
L'application vous permet d'effectuer des recherches facilement dans des lecteurs, des répertoires ou des partages réseau pour y trouver d'éventuels doublons. Au-delà des comparaisons de noms, l'application vous permet de regrouper des fichiers en fonction de leurs tailles, de leurs sommes de contrôle, voire même du calcul des fichiers condensés pour faire en sorte que les fichiers que vous nettoyez sont réellement différents. Il n'est pas non plus nécessaire de supprimer vos doublons de façon permanente. Par mesure de précaution, l'application vous permet de déplacer tous les doublons marqués dans un dossier spécifié.
Autre fonctionnalité intéressante : l'option « Keep Files in this Folder, Delete Duplicates Elsewhere » (Garder les fichiers de ce dossier, supprimer les doublons ailleurs) qui vous permet de choisir votre répertoire source propre et d'éliminer ceux qui sont sur le disque. Dans les résultats de recherche, vous pouvez également double-cliquer sur les fichiers pour les ouvrir avec une visionneuse de fichier associée, les trier et les sélectionner pour obtenir exactement les résultats dont vous avez besoin. Une fonction « IT pro » intéressante vous permet de définir la mémoire que l'application est autorisée à consommer pour la recherche de doublons. Comme protection supplémentaire, vous pouvez également désactiver les fichiers masqués ou les fichiers système pour vous assurer de ne pas supprimer ce qu'il ne faut pas ou supprimer un fichier géré par le système d'exploitation ou une autre application.
L'édition professionnelle vous offre également un filtre précis sur vos ensembles de résultats de recherches en vous permettant d'appliquer une expression régulière pour trouver les fichiers à éliminer.
Prix : 39,95 $ pour une licence utilisateur unique.

Emmener vos applications avec vous
MojoPac
www.mojopac.com
Si vous passez sans cesse d'un environnement à un autre et que vos applications et paramètres de poste de travail préférés vous manquent, ou si vous n'aimez tout simplement pas laisser vos empreintes sur le poste de travail de quelqu'un d'autre, MojoPac de RingCube Technologies vous intéressera peut-être.
MojoPac vous permet de transporter vos paramètres et vos applications vers n'importe quel système Windows XP (Home, Professional, Media Center ou Tablet) sur un disque dur USB, un périphérique multimédia personnel que vous pouvez connecter au système hôte via USB 2.0, par exemple un Zune ou un iPod, voire un téléphone portable avec suffisamment d'espace de stockage. Au moment de l'écriture de cet article, les hôtes Windows Vista™ et Windows 2000 n'étaient pas pris en charge, mais, d'après la documentation du produit qui se trouve sur le site Web, une mise à niveau prenant en charge ces systèmes d'exploitation devrait être disponible bientôt.
Transporter vos paramètres avec MojoPac
Transporter vos paramètres avec MojoPac (Cliquer sur l'image pour la réduire)
Transporter vos paramètres avec MojoPac
Transporter vos paramètres avec MojoPac (Cliquer sur l'image pour l'agrandir)
Actuellement, MojoPac requiert des privilèges d'administrateur sur le système d'hôte, mais la version 2.0 en cours de développement prendra en charge le mode utilisateur limité. L'outil exécute essentiellement des interférences entre le système d'exploitation hôte et les périphériques de stockage et, lors du premier lancement après l'installation de l'application sur votre périphérique portable, MojoPac déclenche le compte Windows initial configuré pour l'exécution, en configurant vos paramètres personnels pour votre utilisateur MojoPac sur le périphérique MojoPac.
Une fois que vous êtes lancé, il est facile de basculer entre le système hôte et le système Mojo : il vous suffit de cliquer sur la barre d'outils (qui peut être réduite) en haut de votre écran. Vous installez des applications sur votre périphérique Mojo de la même façon que lorsque votre MojoPac est actif. Tant que vous tenez compte de l'avertissement figurant dans les documents Lisez-moi sur l'installation dans un répertoire par défaut, vous devriez être paré.
Au final, MojoPac a le potentiel d'être un grand avantage pour n'importe quel professionnel de l'informatique souvent en déplacement qui souhaite sa propre installation. Vous pourriez par exemple avoir tous vos utilitaires système, renifleurs de paquets et moniteurs de trafic sur votre MojoPac et résoudre les problèmes depuis n'importe quel ordinateur dans votre organisation, sans laisser de traces.
Prix : 49,99 $ pour une licence utilisateur unique.

Critique
Guide de l'administrateur SQL Server 2005
www.aw-bc.com
De plus en plus de groupes informatiques se rendent compte du pouvoir potentiel et de la richesse des fonctionnalités fournies par SQL Server 2005. De la prise en charge étendue des données XML à SQL Server Integration Services (SSIS), en passant par SQL Server 2005 Service Broker, l'application compte tout un tas d'améliorations utiles. Pour vous aider à créer votre propre chemin de mise à niveau ou à gérer votre instance SQL Server récemment mise en place, Buck Woody a écrit un excellent guide de référence : Administrator's Guide to SQL Server 2005 (Addison-Wesley Professional, 2006 - en anglais).
Ce livre vous donne un aperçu des pratiques d'administration appliquées à la nouvelle plate-forme serveur et, contrairement à de nombreuses références disponibles sur le marché, le fait de façon concise. Le livre commence par une section consacrée au dimensionnement correct de votre infrastructure adapté aux besoins de votre application, ainsi qu'un guide des versions de SQL Server les plus appropriés en fonction de différents scénarios. Ici, aussi, vous vous ferez une idée de la façon d'organiser votre infrastructure pour faire en sorte de ne pas vous retrouver avec des goulets d'étranglement de performances évitables sur votre installation.
Le guide présente ensuite les différents outils fournis avec SQL Server, tels que le SQL Server Profiler amélioré et le nouveau SQL Server Management Studio. Vous trouverez également des explications détaillées sur les tâches de maintenance et d'automatisation et verrez comment planifier la croissance en fonction du profilage des serveurs et comment trouver un plan de maintenance adapté à votre implémentation.
Dans le chapitre sur la sécurité, vous apprendrez à sécuriser votre installation, à partir du réseau et du matériel, en passant par le système d'exploitation et l'instance de SQL Server. Vous obtiendrez également un aperçu des services supplémentaires de cryptage, de certificat et de gestion des clés offerts par la nouvelle plate-forme.
Un autre chapitre explique les mécanismes existants pour assurer une disponibilité élevée de votre système, en fonction des besoins de votre implémentation. Vous étudierez les clusters, la mise en miroir des bases de données, la réplication et l'envoi de journaux comme méthodes pour atteindre vos exigences de temps disponible. Maintenant que la virtualisation devient un excellent moyen d'atteindre une haute disponibilité sans la surcharge d'infrastructures physiquement distinctes, le livre vous présente un guide pas-à-pas pour configurer un cluster à deux nœuds à l'aide de Microsoft Virtual Server.
Non seulement le chapitre sur SSIS vous montre comment utiliser le nouvel outil (au revoir DTS !) pour développer et déployer des fonctions d'extraction, de transformation et de chargement de données (ETL), mais il vous explique également comment utiliser les services pour créer des tâches de surveillance, de notification par courrier électronique et de sauvegarde.
Pour finir, les quelques derniers chapitres se consacrent aux services de création de rapports et d'analyse fournis avec la nouvelle plate-forme SQL Server. Vous en apprendrez plus sur la conception et la création de rapports, la gestion de systèmes de création de rapports et ce qu'implique la gestion d'un déploiement de services d'analyse.
Au final, l'Administrator's Guide to SQL Server 2005 est un excellent moyen de vous familiariser avec la gestion, la surveillance et la mise à niveau vers SQL Server 2005.
Prix : $49.99.


 Forum aux questions sur SQL&amp;: Taille de la base de donn&#233;es, Mise en miroir, Transactions marqu&#233;es et autres
Forum aux questions sur SQL&
Taille de la base de données, Mise en miroir, Transactions marquées et autres
Par Nancy Michell

Déplacement de cluster
Q J'ai besoin de déplacer un cluster SQL Server 2000 vers de nouvelles adresses IP pour les deux serveurs physiques sous-jacents, ainsi que le cluster Windows® et le cluster SQL Server™. Vais-je devoir reconstruire l'ensemble de la solution ?
R Non, il vous suffit d'exécuter le module d'installation de SQL Server et de modifier les adresses IP. Voici un article de la base de connaissances qui explique comment faire.

Taille de la base de données
Q J'ai SQL Server 2000 SP4 en production avec une base de données stratégique de presque 10 Go, un modèle de récupération SIMPLE, un fichier primaire de 9 850 Mo et un fichier journal des transactions de 88 Mo. La sauvegarde de la base de données atteint également presque 10 Go. Dois-je réduire la taille de la base de données pour obtenir de meilleures performances ? Si oui, dois-je utiliser DBCC SHRINKDATABASE ou DBCC SHRINKFILE ? (Malheureusement, je ne dispose pas de période hors heures de pointe pour réaliser cette maintenance).
R DBCC SHRINKDATABASE ou DBCC SHRINKFILE ne seront utiles que si de nombreuses suppressions et mises à jour résultant en un plus petit volume de données sont effectuées sur la base de données. Mais la vraie question est : pourquoi vous en inquiétez-vous ? Un espace disque de 10 Go coûte environ 20 $US à l'heure actuelle. Ne serait-il pas plus simple d'ajouter environ 100 Go d'espace disque et de laisser faire ? Les performances diminueront à mesure que l'espace sera plus fragmenté, mais si vous ne pouvez pas effectuer de maintenance, vous n'avez guère d'autre choix. Dans un tel cas, certains choisissent d'utiliser une deuxième copie de la base de données. Ils gardent une copie de sauvegarde à jour avec la réplication, effectuent la maintenance sur la copie de sauvegarde, et font ensuite basculer les applications vers la sauvegarde. Ceci nécessite évidemment quelques modifications de code et le retrait du modèle de récupération SIMPLE (en basculant vers le modèle FULL ou BULK_LOGGED), mais peut représenter une bonne solution à long terme.

Mise à niveau et performances
Q J'ai besoin de déplacer deux applications de SQL Server 2000 vers le SQL Server 2005. Comment puis-je éviter les baisses de performance durant la mise à niveau ?
R De façon générale, les pièges suivants peuvent entraîner une détérioration des performances durant la mise à niveau. Je vous conseille donc d'essayer de les éviter :
  1. Vous n'avez pas reconstruit les statistiques après la mise à niveau vers SQL Server 2005.
  2. Vous avez des clauses JOINS et WHERE qui comparent deux types de données différents, ce qui se traduit par de mauvaises performances, en particulier si le serveur exécutait SQL Server 2000 SP3 ou une version antérieure (voir support.microsoft.com/kb/271566/).
  3. L'instance du serveur SQL Server 2005 n'est pas configurée correctement. La mémoire, les extensions AWE (address windowing extension), les pilotes, etc. sont configurés de façon incorrecte. L'ordinateur exécutant SQL Server 2000 a été modifié. La personne qui a effectué les modifications a quitté l'organisation et n'a pas documenté ses actions, et elles n'ont donc jamais été répétées sur l'instance SQL Server 2005.
  4. L'erreur provient du matériel. Il arrive souvent que du nouveau matériel soit acheté parce que cela semble être une bonne idée en théorie, mais qu'il ne soit pas à la hauteur des besoins dans la réalité.
Avant de mettre une instance de SQL Server en production, il est recommandé d'établir un niveau de performance de référence afin de confirmer les performances que vous comptez obtenir. Ceci peut alors permettre d'éliminer l'infrastructure comme source de problème potentielle. Examinez les compteurs Perfmon tels que disque, E/S et mémoire, et comparez-les entre les différentes instances.

Mise en miroir de la base de données
Q J'utilise la mise en miroir de la base de données et je souhaite activer l'option de base de données READ_COMMITTED_SNAPSHOT. Lorsque j'essaie de l'activer après que la mise en miroir a été configurée, j'obtiens une erreur indiquant que la base de données est dans une session en miroir et que la commande ne peut pas être exécutée.
R Ceci se produit parce que la configuration de l'option READ_COMMITTED_SNAPSHOT nécessite un redémarrage de la base de données pour prendre effet. Il est donc nécessaire d'interrompre la session de mise en miroir, de configurer l'option puis de redémarrer la base de données. Une fois ces étapes terminées, vous pouvez restaurer la mise en miroir. La base de données miroir détectera l'option après l'établissement de la session et l'utilisera en cas de basculement.

Q J'essaie de configurer une mise en miroir asynchrone et j'obtiens une erreur 1418. L'exécution de Netstat -ano indique que SQL Server écoute le port correct sur tous les serveurs. L'erreur apparaît lorsque j'essaie de lancer la mise en miroir. Quel est le problème ?
R Il est possible que votre pare-feu bloque la communication. Il s'agit d'un problème relativement courant qu'il convient d'envisager. Consultez les documents techniques suivants pour une aide plus détaillée : Troubleshooting Database Mirroring Setup et MSSQLSERVER_1418.
Veuillez noter que ce problème n'est pas spécifique à la mise en miroir asynchrone. De fait, il peut également se produire avec la mise en miroir synchrone.
L'erreur que vous obtenez (« L'adresse de réseau de serveur » %.*ls” ne peut pas être atteinte ou n'existe pas. Vérifiez le nom d'adresse de réseau et réitérez la commande ») est correcte. Souvent, le problème n'est pas que le partenaire distant n'existe pas, mais plutôt que ce partenaire distant ne peut tout simplement pas être atteint.
Ceci peut se produire si le partenaire distant est inactif, n'écoute pas le port, ou même si le point de terminaison est inactif (ceci peut arriver si les partenaires ne peuvent pas négocier le même mécanisme de chiffrement ou rencontrent d'autres problèmes d'authentification). Le problème peut également apparaître si le partenaire est bloqué, ce qui peut arriver si le pare-feu du partenaire initie la commande.
D'autres problèmes que vous devrez éventuellement éliminer incluent le nom de la source de données (DSN) et les problèmes de résolution de nom. Il est généralement recommandé d'utiliser des noms de domaine pleinement qualifiés. Ainsi, même si votre pare-feu peut fréquemment constituer la source du problème, n'oubliez pas qu'il existe de nombreuses autres causes potentielles.

Q Je souhaite utiliser la mise en miroir de SQL Server 2005. Toutefois, j'ai entendu dire que la mise en miroir n'est pas recommandée lorsque plusieurs applications se connectent à plusieurs bases de données sur la même instance de SQL Server. Est-ce correct ?
R La réponse dépend en fait de si chaque application a sa propre base de données ou si les applications utilisent des transactions d'une base de données à une autre ou des transactions DTC (Distributed Transaction Coordinator). Si vous utilisez des transactions entre bases de données, il se peut que la mise en miroir introduise des incohérences logiques lors desquelles les transactions ne sont pas validées comme prévu. Vous trouverez ici une bonne explication de ce qui se produit dans ces circonstances.
Si plusieurs bases de données sont utilisées par plusieurs applications et que chaque application a sa propre base de données, la mise en miroir ne causera pas ces problèmes.

Transactions marquées
Q Que sont exactement les transactions marquées, et peuvent-elles être utilisées si l'une des bases de données est SQL Server et que l'autre est Oracle ?
R Le marquage des transactions est une opération effectuée périodiquement par l'administrateur de base de données pour insérer une marque au même endroit dans tous les journaux. Cette action, alliée à la possibilité de restaurer une table sur une marque de transaction, vous permet de restaurer toutes les bases de données au même point. Cette opération peut s'avérer douloureuse parce qu'il est nécessaire de restaurer toutes les bases de données concernées et que des données seront perdues dans toutes les bases de données. Veillez donc à ne pas perdre vos fichiers journaux afin d'éviter d'avoir à la réaliser. Les transactions marquées sont spécifiques à SQL Server. Si vos transactions distribuées incluent des bases de données autres que SQL Server, elles ne peuvent donc pas participer au marquage des transactions. En général, un très petit nombre de systèmes de bases de données distribuées utilisent les marques de transaction. Ils traitent simplement la perte de l'un des journaux des transactions comme un événement catastrophique dont la récupération nécessite beaucoup de travail manuel.

Outil de Conversion Access-To-T-SQL
Q Existe-t-il un outil de conversion Access™-SQL to T-SQ automatisé disponible pour les procédures stockées ?
R Essayez l'assistant de migration de SQL Server (SSMA) pour Access que vous pouvez télécharger. Vous y trouverez également l'Assistant de migration de SQL Server pour Oracle, l'Assistant de migration de SQL Server pour Sybase, et la migration de bases de données Informix vers Microsoft® SQL Server 2000.
Pour la migration à partir d'Access vers SQL Server, vous pouvez utiliser l'Assistant de migration d'Office, mais l'Assistant SSMA pour Access présenté à la figure 1 offre davantage de fonctionnalités, notamment les rapports d'évaluation de conversion et l'analyse du réseau. SSMA pour Access résout également bon nombre de problèmes qui ne sont pas actuellement contrôlés correctement par l'Assistant de migration d'Office.
Figure 1 Assistant de Migration de SQL Server pour Access
Figure 1 Assistant de Migration de SQL Server pour Access (Cliquer sur l'image pour la réduire)
Figure 1 Assistant de Migration de SQL Server pour Access
Figure 1 Assistant de Migration de SQL Server pour Access (Cliquer sur l'image pour l'agrandir)

Index non membre d'un cluster
Q J'ai une table dans laquelle la clé principale est constituée de deux GUID (par exemple GUID1 et GUID2). J'ai déjà seul mon index cluster sur GUID1 et GUID2. Pour des raisons de performance, je souhaite maintenant créer un second index non cluster sur GUID2 et GUID1. Vais-je subir un ralentissement des performances si je déclare l'index comme étant unique ?
R Le fait de déclarer l'index non cluster comme étant unique n'entraîne absolument aucune baisse des performances. En fait, cette opération peut réduire le nombre de niveaux dans l'arborescence de l'index.
Lorsqu'un index non cluster est déclaré comme étant non-unique, le localisateur de ligne est ajouté à la partie clé des entrées d'index à la racine et sur les pages non-feuilles. Ceci est effectué pour faciliter la suppression et la mise à jour des entrées d'index, ce qui évite de devoir analyser une chaîne synonyme lorsqu'il existe des doublons pour une clé puisque l'entrée spécifique à modifier peut être localisée par une opération de recherche de système sur la clé plus le localisateur. Il en résulte que ces entrées sont plus longues (notablement plus longue avec la clé de cluster que vous avez choisie). Par conséquent, la racine et les pages non-feuilles se rempliront naturellement plus vite. Si l'index est unique, vous devez le déclarer comme tel.
Que la table ait un index cluster ou non, tout index de table non cluster qui n'est pas déclaré comme étant unique voit le localisateur ajouté aux entrées d'index dans la racine et dans les autres pages non-feuilles.
Par ailleurs, si vous utilisez une colonne d'identificateur int comme clé de substitution et que vous ajoutez ensuite deux index uniques (GUID1, GUID2) et (GUID2, GUID1), les performances en seront sans doute améliorées puisque les index auront une clé de clustering de 4 octets au lieu d'une clé de clustering de 32 octets.

Mise à jour des verrous
Q J'ai une procédure stockée contenant la structure suivante :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
Cette procédure enregistrée n'autorise qu'un seul appelant à prendre le verrou et fait attendre les autres appelants. Puis-je obtenir le même comportement en réduisant le niveau d'isolation ?
READ COMMITTED semble être le niveau d'isolation correct parce que cette transaction n'a qu'une requête, et si une autre transaction est en train de mettre à jour le même enregistrement, cette transaction attendra la fin de l'autre transaction. Est-ce correct ?
R Ce n'est pas le paramètre sérialisable dans votre exemple qui fait attendre les autres appelants, mais la mise à jour elle-même. Oui, l'isolation peut être configurée sur READ COMMITTED et la mise à jour adopte automatiquement un verrouillage de mise à jour pour l'index qu'elle utilise. Ceci causera des problèmes pour les autres processus exécutant la même instruction. Ils seront donc bloqués jusqu'à ce que la mise à jour soit effectuée. (Vous n'avez pas non plus besoin de la transaction explicite ici si la mise à jour est la seule instruction. En effet; chaque instruction est implicitement dans sa propre transaction si elle n'est pas dans une transaction explicite).
Cependant, s'il n'y a pas de ligne correspondant à la clause WHERE dans l'instruction UPDATE, l'utilisation du niveau d'isolation sérialisable empêche l'insertion ou la modification de telles lignes dans d'autres transactions. Si vous exécutez l'isolation UPDATE dans READ COMMITTED, ceci ne se produit pas et d'autres transactions peuvent introduire des lignes pouvant être mises à jour. Si le code de la procédure stockée est semblable au code que vous avez illustré, il n'est pas nécessairement utile d'effectuer ces actions (sérialisables ou transactions). Il vous suffit d'exécuter la mise à jour.

Merci aux informaticiens Microsoft nommés ci-dessous pour leur expertise technique : Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip et Frankie Yuen.


 Coup de projecteur sur les utilitaires: Group&#160;Policy&#160;Inventory
Coup de projecteur sur les utilitaires
Group Policy Inventory
Greg Steen
Télécharger le code de cet article: GPInventory.exe (150KB)

COMMENT savoir ce dont vous disposez si vous n’en assurez pas le suivi ? Avoir des informations sur vos inventaires à portée de main peut vous épargner quelques migraines lorsque la saison des réunions d'affectation de budget et des audits revient. Et, bien entendu, les instances supérieures semblent toujours vouloir savoir qui dispose de quoi et pourquoi, et ce qui sera nécessaire pour entreprendre cette mise à niveau majeure.
Un outil peut vous aider à gérer tout cela : Group Policy Inventory (GPInventory.exe), fourni avec le Kit de ressources Windows Server® 2003. Ce programme vous permet d'interroger et d'extraire des informations système par le biais de requêtes RSOP (Jeu de stratégie d'utilisateur résultant) et/ou WMI (Windows® Management Instrumentation) à partir de plusieurs hôtes distants, comme illustré à la figure suivante. Sans surprise, le programme récupère facilement les informations de stratégie de groupe, mais il s'agit également d'un moyen efficace pour extraire des informations système détaillées, par exemple les applications installées, le nom et la vitesse du processeur ou la liste de correctifs logiciel installés. Mais attendez, ce n'est pas tout ! Comme il fait partie du Kit de ressources Windows Server 2003, il est entièrement gratuit.
Figure 1 Utilisation de GPInventory pour obtenir des informations
Figure 1 Utilisation de GPInventory pour obtenir des informations (Cliquer sur l'image pour la réduire)
Figure 1 Utilisation de GPInventory pour obtenir des informations
Figure 1 Utilisation de GPInventory pour obtenir des informations (Cliquer sur l'image pour l'agrandir)
GPInventory.exe peut être utilisé de nombreuses façons. Par exemple, si vous avez besoin de vérifier l'état d'une garantie, vous pouvez recueillir les numéros de série ou de service des ordinateurs de votre réseau sans devoir aller vérifier chaque boîtier. Ou bien, si vous avez un environnement de laboratoire et que vous voulez savoir si une machine est actuellement utilisée, vous pouvez lancer une requête pour connaître les utilisateurs connectés au système sans quitter votre fauteuil. Si vous avez un serveur lame sur lequel des images sont régulièrement envoyées aux lames (afin de nettoyer et de restaurer votre environnement d'Assurance Qualité, par exemple), vous pouvez lancer une requête sur la date d'installation de l'ordinateur pour vérifier quand la dernière image a été envoyée.
GPInventory est aussi très facile à utiliser. Vous lui indiquez un fichier contenant une liste d'ordinateurs que vous souhaitez inventorier, sélectionnez les requêtes à exécuter, puis traitez la liste. L'outil se connecte ensuite à chaque ordinateur de la liste et l'interroge. Si vous effectuez une requête rapide, vous pouvez aussi sélectionner les ordinateurs cibles directement à partir d'Active Directory® et les actions de requête à exécuter à partir du menu d'interrogation.
Pour exécuter une requête RSOP sur une machine, vous devez disposer d'une autorisation Générer le Jeu de stratégie résultant (Enregistrement), (qui est alloué par défaut aux administrateurs de domaine et aux administrateurs délégués). Les requêtes WMI nécessitent des droits administratifs sur l'ordinateur distant à moins que vous n'utilisiez le composant logiciel enfichable MMC de contrôle de WMI pour accorder à un autre utilisateur des droits Activer le compte et Appel à distance autorisé sur l'espace de noms root\cimv2.
Une fois la requête exécutée, vous pouvez enregistrer les résultats sous forme de fichier texte délimité par des tabulations ou de fichier XML. Ces deux types de fichier peuvent être importés dans Microsoft® Excel® pour être analysés. Vous pouvez les trier et leur appliquer un filtre automatique pour rechercher toutes les informations.
GPInventory prend également en charge l'exécution de ligne de commande, ce qui signifie que vous pouvez facilement définir une tâche planifiée pour interroger les informations système et les enregistrer directement sur un fichier XML, sans intervention d'une interface graphique. Ceci peut être très utile pour les requêtes de longue durée pour lesquelles une exécution en dehors des heures de bureau est plus adaptée.
L'outil est fourni avec un ensemble de requêtes RSOP et WMI par défaut, mais vous pouvez ajouter, modifier et mettre à jour le fichier de requêtes avec votre propre liste personnalisée si le requêtes dont vous avez besoin n'y figure pas. Le document d'aide inclus vous explique comment définir une nouvelle requête dans le fichier XML de liste de requêtes.
GPInventory.exe est un outil formidable pour la collecte d'informations à partir des machines de votre réseau fonctionnant sous Windows, qu'il s'agisse d'informations d'inventaire, de stratégie de groupe ou d'état. Vous trouverez un lien vers l'outil Group Policy Inventory dans la section de téléchargements de notre site Web.

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


 Le petit c&#226;bleur: Prise en charge de la qualit&#233; de service (QoS) dans Windows
Le petit câbleur
Prise en charge de la qualité de service (QoS) dans Windows
Joseph Davies
Cet article est en partie basé sur une version bêta de Windows Server « Longhorn ». Toutes les informations contenues dans le présent document sont susceptibles d'être modifiées.

La qualité de Service (QoS) englobe une série de technologies destinées à gérer le trafic réseau de façon économique afin d'améliorer l'expérience des utilisateurs dans les environnements domestiques et d'entreprise. Les technologies de QoS vous permettent de mesurer la bande passante, de détecter les modifications de l'état du réseau (par exemple des situations de congestion ou de disponibilité de la bande passante),
et de hiérarchiser ou de limiter le trafic. Ainsi, la qualité de service peut être appliquée à la hiérarchisation de la livraison d'un trafic sensible à la latence (comme c'est le cas pour les applications vocales et vidéo) et au contrôle de l'impact du trafic non sensible à la latence, tel que les transferts de données en masse. Assurer une livraison hiérarchisée du trafic TCP/IP nécessite une prise en charge de la part des périphériques hôtes et d'infrastructure du réseau. Cet article décrit les méthodes permettant d'utiliser la qualité de service (QoS) avec des hôtes basés sur Microsoft® Windows®.
Lorsque l'on tente de définir la QoS pour les réseaux TCP/IP, le problème principal consiste à savoir comment préciser et assurer une livraison hiérarchisée du trafic IP. Bien que le RFC 791 pour IP original ait défini le champ Type de Service (TOS) en lui octroyant la capacité de spécifier des caractéristiques de priorité, retard, débit, fiabilité et coût, la technologie IP est, fondamentalement, une technologie de commutation de paquets de type Meilleur effort basée sur datagramme qui traite normalement chaque paquet de la même façon ou sur la base du premier arrivé, premier servi.

Configuration d'une livraison hiérarchisée
Plusieurs possibilités s'offrent à vous si vous recherchez un service de livraison hiérarchisée. Vous pouvez notamment configurer l'infrastructure du réseau afin que le trafic marqué reçoive un traitement spécial et que les hôtes envoyeurs marquent leur trafic sortant. Vous pouvez également faire en sorte que les hôtes expéditeurs programment l'infrastructure du réseau de façon dynamique pour instaurer un traitement spécial en fonction des caractéristiques de leur trafic sortant (par exemple les adresses et numéros de port).
Pour le trafic TCP/IP, vous pouvez utiliser plusieurs méthodes différentes permettant d'assurer une livraison hiérarchisée. Par exemple, au niveau de la couche d'interface réseau pour Ethernet, le marquage IEEE 802.1p s'appliquera aux cadres envoyés pour livraison hiérarchisée par un hôte utilisant un champ de priorité de 3 bits dans l'en-tête réseau local virtuel (VLAN) du cadre Ethernet. L'en-tête VLAN est placé dans l'en-tête Ethernet, entre le champ Adresse source et le champ Longueur (pour un cadre IEEE 802.3) ou EtherType (pour un cadre Ethernet II).
L'implémentation du marquage 802.1p sur un hôte expéditeur nécessite que l'adaptateur réseau et le pilote de périphérique prennent en charge le standard 802.1p et que la prise en charge 802.1p soit activée sur l'adaptateur réseau. Généralement, la prise en charge 802.1p peut s'activer depuis l'onglet Avancé des propriétés des pilotes de carte réseau. La prise en charge 802.1p doit également être activée sur les commutateurs Ethernet.
Au niveau de la couche d'interface réseau pour IEEE 802.11 sans fil, la certification Wi-Fi Alliance pour Wi-Fi Multimédia (WMM) définit quatre catégories d'accès pour la hiérarchisation du trafic réseau. Ces catégories d'accès sont les suivantes (classées de la priorité la plus élevée à la priorité la plus basse) : voix, vidéo, meilleur effort et arrière-plan. La prise en charge de la définition des priorités WMM nécessite que les adaptateurs réseau et leurs pilotes prennent en charge le WMM. Le WMM doit être activé sur les points d'accès sans fil (AP).
Au niveau de la couche Internet, vous pouvez utiliser des services différenciés et préciser la valeur DSCP (Differentiated Services Code Point) dans l'en-tête IP. Comme défini dans le RFC 2472, la valeur DSCP est le nombre 6 bits d'ordre haut du champ Type de service d'IP version 4 (IPv4) et du champ Classe de trafic d'IP version 6 (IPv6).
La plupart des routeurs d'entreprise modernes prennent en charge la différenciation de trafic DSCP, mais celle-ci est généralement désactivée par défaut. Pendant le transfert, les routeurs compatibles DSCP lisent la valeur DSCP et placent le paquet dans une file d'attente spécifique. Par exemple, vous pouvez configurer vos routeurs pour qu'ils placent les paquets dans les files d'attente haute priorité, meilleur effort ou inférieur au meilleur effort en fonction des valeurs DSCP que vous définissez. Une fois les files d'attente et les valeurs DSCP configurées, le trafic marqué DSC peut présenter des niveaux de service différenciés. Par exemple, le trafic réseau stratégique pour l'entreprise est privilégié au transfert et n'est pas retardé par un autre trafic de données de moindre priorité. La spécification WMM définit la façon dont les catégories d'accès WMM les catégories d'accès sont associées aux valeurs DSCP. Un AP sans fil compatible WMM lit la valeur DSCP et contrôle le trafic en fonction de sa catégorie d'accès.
Au niveau de la couche Internet, vous pouvez également utiliser le protocole RSVP, un protocole de signalisation défini dans le RFC 2205. Les hôtes peuvent utiliser ce protocole pour tenter de réserver de la bande passante sur un réseau jusqu'à un point final. Cependant, le protocole RSVP n'est pas largement déployé sur les réseaux et, actuellement, il n'est pas pris en charge par Windows XP, Windows Server® 2003, Windows Vista™ ni par la prochaine version de Windows Serveur nom de code « Longhorn » (actuellement en version bêta).
Pour envoyer des paquets marqués en vue d'une livraison hiérarchisée, les composants des applications ou du système d'exploitation doivent pouvoir spécifier les valeurs de la priorité 802.1p ou la valeur DSCP. Les sections suivantes décrivent comment des composants de Windows ou les applications Windows peuvent spécifier la priorité 802.1p pour les cadres Ethernet ou la valeur DSCP pour le trafic TCP/IP.

Qualité de service (QoS) dans Windows XP et Windows Server 2003
Windows XP et Windows Server 2003 fournissent des API permettant d'attribuer des paramètres de QoS au trafic. Les développeurs d'applications peuvent utiliser des API Windows Socket (Winsock) et de QoS générique (GQoS) pour appliquer les paramètres de QoS au niveau de l'application pour chaque socket. Les administrateurs réseau peuvent utiliser les outils de gestion du trafic écrits pour appeler l'API de contrôle du trafic (TC) afin d'appliquer des paramètres de qualité de service au niveau de l'hôte.
Vous pouvez utiliser Winsock et l'option de socket IP_TOS pour déterminer la valeur DSCP des paquets sortants pour un socket. Cependant, par défaut, la pile TCP/IP ignore l'option de socket IP_TOS. Pour utiliser l'option de socket IP_TOS, vous devez d'abord créer et définir la valeur de registre DWORD DisableUserTOSSetting = 0 sous la clé de registre suivante (voir la figure 1) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Figure 1 Configuration de la valeur de registre de DisableUserTOSetting
Figure 1 Configuration de la valeur de registre de DisableUserTOSetting
Vous devez redémarrer l'ordinateur pour que ce paramètre de registre prenne effet.
Pour spécifier la valeur DSCP du trafic sans avoir à utiliser l'option de socket IP_TOS, vous pouvez utiliser les API GQoS. GQoS fait partie de Windows Sockets 2.0 (Winsock2). La plupart des applications compatibles avec QoS utilisent l'API GQoS pour invoquer les fonctionnalités de QoS de Windows. Dans Windows XP Service Pack 2 (SP2), GQoS autorise une application à déterminer une valeur DSCP et à limiter son trafic sortant. Pour déterminer des priorités 802.1p sur les ordinateurs exécutant Windows XP SP2, vous devez utiliser l'API TC.
L'API TC permet d'accéder aux mécanismes de contrôle de trafic qui régulent le trafic réseau sur l'hôte local. Elle permet un contrôle direct sur les valeurs DSCP, les étiquettes 802.1p et le taux de limitation. Les administrateurs réseau peuvent utiliser les programmes de gestion de trafic pour invoquer directement l'API TC pour le compte d'applications qui ne reconnaissent pas QoS. Comme le niveau de cette API est inférieur à celui de l'API GQoS, l'API TC nécessite des privilèges d'administrateur.
Contrairement à l'API GQoS, l'API TC autorise l'agrégation du trafic provenant de plusieurs applications situées sur le même hôte expéditeur dans un flux unique de qualité de service (QoS). Dans le cadre de cette agrégation, le trafic peut être identifié par une combinaison de ses adresses IP source et de destination, de ses ports source et de destination et du protocole (TCP ou UDP). Par exemple, tout le trafic envoyé vers une adresse IP de destination spécifique peut être inclus dans un flux de QoS unique pour n'importe quel port source et port de destination, indépendamment de l'application d'expédition sur l'hôte. Par ailleurs, l'API GQoS permet à une application de définir son propre traitement de QoS sur les données qu'elle envoie par un socket.
Pour que la fonctionnalité de qualité de service (QoS) soit prise en charge par les ordinateurs exécutant Windows XP et Windows Server 2003, le composant Planificateur de paquets QoS doit être installé et activé depuis les propriétés des connexions réseau dans le dossier Connexions Réseau (voir la figure 2). Le composant Planificateur de paquets QoS (lPsched.sys) est installé et activé par défaut sur les ordinateurs exécutant Windows XP. Le composant Planificateur de paquets peut être installé sur Windows Server 2003.
Figure 2 Configuration du Planificateur de paquets QoS
Figure 2 Configuration du Planificateur de paquets QoS

Qualité de service (QoS) dans Windows Vista et Windows Server « Longhorn »
La prise en charge de la qualité de service dans Windows Vista et Windows Server « Longhorn » a été améliorée et simplifiée. Pour le personnel informatique, il est désormais possible d'utiliser une qualité de service basée sur les stratégies pour déterminer les valeurs DSCP et contrôler les taux d'expédition des applications sans devoir utiliser d'API ni modifier d'application existante. Pour les développeurs, les API GQoS et TC sont prises en charge, bien que la prise en charge de ces API ne soit pas prévue dans les futures versions de Windows. De plus, l'option IP_TOS de Winsock a été supprimée. Pour remplacer les API GQoS et TC et simplifier la prise en charge de la qualité de service dans des applications futures ou mises à niveau, Windows Vista et Windows Server « Longhorn » prennent en charge la nouvelle API QoS2, également connue sous le nom de qWAVE (Quality Windows Audio-Video Experience).
Dans Windows Server « Longhorn » et Windows Vista, la qualité de service (QoS) basée sur les stratégies vous permet d'améliorer l'expérience de l'utilisateur final ainsi que le contrôle des coûts de la bande passante, ou de négocier de meilleurs niveaux de service avec les fournisseurs de bande passante ou les services d'exploitation. Vous pouvez gérer de façon centralisée la bande passante du réseau pour les ordinateurs exécutant Windows Vista ou Windows Server « Longhorn », indépendamment de l'application et dans toute une infrastructure Active Directory®. Étant donné que la gestion de trafic intervient en dessous de la couche d'application, les applications existantes n'ont pas besoin d'être modifiées pour la gestion du trafic QoS basée sur les stratégies.
Dans Windows Server « Longhorn » et Windows Vista, les paramètres de qualité de service basée sur les stratégies vous permettent de hiérarchiser ou de gérer le taux d'expédition pour le trafic sortant en fonction des conditions suivantes :
  • L'application qui envoie (chemin d'accès et nom de l'exécutable)
  • Les adresses IPv4 ou IPv6 source ou de destination ou les préfixes d'adresse
  • Le protocole (lTCP, UDP ou les deux)
  • Les ports sources ou de destination ou les étendues de ports (TCP ou UDP)
Les stratégies de QoS sont appliquées à une session de connexion utilisateur ou à un ordinateur en tant qu'élément d'un objet de stratégie de groupe (GPO) lié à un conteneur Active Directory tel qu'un domaine, un site ou une unité d'organisation (UO), ou elles peuvent être appliquées à un groupe de sécurité. En tant qu'éléments d'une stratégie de groupe, les stratégies de QoS sont générées sur votre infrastructure de gestion Active Directory existante.
La qualité de service (QoS) basée sur les stratégies vous permet de définir la priorité du trafic. Vous pouvez configurer une stratégie de QoS pour marquer le trafic IPv4 ou IPv6 sortant avec une valeur DSCP spécifique. Vous pouvez également gérer l'utilisation de la bande passante pour le trafic sortant. Vous pouvez configurer une stratégie de QoS pour appliquer un taux de limitation au trafic sortant. Grâce à la limitation, les composants de QoS limitent le trafic réseau sortant agrégé à un taux spécifié. Pour les ordinateurs, vous pouvez gérer l'utilisation de la bande passante pour le trafic entrant et configurer des paramètres avancés de façon à spécifier le débit entrant pour le trafic TCP en définissant la valeur maximale de la taille de la fenêtre de réception de TCP.
Dans Windows Vista et Windows Server « Longhorn, » le Planificateur de paquets QoS est installé et activé par défaut. Le composant Pacer.sys est un nouveau pilote de filtre NDIS 6.0 léger qui contrôle la planification des paquets pour la qualité de service (QoS) basée sur les stratégies et pour le trafic d'applications compatibles QoS. Pacer.sys remplace Psched.sys dans Windows XP et Windows Server 2003.
Pour déployer une qualité de service basée sur les stratégies sur votre intranet, configurez les stratégies de QoS basées sur l'utilisateur ou l'ordinateur et appliquez-les au conteneur Active Directory approprié. Les ordinateurs Windows Vista ou Windows Server « Longhorn » téléchargent et appliquent leurs paramètres de QoS basée sur les stratégies lorsqu'ils mettent à jour leur configuration utilisateur ou leur stratégie de groupe de configuration de l'ordinateur.
Du fait que les réseaux sont de plus en plus souvent partagés par les applications de données et les applications audio/vidéo (AV), il convient d'implémenter une solution de QoS pour pouvoir assurer un traitement préférentiel au trafic AV avec période de validité par rapport au trafic de données. En outre, les réseaux sont de plus en plus souvent sans fil, ce qui ajoute des complications pour les applications sensibles à la latence et à la bande passante.
Dans Windows Vista, la fonctionnalité qWAVE fournit un ensemble de modules logiciels relatifs à Qos qui répondent aux défis posés par l'introduction d'applications AV et de réseaux sans fil. La fonctionnalité qWAVE est intégrée au sous-système QoS et utilise de nombreuses technologies Internet et de priorité des paquets au niveau de la couche d'interface réseau. qWAVE prend simultanément en charge plusieurs flux AV (flux en temps réel nécessitant QoS) et flux de données (lux de type Meilleur effort tels que le courrier électronique ou les transferts de fichiers).
L'ensemble de technologies qWave détecte et contrôle la bande passante sur le réseau local, détermine la capacité QoS du réseau et assure un contrôle d'admission distribué pour une utilisation à la fois juste et cohérente de la bande passante réseau. Ces technologies permettent l'utilisation des techniques de diffusion AV en flux continu pour que les applications puissent s'adapter dynamiquement à l'évolution des conditions du réseau, et ne sont accessibles aux développeurs que par le biais de l'API QoS2.
Dans Windows Vista et Windows Server « Longhorn », l'API QoS2 remplace l'API GQoS et l'option IP_TOS de Winsock et devrait s'avérer plus facile à utiliser que l'API GQoS.

Pour plus d'informations
Pour en savoir plus sur la qualité de service (QoS), il existe plusieurs sources d'excellente qualité disponibles sur Technet. Vous pouvez commencer par consulter le site Web de Microsoft sur la qualité de service. Consultez également la section sur la qualité de service (QoS) du blog Windows Core Networking (en anglais).

Joseph Daviesest rédacteur technique chez Microsoft. Il enseigne et rédige des articles sur les questions relatives aux réseaux Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press® et est l'auteur des articles mensuels du petit câbleur de Technet


 Windows&#160;PowerShell: &#201;criture de scripts une ligne &#224; la fois
Windows PowerShell
Écriture de scripts une ligne à la fois
Don Jones

Dans de précédents articles, j'ai insisté sur le fait que Windows PowerShell est un shell. Il est destiné à une utilisation interactive, un peu comme le shell cmd.exe (ou invite de commande) que vous connaissez sans doute déjà. Ceci dit, Windows PowerShell prend en charge un langage de script : ce langage est plus robuste que le langage de lot de cmd.exe. Il est
également tout aussi puissant, voire plus, que des langages comme VBScript. Cependant, le fait que Windows PowerShell™ est un shell interactif facilite considérablement l'apprentissage de l'écriture des scripts. En fait, vous pouvez développer des scripts de façon interactive à l'intérieur du shell, ce qui permet d'écrire des scripts une ligne à la fois et de voir immédiatement le résultat de vos efforts.
Cette technique d'écriture des scripts interactifs facilite également le débogage. Puisque vous voyez les résultats de votre script immédiatement, vous pouvez le réviser rapidement lorsque le résultat n'est pas celui attendu.
Dans cet article, je vous décrirai étape par étape un exemple d'écriture de script interactif dans Windows PowerShell. Je créerai un script lisant les noms de services à partir d'un fichier texte et définissant le mode de démarrage de chaque service sur Désactivé.
J'aimerais que vous reteniez de cette description le concept de création morceau par morceau de scripts Windows PowerShell, plutôt que d'essayer de s'attaquer à un script entier en une fois. Vous pouvez prendre n'importe quelle tâche administrative à accomplir et la décomposer pour comprendre comment faire fonctionner chaque composant de manière indépendante. Windows PowerShell fournit d'excellents moyens de relier ces morceaux. Vous découvrirez aussi qu'en travaillant morceau par morceau, vous aurez moins de mal à développer le script final.

Lecture de noms à partir d'un fichier
Il n'est pas toujours évident de comprendre comment lire des fichiers texte dans Windows PowerShell. Si j'exécute Help *file*, je n'obtiens que le cmdlet Out-File, qui envoie du texte à un fichier, plutôt que de lire dans le fichier. Pas très utile ! Cependant, les noms de cmdlets Windows PowerShell suivent une certaine logique que je peux utiliser à mon avantage. Lorsque Windows PowerShell récupère quelque chose, le nom de cmdlet commence généralement par Get. Donc j'exécute Help Get* pour afficher ces cmdlet, puis je fais défiler la liste jusqu'à Get-Content. Cela paraît prometteur ! J'exécute donc Help Get-Content pour en savoir plus (voir la figure 1) et on dirait que c'est ce qu'il me faut.
Figure 1 Exécution de Help Get-Content pour plus d'informations
Figure 1 Exécution de Help Get-Content pour plus d'informations (Cliquer sur l'image pour la réduire)
Figure 1 Exécution de Help Get-Content pour plus d'informations
Figure 1 Exécution de Help Get-Content pour plus d'informations (Cliquer sur l'image pour l'agrandir)
Windows PowerShell traite presque tout comme un objet et c'est le cas notamment pour les fichiers texte. D'un point de vue technique, un fichier texte est un ensemble de lignes, chaque ligne du fichier jouant en quelque sorte le rôle d'un objet indépendant. Donc, si j'ai créé un fichier texte nommé C:\services.txt et que je l'ai rempli de noms de services (en plaçant chaque nom sur sa propre ligne à l'intérieur du fichier), Windows PowerShell peut lire les noms individuellement à l'aide du cmdlet Get-Content. Puisque l'idée de cette description est de montrer comment les scripts peuvent être développés de façon interactive, je commencerai par exécuter Get-Content, en lui donnant le nom de mon fichier texte, avant de voir ce qui se passe :
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Comme prévu, Windows PowerShell lit le fichier et affiche le nom. Bien entendu, l'affichage des noms n'est pas exactement ce qui m'intéresse, mais maintenant je sais que Get-Content fonctionne comme je le veux.

Modification d'un service
À présent, je souhaite modifier le mode de démarrage d'un service. À nouveau, je commence par essayer de trouver le bon cmdlet. J'exécute donc Help *Service*. Ceci renvoie une liste courte et le cmdlet Set-Service a l'air d'être le seul adapté à mes besoins. Je veux tester ce cmdlet pour m'assurer que je comprends comment il marche avant d'essayer de l'incorporer dans un script. L'exécution de Help Set-Service me montre comment le cmdlet doit fonctionner et un test rapide le confirme :
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Association des deux parties
Je dois maintenant associer la capacité de lire des noms de services à partir d'un fichier au cmdlet Set-Service et c'est là que les fonctionnalités de pipeline puissantes de Windows PowerShell entrent en jeu. Avec le pipeline, le résultat d'un cmdlet peut servir d'entrée pour le second cmdlet. Le pipeline fait passer des objets entiers. Au cas où un ensemble d'objets est placé dans le pipeline, chaque objet passe par le pipeline individuellement. Cela signifie que le résultat de Get-Content qui, souvenez-vous, est un ensemble d'objets, peut être transmis à Set-Service. Étant donné que Get-Content fait passer un ensemble, chaque objet ou ligne de texte de l'ensemble est transmis à Set-Service individuellement. Il en résulte que Set-Service est exécuté une fois pour chaque ligne dans mon fichier texte. Voici à quoi ressemble la commande :
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Voici ce qui se produit :
  1. Le cmdlet Get-Content s'exécute, en lisant le fichier entier. Chaque ligne du fichier est traitée comme un objet unique et ensemble elles représentent un ensemble d'objets.
  2. L'ensemble d'objets est transmis à Set-Service.
  3. Le pipeline exécute le cmdlet Set-Service une fois pour chaque objet d'entrée. Pour chaque exécution, l'objet d'entrée est transféré à Set-Service comme premier paramètre du cmdlet, c'est-à-dire le nom de service.
  4. Set-Service s'exécute, en utilisant l'objet d'entrée pour son premier paramètre et les autres paramètres spécifiés, le paramètre -startuptype, dans ce cas.
Il est intéressant de souligner qu'en fait, à ce stade, j'ai accompli ma tâche sans avoir écrit un seul script. Il serait difficile de réaliser cette même action dans le shell Cmd.exe et cela nécessiterait une dizaine de lignes de code dans VBScript. Mais Windows PowerShell réalise tout cela en une ligne. Ceci dit, je n'ai pas complètement fini. Comme vous pouvez le voir, ma commande ne fournit pas beaucoup de sorties d'états ou de commentaires. En dehors du manque d'erreurs, il est difficile de voir si quelque chose s'est produit. À présent que je maîtrise la fonctionnalité nécessaire pour accomplir ma tâche, je peux commencer à la rendre plus attrayante en écrivant des scripts.
Invite de Windows PowerShell ici par Michael Murgolo
L'outil Ouvrir une fenêtre de commandes ici est l'un des PowerToys Microsoft® pour Windows® les plus populaires (et également l'un de mes préférés). Disponible dans le cadre des PowerToys Microsoft pour Windows XP ou dans les outils du kit de ressources Windows Server® 2003, Ouvrir une fenêtre de commandes ici vous permet de cliquer avec le bouton droit de la souris sur un dossier ou lecteur dans Windows Explorer pour ouvrir une fenêtre de commandes qui pointe vers le dossier sélectionné.
En découvrant Windows PowerShell, je me suis pris à souhaiter y voir la même fonctionnalité. Je me suis donc emparé du fichier .inf de configuration d'Ouvrir une fenêtre de commandes ici, cmdhere.inf, à partir des outils du kit de ressources Windows Server® 2003. Puis, je l'ai modifié pour créer un menu contextuel Invite de Windows PowerShell ici. Ce fichier .inf est inclus avec le message de blog original sur lequel se base cet encadré (disponible à l'endroit suivant : leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). Pour installer l'outil, cliquez avec le bouton droit de la souris sur le fichier .inf et sélectionnez Installer.
En créant la version Windows PowerShell de cet outil, j'ai découvert que l'original avait un bogue : si Ouvrir une fenêtre de commandes ici était désinstallé, il resterait une entrée inutilisée dans le menu contextuel. Par conséquent, j'ai fourni une version mise à jour de cmdhere.inf, également disponible sur le message de blog original.
Ces deux PowerToys tirent parti du fait que ces entrées de menu contextuel sont configurées dans le registre sous des clés associées au Répertoire et aux types d'objets Lecteur. Ceci est semblable aux actions de menu contextuel qui sont associées à des types de fichiers. Par exemple, lorsque vous cliquez avec le bouton droit sur un fichier .txt dans Windows Explorer, plusieurs actions (telles que Ouvrir, Imprimer et Modifier) figurent en haut de la liste. Pour comprendre comment ces éléments sont configurés, examinons la ruche de registre HKEY_CLASSES_ROOT.
Si vous ouvrez l'Éditeur du Registre et que vous développez la branche HKEY_CLASSES_ROOT, vous verrez des clés nommées pour les types de fichiers tels que .doc, .txt et autres. Si vous cliquez sur la clé .txt, vous verrez que la valeur (par défaut) est txtfile (voir la figure A). Il s'agit du type d'objet associé à un fichier .txt. En faisant défiler vers le bas et en développant la clé txtfile, puis en développant la clé de shell correspondante, vous verrez des clés nommées pour certaines des entrées du menu contextuel pour un fichier .txt. (Vous ne les verrez pas toutes parce qu'il y a d'autres méthodes de création de menus contextuels). Sous chacune d'entre elles se trouve une clé de commande. La valeur (par défaut) se trouvant sous la clé de commande est la ligne de commande que Windows exécute lorsque vous sélectionnez cet élément du menu contextuel.
Les outils de l'invite cmd et de l'invite Windows PowerShell utilisent cette technique pour configurer les entrées de menu contextuel Ouvrir une fenêtre de commandes ici et Invite Windows PowerShell ici. Il n'y a pas de type de fichier associé aux lecteurs et aux répertoires, mais il y a des clés Lecteur et Répertoire sous HKEY_CLASSES_ROOT associées à ces objets.
Figure A Les entrées de menu contextuel sont configurées dans le Registre.
Figure A Les entrées de menu contextuel sont configurées dans le Registre. (Cliquer sur l'image pour la réduire)
Figure A Les entrées de menu contextuel sont configurées dans le Registre.
Figure A Les entrées de menu contextuel sont configurées dans le Registre. (Cliquer sur l'image pour l'agrandir)

Michael Murgolo est consultant en infrastructure senior pour Microsoft Consulting Services. Il est spécialisé dans les domaines des systèmes d'exploitation, du déploiement, des services réseau, d'Active Directory, de la gestion des systèmes, de l'automatisation et de la gestion des correctifs.

Écriture interactive de scripts
J'ai besoin d'avoir une exécution de plusieurs cmdlets pour chaque service répertorié dans C:\services.txt. De cette façon, je peux générer le nom de service et toutes les informations qui m'intéressent, afin de pouvoir suivre la progression du script.
Avant, j'utilisais le pipeline pour faire passer des objets d'un cmdlet à un autre. Cette fois, cependant, je vais utiliser une technique plus semblable au script appelée construction Foreach (que j'ai présentée dans l'article du mois dernier). La construction Foreach peut accepter un ensemble d'objets et elle exécutera plusieurs cmdlets pour chaque objet de l'ensemble. Je désigne une variable qui représente l'objet actuel à chaque fois qu'il passe par la boucle. Par exemple, la construction pourrait commencer de la façon suivante :
foreach ($service in get-content c:\services.txt)
J'exécute toujours le même cmdlet Get-Content pour récupérer le contenu du fichier texte. Cette fois, je demande à la construction Foreach de faire une boucle dans l'ensemble d'objets renvoyé par Get-Content. La boucle s'exécute une fois pour chaque objet et l'objet actuel est placé dans la variable $service. À présent, il faut que je spécifie le code que je souhaite exécuter dans la boucle. Je commencerai par essayer de dupliquer ma commande d'une ligne d'origine (ceci réduira la complexité et m'empêchera de perdre des fonctionnalités) :
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Quelque chose d'intéressant se produit ici. Vous noterez que j'ai terminé la première ligne de la construction Foreach par une accolade ouvrante. Tout ce qui se trouve entre l'accolade d'ouverture et l'accolade de fermeture est considéré comme étant à l'intérieur de la boucle Foreach et sera exécuté une fois pour chaque objet de l'ensemble d'entrée. Notez qu'une fois que j'ai saisi { et appuyé sur la touche Entrée, l'invite Windows PowerShell est devenue >> (voir la figure 2). Ceci indique que le programme est conscient du fait que j'ai commencé une construction et qu'il attend que je la finisse. J'ai saisi ensuite mon cmdlet Set-Service. Cette fois, j'ai utilisé $service comme premier paramètre, puisque $service représente le nom de service actuel lu à partir de mon fichier texte. Sur la ligne suivante, je conclus la construction par une accolade de fermeture. J'appuie deux fois sur la touche Entrée et Windows PowerShell exécute immédiatement mon code.
Figure 2 Windows PowerShell sait qu'une construction a été lancée.
Figure 2 Windows PowerShell sait qu'une construction a été lancée. (Cliquer sur l'image pour la réduire)
Figure 2 Windows PowerShell sait qu'une construction a été lancée.
Figure 2 Windows PowerShell sait qu'une construction a été lancée. (Cliquer sur l'image pour l'agrandir)
En un clin d'œil ! Ce que j'ai saisi ressemble à un script, mais Windows PowerShell l'exécute en fait en direct et il n'est stocké dans aucun fichier texte nulle part. À présent, je vais tout retaper, en ajoutant une ligne de code pour sortir le nom de service actuel :
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Notez que je lui demande d'afficher quelque chose et que j'ai mis ce quelque chose entre des guillemets doubles. Les guillemets indiquent à Windows PowerShell qu'il s'agit d'une chaîne de texte, pas d'une autre commande. Cependant, lorsque vous utilisez des guillemets doubles plutôt que des guillemets simples, Windows PowerShell recherche d'éventuelles variables dans la chaîne de texte. S'il en trouve, il remplace la valeur réelle de la variable par son nom. Ainsi, lorsqu'il exécute ce code, vous pouvez voir que le nom de service actuel est affiché.
Ce n'est toujours pas un script !
Jusqu'à présent, j'ai utilisé Windows PowerShell de façon interactive, ce qui est une façon excellente de voir immédiatement les résultats de ce que j'écris. Cependant, recopier ces lignes de codes va devenir lassant. C'est pourquoi Windows PowerShell peut également exécuter des scripts. En fait, les scripts Windows PowerShell suivent la définition la plus littérale du mot script : Windows PowerShell se contente de lire dans le fichier texte de script et « saisit » chaque ligne trouvée, exactement comme si vous saisissiez les lignes manuellement. Cela signifie que tout ce que j'ai fait jusqu'à présent peut être recollé dans un fichier de script. Je vais donc utiliser le Bloc-notes pour créer un fichier appelé disableservices.ps1 et coller dedans les informations suivantes :
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
J'ai placé ce fichier dans un dossier nommé C:\test. Je vais maintenant essayer de l'exécuter depuis Windows PowerShell :
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
Mince ! Que s'est-il passé ? Windows PowerShell est concentré sur le dossier C:\test, mais il n'a pas trouvé mon script. Pourquoi ? En raison des contraintes de sécurité, Windows PowerShell est conçu pour ne pas exécuter de scripts du dossier actuel, ce qui empêche les scripts de détourner une commande du système d'exploitation. Par exemple, je ne peux pas créer un script appelé dir.ps1 et le faire remplacer la commande dir normale. Si j'ai besoin d'exécuter un script du dossier actuel, je dois spécifier un chemin relatif :
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
Et maintenant ? Ça ne marche toujours pas. J'ai indiqué le bon chemin, mais Windows PowerShell dit qu'il ne peut pas exécuter de scripts. C'est parce que, par défaut, Windows PowerShell ne peut pas exécuter de scripts. Ici encore, il s'agit d'une mesure de précaution pour éviter les problèmes que nous avons tous eus avec VBScript. Les scripts malveillants ne peuvent pas s'exécuter sous Windows PowerShell par défaut parce qu'aucun script ne peut s'exécuter par défaut ! Pour exécuter mon script, je dois modifier la stratégie d'exécution de manière explicite :
PS C:\test> set-executionpolicy remotesigned
La stratégie d'exécution RemoteSigned autorise l'exécution de scripts non signés à partir de l'ordinateur local. Les scripts téléchargés doivent tout de même être signés pour être exécutés. Allsigned représente une meilleure stratégie. Il exécute uniquement des scripts ayant été signés numériquement avec un certificat émis par un éditeur approuvé. Cependant, je n'ai pas de certificat sous la main, donc je ne peux pas signer mes scripts, ce qui fait que RemoteSigned est la meilleure solution dans le cas présent. À présent, je vais réessayer d'exécuter mon script :
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Je tiens à signaler que la stratégie d'exécution RemoteSigned que nous utilisons n'est pas un très bon choix, mais elle fait l'affaire ici. Il existe toutefois une bien meilleure solution. Il serait beaucoup plus sûr d'obtenir un certificat de signature de code, d'utiliser le cmdlet Windows PowerShell Set-AuthenticodeSignature pour signer mes scripts et de définir la stratégie d'exécution sur la stratégie AllSigned, qui est beaucoup plus sûre.
Il existe également une autre stratégie, Unrestricted, qu'il vaut mieux éviter. Cette stratégie autorise l'exécution absolue de tous les scripts, même les scripts malveillants, d'emplacements distants sur votre ordinateur, ce qui peut être très dangereux. Par conséquent, je vous recommande d'éviter à tout prix d'utiliser la stratégie Unrestricted.

Résultats immédiats
Les capacités d'écriture de scripts interactive dans Windows PowerShell vous permettent de tester rapidement des scripts, voire simplement des petits morceaux de scripts. Vous obtenez des résultats immédiats et vous pouvez ainsi modifier vos scripts aisément pour obtenir les résultats souhaités. Lorsque vous avez terminé, vous pouvez transférer votre code dans un fichier .ps1, ce qui le rend permanent et facilement accessible à l'avenir. N'oubliez pas ! Idéalement, vous devez signer numériquement ces fichiers .ps1 pour laisser Windows PowerShell défini sur la stratégie d'exécution AllSigned, la stratégie la plus sûre pour l'exécution de scripts.

Don Jones est le gourou principal des scripts chez SAPIEN Technologies et co-auteur de Windows PowerShell : TFM (voir www.SAPIENPress.com). Contactez Don à l'adresse don@sapien.com.


 H&#233;, vous le scripteur&#160;!: La chasse au voitures... et le XML
Hé, vous le scripteur !
La chasse au voitures... et le XML
Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_02,exe (150KB)

« JE NE SAIS PAS pourquoi mon chien court après les voitures, » dit la vieille blague. « Après tout, qu'en ferait-il s'il finissait par en rattraper une » ?
Bonne question, à laquelle les scripteurs n'ont pas réponse. Enfin, sauf s'il s'agit de Lucy, la chienne de notre rue, qui rattrape les voitures. Nous ne doutons pas le moins du monde qu'elle serait parfaitement capable de cambrioler un marchand de vin et d'utiliser ensuite la voiture pour s'enfuir. Et vu l'état du gazon, nous sommes convaincu qu'elle ne s'arrêterait pas aux aires de repos en cours de route, si vous voyez ce que nous voulons dire.
Si nous devions mettre à jour cette vieille blague pour l'ère ultratechnologique actuelle, elle pourrait ressembler à ce qui suit : « Je ne sais pas pourquoi que mon administrateur système continue d'essayer à apprendre le XML. Après tout, qu'en ferait-elle s'elle finissait par l'apprendre » ?
Remarque : pour notre défense, nous avons seulement dit que nous allions mettre à jour cette vieille plaisanterie fatiguée, nous n'avons jamais dit que nous la rendrions drôle.
Pour être honnête, on fait peut-être un peu trop de battage autour de la technologie XML, du moins pour ce qui est de l'administration système. La vérité est que beaucoup d'administrateurs système ont mené une vie longue et heureuse sans jamais écrire de script entrant en interaction avec un fichier XML, et nous ne nous attendons pas à ce que cela change dans un avenir proche.
Ceci dit, il est également vrai que de plus en plus d'applications adoptent le XML comme norme pour le stockage de données. Et pourquoi pas ? Ces fichiers de données XML, qui ne sont rien de plus que des fichiers texte en plus raffiné, sont faciles et rapides à créer, sont transférables d'une plate-forme à une autre, et ne nécessitent aucun programme de base de données complexe (et coûteux). Vous possédez un système d'exploitation et un éditeur de texte ? Alors vous pouvez créer une base de données XML.
Ce qui veut dire, bien sûr, qu'il y a au moins une chose qu'un administrateur système peut faire avec XML : écrire des scripts qui interrogent un fichier XML comme s'il s'agissait d'une véritable base de données. Et qui mieux que les Scripteurs pour vous donner quelques astuces pour cela ?
Très bien, d'accord. Mais nous sommes convaincus que Lucy est probablement bien trop occupée à déterrer un parterre de fleurs pour écrire une chronique sur le XML.
Pour commencer, jetons un coup d'œil sur un fichier XML simple (voir la figure 1) : il s'agit d'un fichier de base de données présentant quatre scripts trouvés dans la chronique quotidienne Hé, vous le Scripteur !
Figure 1 Hé, vous le Scripteur ! Les scripts dans XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Comme vous pouvez le constater, c'est un petit fichier très simple. Chaque script individuel est classé sous une balise <Script>. A partir de maintenant, nous appellerons ces scripts « enregistrements ». Oui, vous avez raison, les passionnés de XML n'appelleraient jamais ces éléments des enregistrements. Mais ce n'est pas un problème. Notre objectif ici est de vous montrer comment appliquer quelque chose que vous connaissez déjà (les techniques d'interrogation de base de données) à un nouveau type de source de données différent. Nous avons décidé de nous concentrer tout d'abord sur la réalisation des opérations, puis de revenir ensuite sur ce sujet et de vous fournir alors la terminologie correcte.
Bien, revenons à nos enregistrements. Chaque enregistrement contient les champs suivants : <Catégorie>, <Sous-catégorie>, <Mot-clé>, <Titre> et <URL>.
Mouais, vous n'êtes pas aussi impressionné que nous l'imaginions. Il vaudrait peut-être mieux que nous vous montrions un script capable d'ouvrir ce fichier XML et d'en renvoyer le contenu :
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Remarque : Faites attention : ces noms de balise sont sensibles à la casse. Il s'agit de « "/Repository/Script" », et non de « "/repository/script" » ou de « "/REPOSITORY/SCRIPT" ».
D'accord, ce n'est pas non plus particulièrement impressionnant. Mais c'est exactement ce que nous souhaitons vous prouver : c'est loin d'être aussi difficile que vous pourriez le croire.
Comme vous pouvez le voir dans le code, nous commençons par créer une instance de l'objet Microsoft.XMLDOM, l'objet COM utilisé pour travailler avec les fichiers XML. Nous définissons ensuite la propriété Async sur False. Ceci permet d'assurer que l'ensemble du fichier est lu en mémoire avant que le contrôle ne soit renvoyé au script. La méthode Load est ensuite utilisée pour lire le fichier C:\Scripts\Scripts.xml:
xmlDoc.Load("C:\Scripts\Scripts.xml")
Dès que le fichier a été chargé en mémoire, nous pouvons utiliser la méthode selectNodes pour sélectionner les enregistrements spécifiés de la base de données :
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Examinez de plus près le paramètre transmis à selectNodes. Il représente le chemin dans le fichier XML. Le fichier XML a la structure suivante :
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
Devez-vous vous en soucier ? Absolument ! Lorsque vous traitez des fichiers XML, la structure est très importante. Par exemple, comment obtenons-nous les propriétés individuelles d'un enregistrement ? Rien de plus simple : nous accédons à la balise <Repository> suivie de la balise <Script>, suivie des balises de propriété individuelles. Et devinez quoi ? Il s'agit du même chemin que celui que nous avons spécifié comme paramètre pour selectNodes. Il suffit d'ajouter /* après le chemin. Cela signifie « Sélectionner toutes les propriétés pour ces enregistrements ». En d'autres termes, l'ensemble renvoyé comprend toutes les propriétés pour tous les enregistrements de la base de données. Cette requête est comparable à la requête « Sélectionner * dans » dans Windows® Management Instrumentation (WMI).
Remarque : testez ce modèle de script pour voir exactement comment il fonctionne.
Le reste du script est simple : il suffit de configurer une boucle For Each pour examiner l'ensemble et renvoyer la valeur de la propriété Text de chaque élément de chaque propriété.
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
C'est nettement plus facile que de courir après les voitures !
Mais vous avez raison : si nous souhaitions simplement renvoyer l'ensemble du contenu du fichier, nous pourrions nous passer de tout ce fatras XML et simplement utiliser le FileSystemObject. (Ce serait peut-être un peu plus compliqué, mais à peine). Si notre intention était de vous éblouir et de vous faire vous exclamer « Ca alors ! Ce XML est bien pratique après tout », nous sommes sans doute encore loin du compte.
Voyons donc ce que nous pouvons faire pour y parvenir. Dans le premier script, nous avons obtenu toutes les valeurs de propriétés pour tous les enregistrements. Très bien, mais supposons que nous ne voulions obtenir que le titre du script ? Est-ce possible ? Mmmhh, une petite minute...
Bon, d'après Lucy, il suffit de modifier la commande selectNodes en ajoutant la propriété qui nous intéresse à la fin du chemin. En d'autres termes :
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
il s'avère que la seule raison pour laquelle nous avons obtenu toutes les propriétés la première fois est que nous avons utilisé le caractère générique *. Maintenant, nous n'obtenons plus que la propriété Titre. Pourquoi ? Parce que c'est la seule valeur de propriété que nous avons demandé à obtenir.
Remarque : n'est-ce pas fabuleux : XML vous donne exactement que vous demandez. Désolé, Lucy, mais nous pensons que le XML est le nouveau meilleur ami de l'homme !
Et bien sûr, il est possible d'obtenir plus d'une propriété. Par exemple, cette commande modifiée renvoie des valeurs pour les propriétés Titre et URL :
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Il est vrai que la syntaxe paraît un peu maladroite, mais une fois que vous vous y êtes fait, ce n'est pas si mal. Pour commencer, spécifions la partie parent du chemin, comme nous l'avons déjà fait :
    /Repository/Script/
Il suffit ensuite d'ajouter des parenthèses et, entre ces parenthèses, de spécifier les propriétés à renvoyer. (Veuillez noter que nous utilisons le caractère | pour séparer les différentes propriétés). En d'autres termes :
    (Title | URL)
comme nous l'avons déjà dit, c'est peut-être un peu gauche, mais ça marche.
Et non, vous n'êtes pas limité à deux propriétés. Tant que vous ajoutez des caractères de séparation |, vous pouvez renvoyer autant d'informations que vous le souhaitez. Par exemple, la commande suivante renvoie trois propriétés (titre, URL et mot-clé) :
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Pas mal, hein ?
Nous pensions que c'était pas mal pourtant. Vous êtes difficile à satisfaire. Mais vous n'avez pas tout à fait tort : tout ce que nous avons fait jusqu'à présent est de récupérer des informations sur les enregistrements dans notre base de données. Cependant, il n'y a pas de mal à cela. C'est souvent ce que vous souhaitez accomplir. D'un autre côté, il arrive aussi (souvent) que vous souhaitiez obtenir des informations seulement sur un sous-ensemble de ces enregistrements. Par exemple, vous ne souhaitez peut-être obtenir des informations que sur les scripts qui ont un mot-clé égal à databases (bases de données). He bien, il suffit d'utiliser une requête telle que celle-ci :
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
Là encore, la syntaxe est un peu bizarre. D'un autre côté, elle est aussi simple et facile à utiliser. Après avoir spécifié le chemin parent, nous plaçons notre clause « Where » (par exemple, where x equals y) entre crochets, comme suit :
/Repository/Script [Keyword = ‘databases’]
Comme vous vous en êtes sans doute déjà aperçu, notre équivalent de la clause Where indique au script de « Renvoyer uniquement les éléments où l'attribut de mot-clé est égal à databases ». Veuillez noter que le terme databases est placé entre des guillemets simples. C'est non seulement parfaitement correct, c'est même obligatoire. Si le terme de filtre est placé entre des guillemets doubles, vous obtiendrez une erreur de syntaxe lorsque vous tenterez d'exécuter le script.
Remarque : pourquoi ? Parce que la chaîne de requête complète "/Repository/Script [Keyword = 'databases']" est placée entre des guillemets doubles.
Bien sûr, vous n'êtes pas limité à l'utilisation du signe égal (=) lorsque vous filtrez les données. Vous pouvez utiliser les symboles supérieur à (>) ou inférieur à (<), de même que ces chouchous universels, les symboles inférieur ou égal à (<=) et supérieur ou égal à (>=). Vous pouvez également annuler tous ces symboles en les faisant précéder d'un point d'exclamation. Par exemple, la commande suivante interroge tous les scripts où le mot-clé n'est pas égal à databases (notez le symbole !=) :
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Quoi ? Qui a dit « D'accord, vous pouvez configurer un filtre, mais je vous parie que vous ne pouvez pas configurer un filtre et spécifier les propriétés que vous souhaitez renvoyer » ? Bien sûr que c'est possible :
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
si tout se passe bien, cette commande ne renverra que la propriété Titre pour tous les scripts qui ont le mot-clé databases. Voyons si cela fonctionne :
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Examinons une dernière commande avant de prendre un repos bien mérité. Nous avons bien avancé, mais nous renvoyons peut-être encore plus d'enregistrements que nous ne le souhaitons vraiment. Après tout, notre commande précédente renvoyait un mélange de scripts Microsoft® Access® et de scripts Microsoft SQL Server™. (Pourquoi ? Parce que tous ces scripts utilisent le mot-clé databases). Que se passe-t-il si nous souhaitons limiter les données renvoyées aux scripts qui ont le mot-clé databases et la sous-catégorie Microsoft SQL Server ? Est-il possible d'effectuer le filtrage sur plusieurs critères ?
La question ne se pose même pas.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
La syntaxe de base est la même. Il suffit d'utiliser deux critères distincts (soit mot-clé = 'databases' et sous-catégorie = 'Microsoft SQL Server') et de connecter les deux à l'aide de l'opérateur AND.
Remarque : vous avez tout à fait raison : avec ce petit fichier XML simple, nous aurions pu simplement interroger tous les scripts dont la sous-catégorie était égale à Microsoft SQL Server. Mais ça n'aurait été ni amusant, ni éducatif.
Il est également possible d'utiliser les clauses OR. Par exemple, supposons que nous avons tout un tas de scripts Microsoft Office, y compris ceux dont la sous-catégorie est égale à Microsoft Excel®,Microsoft PowerPoint®,Microsoft Outlook®, etc. Est-il possible de limiter les données renvoyées aux scripts des sous-catégories Microsoft Word ou Microsoft Access uniquement ? Absolument.
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
Cela vous convient-il mieux ? D'accord, cette chronique ne va peut-être pas vous changer la vie, mais il est fort probable que, tôt ou tard, vous trouviez utile de pouvoir interroger un fichier XML de la sorte. Mais la décision vous revient : vous pouvez apprendre quelques techniques XML de base, ou vous pouvez courir après les voitures. C'est vous qui voyez. (Si vous choisissez la seconde option et que vous rencontrez Lucy, la chienne de notre rue, passez-lui le bonjour du Scripteur. Et dites-lui de laisser notre jardin tranquille !)
Hé, vous le Scripteur ! - Tous les jours
Vous venez de lire la chronique Hé, vous le Scripteur de ce mois-ci, et vous pensez que c'est le meilleur article technique que vous ayez jamais lu. Vous iriez même jusqu'à dire que c'est le meilleur article jamais écrit. Qui plus est, vous ne quittez pas votre boîte de réception des yeux, dans l'attente du prochain numéro de Technet Magazine, dans lequel vous espérez trouver d'autres articles du même style.
Qu'attendez-vous ? Vous voulez en savoir plus sur Lucy, la chienne de notre rue, ou vous avez envie de lire les derniers exploits du Fils du scripteur ? Avez-vous entendu les résultats du Turducken Bowl de l'année dernière ? Restez informé de tous ces événements cruciaux en lisant la chronique quotidienne (oui, nous avons bien dit quotidienne) Hé, vous le Scripteur ! Du lundi au vendredi (sauf durant les jours fériés et pendant les vacances du Scripteur), vous pouvez lire tous les résultats de l'équipe de base-ball au lycée et des équipes de football et de basketball de l'université, et, de temps à autre, un bulletin météorologique local. (D'accord, ce n'est vrai que si pour vous, « local » veut dire Redmond, mais qui ne souhaiterait pas en savoir plus sur la météo de Redmond) ?
Non seulement cela, mais vous découvrirez chaque jour quelque chose de nouveau sur la rédaction des scripts. Oui, parmi tout ce contenu passionnant, vous trouverez aussi de véritables informations sur les scripts. Dans chaque chronique, les Scripteurs répondent à de vraies questions envoyées par ce qu'ils supposent être de vrais utilisateurs. Vous pouvez lire la chronique quotidienne en ligne à l'adresse microsoft.com/technet/scriptcenter/resources/qanda. Par ailleurs, puisque les scripteurs ont déjà répondu à des centaines de questions, les archives sont vastes et représentent une large source d'informations sur la rédaction de scripts (voir microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
Avez-vous une question pour les Scripteurs ? Vous avez une petite chance d'obtenir une réponse à votre question si vous la soumettez à scripter@microsoft.com. (Vous n'avez par contre aucune chance d'obtenir une réponse si vous n'envoyez pas votre question, alors qu'avez-vous à perdre ? Contrairement à un billet de loto, c'est gratuit, et vos chances sont légèrement supérieure).

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


 Surveillance de la s&#233;curit&#233;: D&#233;ploiement d'EFS&#160;: Partie 1
Surveillance de la sécurité
Déploiement d'EFS : Partie 1
John Morello

À présent, tout le monde a entendu parler de pertes de données confidentielles ou sensibles dues au vol ou à la perte de portables. Des portables disparaissent régulièrement. Avec l'augmentation des vols d'identités et le fait que la conformité aux règlementations n'a jamais été aussi indispensable, la protection approfondie des données se trouvant sur les systèmes informatiques mobiles est essentielle.
Une des solutions consiste à utiliser le système de fichiers EFS (Encrypting File System), inclus dans Windows® depuis Windows 2000. Ce système fournit un cryptage sur disque hautes performances intégré. EFS s'intègre parfaitement avec Windows Explorer, si bien que, souvent, les utilisateurs finaux ne sauront même pas lorsque l'un des fichiers qu'ils utilisent est crypté. De plus, EFS fonctionne également bien avec l'authentification Windows native et les technologies de contrôle d'accès, de sorte que les utilisateurs n'ont pas besoin de se rappeler différents mots de passe pour accéder à leurs données. Enfin, EFS fournit des options faciles à gérer pour la récupération des données au cas où un utilisateur perd l'accès à ses clés de cryptage (par exemple, si son profil utilisateur est supprimé ou endommagé ou en cas de perte de sa carte à puce).
EFS utilise la technologie de cryptographie intégrée dans Windows pour créer, enregistrer et déployer des clés de cryptage solides pour la protection des données. Dans Windows XP Service Pack 1 (SP1) et les versions ultérieures, EFS utilise l'algorithme AES (Advanced Encryption Standard) avec une clé 256 bits pour crypter les données sur le disque. Ces clés symétriques sont ensuite protégées avec une paire de clés asymétriques (RSA). Le système EFS crypte chaque fichier avec sa clé AES, puis il crypte cette clé avec la clé RSA de l'utilisateur et il enregistre le résultat dans le fichier. Pour plus d'informations sur la cryptographie EFS, consultez l'encadré « Ressources EFS ». Pour le moment, je vais laisser de côté les bases techniques du système de fichiers EFS pour vous expliquer comment déployer le système et le rendre viable dans votre environnement. C'est la raison pour laquelle cet article suppose une connaissance préalable des concepts de cryptographie EFS.

Remarque sur la sécurité EFS
Certaines applications prétendent pouvoir décrypter le cryptage EFS. En fait, aucune de ces applications ne décrypte le chiffrement AES (ou DES - Data Encryption Standard - ou DESX - Expanded Data Encryption Standard), mais elles parviennent à accéder à la clé confidentielle EFS de l'utilisateur en s'acharnant à découvrir son mot de passe. Une chose importante qu'il ne faut pas oublier en ce qui concerne le cryptage EFS : les clés confidentielles utilisées pour créer et protéger les données cryptées utilisent les normes DPAPI (Data Protection API). DPAPI utilise des dérivés des informations d'identification de l'utilisateur pour protéger les données de sorte que cette protection des données avec EFS n'est pas plus efficace que le mot de passe de l'utilisateur. Avec Windows Vista™, vous pouvez maintenant stocker des certificats de cryptage EFS sur des cartes à puce, ce qui modifie ce paradigme et augmente considérablement la sécurité relative des données protégées par EFS.
Quelle doit être la longueur d'un mot de passe pour qu'il soit résistant à ces attaques ? Étant donné les possibilités matérielles d'aujourd'hui et les algorithmes d'attaque de mots de passe modernes, il est recommandé d'utiliser un mot de passe de 11 caractères ou plus (ou, plus exactement, une phrase clé). Une phrase clé de 11 caractères ou plus est extrêmement résistante aux méthodes les plus avancées d'aujourd'hui, y compris les attaques par hachage précalculé (telles que les Rainbow Tables, consultez le message sur le blog « Why you shouldn't be using passwords of any kind on your Windows networks » (en anglais) répertorié dans l'encadré « Ressources », pour plus d'informations).

PKI ou ne pas PKI ?
On pense souvent à tort qu'une infrastructure PKI est nécessaire pour permettre le fonctionnement du système de fichiers EFS. Il est vrai qu'EFS peut facilement s'intégrer avec à cette infrastructure et tirer parti d'une architecture PKI si votre organisation en a déjà une, mais cela n'est pas indispensable. Ceci dit, la décision d'utiliser ou non une architecture PKI dans votre déploiement EFS influera sur de nombreuses décisions de déploiement futures, il faut donc bien étudier le problème.
L'avantage principal de l'utilisation d'une architecture PKI avec EFS est la possibilité de réaliser un archivage et une récupération des clés. Tandis qu'EFS tout seul permettra aux administrateurs d'exécuter la récupération des données, la récupération automatique des clés est disponible uniquement avec une PKI, et même dans ce cas, seulement en exécutant Windows Server® 2003 Enterprise Edition en tant qu'autorité de certification. La récupération des données est le processus par lequel un utilisateur qui perd l'accès à sa clé de cryptage peut fournir ses données cryptées à un administrateur désigné et connu comme l'agent de récupération de données. Ce dernier peut ensuite décrypter ces données et les renvoyer à l'utilisateur ou les recrypter pour qu'elles soient utilisées avec une nouvelle clé confidentielle. L'agent de récupération travaille en quelque sorte dans l'ombre du processus de cryptage de l'utilisateur car tout ce que l'utilisateur crypte avec sa clé est également crypté avec une copie de la clé de l'agent. Ainsi, lorsque la clé de l'utilisateur est perdue, l'agent peut intervenir, déchiffrer les données, leur appliquer sa clé pour le décryptage (ou le recryptage), puis renvoyer les données à l'utilisateur. L'approche par agent fonctionne bien, mais elle peut être difficile à gérer si l'utilisateur a crypté de grandes quantités de données ou s'il ne dispose pas d'un personnel informatique local pouvant servir d'agents de récupération des données.
La récupération des clés, en revanche, requiert que l'autorité de certification fasse une copie de la clé de cryptage de l'utilisateur pendant le processus de création de la clé et stocke cette copie en toute sécurité dans la base de données de l'autorité de certification. Ensuite, lorsqu'un utilisateur perd l'accès à des fichiers cryptés, l'administrateur de l'autorité de certification n'a plus qu'à accéder à cette base de données pour récupérer la clé de l'utilisateur. À ce stade, l'utilisateur retrouvera un accès immédiat à ses données sans avoir à passer par l'intermédiaire d'un agent de récupération de données. De cette façon, la récupération des clés est souvent plus rapide et plus efficace. Notez, cependant, qu'il est préférable de toujours disposer d'agents de récupération de données, même si vous utilisez la récupération des clés, pour avoir une solution de secours en cas de perte de clés. Ceci permet également aux grandes organisations d'avoir un système de récupération distribué dans lequel les administrateurs informatiques locaux peuvent récupérer des données d'utilisateurs sans avoir à faire appel au groupe d'administrateurs PKI.
Autre avantage de l'utilisation d'une PKI avec EFS : elle peut également faciliter le partage de fichiers cryptés. Rappelez-vous qu'EFS n'est pas uniquement limité aux systèmes portables. Il peut être tout aussi utile dans toute situation où la sécurité physique d'un ordinateur ne peut pas être garantie. Dans ces situations, il peut être nécessaire que plusieurs utilisateurs accèdent aux mêmes données cryptées. Bien que la prise en charge de Windows pour le partage de fichiers cryptés soit quelque peu limitée parce qu'elle permet uniquement le partage de fichiers individuels, et non de répertoires, elle peut s'avérer un outil utile. Pour faciliter le partage de fichiers EFS, l'utilisateur qui partage le fichier doit avoir accès aux clés publiques des utilisateurs avec lesquels il partage (ce qui est plus facile si ces utilisateurs ont un certificat EFS valide publié pour leur compte dans Active Directory®). Bien qu'il soit possible d'exécuter cette publication manuellement, l'utilisation d'une autorité de certification Windows installée dans le mode Enterprise (intégré à Active Directory) automatise entièrement le processus.

Gestion des clés EFS
Si vous avez une PKI basée sur Windows Server 2003 que vous pouvez utiliser, la création de certificats EFS d'utilisateurs est un processus simple. Une autorité de certification Windows Server 2003 est fournie avec un ensemble de modèles de certificats par défaut, notamment un modèle qui s'appelle EFS basique. Toutefois, ce modèle est une modèle de version 1 qui ne prend pas en charge l'archivage des clés. Si, avant de le rendre disponible sur votre autorité de certification, vous souhaitez dupliquer le modèle pour créer un nouveau modèle de version 2 (vous pourriez par exemple l'appeler EFS avec archive des clés, comme illustré à la figure 1). Sur ce nouveau modèle, accédez à l'onglet Traitement de la demande et sélectionnez l'option d'archivage de la clé de cryptage de l'utilisateur. Notez qu'il faudra que l'archivage des clés soit configuré correctement sur l'autorité de certification pour que vous puissiez activer cette option. La section des ressources inclut une excellente description étape par étape du processus. Définissez également ce modèle pour qu'il remplace le modèle EFS basique pour faire en sorte que les clients utilisent cette nouvelle version (voir la figure 2).
Figure 1 EFS avec Archive des clés
Figure 1 EFS avec Archive des clés (Cliquer sur l'image pour la réduire)
Figure 1 EFS avec Archive des clés
Figure 1 EFS avec Archive des clés (Cliquer sur l'image pour l'agrandir)
Figure 2 Remplacement du modèle EFS basique
Figure 2 Remplacement du modèle EFS basique (Cliquer sur l'image pour la réduire)
Figure 2 Remplacement du modèle EFS basique
Figure 2 Remplacement du modèle EFS basique (Cliquer sur l'image pour l'agrandir)
Vous devrez ensuite déterminer les autorisations correctes sur le modèle pour accorder un accès aux bons utilisateurs. Étant donné que le composant EFS de Windows demandera automatiquement un certificat lors de la première utilisation d'EFS, vous n'avez généralement pas besoin de permettre aux utilisateurs de s'auto-inscrire au modèle EFS. En fait, je vous déconseille de permettre l'auto-inscription pour les certificats EFS à moins que vous ne soyez sûr que tous les utilisateurs auto-inscrits utiliseront EFS. La figure 3 illustre les paramètres d'auto-inscription EFS. En émettant des certificats à des utilisateurs qui n'utiliseront peut-être jamais EFS, vous augmentez la taille de votre base de données d'autorité de certification inutilement. Bien que la taille de la base de données d'autorité de certification ne soit pas en elle-même limitée, elle risque de devenir plus difficile à gérer (en particulier via Microsoft Management Console ou MMC) car vous augmentez le nombre de certificats émis.
Figure 3 Configuration des autorisations d'utilisateurs EFS
Figure 3 Configuration des autorisations d'utilisateurs EFS (Cliquer sur l'image pour la réduire)
Figure 3 Configuration des autorisations d'utilisateurs EFS
Figure 3 Configuration des autorisations d'utilisateurs EFS (Cliquer sur l'image pour l'agrandir)
Pour finir, si vous avez besoin de prendre en charge le partage de fichiers cryptés, vous souhaiterez peut-être que l'autorité de certification publie automatiquement le certificat de l'utilisateur dans Active Directory.
Une fois le modèle configuré correctement sur votre autorité de certification, la première fois qu'un utilisateur essaie de crypter un fichier avec EFS, il obtiendra son certificat de votre autorité de certification et votre autorité de certification archivera automatiquement sa clé confidentielle.

Gestion des clés DRA
Le point suivant à envisager si vous disposez d'une PKI est l'utilisation ou non des certificats DRA générés par l'autorité de certification. Pourquoi ne pas utiliser les certificats DRA de votre PKI ? Imaginez un scénario dans lequel vous avez une autorité de certification émettrice avec une période de validité de certificat relativement courte (deux années ou moins). Cette autorité de certification ne pourra pas émettre de certificats avec des durées de validité supérieures à la sienne, ce qui signifie que vos certificats DRA auront une durée de validité de deux ans (au plus). Ceci peut résulter dans un scénario de récupération des données beaucoup plus complexe. Cette hypothèse est illustrée dans le scénario suivant.
  1. Un utilisateur crypte un fichier en janvier 2006. Les certificats DRA qui sont attribués à son ordinateur par la stratégie de groupe ont une durée de validité de deux ans (ils expirent en janvier 2008).
  2. L'utilisateur continue à crypter de nouveaux fichiers, en utilisant EFS.
  3. En janvier 2008, les certificats DRA expirent et l'administrateur fait parvenir de nouveaux certificats par le biais de la stratégie de groupe.
  4. Toutes les opérations de cryptage effectuées à partir de ce moment utilisent les nouveaux certificats DRA (y compris les fichiers que cet utilisateur ouvre qui ont été cryptés avec les anciens certificats DRA ; ils utiliseront les nouveaux certificats lorsqu'ils seront enregistrés). Les fichiers auxquels l'utilisateur ne touche pas seront uniquement protégés par les anciens certificats DRA.
  5. L'utilisateur endommage accidentellement son profil et a besoin de récupérer des données.
  6. L'administrateur informatique doit maintenant avoir deux groupes de certificats DRA : les nouveaux pour les fichiers utilisés depuis l'étape 3 et les anciens pour les fichiers auxquels l'utilisateur n'a pas accédé depuis cette étape.
L'administrateur informatique a la possibilité d'exécuter un script après l'étape 3 pour mettre à jour tous les fichiers avec le nouveau certificat RA (à l'aide de cipher.exe/u), mais cela prendra du temps. De plus, il faut souligner que les paires de clés DRA ne deviennent pas inutiles après leur expiration, même si le composant EFS ne permet plus de nouvelles opérations de cryptage si un certificat DRA expiré est inclus dans sa stratégie de récupération. Les vieux fichiers cryptés avec des paires de clés DRA expirées peuvent, bien sûr, toujours être récupérés. Par conséquent, les paires de clés DRA ne doivent pas être ignorées, même après l'expiration de leur durée de validité. Vous ne savez simplement pas quand vous aurez besoin de les utiliser.
C'est pour ces raisons que je recommande que les environnements ayant des autorités de certification avec des certificats à courte validité emploient des certificats DRA auto-signés avec des durées de validité plus longues. L'utilitaire de chiffrement comprend un commutateur (cipher.exe /r) qui crée automatiquement des paires de clés d'agents de récupération EFS avec une durée de vie de 100 ans (voir la figure 4). Le certificat de cette paire de clés peut ensuite être associé aux objets de stratégie de groupe et utilisé comme un certificat DRA dans l'ensemble de votre organisation. Étant donné que le composant EFS ne vérifie pas la chaîne de confiance des certificats DRA, ces certificats auto-signés fonctionneront sans que vous ayez besoin d'apporter des modifications à la liste des autorités de certification racine reconnues sur vos systèmes. Quelle que soit la durée de vie de l'autorité de certification d'une organisation, je recommande toujours de créer au moins un certificat DRA de longue durée et de l'associer à un GPO au niveau du domaine. Il s'agit de l'option de secours de récupération des données à utiliser en cas d'échec de toutes les autres options. Ceci est tout particulièrement essentiel si vous utilisez des clés DRA créées par l'autorité de certification en l'absence d'une archive des clés de l'autorité de certification. Si un certificat DRA se trouvait compromis, vous pouvez mettre à jour le GPO avec un nouveau certificat et utiliser cipher.exe /u comme expliqué plus haut pour mettre à jour vos fichiers.

Figure 4 Exécution de Ciquer /R (Cliquer sur l'image pour la réduire)

Figure 4 Exécution de Ciquer /R (Cliquer sur l'image pour l'agrandir)
Ressources EFS
Vous pouvez obtenir beaucoup plus d'informations sur les détails d'EFS et les meilleures pratiques en visitant les sites suivants.
  • Why you shouldn’t be using passwords of any kind on your Windows networks (en anglais)
  • Implementing Key Archival Walkthrough (en anglais)
  • Encrypting File System in Windows XP and Windows Server 2003 (en anglais)

Déploiement KRA et DRA
L'archivage des clés permet aux administrateurs de l'autorité de certification de récupérer des clés de cryptage mises en dépôt par l'utilisateur. Il s'agit évidement d'une capacité très sensible et puissante puisqu'elle peut permettre à un administrateur de l'autorité de certification de décrypter toutes les données dans l'organisation qui utilise une clé signée par l'autorité de certification. Par conséquent, l'archivage et la récupération des clés doivent faire l'objet de précautions particulières et seul un petit nombre d'employés de sécurité de confiance devraient y être autorisés. Étant donné la nature sensible de la récupération des clés, si vous souhaitez en faire votre principal mécanisme pour réobtenir l'accès à des données cryptées par EFS, il est important que vous disposiez d'un processus de remontée défini clairement pour que les demandes de récupération soient adressées à votre équipe d'administration de l'autorité de certification. Chaque demande devra alors être approuvée pour que le processus de récupération puisse commencer. Ensuite, une fois la clé récupérée, elle doit être fournie à l'utilisateur à l'aide d'une méthode sécurisée (en d'autres termes, pas par message électronique) puisque la clé récupérée fournit l'accès à tous les données protégées par EFS de l'utilisateur.
Les clés de l'agent de récupération de clé (ou KRA) sont créées et conservées par les administrateurs de l'autorité de certification et ne sont pas publiées par l'intermédiaire de la stratégie de groupe. En fait, le système EFS ne peut pas déterminer si les clés qu'il utilise ont été archivées. Il exécute simplement ses opérations de cryptage normalement. De plus, les clés KRA créées sur l'autorité de certification ne sont pas spécifiques à EFS. Une autorité de certification utilisant l'archivage des clés sera associée à n clés KRA au niveau de l'autorité de certification qui sera utilisée pour protéger toute clé archivée par l'autorité de certification. Ces clés peuvent inclure celles utilisées avec EFS, un courrier électronique sécurisé ou tout autre certificat comportant un cryptage. Les clés KRA doivent être stockées en sécurité par les agents de récupération des clés individuels. Deux agents de récupération de clé individuels au moins doivent être utilisés comme recours en cas de perte d'une clé.
La première fois qu'un administrateur se connecte au contrôleur de domaine dans un domaine créé récemment, une stratégie de récupération par défaut est créée au niveau du domaine à l'aide d'un certificat auto-signé. Une paire de clés est également stockée dans le profil de l'administrateur sur le contrôleur de domaine. Ce certificat DRA aura une durée de vie de trois ans. L'approche recommandée consiste à supprimer ce certificat par défaut pour le remplacer par des certificats auto-signés de plus longue durée ou des certificats émis par votre PKI. Si vous ne supprimez pas ce certificat par défaut auto-signé, EFS cessera de crypter de nouveaux fichiers sur l'ensemble de votre domaine trois ans après sa création. Ceci parce que le certificat aura expiré. EFS empêche le cryptage de nouvelles données lorsqu'un certificat DRA expiré est inclus dans sa stratégie de récupération. Bien qu'il soit possible d'exploiter Windows XP et les systèmes ultérieurs sans aucune stratégie d'agent de récupération en place, ceci est fortement déconseillé. Dans ce cas, si un utilisateur perd l'accès à sa clé de cryptage pour quelque raison que ce soit et que la récupération des clés n'est pas possible, toutes ses données seront irrévocablement perdues.
Comme je l'ai déjà dit, les clés DRA peuvent être auto-signées ou émises par une autorité de certification. Dans la plupart des cas, une approche hybride est recommandée, avec au moins deux clés d'agent de récupération de répertoire auto-signées, de longue durée, utilisées à l'échelle de l'entreprise en tant qu'agent de récupération de dernier recours. Comme les certificats DRA sont déployés à l'aide des objets de stratégie de groupe, ils possèdent les mêmes capacités d'héritage que les autres objets de stratégie de groupe. En d'autres termes, l'algorithme d'accumulation et d'application de GPO local, de site, de domaine, d'unité d'organisation qui contrôle l'application d'autres paramètres GPO s'applique également aux DRA. Ainsi, une organisation peut facilement implémenter une approche à plusieurs niveaux pour les certificats DRA, dans laquelle le groupe informatique central a un accès DRA à chaque partie de l'entreprise, mais où les groupes informatiques locaux gèrent cette capacité pour leurs domaines de responsabilité spécifiques. Ceci est particulièrement précieux dans les grandes organisations géographiquement dispersées puisqu'il n'est plus nécessaire de transférer de grandes quantités de données cryptées via des liaisons WAN pour faciliter la récupération de données. La figure 5 illustre un déploiement DRA typique à plusieurs niveaux.
Figure 5 Déploiement DRA à plusieurs niveaux
Figure 5 Déploiement DRA à plusieurs niveaux
Dans ce cas, un utilisateur de l'unité d'organisation de Baton Rouge aurait six agents de récupération de répertoire pour chaque fichier crypté : deux de ses administrateurs locaux, deux du groupe informatique d'Amérique du Nord et deux du niveau du domaine. Ainsi, si l'utilisateur perdait l'accès à ses données cryptées, il pourrait demander à un agent de récupération de répertoire local, à Baton Rouge, ou au groupe informatique d'Amérique du Nord, de se charger de leur récupération. En dernier recours, si ces quatre agents étaient indisponibles ou perdus, les agents du niveau du domaine pourraient prendre le relais et récupérer tout aussi bien les données. Quel que soit l'agent qui effectue la récupération, le processus sera toujours essentiellement le même. L'utilisateur commencera par mettre les données à la disposition de l'agent. Il est important que l'agent prenne les mesures nécessaires pour s'assurer que la demande est légitime et qu'elle provient bien du véritable propriétaire des données. Cela fait, l'agent charge le certificat DRA, décrypte (et recrypte, de préférence) les données, puis il les renvoie à l'utilisateur final. Certaines organisations choisissent également d'exécuter une récupération locale : l'agent rend visite à l'utilisateur, il charge sa paire de clés DRA dans le profil, puis il décrypte les données et supprime la paire de clés. L'utilisateur a ensuite accès aux données sous forme de texte brut et il peut les recrypter avec une nouvelle clé. Il convient de noter que cette approche est beaucoup moins sûre parce que la paire de clés DRA est copiée (bien que de façon temporaire) sur l'ordinateur local, mais elle peut faire gagner du temps, en particulier si un grand nombre de données doivent être récupérées.
Notez que si la récupération doit être fournie à l'utilisateur par le biais de l'archivage et la récupération des clés, la demande de récupération sera exécutée complètement indépendamment de ce processus. Au lieu d'utiliser un DRA, la demande de récupération de clé de l'utilisateur parviendra aux administrateurs de l'autorité de certification, qui doivent l'approuver, avant d'accéder à l'archive pour récupérer la clé confidentielle de l'utilisateur. Ils mettront ensuite cette clé confidentielle à la disposition de l'utilisateur de façon sécurisée, en la plaçant par exemple sur un site Web sécurisé pour permettre son téléchargement. (Si l'utilisateur se servait d'une carte à puce pour stocker sa clé EFS, disponible avec Windows Vista, cette clé doit également être réémise). L'utilisateur chargera cette clé dans son profil et aura ensuite un accès immédiat à toutes ses données cryptées.
Étant donné que les paires de clés DRA et KRA peuvent être utilisées pour décrypter des données sensibles, il importe qu'elles soient protégés correctement. Les paires de clés DRA et KRA ne doivent pas être stockées dans les profils de bureau normaux des administrateurs (les profils dans lesquels ils effectuent leurs tâches quotidiennes normales). Elles doivent être stockées de manière sécurisée hors ligne sur une disquette, un support optique ou flash conservé dans un endroit physiquement sécurisé. Ensuite, si besoin est, l'agent de récupération peut charger la paire de clés sur un poste de travail de récupération à partir de ce support, exécuter l'opération de récupération, puis supprimer la paire de clés. Dans certaines organisations où la sécurité des informations est particulièrement indispensable, des postes de travail dédiés sont désignés pour la récupération afin d'accroître la sécurité de ces paires de clés, mais ce n'est pas le cas pour toutes les organisations.

La prochaine fois
Maintenant que j'ai examiné les aspects de la gestion des clés, de la récupération des données et d'Active Directory dans la planification EFS, je me concentrerai le mois prochain sur les questions de déploiement côté client dans la 2ème partie de ce sujet. J'aborderai des sujets tels que le contrôle de l'utilisation d'EFS par la stratégie de groupe, le choix des données à crypter, le cryptage automatique des données par les scripts de connexion et les améliorations côté client pour Windows Explorer afin de faciliter encore plus l'utilisation de données protégées par EFS.

John Morello a obtenu une mention très bien à la Louisiana State University et a occupé plusieurs postes chez Microsoft, qu'il a rejoint il y a six ans. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises classées dans Fortune 100 ainsi que des clients civils et militaires du Gouvernement. Il est actuellement responsable de programme dans le groupe Windows Server qui se consacre aux technologies de sécurité et d'accès distant.


 Affaires de Bureau: Extension de Windows&#160;PE
Affaires de Bureau
Extension de Windows PE
Wes Miller

Avant même la sortie de Windows PE il y a plus de cinq ans, les clients impatients réclamaient déjà davantage de fonctions. Malheureusement, Windows PE n'a pas été conçu pour être facilement étendu de la même façon que, disons, Windows XP, en ajoutant des couches supplémentaires du système d'exploitation. Bien sûr, Windows PE se devait d'offrir une prise en charge
Win32® rudimentaire (pour permettre le fonctionnement de la plupart des applications Windows®) et une prise en charge de réseau et de stockage de masse (pour communiquer sur le réseau et pouvoir installer Windows). Cependant, dès le début, le shell était un élément que nous souhaitions limiter. En utilisant cmd.exe à la place du shell Windows Explorer traditionnel, nous avons limité ce que l'environnement de Windows PE pouvait faire et, surtout, nous avons fait en sorte que l'environnement par défaut soit facilement scriptable pour toutes les tâches d'automatisation.
Cela ne signifie pas que vous ne pouvez pas étendre Windows PE ; vous devez juste vous rappeler qu'il est limité. Vous pouvez vous attendre à ce que votre application ne fonctionne pas ou à ce que son comportement soit incorrect si elle requiert une des technologies répertoriées à la figure 1 (cette liste n'est pas exhaustive).
Figure 1 API Windows manquantes (Close Figure 1)

.NET Framework (toutes versions)
Interfaces ADSI (Active Directory® Services Interfaces)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (y compris les versions pré-.NET)
Tout type d'exécutable nécessitant une infrastructure qui n'est pas installée avec Windows en mode natif.
Windows Explorer ou Internet Explorer
Windows Media® Player
SAPI, MAPI, TAPI (API Windows Speech, Mail et Téléphonie, respectivement)
Si vous ne savez pas de quoi votre application dépend, vous devez le découvrir. Mais comment ? Lorsque nous avons essayé de faire marcher ADO, des applications HTML (HTA) et des composants Windows Script Host (WSH) sous Windows PE avant sa sortie, nous avons été confrontés au même problème. Toutefois, vous devez être conscient que bien que cet article expose des façons de rechercher ces dépendances, l'ajout de fichiers binaires Windows à votre image Windows PE au delà de ce que la commande MKIMG inclut n'est pas couvert par le contrat de licence utilisateur final (CLUF). Il vous faudra acquérir un complément de licence auprès de Microsoft afin d'implémenter des modifications de cette nature dans votre environnement.

Comprendre les dépendances
Si vous ouvrez le fichier .inf d'une application dans le Bloc-notes et que vous l'examinez soigneusement, vous pouvez en apprendre beaucoup. En fait, c'est souvent la façon la plus facile de comprendre une application et de voir quelles sont ses dépendances. La chose importante à retenir au sujet de Windows PE est le fait que l'application est généralement si dépouillée que vous devrez déboguer plusieurs niveaux de dépendances : les dépendances directes propres de votre application et les dépendances que celles-ci peuvent amener, afin d'assurer un fonctionnement fiable de votre application. En gros, une cascade assez grande de dépendances peut survenir si vous ne faites pas attention. Avec quelques ajouts de composants accidentels (ou voulus), votre image peut grandir considérablement en taille et en complexité.
Si vous disposez d'un fichier .inf qui décrit l'application, vous pouvez obtenir des indices sur les dépendances en recherchant les clés de registre et les fichiers ajoutés à votre système par le fichier .inf. Recherchez les sections CopyFiles et AddReg. Ces entrées pointeront vers des applications, des fichiers DLL et d'autres fichiers dont dépend votre application. Parmi les trois compléments conçus pour Windows PE (ADO, HTA, et WSH), WSH fut le plus simple à créer. Étant donné qu'une version redistribuable de WSH était encore disponible pour des versions plus anciennes de Windows et qu'il existe actuellement un fichier .inf intégré dans Windows qui exécute les associations de fichiers pour WSH (dans %windir%\inf\wsh.inf), son installation dans Windows PE fut relativement facile.

Orca et prise d'instantanés
Si l'application en question est distribuée en tant que fichier Microsoft® Installer (MSI), vous pouvez faire deux choses pour trouver les dépendances. Si vous êtes un spécialiste de MSI, vous pouvez utiliser Orca (un outil d'édition des fichiers Windows Installer distribué dans le cadre du kit de développement logiciel Windows Server® 2003 R2 platform : Rendez-vous sur la page go.microsoft.com/fwlink/?LinkId=77941) pour l'afficher. Vous pouvez également installer le MSI pour les composants de votre choix, en réalisant une analyse avant/après des fichiers et de clés de registre qui ont été modifiés. Vous pouvez vider le registre, installer l'application, exporter à nouveau le registre, puis exécuter WinDiff dessus (voir l'encadré « Utilisation de WinDiff »). Le résultat peut ensuite être utilisé comme modèle pour les modifications qui doivent être apportées au registre. Le problème est que le nombre de modifications peut être assommant. Néanmoins, ce peut être la meilleure option si vous n'avez pas de fichier .inf (ou l'auteur de l'application) à votre disposition.
Vous connaissez peut-être le processus de prise d'instantanés d'applications. En gros, il s'agit de la même analyse avant/après que celle réalisée pour faire fonctionner votre application. Auparavant, Microsoft distribuait (avec Windows 2000) un outil qui faisait la même chose, mais cet outil n'est pas compatible avec les versions plus récentes de Windows. Un certain nombre d'applications commerciales (rassembleurs d'installations) peuvent s'en charger, mais certains utilitaires gratuits aussi. Comme solution, vous pouvez installer le kit de développement logiciel de plate-forme (voir le lien dans le paragraphe précédent), qui inclut WinDiff. Notez que pour réaliser la comparaison avec WinDiff, il est préférable d'installer l'application sur Windows Server 2003 Service Pack 1 (SP1) parce qu'il s'agit de la version de Windows PE que vous êtes censé utiliser : Windows PE 1.6 généré à partir de Standard Edition ou Enterprise Edition (avec SP1). En réalisant cette tâche sur Windows Server 2003, vous disposerez de l'environnement le plus proche de ce que vous obtiendriez sur Windows PE (où évidemment vous ne pouvez pas exécuter un MSI). Suivez les étapes de l'encadré « Utilisation de WinDiff ».
Vous trouverez ainsi un bon nombre des informations modifiées. Malheureusement, il n'existe pas de méthode facile pour exporter les informations modifiées des captures de registre ou de fichiers afin de créer un manifeste pour installer votre application. Vous devez incorporer les modifications manuellement. C'est là que nous avons rencontré certains de nos plus gros problèmes avec la première version de Windows PE. Le simple fait de parvenir à faire fonctionner les composants HTA relevait de la gageure puisqu'il n'y avait pas de définition pour eux (en dehors d'Internet Explorer®) au sein de Microsoft. En utilisant la différenciation, nous avons pu confectionner une prise en charge HTA suffisante pour que ça fonctionne. Vous pouvez ajouter manuellement ces clés dans le registre Windows PE, mais vous souhaiterez peut-être ajouter les clés une fois que Windows PE aura démarré. Vous pouvez regarder les fichiers OC.bat et OC2.bat utilisés pour installer la prise en charge HTA, WSH et/ou ADO dans Windows PE à l'aide du script buildoptionalcomponents.vbs inclus dans les outils de génération de Windows PE.

Outils utiles
Même après avoir isolé les dépendances directes, il est souvent difficile de trouver tous les fichiers binaires dont dépend votre application. Vous ne saurez pas, par exemple, si elle nécessite un autre fichier DLL ou OCX pour réaliser certaines tâches. Alors, comment savoir ? Mark Russinovich, rendu célèbre par Sysinternals (à présent Technical Fellow chez Microsoft), a conçu un utilitaire pratique appelé listdlls qui s'en charge. Vous pouvez télécharger listdlls à l'adresse microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. Pour utiliser l'utilitaire, exécutez la commande listdlls.exe > dlls.txt et examinez ensuite le résultat. La figure 2 présente le résultat de listdlls exécuté sur lui-même. Vous pouvez comparer cette liste aux fichiers DLL et OCX inclus dans Windows PE pour déterminer si toutes les dépendances de votre application sont en place ou non (dans le cas de listdlls, elles sont déjà présentes). Pour la prise en charge HTA dans Windows PE, listdlls était essentiel pour l'identification de certaines dépendances qui ne pouvaient pas être identifiées autrement.
Figure 2 Résultat de listdlls exécuté sur lui-même
Figure 2 Résultat de listdlls exécuté sur lui-même (Cliquer sur l'image pour la réduire)
Figure 2 Résultat de listdlls exécuté sur lui-même
Figure 2 Résultat de listdlls exécuté sur lui-même (Cliquer sur l'image pour l'agrandir)
Mais ce n'est pas parce qu'une DLL est répertoriée que l'application en a forcément besoin pour fonctionner. Si vous chargez le Bloc-notes, par exemple, vous verrez qu'il charge uxtheme.dll. Sous Windows PE, cette DLL n'est pas disponible et, en fait, puisque les thèmes Windows ne sont pas utilisés, elle ne sera jamais chargée. Il est très difficile de distinguer les DLL répertoriées par listdlls qui vous sont utiles de celles qui sont chargées sur demande par Windows. Malheureusement, seule une expérimentation empirique ou une connaissance très poussée des aspects les plus précis de Windows vous y aideront (à cette fin, je recommande le livre de Mark Russinovich et David Salomon, Microsoft Windows Internals, Fourth Edition (Microsoft Press®,2004).
En fait, Mark inclut également la même fonctionnalité dans le remplacement de Process Explorer pour le gestionnaire des tâches de Windows, disponible gratuitement. La différence est que listdlls crée un résultat qui, à mon avis, est plus facilement converti en script et utilisé pour la recherche et le rassemblement de dépendances manquantes.
Notez que même après avoir ajouté une DLL à votre image, vous risquez d'être encore loin d'en avoir terminé. En effet, il existe deux types de DLL : celles qui doivent être enregistrées et celles qui ne doivent pas l'être. Malheureusement, il n'est pas facile de les distinguer, à moins d'essayer de les enregistrer toutes. Pour enregistrer une DLL (ou un OCX), exécutez regsvr32 dllname.dll. Si cela fonctionne correctement, une boîte de dialogue vous avertit que la DLL a été enregistrée. Sinon, vous ne recevez pas de message ou, plus probablement, une boîte de dialogue vous informera soit que l'enregistrement de la DLL a échoué, soit qu'il n'a pas pu se faire. Au cours du développement des composants facultatifs HTA et ADO pour Windows PE, nous avons découvert que les DLL requièrent un stockage réinscriptible lors de leur enregistrement, soit pour écrire temporairement un fichier .inf pour l'installation, soit pour enregistrer une autre dépendance (disons un répertoire spécifique dont elles ont besoin). Dans Windows PE, cela était synonyme d'échec. Heureusement, avec Windows PE 2.0, les tâches de ce type fonctionnent puisqu'il y a de l'espace disponible par défaut.
Process Monitor est un troisième outil créé par Mark et publié récemment. Process Monitor peut être considéré comme un sur-ensemble de Regmon et Filemon, qui fournit cependant beaucoup plus de détails tout en ajoutant une toute nouvelle couche de communication interprocessus. Cet outil incroyablement puissant peut vous aider à résoudre des problèmes d'applications dans Windows et à répondre à des questions sur les interdépendances des DLL. Process Monitor peut être téléchargé.

Suppression de fichiers Windows PE
Outre la possibilité d'ajouter des éléments à Windows PE, l'une des demandes les plus fréquentes concernait la réduction de la taille de réduire Windows PE. Vous pouvez prendre certaines mesures pour réduire quelque peu la taille de Windows PE. Votre copie sous licence de Windows PE comprend normalement un ensemble d'outils de génération et de la documentation. L'un des documents est un fichier d'aide appelé winpe.chm. Si vous ouvrez ce fichier et que vous explorez la section Guide de l'utilisateur de l'Environnement de préinstallation Windows, vous devriez voir une rubrique intitulée Reducing the Size of Windows PE (Réduction de la taille de Windows PE). Cette section répertorie un ensemble de fichiers que vous pouvez supprimer en toute sécurité (si vous n'en avez pas besoin). Vous trouverez trois sections concernant les fichiers supprimables :
  • Les fichiers de police peuvent toujours être supprimés.
  • Les fichiers .inf concernant la mise en réseau et les utilitaires peuvent être supprimés, mais ne le faites que si vous n'avez absolument pas l'intention d'utiliser votre version sur le réseau.
  • Les utilitaires de ligne de commande ne doivent pas être supprimés. Je vous déconseille d'en supprimer à moins que vous ne sachiez exactement à quoi ils servent et ce qui risque de se passer si vous les supprimez.
Après avoir déterminé quels sont les fichiers que vous pouvez exclure en toute sécurité, vous pouvez tout simplement écrire un fichier batch ou un autre script et les supprimer de votre version de Windows PE une fois que mkimg.cmd a terminé la mise en œuvre.

Modification du Registre Windows PE
Vous pouvez constater que nous avons fait le choix conscient de ne pas installer les composants facultatifs au moment de la mise en œuvre. Bien que ceci prenne un peu plus de temps au moment de l'exécution, cela signifie également que nous n'avons pas dû concevoir un moyen entièrement nouveau de replacer ces composants dans Windows PE, ce que nous n'avions pas le temps de faire et qui serait sans doute revenu à les omettre complètement. Mais que faire si vous souhaitez effectuer une modification du Registre, par exemple ajouter un delta de modification du Registre pour votre application, ou si vous voulez simplement modifier une clé qui pourrait empêcher le fonctionnement de l'application ? C'est en fait très simple grâce à regedit, comme illustré à la figure 3. Procédez de la façon suivante :
  1. Exécutez regedit et sélectionnez la ruche HKEY_LOCAL_MACHINE.
  2. Sélectionnez Fichier | Chargement de la ruche, puis accédez à l'emplacement de votre version de Windows PE. Sélectionnez setupreg.hiv sous I386\System32\ (ou MiniNT\System32, si c'est une image que vous mettez sur un disque dur).
  3. Entrez un nom temporaire pour la ruche, tel que WinPE, et accédez à ce nœud sous HKLM.
  4. Apportez les modifications nécessaires à cette clé. Il est intéressant de noter que ce nœud correspond effectivement au nœud HKLM\System que l'on trouverait sur une installation Windows normale.
  5. Une fois vos modifications réalisées, sélectionnez la clé que vous avez créée sous HKLM à l'étape 3 (il est très important de ne pas se tromper ici car vous pourriez endommager votre système).
  6. Sélectionnez Fichier | Décharger la ruche... et confirmez dans la boîte de dialogue Oui | Non. Veillez à démonter le registre à chaque fois car son verrouillage empêcherait une mise en œuvre réussie de Windows PE.
Figure 3 Ouverture du Registre Windows PE
Figure 3 Ouverture du Registre Windows PE (Cliquer sur l'image pour la réduire)
Figure 3 Ouverture du Registre Windows PE
Figure 3 Ouverture du Registre Windows PE (Cliquer sur l'image pour l'agrandir)
En suivant ces étapes, vous pouvez modifier HKLM\System. Il existe également deux autres clés situées sous I386\System32 qui vous permettent de modifier d'autres zones du registre : DEFAULT est la ruche par défaut pour les utilisateurs (même SYSTEM, que vous exécutez en utilisant Windows PE) et SOFTWARE, qui est identique à HKLM\Software. Comme toujours, modifiez le registre avec précaution et seulement en cas de besoin.
Fort de ces informations, vous devriez pouvoir essayer de déplacer votre outil de dépannage ou de récupération préféré sur Windows PE. Le mois prochain, j'aborderai la suite PSTools, un ensemble d'outils de gestion système très utiles également écrit par Mark Russinovich.
Utilisation de WinDiff
WinDiff peut vous aider à trouver les dépendances de votre application. Il vous suffit de suivre ces étapes pour réussir votre installation et votre exécution :
  1. Préparez votre système pour l'installation : cela vous permettra de réduire le temps et les éventuelles modifications de fichier ou de registre entre l'instantané initial et l'instantané final.
  2. Ouvrez une invite de commande et exécutez HKLM C:\HKLM1.reg pour réaliser une exportation complète de la ruche de registre HKEY_Local_Machine.
  3. Exécutez C:\*.* /S > C:\C1.txt pour supprimer tous les fichiers du lecteur C: (si C: est votre lecteur système).
  4. Installez votre application et configurez les paramètres de post-installation.
  5. Exécutez l'exportation de registre HKLM C:\HKLM2.reg.
  6. Exécutez le répertoire C:\*.* /S > C:\C2.txt.
  7. Ouvrez WinDiff, sélectionnez Fichier | Comparer les fichiers... et sélectionnez HKLM1.reg dans la première boîte de dialogue Ouvrir et HKLM2.reg dans la seconde.
  8. Vous devriez voir s'afficher en rouge un message indiquant le plus récent. Soyez patient ; ceci peut prendre un bon moment car il arrive que les exportations HKLM soient assez volumineuses.
  9. Double-cliquez sur le texte en rouge pour développer les différences.
  10. Vous souhaiterez peut-être configurer ce qui est affiché dans la comparaison en cochant Options | Show Right-Only Lines. Ceci affichera uniquement les nouvelles lignes dans le second fichier de comparaison (donc seuls les nouveaux fichiers et les nouvelles clés de registre apparaîtront).
Notez que vous aurez peut-être besoin d'utiliser la fonction de recherche pour trouver les clés en rapport avec votre application. Dans les Figures A et B, vous pouvez voir les modifications de fichier et de registre pour une application fictive créée par mes soins. Heureusement, les fonctions Copier et coller sont disponibles dans WinDiff. Pour utiliser ces fonctions, il suffit de cliquer sur la ligne !> et de sélectionner les lignes souhaitées.
Figure A Entrées WinDiff
Figure A Entrées WinDiff (Cliquer sur l'image pour la réduire)
Figure A Entrées WinDiff
Figure A Entrées WinDiff (Cliquer sur l'image pour l'agrandir)
Figure B Clé spécifique dans WinDiff
Figure B Clé spécifique dans WinDiff (Cliquer sur l'image pour la réduire)
Figure B Clé spécifique dans WinDiff
Figure B Clé spécifique dans WinDiff (Cliquer sur l'image pour l'agrandir)

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


 Sur le terrain: D&#233;connexion sauvage
Sur le terrain
Déconnexion sauvage
R'ykandar Korra'ti

« CHAIS PAS, ma connexion n'arrête pas de lâcher ».
« À une heure précise de la journée ? Tu fais quelque chose de précis lorsque ça se produit ? Tu te connectes à partir d'un ordinateur spécifique ?»
« Naan ! Un coup je suis connectée, et puis rien ! Pof ! Parti. »
« Tout ça, ca ne m'aide pas beaucoup, tu sais... Donne-moi quelque chose. Une piste, un indice, n'importe quoi. »
« Je t'ai dit tout ce que je sais. Parfois, la connexion lâche comme ça. Tu peux-réparer ça ? »
Je lui dis que je vais essayer. Il n'y a rien de concret dans les journaux du routeur, mais de temps à autre, notre trafic faiblit considérablement, ce qui indique que quelque chose ne va pas, mais seulement pendant une minute ou deux, et après, tout redevient normal. Aucune erreur, aucune régularité. Juste, pas de trafic à certains moments. Bizarre... Et là, coup de pot !
Dring, dring, coup de fil sur la ligne DSL.
Clic, clac fait notre connexion IP.
Non, c'est une blague, je me dis. Et pourtant, ca se reproduit : si quelqu'un appelle sur la ligne DSL, la ligne que personne n'utilise et que personne n'est supposé connaître, notre connexion est coupée. L'argument de vente de services n°1 de l'opérateur téléphonique, la calamité des calamités dont vous n'aurez jamais à vous soucier nous dit-on, eh bien, elle se produit !
Et pourtant, nous sommes seulement à 300 mètres de la sous-centrale. Ceci ne devrait pas se produire. Je vérifie les câbles, je réinitialise tout et je m'offre même le luxe de nettoyer les connexions, au cas où. Bien sûr, ça ne donne rien ! Du coup, j'appelle l'opérateur téléphonique. « Vous savez votre histoire de connexion qui ne peut jamais être interrompue pas un appel de téléphone entrant ? Ben, devinez un peu ? On peut subir un déni de service à cause des téléprospecteurs ! »
Attendez, c'est peut-être les câbles...
Attendez, c'est peut-être les câbles...
Le lendemain, un technicien arrive et découvre, chose bizarre, après avoir testé la ligne, que nous nous trouvons à plus d'un kilomètre de la sous-centrale, soit suffisamment loin pour être déconnectées par un écureuil farfelu équipé d'une boussole magnétique. Finalement, il découvre que lorsque le quartier a été câblé, toutes les lignes téléphoniques ont été regroupées et chaque ligne a été reliée à chaque bâtiment du pâté, de façon à éviter d'avoir jamais à tirer de nouveaux câbles. Cela ne pose pas de problème si vous êtes resté à l'ère analogique, mais dans le cadre d'une ligne DSL, chaque cm de branche augmente la distance par rapport à la sous-centrale, ce qui affaiblit la puissance du signal.
Fort heureusement, le problème a été vite résolu. Toutes les branches latérales de la ligne ont été déconnectées, et une note a été ajoutée : « NE PAS RECONNECTER. SECTION DSL EN COURS D'UTILISATION ». Et voilà ! Une distance de seulement 300 mètres, un signal beaucoup plus puissant et surtout, pas de déconnexion sur appel.
La morale de l'histoire ? Il ne faut jamais penser qu'un problème de connexion est ésotérique ou même qu'il est causé par le logiciel. Parfois, c'est juste une question de câble. N'oubliez jamais de faire vérifier le signal de votre ligne DSL par les techniciens au moment de son installation, même s'ils pensent que vous leur faites perdre leur temps. Cela pourrait vous éviter pas mal d'ennuis ! Et ne croyez pas aveuglément ce qu’ils vous racontent sur la distance à la sous-centrale. On ne sait jamais où ils vont, ces câbles. Ayez-en le cœur net ! Ils ont les outils et la technologie. Faites en sorte qu'ils les utilisent. Vous ne le regretterez pas. Surtout si les téléprospecteurs s'emparent de votre numéro DSL !

R'ykandar Korra'ti, administratrice d'un fournisseur d'accès Internet coopératif, habite près de Seattle avec Anna, sa partenaire. Ancienne collaboratrice de Microsoft où elle contribuait à l'expédition des produits commandés en ligne, elle contemple actuellement des études supérieures, dans un domaine si ésotérique qu'il ne possède pas vraiment de nom. Les conseillers d'orientation potentiels peuvent la joindre à l'adresse suivante : darako@murkworks.net.


 Windows Confidential: Un bienfait &#171;&#160;discutable&#160;&#187;
Windows Confidential
Un bienfait « discutable »
Raymond Chen

Lors de l'insertion d'un CD ou d'un DVD, l'interpréteur de commandes « détecte » le disque pour déterminer son type de contenu. Cette détermination guide ensuite l'interpréteur de commandes lorsqu'il doit choisir l'action d'exécution automatique à exécuter. La façon précise dont la détection s'effectue n'est pas décrite car il s'agit d'une méthode heuristique susceptible de changer à l'avenir si un meilleur algorithme est trouvé.
Décrire cet algorithme de façon formelle le rendrait contractuel et l'empêcherait par là même d'être affiné dans les versions subséquentes. Officiellement, donc, les détails de l'algorithme ne sont pas spécifiés.
Si vous n'avez jamais rédigé de documentation pour un SDK, vous n'avez peut-être pas conscience que cette documentation mène au contrat. Une fois que vous avez déclaré publiquement qu'un élément se comporte d'une certaine façon, vous ne pouvez plus le modifier. En effet, si vous le modifiez, les gens qui comptaient sur ce comportement diront, « Hé, ce n'est pas ce que dit la documentation. Vous modifiez les règles en cours de route. »
Ceci étant dit, voici une description rapide et incroyablement simplifiée de la façon dont Windows® XP Service Pack 2 (SP2) classe les contenus des CD et DVD de données dépourvus de fichier autorun.inf. (Les service packs futurs et les versions futures de Windows se comporteront peut-être différemment.) Si j'ai dit « incroyablement simplifiée », c'est parce que le véritable algorithme est une table de décisions comportant 61 étapes qui prend en considération toutes sortes d'informations. Il cherche notamment à déterminer si l'application en premier plan a répondu ou non à la notification « Query cancel autoplay » (Exécution automatique d'annulation de requête), si un programme en mode plein écran s'exécute et même si l'ordinateur est un portable qui a récemment été connecté à, ou déconnecté de sa console d'accueil. Mais nous allons nous intéresser uniquement à l'étape concernant la détection du contenu.

En premier lieu, l'interpréteur de commandes vérifie si l'utilisateur a choisi l'option « Take no action » (Ne rien faire) comme action pour tous les types de contenus. Si tel est le cas, il est inutile de détecter. La décision est simplement « Take no action » (Ne rien faire).
Autrement, l'interpréteur de commandes doit agir. Il examine chaque fichier sur le disque (en explorant jusqu'à quatre annuaires) et classe ces fichiers dans l'une des catégories suivantes en fonction du type qu'il a perçu : image, musique, film.
Les fichiers qui ne correspondent à aucune de ces catégories sont ignorés. Si une seule catégorie est représentée parmi tous les fichiers qui ont été vérifiés (supposons, par exemple, que tous les fichiers figurant sur le disque sont des fichiers de musique), elle détermine le type du disque. Si plusieurs de ces trois catégories sont représentées, on considère que le disque présente un contenu mixte.
Ceci signifie que la présence d'une pochette d'album sur un CD rempli de fichiers de musique conduira Windows XP SP2 à considérer le CD comme un CD à contenu mixte. Voici un parfait exemple de ce qui aurait sans doute besoin d'être affiné. Mais supposons maintenant que cet algorithme a effectivement été modifié et qu'il a été décidé que la présence occasionnelle d'une image sur un CD par ailleurs rempli de fichiers MP3 ne suffirait plus à faire de son contenu un contenu mixte. Il peut se faire qu'une entreprise ait un CD comportant de nombreux fichiers audio et seulement quelques images. Cette entreprise escompte, en fait, que le CD sera détecté comme ayant un contenu mixte. Mais lorsque l'algorithme est modifié, le CD est à tort classé comme CD de musique, ce qui contrarie l'entreprise. À qui incombe maintenant la responsabilité de ce problème ? Peut-on blâmer l'entreprise parce qu'elle a fait confiance au fonctionnement décrit de l'algorithme de détection ? Ou faut-il blâmer Windows qui est responsable de la modification de l'algorithme ?
Surprise : dans Windows Vista™, l'algorithme a été modifié, bien que légèrement. Dans Windows Vista, plusieurs vérifications ont été effectuées dès le début pour court-circuiter l'algorithme lorsque se présentent certaines dispositions de disque bien connues. Par exemple, si un dossier DCIM est présent dans la racine du disque, on suppose alors qu'il est composé d'images numériques. Attendons maintenant de voir si quelqu'un s'en rend compte.

Raymond Chen, appelé The Old New Thing (en anglais), et son livre portant le même titre (Addison-Wesley, 2007) traitent de l'historique de Windows et de la programmation Win32. Raymond se demande à quoi ressemble le soleil.