 TechNet Magazine April 2007
TechNet Magazine April 2007
APRIL 2007
Administration de Windows

Dans ce numéro, Mark Russinovich explore une nouvelle fois le noyau de Windows Vista pour analyser les améliorations apportées à la sécurité, la fiabilité et la récupération. La récupération Active Directory est également au cœur de notre magazine, ce mois-ci. Au lieu de réagir à une urgence, préparez un plan de récupération d'Active Directory à l'avance. Enfin, avant de décider que Windows XP Embedded n'a pas sa place dans votre entreprise, lisez notre article sur le sujet : vous serez étonné.

Administration

Comment atteindre le bon équilibre entre capacité de matériel et rentabilité ? Ce mois-ci, découvrez comment System Center Capacity Planner vous permet de modeler les besoins de votre infrastructure afin de bien planifier. Apprenez également à combiner Systems Management Server, WMI et un bout de script pour améliorer le rapport d'inventaire du client et à déployer des mises à jour personnalisées avec SMS.
FONCTIONNALITÉS
Administration de Windows Dans le Noyau de Windows Vista : Partie 3

Dans cette édition, nous proposons un condensé de la discussion approfondie que nous avons eue sur les nouveautés du noyau de Windows Vista. Dans ce numéro final, nous abordons les changements et les nouvelles fonctionnalités se rapportant à la fiabilité, à la récupération et à la sécurité.

Mark Russinovich Récupération après incident : utilisateurs et groupes Active Directory

La récupération de données dans Active Directory peut être très complexe, mais il est essentiel que vous mettiez en place un plan de récupération. Nous allons vous expliquer comment Active Directory enregistre, supprime, restaure et réplique des objets, pour que vous soyez prêt la prochaine fois qu'un utilisateur ou qu'une appartenance au groupe est accidentellement supprimé.

Gil Kirkpatrick Pourquoi Windows XP Embedded est important pour vous

Quoique vous ne le sachiez pas, Windows XP Embedded pourrait parfaitement convenir à la gamme informatique de votre organisation. Découvrez comment Windows XP Embedded peut réduire vos frais administratifs, vous faire économiser de l'argent et améliorer la sécurité.

Don Jones Administration Planification avec System Center Capacity Planner

Une insuffisance en matériel mène à de mauvais temps de réponse, alors qu'un excès de matériel constitue une perte de ressources de budget et d'administration. Découvrez comment utiliser System Center Capacity Planner pour modeler votre réseau et bien évaluer vos besoins en infrastructure.

John Savill Inventaires de clients avancés avec SMS

Dès l'installation, Microsoft Systems Management Server 2003 recueille beaucoup d'informations, mais pas autant que vous n'en voulez. Découvrez comment une bonne combinaison de connaissances en écriture de script, en WMI et en SMS peut vous aider à développer les inventaires SMS pour recueillir et signaler presque n'importe quelle information.

Wes Dobry Déployer des mises à jour de logiciel personnalisées avec SMS 2003 R2

Systems Management Server 2003 R2 vous permet d'utiliser des fonctions managedupdate pour déployer des mises à jour personnalisées. Explorez deux nouveaux outils, l'outil d'inventaire pour les mises à jour personnalisées et l'outil de publication des mises à jour personnalisées, et voyez comment ils peuvent vous aider à déployer vos propres mises à jour, ainsi que les mises à jour des développeurs tiers.

Steve Rachui
COLONNES
Le mot du rédacteur en chef

Nous avons peut-être tort...

Joshua Trupin Boîte à outils

Nouveaux produits pour les professionnels de l'informatique

Greg Steen Forum aux questions SQL

Reconstruction d'index, longueur de la file d'attente du disque, etc.

Par Nancy Michell Coup de projecteur sur les utilitaires

Autoruns

Lance Whitney Le petit câbleur

Paramètres de stratégie de groupe sans fil pour Windows Vista

Joseph Davy Windows PowerShell

Filtrage et formatage de données

Don Jones 		Hé, vous le Scripteur !

Approche naïve des utilisateurs et groupes locaux

Les scripteurs Microsoft Vigilance sécurité

L'assistant de configuration de sécurité

John Morello Histoires de Bureau

x64 et moi, et moi, et moi

Wes Miller Microsoft.com au jour le jour

Utilisation des services ADFS (Active Directory Federation Services)

Jim Guthrie Sur le terrain

Apprendre dans la joie (et la douleur)

Mark D. Scott La vie secrète de Windows

Le Pouvoir de bogues

Raymond Chen


 Administration Windows: Dans le noyau de Windows Vista&#160;: 3&#232; partie
Administration Windows Mark Russinovich

Dans le noyau de Windows Vista : 3è partie
Vue d'ensemble:
  • Fiabilité
  • Récupération
  • Sécurité

Cette série a couvert jusqu'à présent les améliorations du noyau de Windows Vista liées aux processus, à l'E/S, à la gestion de la mémoire, au démarrage et à l'arrêt du système, ainsi qu'à la gestion de l'alimentation. Dans ce troisième et dernier
numéro, je jette un coup d'œil sur les fonctionnalités et les améliorations concernant la fiabilité, la récupération et la sécurité.
L'une des fonctionnalités que je n'aborde pas dans cette série est le Contrôle du compte utilisateur (UAC), qui se compose de plusieurs technologies différentes, y compris la virtualisation des systèmes et registres de fichiers pour les applications héritées, le consentement d'élévation pour accéder aux droits administratifs et le mécanisme Windows® Integrity Level isolant les processus fonctionnant avec les droits administratifs provenant des processus moins privilégiés s'exécutant dans le même compte. Vous pourrez consulter mon analyse approfondie du fonctionnement interne de l'UAC dans une prochaine édition de Technet Magazine.
Windows Vista™ améliore la fiabilité de votre système et votre capacité à diagnostiquer les problèmes relatifs aux systèmes et aux applications via plusieurs nouvelles fonctionnalités et améliorations. Par exemple, le Suivi d'évènements du noyau de l'enregistreur Windows (ETW) est toujours actif, générant des évènements de suivi pour les fichiers, les registres, les interruptions et autres types d'activités dans un tampon circulaire. Lorsqu'un problème survient, la nouvelle Windows Diagnostic Infrastructure (WDI) peut capturer un cliché du tampon et l'analyser localement ou l'envoyer au service d'assistance de Microsoft pour obtenir un dépannage.
Le nouveau moniteur de performances et de fiabilité Windows aide les utilisateurs à relier les erreurs, telles que les incidents et les blocages, aux changements qui ont été apportés à la configuration du système. Le puissant SRT (System Repair Tool) remplace la Console de récupération pour les récupérations hors ligne des systèmes qui ne peuvent pas redémarrer.
Il existe trois domaines qui s'appuient sur les changements du système au niveau du noyau, ce qui mérite une analyse plus précise dans cet article : Le Gestionnaire de transactions du noyau (KTM), le traitement amélioré des incidents et les Versions précédentes.

Gestionnaire de transactions du noyau
L'un des aspects les plus ennuyeux du développement de logiciels consiste en la gestion des conditions d'erreur. Ceci est particulièrement vrai si, lors de la réalisation d'une opération de haut niveau, une application a terminé une ou plusieurs sous-tâches, entraînant des modifications au système ou au registre de fichiers. Par exemple, un service de mise à jour des logiciels d'une application donnée peut effectuer plusieurs mises à jour du registre, remplacer l'un des exécutables de cette application, puis se voir refuser l'accès lorsqu'il tente de mettre à jour un second exécutable. Si ce service ne veut pas quitter l'application dans cet état incohérent, il doit suivre tous les changements qu'il apporte et être prêt à les annuler. Il est difficile de tester le code de récupération des erreurs et cette opération est donc souvent ignorée. Ainsi, en cas d'erreur au niveau du code de récupération, ces manœuvres peuvent s'avérer inefficaces.
Les applications écrites pour Windows Vista peuvent, avec très peu d'efforts, générer des capacités automatiques de récupération des erreurs à l'aide de la nouvelle prise en charge transactionnelle NTFS et du registre du Gestionnaire de transactions du noyau. Lorsqu'une application souhaite effectuer plusieurs modifications apparentées, elle peut soit créer une transaction avec le Coordinateur de transactions réparties (DTC) et une gestion transactionnelle KTM, soit directement créer une gestion KTM et associer les modifications des fichiers et des clés du registre à la transaction. Si tous les changements réussissent, l'application valide la transaction et les changements sont appliqués, mais à tout moment et jusqu'à ce point, elle peut restaurer la transaction, auquel cas les changements sont supprimés.
Un autre avantage est que les autres applications ne voient pas les modifications apportées à une transaction donnée, tant que celle-ci n'est pas validée. Les applications qui utilisent le DTC de Windows Vista et le futur Windows Server®, dont le nom de code est « Longhorn, » peuvent coordonner leurs transactions avec SQL Server™, Microsoft® Message Queue Server (MSMQ) et d'autres bases de données. Un service de mise à jour des applications qui se sert des transactions KTM ne laissera donc jamais une application dans un état incohérent. C'est pourquoi la mise à jour et la restauration du système Windows utilisent des transactions.
KTM, véritable cœur de la prise en charge des transactions, permet aux gestionnaires de ressources transactionnelles, tels que NTFS et le registre, de coordonner leurs mises à jour pour un ensemble spécifique de modifications faites par une application donnée. Dans Windows Vista, NTFS utilise une extension afin de prendre en charge les transactions appelées TxF. Le registre utilise une extension similaire appelée TxR. Ces gestionnaires de ressources en mode noyau travaillent avec le KTM pour coordonner l'état des transactions, exactement de la même façon que les gestionnaires de ressources en mode utilisateur utilisent le DTC pour coordonner l'état des transactions parmi une multitude de gestionnaires de ressources en mode utilisateur. Les parties tierces peuvent également utiliser KTM pour mettre en place leurs propres gestionnaires de ressources.
TxF et TxR définissent tous deux un nouvel ensemble d'API de système de fichiers et de registre, similaires à ceux qui existent, sauf qu'ils incluent un paramètre de transaction. Si une application veut créer un fichier dans une transaction, elle utilise d'abord KTM pour créer la transaction, puis passe la gestion de la transaction résultante à l'API de création du nouveau fichier.
TxF et TxR s'appuient tous deux sur la fonctionnalité d'enregistrement ultra-rapide du système de fichiers du Common Log File System (%SystemRoot%\System32\Clfs.sys), introduit dans Windows Server 2003 R2. TxR et TxF utilisent CLFS pour durablement enregistrer les modifications de l'état des transactions avant de valider ces transactions. Ceci leur permet de fournir une récupération des transactions et des assurances, même en cas de court-circuit. Outre le journal CLFS, TxR crée un ensemble de fichiers de journaux apparentés pour suivre les modifications de transactions apportées au fichier du registre du système dans %Systemroot%\System32\Config\Txr, tel que le montre la figure 1, et sépare les fichiers de journaux pour la ruche de registre de chaque utilisateur. TxF enregistre des données transactionnelles pour chaque volume dans un répertoire masqué sur le volume nommé $Extend\$RmMetadata.
Figure 1 Fichiers d'enregistrement TxR de la ruche de registre du système
Figure 1 Fichiers d'enregistrement TxR de la ruche de registre du système (Cliquer sur l'image pour la réduire)
Figure 1 Fichiers d'enregistrement TxR de la ruche de registre du système
Figure 1 Fichiers d'enregistrement TxR de la ruche de registre du système (Cliquer sur l'image pour l'agrandir)

Prise en charge améliorée des incidents
Lorsque Windows rencontre une erreur en mode noyau irrécupérable - que ce soit en raison d'un blocage au niveau du pilote d'un périphérique, de matériel défectueux ou du système d'exploitation - il essaie d'empêcher l'altération des données du disque en arrêtant le système après avoir affiché le fameux « écran bleu de mort » et, si la configuration le permet, en écrivant le contenu d'une partie ou de l'intégralité de la mémoire physique vers un fichier de décharge d'incidents. Les fichiers de décharge sont utiles car lorsque vous redémarrez après un incident, le service d'analyse en ligne des incidents de Microsoft (OCA) propose de les analyser afin de déterminer la cause d'origine. Si vous le souhaitez, vous pouvez également les analyser en utilisant les outils de débogage Microsoft pour Windows).
Cependant, dans les versions précédentes de Windows, la prise en charge des fichiers de décharge d'incidents était inactive tant que le processus Gestionnaire de sessions (%Systemroot%\System32\Smss.exe) ne commençait pas la pagination des fichiers. Ceci voulait dire que toutes les erreurs critiques survenant avant ce point affichaient un écran bleu, mais pas de fichier de décharge. Puisque la plus grande partie de l'initialisation des pilotes de périphérique se produit avant le démarrage de Smss.exe, les premiers incidents n'entraînaient jamais la création de fichiers de décharge, rendant ainsi extrêmement difficile de diagnostiquer la cause de ce problème.
Windows Vista réduit l'intervalle au cours duquel aucun fichier de décharge n'est généré par l'initialisation de la prise en charge de ces fichiers, une fois que tous les pilotes de périphérique de démarrage ont été initialisés, mais avant de charger les pilotes de démarrage du système. À cause de cette modification, si vous rencontrez un incident au cours de la période initiale du processus de démarrage, le système peut capturer une décharge d'incidents, permettant à OCA de vous aider à résoudre le problème. De plus, Windows Vista enregistre les données dans un fichier de décharge en blocs de 64 Ko, tandis que les versions précédentes de Windows les écrivaient en blocs de 4 Ko. Cette modification entraîne la création de grands fichiers de décharge écrits jusqu'à 10 fois plus rapidement.
Dans Windows Vista, la gestion des incidents d'application est également améliorée. Dans les versions précédentes de Windows, lorsqu'une application plantait, elle exécutait un gestionnaire d'exceptions non gérées. Le gestionnaire lançait le processus de signalement d'erreurs d'application de Microsoft (AER) (%Systemroot%\System32\Dwwin.exe) pour afficher une boîte de dialogue indiquant que le programme avait planté et vous demandant si vous vouliez envoyer un rapport d'erreur à Microsoft. Cependant, si la pile du fil principal du processus était corrompue pendant l'incident, le gestionnaire d'exceptions non gérées plantait lors de son exécution, entraînant l'arrêt du processus par le noyau, la disparition immédiate des fenêtres du programme et l'absence de boîte de dialogue pour le signalement des erreurs.
Windows Vista déplace la gestion des erreurs hors du contexte du processus de plantage vers un nouveau service, Windows Error Reporting (WER). Ce service est mis en place par une DLL (%Systemroot%\System32\Wersvc.dll) au sein d'un processus d'hébergement de services. Lorsqu'une application plante, elle continue d'exécuter le gestionnaire d'exceptions non gérées, mais ce gestionnaire envoie un message au service WER, lequel lance le processus de signalement des fautes WER (%Systemroot%\System32\Werfault.exe) pour afficher la boîte de dialogue de signalement des erreurs. Si la pile est corrompue et que le gestionnaire d'exceptions non gérées plante, le gestionnaire continuera de s'exécuter et de planter, finissant par consommer toute la pile du fil (zone de mémoire « scratch ») ; c'est alors que le noyau intervient et qu'il envoie le message de notification du plantage au service.
Vous pouvez voir le contraste entre ces deux approches dans les figures 2 et 3, lesquelles montrent la relation entre les processus d'Accvio.exe, un programme de test qui plante, et les processus de signalement d'erreurs soulignés en vert, sur Windows XP et Windows Vista. Avec la nouvelle architecture de gestion des erreurs de Windows Vista, les programmes ne s'arrêteront plus de façon silencieuse sans offrir à Microsoft la possibilité d'obtenir un rapport d'erreur et sans aider les développeurs à améliorer leurs applications.
Figure 2a Gestion des erreurs d'application dans Windows XP
Figure 2a Gestion des erreurs d'application dans Windows XP (Cliquer sur l'image pour la réduire)
Figure 2a Gestion des erreurs d'application dans Windows XP
Figure 2a Gestion des erreurs d'application dans Windows XP (Cliquer sur l'image pour l'agrandir)
Figure 2b
Figure 2b (Cliquer sur l'image pour la réduire)
Figure 2b
Figure 2b (Cliquer sur l'image pour l'agrandir)
Figure 3a Gestion des erreurs d'application dans Windows Vista
Figure 3a Gestion des erreurs d'application dans Windows Vista (Cliquer sur l'image pour la réduire)
Figure 3a Gestion des erreurs d'application dans Windows Vista
Figure 3a Gestion des erreurs d'application dans Windows Vista (Cliquer sur l'image pour l'agrandir)
Figure 3b
Figure 3b

Cliché instantané des volumes
Windows XP a introduit une technologie appelée Cliché instantané des volumes pour prendre des clichés des volumes du disque à un moment donné. Les applications de sauvegarde peuvent utiliser ces clichés pour créer des images de sauvegarde cohérentes. Cependant, ces clichés sont normalement masqués et conservés uniquement pendant la durée du processus de sauvegarde.
Les clichés ne sont en fait pas des copies complètes des volumes. Ce sont plutôt des vues d'un volume d'un moment antérieur comprenant les données de volume actives superposées aux copies des secteurs de volume, qui, depuis la prise du cliché, ont été modifiées. Le pilote Fournisseur de clichés de volumes (%Systemroot\%System32\Drivers\Volsnap.sys) contrôle les opérations destinées aux volumes et crée des copies de sauvegarde des secteurs avant de leur permettre d'être modifiées, stockant les données d'origine dans un fichier associé au cliché dans le répertoire du volume intitulé Informations sur les volumes du système.
Windows Server 2003 affichait la gestion des clichés aux administrateurs du serveur et aux utilisateurs des systèmes clients, grâce à ses clichés instantanés pour dossiers partagés. Cette fonctionnalité activait des clichés permanents, auxquels les utilisateurs pouvaient accéder via l'onglet Versions précédentes dans les boîtes de dialogue de propriétés de l'explorateur, ceci pour leurs dossiers et fichiers situés dans les partages de fichiers du serveur.
La fonctionnalité Versions précédentes de Windows Vista offre cette prise en charge à tous les systèmes clients, créant automatiquement des clichés de volumes, généralement une fois par jour. Vous pouvez y accéder via les boîtes de dialogue de propriétés de l'explorateur à l'aide de la même interface utilisée par les clichés instantanés pour dossiers partagés. Ceci vous permet d'afficher, de restaurer ou de copier des vieilles versions de fichiers et de répertoires que vous pourriez avoir accidentellement modifiées ou supprimées. Si du point de vue technique il ne s'agit pas d'une nouvelle technologie, la mise en place de la fonction Cliché instantané de volumes par la fonctionnalité Versions précédentes de Windows Vista optimise celle de Windows Server 2003 destinée aux environnements de postes de travail clients.
Windows Vista tire également parti des clichés de volumes pour unifier les mécanismes de protection des données de l'utilisateur et du système, ainsi que pour éviter d'enregistrer des données de sauvegarde redondantes. Lorsque l'installation d'une application ou le changement d'une configuration entraîne des comportements incorrects ou indésirables, vous pouvez utiliser la fonction Restauration du système, une fonctionnalité introduite dans la gamme de systèmes d'exploitation Windows NT ® de Windows XP visant à restaurer les fichiers et données du système tels qu'ils étaient lors de la création du point de restauration.
Dans Windows XP, la fonction Restauration du système fait appel à un pilote de filtre pour le système de fichiers £ un type de pilote qui peut voir les modifications au niveau du fichier £ afin de créer des copies de sauvegarde des fichiers du système lors de leur modification. Dans Windows Vista, cette fonction utilise les clichés de volume. Lorsque vous utilisez l'interface utilisateur Restauration du système de Windows Vista pour revenir à un point de restauration donné, vous copiez en fait les versions précédentes des fichiers de système modifiés à partir du cliché associé à ce point de restauration vers le volume actif.

BitLocker
Windows Vista est à ce jour la version la plus sûre de Windows. Outre l'inclusion du moteur antivirus Windows Defender, Windows Vista introduit de nombreuses fonctionnalités de sécurité et de défense approfondies, y compris le chiffrage complet de volumes BitLocker™, la signature de code pour le code en mode noyau, les processus protégés, la randomisation du chargement des espaces d'adressage et les améliorations apportées à la sécurité des services Windows et au Contrôle du compte utilisateur.
Un système d'exploitation peut uniquement appliquer ses stratégies de sécurité lorsqu'il est actif ; vous devez donc prendre des mesures supplémentaires pour protéger les données lorsque la sécurité physique d'un système peut être corrompue et qu'il est possible d'accéder aux données hors du système d'exploitation. Les mécanismes basés sur le matériel tels que les mots de passe et le chiffrage du BIOS sont deux technologies fréquemment utilisées pour empêcher les accès non autorisés, en particulier sur les ordinateurs portables, lesquels sont les plus susceptibles d'être perdus ou volés.
Windows 2000 a introduit le système de fichiers EFS (Encrypting File System) et, dans sa version Windows Vista, EFS inclut plusieurs améliorations par rapport aux mises en place précédentes, y compris des améliorations de performances, la prise en charge du chiffrage du fichier de pagination et le stockage des clés utilisateur EFS sur les cartes à puce. Cependant, vous ne pouvez pas utiliser EFS pour protéger l'accès aux zones sensibles du système, telles que les fichiers de la ruche du registre. Par exemple, si la Stratégie de groupe vous autorise à vous connecter sur votre ordinateur portable même lorsque vous n'êtes pas connecté à un domaine, vos vérificateurs d'authentification sont mis en cache dans le registre : un pirate pourrait alors utiliser des outils pour obtenir le hachage du mot passe de votre compte de domaine, puis se servir de cela pour retrouver votre mot de passe avec un outil de recherche de mot de passe. Ce mot de passe lui permettrait alors d'accéder à votre compte et à vos fichiers EFS (en supposant que vous n'avez pas enregistré la clé EFS sur une carte à puce).
Pour faciliter le chiffrage de l'intégralité du volume de démarrage (le volume accompagné du répertoire Windows), y compris tous ses fichiers et données de système, Windows Vista offre une fonctionnalité de chiffrage complet de volume appelée Windows BitLocker Drive Encryption. Contrairement à EFS, mis en place par le pilote du système de fichiers NTFS et fonctionnant au niveau du fichier, BitLocker chiffre au niveau du volume à l'aide du pilote Full Volume Encryption (FVE) (%Systemroot%\System32\Drivers\Fvevol.sys), tel que le montre le diagramme de la figure 4.
Figure 4 Pilote de filtre FVE de BitLocker
Figure 4 Pilote de filtre FVE de BitLocker (Cliquer sur l'image pour la réduire)
Figure 4 Pilote de filtre FVE de BitLocker
Figure 4 Pilote de filtre FVE de BitLocker (Cliquer sur l'image pour l'agrandir)
FVE est un pilote de filtre ; il voit donc automatiquement toutes les requêtes d'E/S que NTFS envoie au volume, chiffrant les blocs au fur et à mesure de leur écriture et les déchiffrant lors de leur lecture, à l'aide de la clé Full Volume Encryption Key (FVEK) attribuée au volume lors de sa configuration initiale pour utiliser BitLocker. Par défaut, les volumes sont chiffrés en utilisant une clé AES de 128 bits et une clé de réflecteur de 128 bits. Puisque le chiffrage et le déchiffrage se produisent sous NTFS, dans le système E/S, le volume apparaît à NTFS comme s'il n'était pas chiffré, celui-ci n'ayant même pas besoin de savoir que BitLocker est activé. Cependant, si vous tentez de lire les données du volume hors de Windows, celles-ci auront une apparence aléatoire.
La clé FVEK est chiffrée avec une clé VMK (Volume Master Key) et stockée dans une zone de métadonnées spéciale du volume. Lorsque vous configurez BitLocker, vous disposez d'un nombre d'options vous permettant de déterminer comment la clé VMK sera protégée, en fonction des capacités du matériel du système. Si le système a un module TPM (Trusted Platform Module) conforme à la v1.2 de la spécification TPM et qu'il est associé à une prise en charge du BIOS, vous pouvez alors chiffrer la clé VMK avec le TPM, exiger que le système chiffre la clé VMK en utilisant une clé stockée dans le TPM et une autre conservée dans le périphérique USB à mémoire flash ou chiffrer la clé à l'aide d'une clé stockée dans le TPM et d'un PIN que vous saisissez au démarrage du système. Pour les systèmes qui n'ont pas de TPM, BitLocker propose de chiffrer la VMK en utilisant une clé stockée sur un périphérique USB externe à mémoire flash. Dans tous les cas, vous aurez besoin d'un volume de système NTFS non chiffré de 1.5 Go dans lequel sont stockés le Gestionnaire de démarrage et la Base de données de configuration du démarrage (BCD).
L'utilisation d'un TPM est avantageuse car BitLocker se sert des fonctionnalités TPM pour s'assurer de ne pas déchiffrer et déverrouiller le volume de démarrage si le BIOS ou les fichiers de démarrage du système ont été modifiés, étant donné que BitLocker était activé. Lorsque vous chiffrez le volume du système pour la première fois, et chaque fois que vous mettez à jour l'un des composants mentionnés, BitLocker calcule les hachages SHA-1 de ces composants et enregistre chacun d'entre eux, ce qui s'appelle une mesure, dans différents PCR (Platform Configuration Registers) du TPM à l'aide du pilote de périphérique de ce dernier (%Systemroot%\System32\Drivers\Tpm.sys). Il utilise ensuite le TPM pour sceller la VMK, une opération qui utilise une clé privée stockée dans le TPM pour chiffrer la VMK et les valeurs stockées dans les PCR avec les autres données que BitLocker passe au TPM. BitLocker stocke ensuite la VMK scellée et la FVEK chiffrée dans la zone de métadonnées du volume.
Lorsque le système démarre, il mesure son propre hachage et code de chargement PCR et écrit le hachage du premier PCR du TPM. Il hache ensuite le BIOS et stocke cette mesure dans le PCR approprié. À son tour, le BIOS hache le composant suivant de la séquence de démarrage, le MBR (Master Boot Record) du volume de démarrage, et ce processus continue jusqu'à ce que le chargeur du système d'exploitation soit mesuré. Chaque partie subséquente de code qui s'exécute est responsable de mesurer le code qu'elle charge et de stocker la mesure dans le registre approprié du TPM. Pour finir, lorsque l'utilisateur sélectionne le système d'exploitation à démarrer, le Gestionnaire de démarrage (Bootmgr) lit la VMK chiffrée à partir du volume et demande au TPM de la desceller. Le TPM déchiffrera correctement la VMK uniquement si toutes les mesures sont identiques à celles qui étaient en vigueur au moment du scellage de la VMK, y compris le PIN facultatif.
Vous pouvez considérer ce plan comme une chaîne de vérification où chaque composant de la séquence de démarrage décrit le composant suivant au TPM. Le TPM divulguera son secret uniquement si toutes les descriptions correspondent à celles d'origine qui lui ont été données. BitLocker protège donc les données chiffrées même lorsque le disque est supprimé et placé dans un autre système, que le système démarre à l'aide d'un système d'exploitation différent ou que les fichiers non chiffrés sur le volume de démarrage sont compromis.

Vérification de l'intégrité du code
Les logiciels malveillants qui sont implémentés comme pilotes de périphérique en mode noyau, y compris les rootkits, s'exécutent à un niveau de privilège identique à celui du noyau ; ainsi, ces programmes sont les plus difficiles à identifier et à supprimer. Ce type de logiciel peut modifier le comportement du noyau et des autres pilotes jusqu'à devenir pratiquement invisible. L'intégrité du code de Windows Vista pour la fonctionnalité de code en mode noyau, également connue sous le nom de signature de code en mode noyau (KMCS), autorise le chargement des pilotes de périphérique seulement s'ils sont publiés et signés numériquement par des développeurs approuvés par l'une des peu nombreuses autorités de certification. Le KMCS est appliqué par défaut sur Windows Vista pour les systèmes de 64 bits.
Puisque les autorités de certification facturent leurs services et procèdent à des vérifications de base, telles que la vérification de l'identité d'une entreprise, il est plus difficile de produire un logiciel malveillant anonyme en mode noyau qui s'exécute sur Windows Vista 64 bits. De plus, si un logiciel malveillant réussit à s'infiltrer via le processus de vérification et qu'il est découvert sur un système corrompu, il peut laisser des indices qui permettent de remonter à son auteur. Le KMCS a également d'autres utilisations, comme la fourniture de coordonnées à l'équipe d'analyse en ligne des incidents Windows, lorsqu'un pilote est soupçonné d'avoir un bogue qui plante les systèmes clients, et le déverrouillage de contenu multimédia de haute définition, que je décrirai bientôt.
Le KMCS se sert des technologies de chiffrage à clé publique, utilisées par Windows depuis plus d'une décennie, et a besoin que le code en mode noyau comprenne une signature numérique générée par l'une des autorités de certification de confiance. Si un éditeur soumet un pilote au Microsoft Windows Hardware Quality Laboratory (WHQL) et que le pilote réussit l'essai de fiabilité, c'est Microsoft qui agira en tant qu'autorité de certification. La plupart des éditeurs obtiendront des signatures à l'aide de WHQL, mais lorsqu'un pilote n'a pas de programme de test WHQL, que l'éditeur ne veut pas se soumettre à l'essai WHQL ou que le pilote est un pilote de démarrage qui se charge tôt dans le démarrage du système, les éditeurs doivent signer le code eux-mêmes. Pour ce faire, ils doivent d'abord obtenir un certificat de signature de code de l'une des autorités de certifications que Microsoft estime être de confiance pour la signature de code en mode noyau. Ensuite, l'auteur hache numériquement le code, signe le hachage en le chiffrant avec une clé privée et insère le certificat et le hachage chiffré dans le code.
Lorsqu'un pilote essaie de se charger, Windows déchiffre le hachage inséré dans le code en utilisant la clé publique stockée dans le certificat, puis vérifie que le hachage correspond à celui inséré dans le code. L'authenticité du certificat est vérifiée de la même façon, mais en utilisant la clé publique de l'autorité de certification, incluse dans Windows.
Windows vérifie également les chaînes de certificats associées jusqu'à l'une des autorités racine intégrées dans le chargeur de démarrage et le noyau du système d'exploitation de Windows. Il ne faut jamais essayer de charger un pilote de 64 bits non signé sur un système de production, donc, contrairement au Gestionnaire Plug-and-play, qui affiche une boîte de dialogue d'avertissement lorsqu'on lui demande de charger un pilote qui n'a pas de signature confirmant qu'il a passé un essai WHQL, Windows Vista 64 bits écrit silencieusement un événement dans le journal des événements d'applications relatives à l'intégrité du code, comme celui qui apparaît dans la figure 5, chaque fois que le chargement d'un pilote non signé est bloqué. Windows 32 bits vérifie également les signatures des pilotes, mais autorise le chargement des pilotes non signés. Les bloquer briserait les systèmes Windows XP mis à niveau, car ils nécessitent des pilotes chargés sur Windows XP, et autoriserait également la prise en charge du matériel pour lequel seuls des pilotes Windows XP existent. Cependant, Windows Vista 32 bits écrit également des événements dans le journal des événements d'intégrité du code lors du chargement d'un pilote non signé.
Figure 5 Événements non signés de tentatives de chargement de pilotes
Figure 5 Événements non signés de tentatives de chargement de pilotes (Cliquer sur l'image pour la réduire)
Figure 5 Événements non signés de tentatives de chargement de pilotes
Figure 5 Événements non signés de tentatives de chargement de pilotes (Cliquer sur l'image pour l'agrandir)
Puisque la signature de code est habituellement utilisée pour étiqueter le code comme une version officielle rigoureusement testée, les éditeurs ne veulent en général pas signer le code de test. Windows Vista inclut donc un mode de signature de test que vous pouvez activer et désactiver avec l'outil de Bcdedit (décrit dans mon article de Technet Magazine de mars 2007), où il chargera les pilotes en mode noyau signés numériquement avec un certificat de test produit par une autorité de certification interne. Ce mode est conçu pour être utilisé par des programmeurs lorsqu'ils développent leur code. Lorsque ce mode est activé dans Windows, des marqueurs s'affichent sur le bureau, tel que le montre la figure 6.
Figure 6 Mode de signature de test de Windows Vista
Figure 6 Mode de signature de test de Windows Vista

Processus protégés
Le contenu multimédia prochaine génération, tel que les DVD HD, BluRay et autres formats autorisés par le système AACS (Advanced Access Content System), sera plus répandu lors des années à venir. Windows Vista inclut plusieurs technologies, appelées PMP (Protected Media Path), exigées par la norme AACS pour que ce contenu soit lu. Les PMP incluent le PUMA (Protected User-Mode Audio) et le PVP (Protected Video Path), lesquels fournissent à eux deux les mécanismes nécessaires aux pilotes audio et vidéo, ainsi que les applications de lecteurs de supports numériques, afin d'empêcher les logiciels ou le matériel non autorisé de capturer du contenu de haute définition.
PUMA et PVP définissent les interfaces et la prise en charge spécifiques aux lecteurs audio et vidéo, aux pilotes de périphérique et au matériel, mais PMP se base également sur un mécanisme de noyau général introduit dans Windows Vista, appelé processus protégé. Les processus protégés se fondent sur la construction de processus standards Windows qui encapsulent une image exécutable en cours de fonctionnement, ses DLL, son contexte de sécurité (le compte sous lequel le processus s'exécute et ses privilèges de sécurité) et les fils qui exécutent le code dans le processus, mais empêchent certains types d'accès.
Les processus standards mettent en place un modèle de contrôle d'accès qui octroie au propriétaire du processus et des comptes administrateur un accès complet, grâce au privilège Déboguer les programmes. L'accès complet permet à un utilisateur de visualiser et de modifier l'espace d'adressage du processus, y compris le code et les données mappés dans le processus. Les utilisateurs peuvent également injecter des fils dans le processus. Ces types d'accès ne sont pas conformes aux exigences de PMP parce qu'ils permettraient au code non autorisé d'avoir accès au contenu haute définition et aux clés de gestion des droits numériques (DRM) stockées dans un processus qui lit le contenu.
Les processus protégés restreignent l'accès à un ensemble limité d'interfaces de gestion des informations et des processus qui incluent les requêtes de nom d'image du processus, ainsi que l'arrêt ou la suspension du processus. Mais le noyau met à disposition les informations diagnostiques des processus protégés via les fonctions générales de requêtes de processus, lesquelles retournent des données concernant tous les processus d'un système particulier et ne nécessitent donc pas un accès direct au processus. Les accès qui pourraient corrompre les supports numériques sont uniquement autorisés par d'autres processus protégés.
De plus, afin d'empêcher les corruptions de l'intérieur, tout le code exécutable chargé dans un processus protégé, y compris son image et ses DLL exécutables, doit être signé par Microsoft (WHQL) avec un indicateur Environnement protégé (PE) ou, s'il s'agit d'un codec audio, par un développeur disposant d'un certificat de signature DRM obtenu auprès de Microsoft. Puisque le code en mode noyau peut avoir un accès complet à tous les processus, y compris les processus protégés, et que Windows 32 bits autorise le chargement du code non signé en mode noyau, le noyau fournit une API pour les processus protégés afin d'interroger la « propreté » de l'environnement en mode noyau et d'utiliser le résultat pour déverrouiller le contenu essentiel, seulement si aucun code non signé est chargé.
Identification d'un processus protégé
Aucun API n'identifie en particulier les processus protégés, mais vous pouvez les identifier indirectement en fonction des informations limitées disponibles et parce qu'ils sont impossibles à déboguer, même à partir d'un compte administrateur. Le processus Audio Device Graph Isolation (%Systemroot%\System32\Audiodg.exe) est utilisé pour lire les DVD codés CSS (Content Scramble System) et peut s'identifier comme un processus protégé dans le volet Gestionnaire des tâches par le fait que ce Gestionnaire des tâches ne peut obtenir sa ligne de commande, sa virtualisation et son état Interdire l'exécution des données, même lorsqu'il est exécuté avec des droits administratifs.
Visualisation du processus protégé audiodg par le Gestionnaire des tâches
Visualisation du processus protégé audiodg par le Gestionnaire des tâches (Cliquer sur l'image pour la réduire)
Visualisation du processus protégé audiodg par le Gestionnaire des tâches
Visualisation du processus protégé audiodg par le Gestionnaire des tâches (Cliquer sur l'image pour l'agrandir)

Randomisation du chargement de l'espace d'adressage
Malgré les mesures comme Interdire l'exécution des données et la vérification améliorée des erreurs du compilateur, les auteurs de logiciels malveillants continuent à rechercher des failles dans la saturation de la mémoire tampon qui leur permettraient d'infecter des processus ouverts sur le réseau, tels qu'Internet Explorer®, les services Windows et les applications tierces, afin de s'ancrer dans un système. Cependant, une fois qu'ils ont réussi à infecter un processus, ils doivent utiliser les API de Windows pour atteindre leur objectif ultime de lire des données utilisateur ou d'établir une présence permanente en modifiant les paramètres utilisateur ou de configuration du système.
La connexion d'une application aux points d'entrée API exportés par les DLL est généralement gérée par le chargeur du système d'exploitation, mais ces types d'infections générés par des logiciels malveillants ne peuvent pas tirer parti des services du chargeur. Dans les versions précédentes de Windows, ceci ne constituait pas un problème pour les logiciels malveillants, car pour chaque version de Windows, les images et les DLL exécutables du système se chargent toujours au même emplacement, permettant aux logiciels malveillants de supposer que les API résident à des adresses fixes.
La fonctionnalité de randomisation du chargement de l'espace d'adressage (ASLR) ne permet pas aux logiciels malveillants de savoir où sont situés les API, car elle charge les DLL et les exécutables du système à un endroit différent à chaque démarrage du système. Tôt dans le processus de démarrage, le Gestionnaire de mémoire choisit un biais aléatoire de chargement d'images DLL dans l'une des 256 adresses alignées de 64 Ko de la zone de 16 Mo située au-dessus de l'espace d'adressage du mode utilisateur. Lorsque les DLL disposant du nouvel indicateur de relocalisation dynamique dans leur en-tête d'image se chargent dans un processus donné, le Gestionnaire de mémoire les regroupe dans la mémoire, en commençant par l'adresse du biais de chargement des images.
Les exécutables dont l'indicateur est défini reçoivent un traitement similaire et se chargent à un endroit aléatoire aligné de 64 Ko dans les 16 Mo de l'adresse de chargement de base stockée dans leur en-tête d'image. De plus, si un DLL ou un exécutable donné se charge encore après avoir été déchargé par tous les processus l'utilisant, le Gestionnaire de mémoire sélectionne à nouveau un emplacement aléatoire où il peut le charger. La figure 7 montre un exemple de disposition de l'espace d'adressage pour un système Windows Vista 32 bits, y compris les zones à partir desquelles l'ASLR choisit le biais de chargement de l'image et l'adresse de chargement de l'exécutable.
Figure 7 Impact de l'ASLR sur les adresses de chargement des exécutables et des DLL
Figure 7 Impact de l'ASLR sur les adresses de chargement des exécutables et des DLL (Cliquer sur l'image pour la réduire)
Figure 7 Impact de l'ASLR sur les adresses de chargement des exécutables et des DLL
Figure 7 Impact de l'ASLR sur les adresses de chargement des exécutables et des DLL (Cliquer sur l'image pour l'agrandir)
Seules les images disposant de l'indicateur de relocalisation dynamique, ce qui inclut toutes les DLL et tous les exécutables de Windows Vista, sont relocalisées, car les images en mouvement héritées pourraient briser les suppositions internes que les développeurs ont faites concernant l'endroit de chargement de leurs images. Visual Studio® 2005 SP1 prend également en charge le paramétrage de l'indicateur pour que les développeurs tiers puissent tirer entièrement parti de l'ASLR.
La randomisation des adresses de chargement des DLL vers l'un des 256 emplacements n'empêche pas les logiciels malveillants de deviner l'emplacement correct d'une API, mais elle entrave sévèrement la vitesse à laquelle un vers de réseau peut se propager et empêche les logiciels malveillants, qui peuvent infecter le système une seule fois, de fonctionner de façon efficace. De plus, la stratégie de relocalisation de l'ASLR permet également de regrouper de façon plus serrée les espaces d'adressage par rapport aux versions précédentes de Windows, créant de plus grandes zones de mémoire libre pour les allocations de mémoire contiguës, réduisant le nombre de tableaux de page que le Gestionnaire de mémoire attribue pour suivre la disposition des espaces d'adressage et diminuant les ratés du TLB (Translation Lookaside Buffer).

Améliorations de la sécurité des services
Les services Windows sont des cibles idéales pour les logiciels malveillants. Beaucoup proposent un accès réseau à leur fonctionnalité, exposant potentiellement l'accès à un système exploitable à distance ; la plupart s'exécutent avec plus de privilèges que les comptes utilisateur standards, rendant possible l'élévation des privilèges sur un système local dans le cas où les logiciels malveillants parviennent à corrompre ces derniers. C'est pour cela que Windows a commencé à évoluer avec les modifications apportées à Windows XP SP2, lesquelles ont réduit les privilèges et l'accès attribués aux services à juste ceux nécessaires à leurs rôles. Par exemple, Windows XP SP2 a introduit les comptes Service local et Service réseau, incluant seulement un sous-ensemble des privilèges disponibles au compte dans lequel les services s'exécutaient auparavant toujours, c'est-à-dire le système local. Ceci minimise l'accès obtenu par un pirate lorsqu'il exploite un service.
Voir l'ASLR en action
Vous pouvez facilement voir les effets de l'ASLR en comparant les adresses de chargement des DLL pour un processus donné dans deux sessions de démarrage différentes en utilisant un outil comme Process Explorer de Sysinternals. Dans ces deux captures d'écran, prises de deux sessions différentes, Ntdll.dll s'est d'abord chargé dans Explorer à l'adresse 0x77A30000, puis à 0x77750000.
Différentes adresses de base de ntdll.dll
Différentes adresses de base de ntdll.dll (Cliquer sur l'image pour la réduire)
Différentes adresses de base de ntdll.dll
Différentes adresses de base de ntdll.dll (Cliquer sur l'image pour l'agrandir)
Différentes adresses de base de ntdll.dll
Différentes adresses de base de ntdll.dll (Cliquer sur l'image pour la réduire)
Différentes adresses de base de ntdll.dll
Différentes adresses de base de ntdll.dll (Cliquer sur l'image pour l'agrandir)

Dans mon article précédent, j'ai décrit comment les services s'exécutent de façon isolée par rapport aux comptes utilisateur dans leur propre session, mais Windows Vista développe également leur utilisation du principe de moindre privilège, en réduisant encore plus les privilèges et l'accès aux fichiers, aux clés de registre et aux ports de pare-feu qu'il attribue à la plupart des services. Windows Vista définit un nouveau compte de groupe, appelé Identifiant de sécurité de service (SID), unique à chaque service. Le service peut déterminer des autorisations sur ses ressources pour que seul son SID de service dispose d'un accès, empêchant les autres services s'exécutant dans le même compte utilisateur d'avoir un accès si un service devient corrompu. Vous pouvez voir le SID d'un service en utilisant la commande sc showsid, suivie par le nom du service, tel que le montre la figure 8.
Figure 8 Visualisation du SID d'un service
Figure 8 Visualisation du SID d'un service (Cliquer sur l'image pour la réduire)
Figure 8 Visualisation du SID d'un service
Figure 8 Visualisation du SID d'un service (Cliquer sur l'image pour l'agrandir)
Les SID de service protègent l'accès aux ressources possédées par un service donné, mais par défaut, les services ont toujours accès à tous les objets que peut atteindre le compte utilisateur dans lequel ils sont exécutés. Par exemple, un service s'exécutant dans le compte de Service local peut ne pas avoir accès à des ressources créées par un autre service s'exécutant en tant que Service local dans un processus différent ayant protégé ses objets avec des autorisations faisant référence à un SID de service. Cependant, il peut toujours lire et écrire les objets pour lesquels le Service Local (et tous les groupes auxquels appartient le Service local, comme le groupe de Service) a des autorisations.
Windows Vista introduit donc un nouveau type de service limité, appelé service limité à l'écriture, qui donne à un service des droits d'écriture uniquement pour les objets accessibles à son SID de service, au groupe Tout le monde et au SID attribué à l'ouverture de session. Pour ce faire, il utilise des SID limités, un type de SID introduit dans Windows 2000. Lorsque le processus ouvrant un objet est un service limité à l'écriture, l'algorithme de vérification des accès se modifie pour qu'un SID n'ayant pas été attribué à un processus à la fois sous forme limitée et illimitée ne puisse pas être utilisé pour accorder au processus un accès d'écriture à un objet donné. Vous pouvez voir si un service est limité avec la commande suivante :
sc qsidtype [service]
Une autre modification facilite l'interdiction à d'autres services s'exécutant dans le même compte d'avoir accès aux objets créés. Dans les versions précédentes de Windows, le créateur d'un objet est également le propriétaire de cet objet, et les propriétaires peuvent lire et modifier les autorisations de leurs objets, leur donnant un accès complet à leurs propres objets. Windows Vista introduit le nouvel SID Droits du propriétaire qui, s'il est présent dans les autorisations d'un objet, peut limiter les accès détenus par un propriétaire à son propre objet, ce qui supprime même le droit de configurer et d'interroger les autorisations.
Une autre amélioration au modèle de sécurité de service de Windows Vista active un développeur de service pour spécifier exactement de quels privilèges de sécurité le service a besoin pour fonctionner lorsque le service s'enregistre sur un système. Par exemple, si le service a besoin de produire des événements d'audit il pourrait lister le privilège Audit.
Lorsque le Gestionnaire de contrôle de service démarre un processus qui héberge un ou plusieurs services Windows, il crée un jeton de sécurité (l'objet de noyau qui liste un compte utilisateur de processus, les appartenances au groupe et les privilèges de sécurité) pour le processus qui inclut seulement les privilèges requis par les services dans le processus. Si un service spécifie un privilège qui n'est pas disponible pour le compte dans lequel il s'exécute, alors le service ne démarre pas. Lorsqu'aucun des services s'exécutant dans un processus de compte de Service local n'a besoin du privilège Déboguer les programmes, par exemple, le Gestionnaire de contrôle de service élimine ce privilège du jeton de sécurité du processus. Ainsi, si le processus du service est corrompu, le code malveillant ne peut pas profiter des privilèges qui n'étaient pas été explicitement demandés par les services s'exécutant dans le processus. La commande sc qprivs signale les privilèges qu'un service a demandés.

Conclusion
Ceci conclut mon analyse en trois parties des modifications du noyau de Windows Vista. Je n'ai pas couvert ou mentionné toutes les fonctionnalités et améliorations, telles que le nouveau regroupement de fils pour les développeurs d'applications, les nouveaux mécanismes de synchronisation comme les verrouillages partagés lecteur/rédacteur, l'étiquetage des fils de services, la prise en charge de la vérification du disque NTFS et le redimensionnement des volumes en ligne, ainsi que le nouveau mécanisme IPC du noyau appelé ALPC (Advanced Local Procedure Call). Recherchez plus d'informations sur ces sujets et autres fonctionnalités dans la prochaine édition de Windows Internals, dont la publication est prévue pour la fin 2007.
Visualisation du service limité à l'écriture
Seul un processus d'hébergement de services dans Windows Vista héberge des services limités. Vous pouvez l'identifier grâce à un outil de visualisation des processus tels que Process Explorer comme celui qui a la ligne de commande :
svchost -k LocalServiceNoNetwork
Les services configurés pour s'exécuter dans ce processus incluent le moteur de filtrage de base, le service de stratégie des diagnostics, le pare-feu Windows, les journaux et alertes de performances et le Windows Media® Center Service Starter.
Cet écran montre la forme textuelle du SID de service du moteur de filtrage de base, NT SERVICE\BFE, listé une fois avec l'indicateur Limité, puis une autre fois sans lui, pour que le processus accède aux ressources accessibles à ce compte. Cependant, il n'a pas nécessairement accès aux autres objets normalement accessibles au compte de Service local. Par exemple, puisque le compte NT AUTHORITY\SERVICE n'apparaît pas dans le jeton de processus avec l'indicateur limité, ce processus peut modifier les objets qui accordent un accès d'écriture unique à ce compte, mais pas aux autres comptes du jeton qui ont un indicateur limité.
Les services s'exécutant dans ce processus limitent également leurs privilèges, parce que les privilèges listés au bas de la boîte de dialogue de propriétés constituent un sous-ensemble de ceux disponibles au compte de Service local.
Indicateurs SID sur un service
Indicateurs SID sur un service (Cliquer sur l'image pour la réduire)
Indicateurs SID sur un service
Indicateurs SID sur un service (Cliquer sur l'image pour l'agrandir)

Mark Russinovich est technicien dans le service responsable des plates-formes et services chez Microsoft. Il est coauteur de Microsoft Windows Internals (Microsoft Press, 2004) et intervient fréquemment lors de conférences informatiques et pour les développeurs, y compris Microsoft Tech•Ed et le symposium PDC. Il a rejoint nos équipes lorsque Microsoft a racheté Winternals Software, la société dont il était le cofondateur. Il a également créé Sysinternals, où il a publié de nombreux utilitaires populaires, notamment 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: R&#233;cup&#233;ration apr&#232;s incident&#160;: utilisateurs et groupes Active Directory
Administration de Windows Gil Kirkpatrick

Récupération après incident : utilisateurs et groupes Active Directory
Vue d'ensemble:
  • Mécanismes de réplication et liaison d'objets
  • Utilisation de NTDSUTIL pour sauvegarder et restaurer
  • Restaurations faisant autorité et ne faisant pas autorité

Active Directory est l'un des services les plus importants dans un réseau Windows. Pour éviter les pannes et la perte de productivité, il est essentiel d'avoir un plan de récupération après incident pour les problèmes apparentés à Active Directory. Cela peut paraître évident, mais
vous seriez surpris d'apprendre le nombre d'administrateurs qui n'ont pas de plan pour l'une des raisons les plus fréquentes qui provoquent la défaillance d'Active Directory® : la suppression accidentelle de données.
La suppression accidentelle d'objets est l'une des causes de défaillance de service les plus communes. Lorsque j'anime des séminaires et des conférences, je demande souvent qui a été victime d'une défaillance d'Active Directory provoquée par une suppression accidentelle de données. Et à chaque fois, presque tout le monde lève la main.
Pour comprendre pourquoi que la récupération de données est si complexe, vous devez d'abord comprendre : comment Active Directory enregistre et copie des objets, comment il supprime des objets, et les mécanismes de restaurations autorisés et non autorisés.

Enregistrement d'objets
Active Directory est une base de données d'objets spécialisée qui implémente le modèle de données X.500/LDAP. La banque de données (appelée arborescence d'information d'annuaire ou DIT) est basée sur le moteur de stockage extensible (Extensible Storage Engine, ESE), un moteur de base de données à méthode d'accès séquentielle indexée (ISAM). Active Directory enregistre la DIT dans deux tableaux : le tableau des données (qui contient les véritables objets et attributs d'Active Directory), et le tableau des liens (qui contient les relations entre les objets).
Chaque objet Active Directory est enregistré dans une ligne séparée au sein du tableau des données, avec une colonne par attribut. Le tableau des données contient toutes les entrées pour toutes les répliques enregistrées dans le contrôleur de domaine (Domain Controller, DC). Dans un DC normal, le tableau des données contient le contexte d'attribution (Naming Context, NC) du domaine, le NC de la configuration, et le NC du schéma. Sur un catalogue global, le tableau des données contient des entrées pour chaque objet de la forêt.
Active Directory utilise la balise DNT (Distinguished Name Tag), un nombre entier de 32 bits, pour identifier de façon unique chaque ligne du tableau des données. La DNT, utilisée pour se référer aux objets en interne, est beaucoup plus petite que d'autres identificateurs tels que le nom unique (DN) ou et le GUID d'objet (une structure binaire de 16 octets). Mais contrairement au GUID d'objet, la DNT est un identificateur local, et est différente sur chaque DC.

Comment Active Directory lie les objets
Active Directory gère deux genres de relations entre les objets dans la DIT : la relation parent-enfant (également appelée relation de conteneur) et la relation de référence (également appelée relation de lien). Pour implémenter la relation parent-enfant, Active Directory enregistre une colonne supplémentaire dans le tableau des données appelé PDNT (Parent Distinguished Name Tag). Cette colonne contient toujours la DNT du parent de l'objet.
Chaque attribut Active Directory est défini par un objet attributeSchema dans le conteneur Schéma Active Directory. Certains attributs Active Directory sont définis comme des attributs de lien, tels qu'ils sont déterminés par une valeur paire différente de zéro dans l'attribut linkID de l'objet attributeSchema. Les attributs de lien établissent une relation entre les objets dans l'annuaire et peuvent posséder une seule ou plusieurs valeurs. L'attribut du membre d'un objet groupe constitue un exemple d'attribut de lien à plusieurs valeurs : il établit un lien entre l'objet de groupe et ses objets membres.
Même s'il semble que l'attribut de membre d'un groupe contient le DN des membres (comme affiché par le composant logiciel enfichable d'Active Directory Users and Computers, par exemple), ce n'est pas ainsi qu'Active Directory les enregistre. Lorsque vous ajoutez le DN d'un objet membre à un attribut de membre du groupe, Active Directory enregistre la DNT de l'objet, et non pas son DN. Puisque la DNT n'est pas modifiée, même lorsqu'un objet est renommé, vous pouvez renommer un objet utilisateur sans qu'Active Directory n'ait à trier tous les groupes dans le système pour mettre à jour chacun des attributs membres. C'est comme cela qu'Active Directory maintient l'intégrité référentielle dans la DIT. La figure 1 illustre une représentation, très simplifiée, de la façon dont le tableau des données et le tableau des liens sont liés entre eux. Ces tableaux indiquent que les trois objets utilisateur, Molly Clark, Alexander Tumanov et Makoto Yamagishi, sont tous membres du groupe Senior Engineers.
Figure 1 Comment les tableaux des données et des liens sont liés (Close Figure 1)

Tableau des données |  |  |
DNT | PDNT | Classe d'objet | Cn
14529 | 14401 | organizationalUnit | Ingénieurs
14530 | 14529 | Groupe | Ingénieurs seniors
14531 | 14529 | Utilisateur | Molly Clark
14532 | 14529 | Utilisateur | Alexander Tumanov
14533 | 14529 | Utilisateur | Makoto Yamagishi
Tableau des liens |  |  |
Attribut | DNT | Lien suivant |
Membre | 14530 | 14531 |
Membre | 14530 | 14532 |
Membre | 14530 | 14533 |
Ces liens sont appelés liens « suivant ». De même, Active Directory fournit également des attributs de liens précédents. Ceux-ci fournissent une référence de l'objet vers lequel pointe un autre objet, celui qui possède le lien suivant. L'attribut memberOf pour les utilisateurs et les groupes est un exemple d'attribut de lien ascendant. L'objet attributeSchema qui décrit un attribut de lien ascendant possède une valeur linkID qui est supérieure à la valeur linkID à nombre paire de l'attribut du lien suivant qui lui correspond. Par exemple, l'attribut de membre dans le schéma de Windows Server® 2003 R2 possède une valeur linkID égale à 2 ; l'attribut memberOf qui sert de lien ascendant possède une valeur linkID égale à 3. La figure 2 fournit une liste des attributs liés définis par défaut dans le schéma de Windows Server 2003 R2.
Figure 2 Schéma des attributs de lien dans Windows Server 2003 R2 (Close Figure 2)

Forward Link Attribute | linkID | Back Link Attribute | Linked
member | 2 | memberOf | 3
manager | 42 | directReports | 43
owner | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Les attributs lien ascendants possèdent toujours plusieurs valeurs, et ils sont gérés automatiquement par Active Directory. En fait, il est impossible de modifier directement un attribut de lien ascendant. Même s'il semble possible de modifier l'attribut memberOf d'un utilisateur ou d'un groupe grâce au composant logiciel enfichable MMC Active Directory Users and Computers, ce dernier modifie en fait l'attribut de membre du groupe correspondant, et Active Directory met à jour l'attribut de memberOf de façon transparente. C'est pourquoi vous n'avez pas besoin d'autorisations sur l'objet utilisateur pour ajouter l'utilisateur à un groupe, car la seule chose que vous modifiez vraiment, c'est l'attribut de membre de l'objet de groupe. Puisque chaque DC gère ses attributs de lien ascendant de façon locale, les modifications des liens ascendants ne sont jamais répliquées. Seule la modification de l'attribut du lien suivant, comme l'attribut de membre d'un groupe, est répliquée.
Dans un DC normal, le tableau des données contient des entrées pour les objets domaine, ainsi que des objets provenant des conteneurs Configuration et Schéma. Mais certains types de groupe peuvent contenir des références aux objets qui résident dans un autre domaine. Comment Active Directory enregistre-t-il une DNT pour un objet qui n'est pas dans son tableau de données ? La réponse réside dans le propriétaire du rôle des opérations à maître unique flottant (FSMO) du maître d'infrastructure et d'un objet appelé objet fantôme.

Les objets fantômes
Lorsque vous ajoutez un membre d'un domaine à un groupe appartenant à un autre domaine, Active Directory crée automatiquement un objet spécial dans le tableau des données appelé un fantôme, qui contient l'objectGUID, l'objectSid et le DN du nouveau membre. Cela fournit une DNT que peut être enregistrée dans l'attribut de membre du groupe. Si un contrôleur de domaine est un catalogue global, il n'aura pas besoin de créer un fantôme, parce qu'il a déjà une entrée dans son tableau des données pour chaque objet de la forêt.
Le DC qui contient le rôle FSMO de l'infrastructure vérifie périodiquement les entrées dans son tableau des données et les compare à celles du catalogue global. Lorsqu'il découvre qu'un objet a été déplacé, renommé ou supprimé, il met à jour les fantômes dans le tableau des données et réplique la modification aux autres DC du domaine. Et grâce à un compte de référence, le maître d'infrastructure peut également supprimer des fantômes auxquels aucun attribut de lien suivant du domaine ne fait plus référence.
Les fantômes autorisent les DC à gérer des références aux objets d'autres domaines de la forêt, mais les attributs lien suivant peuvent aussi faire référence aux objets qui sont hors de la forêt : par exemple, dans un domaine de confiance. Dans ce cas, Active Directory crée un objet appelé Sécurité extérieure principale (Foreign Security Principal, FSP) dans le conteneur CN=ForeignSecurityPrincipals du NC du domaine. La FSP contient l'Identificateur de sécurité de l'objet étranger (le SID) et les autres attributs qui identifient l'objet dans le domaine étranger, mais il n'y a pas de processus pour s'assurer que le FSP est maintenu à jour. Dans l'objectif de récupération de données, nous traitons les FSP comme n'importe quel autre objet d'Active Directory.

Suppression d'objets
Ici, je m'intéresse en priorité à la restauration d'utilisateurs et de leurs appartenances aux groupes. Cependant, les mêmes principes s'appliquent à la récupération d'autres attributs liés.
Lorsqu’Active Directory supprime un objet, il ne supprime pas physiquement l'objet de la DIT. Il se contente en fait de paramétrer son attribut Deleted sur vrai, ce qui le rend invisible aux opérations d'annuaire normales. Active Directory supprime tous les attributs qui ne sont pas destinés à être enregistrés, tels qu'ils sont définis par le schéma, et modifie le nom distingué relatif (Relative Distinguished Name, RDN) de l'objet en <ancien RDN>\0aDEL:<objectGUID>. Il transfère ensuite l'objet vers le conteneur CN=Deleted Objects pour le NC. (Il existe certaines classes d'objets dans le NC de Configuration qu'Active Directory ne transfère pas au conteneur d'Objets Supprimés). Active Directory supprime tous les liens « suivant » vers d'autres objets que détient l'objet supprimé, ce qui réduit leur compte de référence dans le tableau de lien. S'il existe d'autres objets qui contiennent des liens suivant vers l'objet désormais supprimé, Active Directory supprime également ces liens.
L'objet résultant est appelé une pierre tombale (« tombstone »). Active Directory copie cette pierre tombale sur les autres DC, où les mêmes modifications sont effectuées. Notez qu'Active Directory ne réplique pas les modifications effectuées vers les liens suivant qui font référence à l'objet supprimé. Chaque DC effectue la modification équivalente localement : il n'y a donc pas de besoin de la répliquer. Cela a des conséquences sur la récupération d'appartenances aux groupes, comme nous verrons plus tard dans cet article.
Active Directory maintient les objets supprimés dans la DIT, ainsi qu'il est défini par l'attribut tombstoneLifetime de l'objet CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domaine racine>. Le processus de nettoyage de la mémoire sur chaque DC supprime les pierres tombales qui sont plus vieilles que la durée de vie configurée de la pierre tombale. Par défaut, la vie de la pierre tombale est de 60 jours pour Windows® 2000, Windows Server 2003 et Windows Server 2003 R2. Elle est de 180 jours sous Windows Server 2003 SP1.
La durée de vie de la pierre tombale a beaucoup d'importance pour le processus de restauration. Il est impossible de restaurer à partir d'une sauvegarde qui est plus vieille que la durée de vie de la pierre tombale. Puisque les objets qui ont été supprimés et nettoyés de la mémoire du domaine n'ont plus de pierre tombale, l'opération de suppression ne répliquera jamais de nouveau vers le DC restauré. Les objets supprimés resteront ensuite sur le DC restauré comme des objets sans but, et le DC restauré ne convergera jamais convenablement avec les autres DC à l'intérieur du domaine.

Réplication d'objets
Quand un contrôleur de domaine exécute une opération de mise à jour de n'importe quel genre, comme par exemple l'ajout d'un objet ou la modification d'un attribut, il attribue un nombre de 64 bits à l'opération de mise à jour appelée Numéro de séquence de mise à jour (USN). Active Directory étiquette les objets et les attributs qui sont mis à jour avec leur USN, pour aider à déterminer s'ils doivent être répliqués.
Active Directory réplique les objets attribut par attribut. C'est-à-dire que si vous modifiez l'un des attributs d'un objet, Active Directory copiera uniquement cet attribut, et non pas l'objet entier. Pour ce faire, Active Directory conserve une trace des modifications qu'il effectue à chaque attribut grâce à des métadonnées de réplication. Les métadonnées de réplication d'un attribut incluent :
  • L'USN local, qui identifie l'opération de modification sur le DC local.
  • L'invocationID du DC qui a provoqué la modification (en particulier, l'attribut invocationID de l'objet nTDSSettings du DC correspond), qui identifie une génération particulière de la DIT sur un contrôleur de domaine.
  • L'USN de l'opération originale, telle qu'il existe sur le DC qui a provoqué la modification.
  • Un horodatage qui contient l'heure système du DC à laquelle le changement a été effectué.
  • Un numéro de version séquentiel de 32 bits qui est incrémenté chaque fois que la valeur est modifiée.
Lorsqu'un DC de destination demande des modifications par l'intermédiaire de son partenaire DC de source, il envoie l'USN de la dernière modification de réplication réussie au DC source, avec un vecteur de mise à jour qui inclut le plus grand USN d'origine que le DC de destination ait vu de chaque DC qui possède une réplique du NC en cours de réplication. Le DC source utilise ces informations pour envoyer uniquement les mises à jour que le DC de destination n'a pas encore vues.
Pendant que le DC de destination traite les mises à jour d'attribut entrantes, il vérifie le numéro de version de chaque attribut. Si le numéro de version d'un attribut entrant est plus grand que la version que le DC possède déjà pour cet attribut, le DC enregistre la valeur entrante. Si le numéro entrant de version est égal à la version que le DC possède déjà, le DC compare les horodateurs et utilise l'attribut possédant l'horodateur le plus récent. Si les horodateurs sont identiques, le DC de destination choisit la valeur avec le plus grand invocationID. Ce système garantit que chaque DC choisira finalement la même valeur pour chaque attribut répliqué.

Réplication de valeurs liées
Sous Windows 2000, Active Directory répliquait les attributs à valeurs multiples de la même manière que les attributs à valeur unique. Cela provoquait des problèmes pour les grands objets de groupe dynamique, dont l'attribut de membre à valeur multiple pouvait changer fréquemment sur différents DC. Si un administrateur ajoutait un utilisateur à un groupe sur un DC, et qu'un autre administrateur ajoutait un utilisateur différent au groupe sur un autre DC dans la fenêtre de latence de réplication, Active Directory choisissait le dernier ajout et perdait le premier. Microsoft a traité ce problème dans Windows Server 2003 avec un processus appelé réplication de valeurs liées (LVR).
Sous Windows Server 2003, au niveau fonctionnel de la forêt ou au niveau fonctionnel de la forêt provisoire, Active Directory copie séparément les valeurs individuelles des attributs de lien suivant, et chaque valeur possède ses propres métadonnées de réplication. Cela résout efficacement le problème rencontré sous Windows 2000, où des mises à jour presque simultanées d'appartenance au groupe sur différents DC pouvaient provoquer des pertes de données.
Il existe cependant un point dont il faut être conscient. Le fait d'augmenter le niveau fonctionnel de la forêt ne corrige pas automatiquement les attributs de lien à valeurs multiples avec les nouvelles métadonnées de réplication. Seules les valeurs qui sont ajoutées après l'augmentation du niveau fonctionnel de la forêt recevront les nouvelles métadonnées. Cela aura un effet significatif sur la récupération d'appartenances aux groupes, comme vous verrez dans un moment.

Sauvegarde
Windows fournit l'utilitaire très basique NT-BACK-UP qui peut être utilisé pour effectuer une sauvegarde de l'état du système d'un DC. L'état du système d'un contrôleur de domaine inclut son registre, SYSVOL, les fichiers de la DIT d'Active Directory ainsi que les fichiers système critiques. La plupart des utilitaires de sauvegarde tiers ont également la capacité de sauvegarder et de restaurer l'état du système d'un DC.
Pour exécuter une sauvegarde d'état du système sur un fichier de disque, utilisez la commande suivante :
NTBACKUP backup systemstate /F “<filename>”
Ici, <filename> est le nom du fichier de sauvegarde devant être créé, et devrait utiliser l'extension .bkf.

Exécution d'une restauration ne faisant pas autorité
La restauration d'objets Active Directory supprimés à partir d'une sauvegarde est un processus de deux étapes. Premièrement, vous redémarrez le DC en mode restauration du service d'annuaire (DSRM), puis vous restaurez l'intégralité de la DIT d'Active Directory à partir de la sauvegarde d'état du système, en utilisant l'utilitaire NTBACKUP de Windows ou un produit tiers équivalent. Ce processus remplacera toute la DIT.
Il y existe deux façons de démarrer un DC en DSRM. Si vous avez accès à la console de système du DC, arrêtez et redémarrez le DC puis appuyez sur F8 à l'invite pour appeler le menu de démarrage de Windows. Sélectionnez Restauration du service d'annuaire dans le menu et entrez le mot de passe du DSRM.
Si vous gérez le serveur à distance, vous ne pourrez pas accéder au menu de démarrage de Windows. À la place, vous pouvez modifier les options de démarrage du système en sélectionnant Propriétés à partir du Poste de Travail, puis en cliquant sur l'onglet Avancé, avant d'appuyer sur le bouton Paramètres situé sous Démarrage et Récupération. Cliquez sur Modifier dans la section Démarrage du système pour modifier le fichier boot.ini, et ajoutez le commutateur /SAFEBOOT:DSREPAIR à la fin de la ligne, comme illustré à la figure 3. (Pour plus d'informations sur les commutateurs de boot.ini, voir microsoft.com/technet/sysinternals/information/bootini.mspx.)
Figure 3 Configuration des options de démarrage pour DSRM
Figure 3 Configuration des options de démarrage pour DSRM (Cliquer sur l'image pour la réduire)
Figure 3 Configuration des options de démarrage pour DSRM
Figure 3 Configuration des options de démarrage pour DSRM (Cliquer sur l'image pour l'agrandir)
Lorsque vous redémarrez le serveur, il s'allumera en DSRM. N'oubliez pas de supprimer le commutateur /SAFEBOOT de boot.ini lorsque vous voulez redémarrer le DC en mode normal.
Une fois connecté à l'aide du mot de passe du DSRM, restaurez la sauvegarde d'état du système en utilisant une nouvelle fois la commande NTBACKUP, mais sans spécifier de paramètre. (Vous ne pouvez pas exécuter une restauration en utilisant NTBACKUP à partir de la ligne de commande). Lorsque l'assistant s'ouvre, sélectionnez Restaurer les fichiers et paramètres, puis cliquez sur Suivant. Sélectionnez ensuite le fichier de sauvegarde et cochez la boîte de dialogue État du système comme indiqué à la figure 4.
Figure 4 Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système
Figure 4 Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système (Cliquer sur l'image pour la réduire)
Figure 4 Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système
Figure 4 Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système (Cliquer sur l'image pour l'agrandir)
Si vous redémarriez le DC en mode normal à ce stade, le processus de réplication d'Active Directory synchroniserait le contrôleur de domaine avec les autres DC du domaine, et toutes les données restaurées seraient remplacées par les données actuelles. Ce n'est pas votre objectif, bien sûr. Vous avez besoin, par contre, d'un moyen de forcer les objets en cours de restauration à se répliquer indépendamment des autres contrôleurs de domaine du domaine.

Exécution d'une restauration faisant autorité
NTDSUTIL augmente également le numéro de version de chaque attribut de 100 000 pour chaque jour entre la date de la sauvegarde et la date de la restauration. À moins qu'il existe des attributs qui sont mis à jour plus de 100 000 fois un jour (scénario assez peu probable), le numéro de version des attributs restaurés sera beaucoup plus grand que celui de la version détenue par d'autres DC, et l'objet restauré d'une manière faisant autorité se répliquera vers les autres DC. Les autres objets qui ont été restaurés d'une façon ne faisant pas autorité à partir de la sauvegarde seront remplacés pour finir par les données existantes sur les autres contrôleurs de domaine.
Après avoir terminé la restauration ne faisant pas autorité, mais avant de redémarrer en mode normal, vous devez utiliser le programme NTDSUTIL pour exécuter une restauration faisant autorité des objets que vous voulez récupérer. Malgré son nom, la restauration faisant autorité d'un objet ne « restaure » pas ce dernier ; elle s'assure simplement qu'Active Directory répliquera l'objet sur les autres DC. Pour ce faire, NTDSUTIL attribue l'USN suivant disponible à l'USN local des attributs de l'objet. L'objet sera ainsi envoyé aux partenaires de réplication la prochaine fois qu'ils se synchroniseront. Pour restaurer un objet, assurez-vous que le DC est lancé en DSRM, et procédez comme suit :
  1. Ouvrez une invite de commande et tapez :
    ntdsutil
  2. Dans l'invite ntdsutil, tapez :
    authoritative restore
  3. À l'invite de restauration faisant autorité, saisissez :
    restore object “<DN of object to be restored>”
    Par exemple, si vous voulez restaurer le compte de Molly Clark à partir de l'OU Eng du domaine DRNET, tapez :
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Si vous voulez effectuer une restauration faisant autorité d'un sous-arbre d'annuaire entier, par exemple une UO, saisissez plutôt ceci :
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    (NTDSUTIL fournit également une commande de base de données de restauration qui effectue une restauration faisant autorité du domaine entier, ainsi que des NC de configuration et de schéma. La restauration du domaine entier est une opération périlleuse, et c'est une option que je ne recommande pas. Si vous avez besoin de restaurer un domaine entier, vous devez restaurer un contrôleur de domaine et promouvoir de nouveau les autres DC du domaine comme décrit dans « Planification d'une récupération de forêt d'Active Directory »,
  4. À l'invite, confirmez que la restauration faisant autorité doit augmenter les numéros de version des objets et de leurs attributs respectifs.
  5. Quittez ntdsutil (vous devrez taper « quit » deux fois).
  6. Redémarrer le DC en mode normal d'Active Directory normal.
La prochaine fois le DC se réplique avec ses partenaires, l'utilisateur que vous avez restauré se répliquera vers l'extérieur. Mais la restauration de l'objet utilisateur ne constitue que la moitié du problème. Lorsque vous introduisez des liens d'objet comme ceux-là entre un groupe et ses membres, la situation devient plus compliquée. Il y a quelques problèmes fondamentaux auxquels vous risquez d'être confronté pendant et après la restauration, et que je vais essayer de décrire.
Tout d'abord, revoyons ce qui se produit lorsque vous supprimez un objet comportant des liens ascendants. Disons que vous supprimez un objet utilisateur qui est membre d'un ou de plusieurs groupes. Chaque contrôleur de domaine disposant d'une copie de l'objet utilisateur le convertit en pierre tombale et supprime toutes les références du tableau des liens, supprimant ainsi l'objet utilisateur des appartenances aux groupes dans le domaine de l'utilisateur. (Rappelez-vous que la suppression d'un utilisateur des appartenances aux groupes n'est pas une modification répliquée, puisque chaque DC met à jour l'appartenance au groupe de façon locale. Le numéro de version et l'USN local de l'attribut du membre du groupe restent inchangés). Un peu plus tard, les objets fantômes seront supprimés des tableaux des liens dans les autres domaines, mais toujours sans mettre à jour les métadonnées de réplication de l'attribut de membre du groupe.
Lorsque vous effectuez une restauration ne faisant pas autorité sur la DIT sur un contrôleur de domaine dans le domaine de l'utilisateur, vous récupérez l'objet utilisateur avec toutes les appartenances aux groupes dans le domaine, de sorte que le DC restauré soit cohérent. Et après avoir utilisé l'utilitaire NTDSUTIL pour exécuter une restauration faisant autorité de l'utilisateur, l'objet utilisateur se réplique vers tous les autres DC dans le domaine.
Mais puisque les métadonnées de réplication des groupes actuels dans le domaine sont inchangées, les attributs de membre des groupes sur le DC restauré sont en contradiction avec ceux qui sont présents sur les autres DC. Et il n'y a rien à faire pour les faire converger vers un état commun. Ainsi, les appartenances de l'utilisateur ne seront pas restaurées sur les autres DC dans le domaine.

Problème : les appartenances aux groupes dans le domaine ne sont pas restaurées
La restauration faisant autorité de l'objet utilisateur ne récupère pas les appartenances aux groupes de l'utilisateur. Pourquoi ? Parce que la relation d'appartenance est enregistrée et répliquée en utilisant l'attribut de membre des objets de groupe (les liens suivant), et non l'attribut memberOf de l'utilisateur (le lien ascendant). Le problème consiste à retrouver les anciennes appartenances aux groupes de l'utilisateur et, une fois que c'est fait, de les récupérer convenablement.
Microsoft a apporté beaucoup d'améliorations au processus de récupération des appartenances aux groupes de l'utilisateur, donc la technique que vous utilisez dépend de la version d'Active Directory que vous vous possédez. La section suivante s'applique principalement à Active Directory de Windows 2000.
Déterminer les anciennes appartenances aux groupes de l'utilisateur est assez simple : Inspectez simplement l'attribut de lien ascendant sur le DC restauré. Dans notre cas, il s'agit de l'attribut memberOf de l'objet utilisateur. L'attribut memberOf contiendra toutes les appartenances aux groupes locaux et globaux dans le domaine de l'utilisateur. Vous pouvez utiliser le composant logiciel enfichable MMC Active Directory Users and Computers (ADUC), ou l'utilitaire LDIFDE, qui est livré avec Windows Server, pour lister les appartenances aux groupes de l'utilisateur restaurés.
La ligne de commande LDIFDE suivante listera les groupes dans le domaine DRNET dont Molly Clark est membre et enregistrera les résultats dans le fichier output.ldf :
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Noter que vous devez démarrer le DC en mode normal pour utiliser un outil LDAP et vous devez à nouveau désactiver la réplication entrante ; autrement les données que vous avez restaurées seraient remplacées. Pour désactiver la réplication entrante, le plus simple est d'utiliser la commande REPADMIN :
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Ici, <dcname> est le nom du DC vers lequel vous restaurez. N'oubliez pas de réactiver la réplication en utilisant –DISABLE_INBOUND_REPL lorsque vous avez terminé.
Si vous récupérez seulement quelques utilisateurs, il est assez facile de réintégrer manuellement quelques utilisateurs aux groupes à l'aide de l'ADUC. Si vous récupérez plus d'utilisateurs que cela, il existe des outils qui peuvent automatiser une partie du processus. L'utilitaire GROUPADD de Microsoft (disponible auprès des services de support technique Microsoft) peut accepter le fichier LDIF que vous avez créé pour lister les anciennes appartenances aux groupes de l'utilisateur, et il génère à son tour un fichier LDIF qui recrée ces appartenances. Par exemple, vous utiliseriez cette commande GROUPADD pour traiter le fichier LDIF nous avons créé dans l'exemple précédent pour Molly Clark :
C:\> groupadd /after_restore output.ldf
Cette commande créera un nouveau fichier LDIF pour chaque domaine dans lequel Molly Clark appartenait à un groupe, avec le nom groupadd_<domain>.ldf (où <domain> est le nom de domaine pleinement qualifié du domaine dont les groupes seront mis à jour). Pour importer le fichier LDIF créé ci-dessus, il suffit de saisir la commande suivante :
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Avec Windows Server 2003, Microsoft a amélioré NTDSUTIL pour profiter des métadonnées supplémentaires qui sont présentes dans l'attribut de membre pour prendre en charge la réplication de valeurs liées (LVR). Si l'objet utilisateur restauré avait été membre de n'importe quel groupe du domaine et si l'appartenance au groupe de l'utilisateur a été enregistrée avec les métadonnées de LVR, NTDSUTIL augmente alors le numéro de version de la valeur qui correspond à l'attribut de membre, ce qui provoque ensuite la réplication vers l'extérieur de l'appartenance aux groupes.
La version Windows Server 2003 SP1 de NTDSUTIL incorpore les fonctions GROUPADD et créera automatiquement les fichiers LDIF quand il exécutera la restauration faisant autorité de l'objet utilisateur. La figure 5 illustre la nouvelle version de NTDSUTIL, et la figure 6 indique le contenu du fichier LDIF créé automatiquement.
Figure 6 Contenu du fichier LDIF créé par NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Figure 5 Nouveau NTDSUTIL avec capacités GROUPADD intégrées
Figure 5 Nouveau NTDSUTIL avec capacités GROUPADD intégrées (Cliquer sur l'image pour la réduire)
Figure 5 Nouveau NTDSUTIL avec capacités GROUPADD intégrées
Figure 5 Nouveau NTDSUTIL avec capacités GROUPADD intégrées (Cliquer sur l'image pour l'agrandir)
Si vous restaurez une UO entière qui contient plusieurs utilisateurs et groupes, il est relativement fatigant de les réintégrer manuellement dans leurs groupes. Une autre façon de récupérer les appartenances aux groupes restaurées est d'effectuer une restauration faisant autorité sur les groupes eux-mêmes.
L'exécution d'une restauration faisant autorité de groupes pose cependant deux problèmes. Le premier problème est assez évident : si vous restaurez un groupe, l'appartenance dans ce groupe reviendra à son état au moment de la sauvegarde. Cela signifie que les modifications effectuées au groupe depuis la dernière sauvegarde devront être appliquées une nouvelle fois au groupe. Le deuxième problème est un peu plus subtil et concerne la façon dont fonctionne la réplication d'Active Directory. Après l'exécution d'une restauration faisant autorité d'utilisateurs et de groupes, il n'y existe pas de garantie sur l'ordre dans lequel ils se répliqueront vers l'extérieur. Si un objet de groupe se réplique vers un DC avant l'objet utilisateur restauré, le contrôleur de domaine en cours de réplication supprimera automatiquement la référence de l'utilisateur du groupe, car l'objet utilisateur n'existe pas encore sur le DC. Lorsque l'objet utilisateur est répliqué plus tard, il ne sera pas ajouté au groupe.
La solution la plus facile est d'exécuter la restauration faisant autorité des groupes une deuxième fois. Après la restauration faisant autorité, redémarrez en mode normal et assurez-vous que cette réplication a lieu convenablement. Ensuite, redémarrez à nouveau en DSRM et exécutez NTDSUTIL pour effectuer une restauration faisant autorité des groupes dont l'utilisateur était membre. Cela garantit que lorsque vous démarrez une nouvelle fois en mode normal, l'objet utilisateur se sera répliqué vers l'extérieur avant que les objets de groupe s'y référant ne se répliquent.

Problème : les appartenances aux groupes dans les autres domaines ne sont pas restaurées
Le problème « de quel groupe était membre cet utilisateur » est en fait plus complexe que ce que j'ai décrit. L'utilisateur que vous restaurez pourrait avoir été membre de groupes locaux et universels de domaine dans les autres domaines, et ces appartenances aux groupes ne seront pas restaurées lorsque vous effectuez une restauration ne faisant pas autorité. Donc comment savoir à quels groupes l'utilisateur appartenait dans les autres domaines ? La réponse se situe dans le catalogue global. Avec ses propres données de domaine, le catalogue global contient une copie en lecture seule des données des autres domaines dans la forêt.
Pour profiter des données du catalogue s'étalant sur toute la forêt, vous devez exécuter la restauration ne faisant pas autorité sur un catalogue global, ce qui signifie que vous devez au préalable avoir sauvegardé un catalogue global. Lorsque vous exécutez LDIFDE pour identifier les appartenances aux groupes de l'utilisateur, vous pouvez découvrir les appartenances aux groupes universels de l'utilisateur sur les autres domaines.
Lorsque vous listez les appartenances aux groupes de l'utilisateur que vous récupérez, connectez-vous au port 3268 du catalogue global, au lieu du port 389 par défaut, et spécifiez le domaine racine de la forêt comme base de la recherche. LDIFDE affichera les appartenances aux groupes récupérés de l'utilisateur, y compris l'appartenance aux groupes universels dans tous les domaines de la forêt. Voici comment procéder :
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Si vous exécutez GROUPADD ou le nouveau NTDSUTIL sur un catalogue global, vous produirez un fichier LDIF pour le domaine de l'utilisateur, ainsi qu'un fichier LDIF pour chaque domaine dans lequel l'utilisateur restauré était membre d'un groupe universel. Lorsque vous importez ces fichiers LDIF, vous restaurez toutes les appartenances aux groupes de l'utilisateur. Enfin, presque toute, ce qui nous amène au problème suivant.

Problème : récupérer les appartenances aux groupes locaux de domaine dans les autres domaines
Il existe trois genres de groupes dans un environnement Active Directory de Windows. Les groupes globaux peuvent seulement contenir des membres dans le même domaine, mais ils peuvent être utilisés comme un membre à l'intérieur de groupes locaux de domaine dans son propre domaine et dans d'autres domaines dans la forêt. L'attribut de membre des groupes globaux n'apparaît pas dans le catalogue global, mais ce n'est pas un problème parce que les groupes globaux contiennent seulement des membres de leur propre domaine. Les groupes universels peuvent contenir des membres de n'importe quel domaine et peuvent être utilisés comme des membres dans les autres groupes universels de la forêt et dans des groupes locaux de domaine dans leur propre domaine comme dans d'autres domaines de la forêt. L'attribut de membre de groupes universels est répliqué vers les catalogues globaux. Les groupes locaux de domaine peuvent contenir des membres de n'importe quel domaine de la forêt, mais ils ne peuvent pas être utilisés comme membres dans les groupes d'autres domaines. Et plus important, l'attribut de membre des groupes locaux de domaine, comme celui des groupes globaux, n'apparaît pas dans le catalogue global. Par conséquent, il n'existe pas de moyen facile pour récupérer l'appartenance de l'utilisateur dans les groupes locaux de domaine dans les autres domaines.
Avant Windows Server 2003 SP1, le seul moyen de récupérer les appartenances aux groupes locaux de domaine dans les domaines étrangers était de restaurer un DC dans chaque domaine, puis de rechercher manuellement les données de domaine pour tous les groupes locaux de domaine qui contenaient l'utilisateur restauré, avant de réintégrer l'utilisateur aux groupes que vous aviez identifiés. Dans un grand environnement contenant beaucoup de domaines, cette approche était exclue, étant donné le temps qu'elle demandait.
La version Windows Server 2003 SP1 de NTDSUTIL peut aider. Lorsque vous exécutez NTDSUTIL sur un contrôleur de domaine, l'utilitaire crée un fichier texte qui contient le DN et le GUID des objets utilisateur restaurés. Ensuite, pour chaque domaine étranger, vous pouvez effectuer une restauration faisant autorité d'un DC unique, copier le fichier texte sur le DC et exécuter NTDSUTIL pour produire un nouveau fichier LDIF spécifique au domaine qui réintègre l'utilisateur récupéré aux groupes locaux de domaine dont il était membre.
Pour ce faire, suivez les étapes suivantes sur un DC dans chaque domaine étranger :
  1. Démarrez le DC dans le domaine étranger en DSRM.
  2. Utilisez NTBACKUP pour restaurer une copie de la DIT qui contient les appartenances aux groupes de l'utilisateur restauré.
  3. Copiez le fichier .txt créé par NTDSUTIL au DC actuel.
  4. Ouvrez une fenêtre de commande et tapez ntdsutil.
  5. Tapez la restauration faisant autorité.
  6. Tapez créer le(s) fichier(s) LDIF à partir de <file name> (où <file name> est le nom du fichier texte).
  7. Tapez Le type « quit » deux fois pour quitter ntdsutil.
  8. Redémarrez le DC en mode normal d'Active Directory.
  9. Tapez ldifde –i –f <ldif filename> (où <filename> est le nom du fichier LDIF que vous venez de créer).
Vous avez maintenant restauré l'ensemble des appartenances aux groupes de l'utilisateur supprimé.

Étape par étape
La récupération des utilisateurs d'Active Directory et de leurs appartenances aux groupes n'est pas aisée, surtout dans un environnement à domaines multiples. Les étapes spécifiques nécessaires à la récupération appropriée des appartenances aux groupes dépendent de votre version de Windows.
S'il s'agit de Windows 2003 SP1, procédez comme suit :
  1. Démarrez un GC en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient l'utilisateur supprimé.
  2. Utilisez NTDSUTIL pour effectuer une restauration faisant autorité de l'utilisateur supprimé. NTDSUTIL créera un fichier texte contenant les DN et GUID de l'objet restauré, ainsi qu'un ou plusieurs fichier(s) LDIF pour restaurer les appartenances aux groupes de l'utilisateur.
  3. Utilisez LDIFDE –i –f <LDIF filename> (où <LDIF filename> est le nom des fichiers LDIF créés à l'étape 2) pour importer les appartenances aux groupes dans le domaine actuel et dans les autres domaines.
  4. Redémarrez le catalogue global en mode normal.
  5. Sur un DC dans chaque domaine étranger, redémarrez en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient les appartenances aux groupes de l'utilisateur restauré.
  6. Exécutez NTDSUTIL en utilisant la commande de création des fichiers ldif.
  7. Redémarrez le DC en mode normal.
  8. Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF que vous avez créé à l'étape 6) pour restaurer les appartenances aux groupes dans le domaine étranger.
  9. À ce stade, vous pouvez forcer la réplication à l'aide de REPADMIN/syncall.
Si vous exécutez une version de Windows Server 2003 sans SP1 ou si vous exécutez Windows 2000, vous devez prendre quelques mesures supplémentaires. Puisque l'ancienne version de NTDSUTIL ne crée pas de fichiers LDIF, utilisez l'utilitaire GROUPADD pour les créer. Le processus est le suivant :
  1. Démarrez un catalogue global dans DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient l'utilisateur supprimé.
  2. Désactivez le NIC ou débranchez le câble pour empêcher la réplication entrante.
  3. Redémarrez le catalogue global en mode normal.
  4. Utilisez LDIFDE –r « (distinguishedName=<dn>) » -t 3268 -l memberOf –p Base -f membership.ldf pour décharger l'appartenance de l'utilisateur avec le nom distingué <dn>.
  5. Utilisez GROUPADD/after_restore membership.ldf pour créer les fichiers LDIF.
  6. Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF créé par GROUPADD à l'Etape 5) pour importer les appartenances aux groupes dans le domaine actuel et dans les autres domaines.
  7. Réactivez la réplication entrante en utilisant REPADMIN/options <dcname> -DISABLE_INBOUND_REPL.
  8. Sur un DC dans chaque domaine étranger, redémarrez en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient les appartenances aux groupes de l'utilisateur restauré.
  9. Redémarrez le DC en mode normal.
  10. Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF créé par GROUPADD à l'étape 5) pour restaurer les appartenances aux groupes dans le domaine étranger.
  11. À ce stade, vous pouvez forcer la réplication à l'aide de REPADMIN/syncall.
Tout ce qu'il reste à faire maintenant pour les environnements précédant Windows Server 2003 SP1, c'est de récupérer les appartenances aux groupes locaux du domaine étranger de l'utilisateur restauré. Vos seuls choix sont de restaurer manuellement les appartenances aux groupes locaux du domaine ou de restaurer un DC à partir d'une sauvegarde, puis d'effectuer une restauration faisant autorité sur les groupes locaux de domaine.

Résumé
S'il est très facile de supprimer accidentellement des utilisateurs ou même des UO sur Active Directory, récupérer convenablement les utilisateurs supprimés et leurs appartenances aux groupes peut s'avérer une tâche complexe, laborieuse et sujette aux erreurs. Pour être sûr de pouvoir récupérer de ce genre d'incident aussi rapidement que possible, vous devez comprendre les mécanismes des liens, de la réplication, de la suppression et de la récupération faisant autorité des objets.
Pensez-vous pouvoir réussir toutes ces étapes la première fois vous les essayez dans votre environnement de production ? Pour être prêt la prochaine fois que vous devez récupérer l'objet utilisateur de votre PDG, préparez un plan de récupération des objets supprimés. Et testez votre plan au moins une fois ou deux avant de l'essayer sur des données réelles. Votre responsable l'appréciera (tout comme votre PDG).
Ressources supplémentaires
  • Comment restaurer des comptes utilisateur supprimés et leurs appartenances aux groupes dans Active Directory
  • Services de support technique Microsoft
  • Guide étape par étape de la gestion d'Active Directory

Gil Kirkpatrick est directeur technique à NetPro, et il développe des logiciels pour Active Directory depuis 1996. Avec Guido Grillenmeier, qui travaille chez HP, il anime des ateliers de récupération après incident d'Active Directory qui connaissent un grand succès. Gil est également le fondateur de Directory Experts Conference (www.dec2007.com).


 Administration de Windows: Pourquoi Windows XP Embedded est important pour vous
Administration de Windows Don Jones

Pourquoi Windows XP Embedded est important pour vous
Vue d'ensemble:
  • Qu'y a-t-il dans Windows XP Embedded
  • Options spéciales de matériel
  • Personnalisation de Windows XP Embedded

Windows XP Embedded est la version composante de Windows souvent associée aux périphériques de l'électronique grand public, tels que les décodeurs ou les appareils. Mais Windows XP Embedded peut également trouver sa place dans la gamme de produits technologiques de votre organisation. Si ce n'est pas la meilleure
solution pour chacun de vos utilisateurs, il existe certains scénarios spécifiques où il permet de réduire les frais administratifs, offre un matériel potentiellement moins cher et plus petit et apporte une plus grande sécurité.

Qu'est-ce que Windows XP Embedded ?
Windows® XP Embedded est l'une des trois versions petite taille de Windows, avec Windows Embedded CE et Windows Embedded pour point de service. Parmi les systèmes d'exploitation Windows intégrés, seul Windows XP Embedded offre les fonctionnalités complètes £ ou au moins le potentiel pour ces fonctionnalités £ d'un ordinateur client Windows XP Professionnel. Il se base sur le Service Pack 2 (SP2) de Windows XP Professionnel ; cependant, Windows XP Embedded est différent du Windows XP normal par son niveau extrême de modularisation. Windows XP Embedded ne dispose pas de ce que l'on pourrait appeler une image d'installation standard. À la place, vous utilisez une trousse à outils, appelée Windows Embedded Studio, afin de créer un environnement Windows XP Embedded pour tous les périphériques que vous générez, cet environnement n'incluant que la fonctionnalité dont votre périphérique aura besoin. Si vous n'avez pas besoin de DirectX® ou de Windows Explorer, ne les installez pas ! Cette modularisation signifie que chaque image Windows XP Embedded que vous générez et déployez aura moins de parties en mouvement, pour ainsi dire, donc moins d'efforts au niveau administratif et une plus grande sécurité, ainsi que la possibilité d'utiliser du matériel à moindre coût. Certaines des options disponibles peuvent être vues dans le Concepteur de cible (partie de Windows Embedded Studio), comme le montre la figure 1.
Figure 1 Sélection des composants dans Target Designer
Figure 1 Sélection des composants dans Target Designer (Cliquer sur l'image pour la réduire)
Figure 1 Sélection des composants dans Target Designer
Figure 1 Sélection des composants dans Target Designer (Cliquer sur l'image pour l'agrandir)

Une place dans l'entreprise
Une solution de périphérique basé sur Windows XP Embedded convient à un nombre croissant de scénarios utilisateur. Par exemple, pensez aux entreprises qui maintiennent de grands centres d'appel de service à la clientèle. Dans un grand nombre de cas, les représentants de ces centres ont besoin d'une ou deux applications développées en interne, voire un navigateur Web. Ils utilisent seulement une fraction des capacités de leur ordinateur, ce que Windows XP Embedded vous permet de faire en ne vous laissant que ce dont vous avez besoin. Moins de fonctionnalités signifie moins de zone de surface exposée aux erreurs ou aux possibles attaques de sécurité.
Étant donné que les périphériques Windows XP Embedded ont des fonctionnalités limitées, ils peuvent fonctionner sur du matériel moins puissant et souvent moins cher. Un certain nombre de fabricants produisent des cartes mères qui utilisent des processeurs à faible consommation d'énergie, compatibles avec Intel. Ces cartes sont extrêmement petites, consomment très peu d'énergie et n'utilisent souvent même pas de ventilateur puisqu'elles ne chauffent pas. Elles fonctionnent parfaitement bien pour un périphérique intégré de petite taille, capable d'exécuter uniquement un ensemble limité d'applications.

Les super pouvoirs spéciaux de Windows XP Embedded
Windows XP Embedded offre certaines options très précieuses qui ne sont pas disponibles dans la version complète de Windows XP. Les options EWF (Enhanced Write Filter) et HORM (Hibernate Once, Resume Many) peuvent toutes deux simplifier vos tâches administratives Windows. EWF est un composant facultatif que vous pouvez ajouter à un déploiement de Windows XP Embedded et qui transforme en lecture seule un volume de disque donné. N'importe quelle activité d'écriture destinée au disque est détournée vers une superposition pouvant se trouver sur un autre disque ou même dans la mémoire. Le système d'exploitation lui-même voit la superposition EWF et son volume parent comme une seule unité, ce qui signifie qu'elle apparaît comme un volume de disque normal. Dans les coulisses, cependant, le volume parent ne change en fait pas ; les modifications sont seulement apportées à la superposition EWF. Ceci peut être avantageux de plusieurs façons. Imaginez que vous déployez une image Windows XP Embedded vers une carte Compact Flash (les images Windows XP Embedded peuvent ne peser que 5 Mo et sont souvent consignées aux alentours de 200 Mo, donc CF jouirait d'un stockage plus que suffisant). Cette carte CF peut se brancher à un adaptateur et se relier à un connecteur IDE de la carte mère, lui donnant un aspect de disque normal fixe. Les cartes CF d'aujourd'hui ont une capacité d'écriture limitée (environ 100 000), donc EWF serait utilisé pour transformer le volume CF en lecture seule. Imaginez que vous mettez la superposition EWF dans la RAM : Si l'utilisateur commet une erreur, il vous suffit de désactiver l'ordinateur. La superposition EWF et toutes les modifications apportées à l'ordinateur sont immédiatement perdues. Lorsque vous redémarrez, vous vous retrouvez au point de départ stocké sur la carte CF. Vous pouvez utiliser la même configuration pour une image basée sur un CD ou un DVD ; puisque ces types de médias sont intrinsèquement en lecture seule, EWF capture toutes les activités d'écriture au niveau d'une superposition. Même si la superposition est stockée sur un petit disque dur interne, vous êtes assuré que le volume de démarrage original (sur CD ou DVD) n'est jamais modifié ; si vous avez besoin de redémarrer l'ordinateur à sa configuration d'origine, il vous suffit d'éliminer la superposition EWF.
HORM vous permet de faire hiberner un ordinateur une fois, puis de redémarrer à partir de ce point à de nombreuses reprises. L'ordinateur s'allume presque instantanément. Configurez simplement l'ordinateur, obtenez toutes les applications nécessaires en cours d'exécution, puis faites-le hiberner. À partir de ce moment-là, chaque fois vous allumez l'ordinateur, vous devrez seulement attendre quelques secondes pour que tout redémarre.

Générer une image Windows XP Embedded
Microsoft a un programme WEP (Windows Embedded Partner) consistant en entreprises spécialisées dans l'utilisation de Windows XP Embedded (vous trouverez les listes de ces partenaires sur la page d'accueil Windows XP Embedded à l'adresse microsoft. com/embedded). Cependant, avec autant d'entreprises fournissant à leurs fabricants de PC normaux des images prégérées (qui comprennent des applications d'entreprise et des configurations spécifiques), il se peut que vous souhaitiez créer vos propres images Windows XP Embedded, que vous pourrez partager ensuite avec un Embedded Partner qui vous fournit des systèmes complets de petite taille. Windows Embedded Studio, qui s'installe sur Windows XP Professionnel, peut être utilisé pour générer et gérer les images Windows XP Embedded.
Pour utiliser la trousse à outils, installez d'abord la version complète de Windows XP Pro sur le matériel que vous avez l'intention d'utiliser pour votre système Windows XP Embedded. Ceci vous permet d'utiliser la routine complète de configuration de Windows XP pour que tout le matériel fonctionne convenablement. Ensuite, vous installez Windows Embedded Studio. Ceci installe normalement une base de données utilisée pour gérer des images intégrées, mais cette base peut en fait être installée ailleurs et servir de référentiel central. Ensuite, vous exécuterez un utilitaire de ligne de commande appelé Tap.exe, qui crée un nouveau composant spécial utilisable par Windows XP Embedded. Normalement, les composants encapsulent les fonctionnalités, telles qu'un lecteur de médias, un système de fichiers ou d'autres applications personnalisées ; dans ce cas, vous créerez un composant contenant les pilotes des périphériques du matériel nécessaires à votre système particulier. Cette étape doit être complétée sur le matériel cible pour que l'outil puisse détecter et inclure les pilotes de matériel appropriés.
Pour l'étape suivante, vous exécutez Component Designer de Windows XP Embedded et importez le package de composants créé par l'utilitaire Tap.exe. Comme le montre la figure 2, le Component Designer lit les informations du périphérique et assemble un composant Windows XP Embedded complet, lequel peut devenir la base d'une nouvelle image Windows XP Embedded. Ceci simplifie grandement le processus qui détermine exactement les pilotes des périphériques dont une plate-forme donnée aura besoin. Après avoir créé le composant, vous utilisez le Gestionnaire de base de données de composants pour importer le nouveau composant dans la base de données de composants de Windows XP Embedded, c'est-à-dire un référentiel dans lequel tous les composants de Windows XP Embedded sont stockés. Lorsque le composant est dans la base de données, il peut être utilisé dans les images Windows XP Embedded.
Figure 2 Concepteur de composants
Figure 2 Concepteur de composants (Cliquer sur l'image pour la réduire)
Figure 2 Concepteur de composants
Figure 2 Concepteur de composants (Cliquer sur l'image pour l'agrandir)
À présent, vous êtes prêt à commencer la création d'une nouvelle configuration cible à l'aide de Target Designer de Windows XP Embedded, l'outil qui abritera le gros de votre véritable travail. Comme indiqué dans la figure 1, vous ajouterez tous les composants dont vous aurez besoin pour créer l'ensemble de fonctions nécessaire à votre périphérique. Vous devrez également ajouter certains composants centraux Windows, tels que l'explorateur Windows (si votre périphérique nécessite un noyau graphique), le système de fichiers NTFS (ou FAT32), NT Loader, la prise en charge d'une langue, le noyau de l'interface utilisateur et ainsi de suite. Plus de dix mille composants sont disponibles par défaut.
Vous pouvez également préconfigurer les paramètres de chaque composant. Par exemple, le composant central de l'interface utilisateur peut être personnalisé pour afficher des éléments spécifiques dans le menu Démarrer de Windows, sur le Bureau, ainsi qu'à d'autres endroits. La personnalisation des paramètres de chaque composant garantit que chaque périphérique sera préconfiguré pour répondre à vos besoins (voir la figure 3).
Figure 3 Personnalisation des paramètres
Figure 3 Personnalisation des paramètres (Cliquer sur l'image pour la réduire)
Figure 3 Personnalisation des paramètres
Figure 3 Personnalisation des paramètres (Cliquer sur l'image pour l'agrandir)
Les dépendances représentent la partie la plus délicate pour une image Windows XP Embedded. Par exemple, vous ne pouvez pas ajouter un composant DirectX à votre image sans ajouter également plusieurs composants qui fournissent à Windows ses principales capacités de gestion des graphiques. Suivre toutes les dépendances peut être assez fastidieux, surtout pour les grandes images complexes qui peuvent littéralement en avoir des milliers. C'est ce dont s'occupe la Base de données de composants. Appuyez simplement sur F5 dans Target Designer et cet outil analysera tous les composants que vous avez ajoutés, insérant automatiquement toutes les dépendances requises par les composants que vous avez listés. La figure 4 montre une analyse en cours d'exécution ; il s'agit d'une étape essentielle et c'est ce qui permet à Windows XP Embedded d'être aussi fortement modularisé. Sans cette intelligence intégrée à Target Designer, il serait très difficile de créer des images contenant toutes les dépendances appropriées.
Figure 4 Vérification des dépendances
Figure 4 Vérification des dépendances (Cliquer sur l'image pour la réduire)
Figure 4 Vérification des dépendances
Figure 4 Vérification des dépendances (Cliquer sur l'image pour l'agrandir)
Lorsque tous vos composants et leurs dépendances ont été ajoutés, vous pouvez générer votre image Windows XP Embedded. Les images sont simplement des fichiers devant être copiés au volume de démarrage de votre périphérique Windows XP Embedded. Vous n'avez pas besoin d'outils spéciaux pour les déployer (bien que le jeu d'outils Windows XP Embedded comporte un serveur de démarrage à distance aux fonctionnalités similaires à celles des Services d'installation à distance ; il permet le déploiement des images Windows XP Embedded vers du matériel en métal nu). Après avoir complété ces étapes, vous pouvez voir la taille réelle de votre image. J'ai créé une image très basique incluant le noyau de l'explorateur et quelques applications, telles que le Bloc-notes et Paint, et une image de moins de 90 méga-octets. D'accord, vous ne trouverez probablement pas beaucoup d'utilisateurs intéressés par un périphérique qui n'exécute que le Bloc-notes et Paint, mais cet exemple montre jusqu'à quel point la taille d'une image spécifique à une tâche peut être réduite.

Windows XP Embedded vs. Windows XP
Windows XP Embedded n'est pas du tout un système d'exploitation dénudé. Microsoft propose des composants pré-emballés permettant à un ordinateur fonctionnant avec Windows XP Embedded d'utiliser une bonne partie des fonctionnalités d'une version complète de Windows XP. Ceci inclut des options permettant d'installer DirectX 9.0c, Microsoft® .NET Framework, Windows Media® Player 10 et bien plus encore. Vous trouverez également une grande documentation destinée aux développeurs et décrivant comment générer des composants personnalisés, tels qu'un noyau personnalisé pour remplacer l'explorateur, ce qui vous permet de créer un environnement adapté à votre périphérique intégré spécifique.
Cependant, Windows XP Embedded n'offre pas toutes les fonctionnalités comprises dans la version complète de Windows XP Pro. Par exemple, la protection des fichiers Windows (WFP) n'est pas incluse dans Windows XP Embedded, tout comme ne sont pas incluses certaines fonctionnalités conviviales, telles que Windows XP Tour, les écrans de bienvenue au démarrage et les assistants qui aident les nouveaux utilisateurs à configurer leurs ordinateurs, ou l'installation de Windows. Windows XP Embedded n'utilise pas l'activation de produits Windows (les images Windows XP Embedded sont activées par le biais d'une touche de produit du service d'exécution à partir des outils Windows Embedded Studio). Ce qui est encore plus remarquable, c'est que Windows XP Embedded n'utilise pas du tout la mise à jour de Windows, bien qu'il puisse utiliser un serveur pour les services de mise à jour des logiciels Microsoft dans votre environnement. Pour finir, Windows XP Embedded ne dispose pas non plus de l'explorateur de MSN®, lequel fait partie de Windows XP Pro.
Si l'on regarde vers l'avenir, on s'aperçoit que Windows XP Embedded entreprend un cycle de développement riche : Feature Pack 2007 est maintenant disponible et ajoute de nouvelles fonctionnalités, telles que le démarrage basé sur USB, une amélioration apportée à EWF qui permet la validation de nouveaux fichiers au niveau du volume parent sans valider l'intégralité de la superposition, la prise en charge de la compression NTFS et bien plus encore. Ces améliorations continuent à ajouter de la flexibilité et des options au système d'exploitation Windows XP Embedded tout en lui procurant un nombre croissant des fonctionnalités contenues dans Windows XP Professionnel.

Adoption de la version Embedded
Les systèmes intégrés sont peut-être plus longs à générer qu'un système Windows XP traditionnel, mais dans certains cas, ils offrent des avantages considérables. Bien que leurs fonctionnalités soient réduites, les systèmes Windows XP Embedded peuvent prendre en charge un matériel plus petit et à consommation d'énergie plus faible, plus facile à entretenir et à réparer et à un coût beaucoup moins élevé. La plus faible consommation d'énergie contribue également à réduire les factures d'électricité et de chauffage, permettant ainsi plus de flexibilité dans la conception des espaces de travail compacts. À part les usages prévus pour Windows XP Embedded £ périphériques grand public, appareils de services médicaux, bornes et autres endroits où vous ne soupçonneriez pas la présence de Windows XP Embedded, ce système d'exploitation intégré pourrait également avoir toute sa place dans votre entreprise.

Don Jones est Directeur des projets et services pour SAPIEN Technologies et coauteur de Windows PowerShell : TFM (SAPIEN Press). Pour contacter Don, rendez-vous sur son site Web à l'adresse suivante : www.ScriptingAnswers.com.


 Administration: Planification avec System Center Capacity Planner
Administration John Savill

Planification avec System Center Capacity Planner
Vue d'ensemble:
  • Principes fondamentaux de SCCP
  • Création d'un nouveau modèle
  • Ajustage du modèle
  • Simulation de l'utilisation véritable

Les composants d'infrastructure d'aujourd'hui sont essentiels pour les entreprises qu'ils prennent en charge. Cependant, lorsque le nombre d'utilisateurs augmente et que les organisations se diversifient, l'estimation précise de la taille et
du nombre de serveurs pour l'exécution des composants devient un défi. Un matériel insuffisant est source de temps de réponse médiocres pour les utilisateurs finaux et un excès de matériel est simplement un gaspillage de budget et une source d'administration supplémentaire. Pour cette raison, Microsoft a créé System Center Capacity Planner (SCCP) 2006.
Au niveau supérieur, SCCP vous permet d'entrer des informations sur la topologie de réseau (emplacements, vitesses de connexion, latence), logiciel et matériel à utiliser et profils d'utilisation (tels que le nombre de messages envoyés). SCCP exécute ensuite des simulations de différents niveaux d'utilisation et offre un détail de l'utilisation du matériel et des composants réseau. Cette modélisation permet de déterminer si la configuration proposée est suffisante pour répondre aux exigences de service en cas de mise en œuvre.
SCCP n'a pas besoin de s'exécuter sur un serveur spécifique ou d'effectuer le test du réseau. Il s'agit essentiellement d'un outil de simulation qui peut exécuter des scénarios de test dans un environnement modélisé. La configuration requise pour SCCP est en fait minimale : Windows® XP avec Service Pack 2 (SP2), Windows Server® 2003 ou Windows 2000 avec SP4, plus Microsoft® .NET Framework 2.0. La prochaine génération de SCCP s'interfacera certainement beaucoup plus étroitement avec Systems Management Server (SMS) et Microsoft Operations Manager et automatisera une partie de la collecte d'informations, puisque MOM recueille déjà des informations sur l'utilisation des serveurs et que SMS rassemble des informations sur la configuration matérielle.
L'installation de SCCP 2006 est simple : l'Assistant d'installation standard nécessite seulement l'acceptation du contrat de licence et la confirmation du dossier d'installation. Une fois le produit installé, un raccourci est ajouté au menu Tous les programmes. Lorsque vous démarrez SCCP pour la première fois, l'écran de bienvenue de Microsoft Capacity Planner offre un accès à trois de ses quatre composants, comme indiqué sur la figure 1.
Figure 1 Démarrage de l'outil Capacity Planner
Figure 1 Démarrage de l'outil Capacity Planner (Cliquer sur l'image pour la réduire)
Figure 1 Démarrage de l'outil Capacity Planner
Figure 1 Démarrage de l'outil Capacity Planner (Cliquer sur l'image pour l'agrandir)
Model Wizard (l'Assistant Modèle) vous pose des questions concernant l'environnement désiré afin de créer un modèle d'architecture système SAM (System Architecture Model). Le modèle SAM inclut des informations détaillées sur les emplacements, les utilisateurs, le réseau, les modèles d'utilisation et le matériel.
Model Editor (l'éditeur de modèles) permet d'ajuster et de modifier les modèles SAM créés précédemment à l'aide de l'Assistant ou de l'éditeur. Vous pouvez y valider des modèles, afficher l'utilisation simulée et tester d'autres scénarios, tels que la charge supplémentaire sur les serveurs de messagerie ou la présence d'utilisateurs distants.
Capacity Planner est livré avec un plusieurs types de matériels prédéfinis pour l'utilisation avec les modèles SAM. Cependant, si vos besoins diffèrent, Hardware Editor (l'éditeur de matériel) prend en charge la définition personnalisée de configurations matérielles.
Lorsqu'un modèle est sélectionné, Capacity Planner Simulation permet d'exécuter des tests divers avec le modèle sélectionné afin de déterminer sa viabilité pour la mise en œuvre en environnement réel.
La meilleure façon d'examiner les composants et la manière dont ils fonctionnent en collaboration est en fait d'utiliser l'outil. Je vais commencer par l'Assistant, exécuter une simulation et ensuite ajuster un modèle d'architecture en ajoutant du matériel personnalisé. Dans cet exemple détaillé, j'utiliserai un environnement Exchange, mais la procédure fonctionne de manière similaire pour MOM.

Création d'un nouveau modèle
Avant de pouvoir effectuer la validation ou des scénarios de type « Et si... », ou même d'exécuter des scénarios pour votre infrastructure actuellement déployée, l'environnement doit être décrit à SCCP. Malheureusement, il n'est pas possible d'analyser tout simplement le réseau dans la version actuelle. Au lieu de cela, vous devez détailler votre infrastructure en termes d'emplacements physiques et de types de connectivités entre ces emplacements, l'emplacement des serveurs, des boîtes aux lettres et des utilisateurs et les détails sur la manière dont les utilisateurs emploieront l'environnement.
L'outil comporte quelques restrictions qui sont expliquées en détail dans le guide de l'utilisateur. Par exemple, dans un modèle Exchange, une seule forêt est prise en charge. Ceci signifie que les domaines des forêts externes ne sont pas modélisés et que les serveurs frontaux sont supposés avoir un catalogue global et une banque de boîtes aux lettres sur le même site. Seuls 100 sites peuvent être modélisés, 10 d'entre eux pouvant être des sites hubs. 300 ordinateurs serveurs et seuls les clients Outlook® 2003 (Web ou locaux) sont pris en charge. La bonne nouvelle est que SCCP prend en charge jusqu'à 49 999 clients dans les sites centraux/de hub et jusqu'à 10 000 dans les succursales. Les fonctionnalités Exchange telles qu'ActiveSync® et les connexions Outlook Mobile Access ne sont pas prises en charge, tout comme les options de connectivité anciennes telles que POP et IMAP. L'utilisation engendrée par les opérations de sauvegarde et de restauration n'est pas prise en compte, tout comme les configurations en clusters. Cependant, Capacity Planner dispose des options requises pour modéliser avec précision l'utilisation de courrier quotidienne typique.
Pour commencer la procédure depuis la page de bienvenue, sélectionnez « Create a model with the Model Wizard » (Créer un modèle avec l'Assistant Modèle) et décrivez l'infrastructure à modéliser. Je vais créer une entreprise qui possède trois sites : un site central à Dallas et des succursales à Houston et Austin, chacune ayant plusieurs utilisateurs de messagerie électronique locaux. Chaque site ne dispose pas nécessairement de ses propres serveurs et je fournis donc des informations sur le nombre et le type d'utilisateurs de messagerie électronique. SCCP calculera les sites sur lesquels des serveurs Exchange locaux doivent être présents et où les utilisateurs accéderont à leur serveur Exchange à distance.
Après avoir créé un modèle de base de l'infrastructure de l'organisation, l'Assistant demande le nombre de sites centraux et de succursales, la connectivité entre les sites et le pourcentage de bande passante qui peut être utilisé pour la messagerie électronique. L'Assistant adopte une approche assez large pour faire démarrer les choses. Plus tard, je pourrai ajuster le modèle créé par l'Assistant pour configurer des liens individuels avec plus de granularité. Dans cet exemple, je peux confirmer le bureau central et les deux succursales (voir la figure 2). Il y a des connexions T1 entre les succursales et le site central. La moitié de la bande passante peut être utilisée pour la messagerie électronique. Je n'ai pas besoin de configurer la vitesse entre les sites centraux puisque je n'en ai qu'un.
Figure 2 Configuration de la topologie de réseau étendu et de la bande passante de connexion
Figure 2 Configuration de la topologie de réseau étendu et de la bande passante de connexion (Cliquer sur l'image pour la réduire)
Figure 2 Configuration de la topologie de réseau étendu et de la bande passante de connexion
Figure 2 Configuration de la topologie de réseau étendu et de la bande passante de connexion (Cliquer sur l'image pour l'agrandir)
La fenêtre suivante de l'Assistant demande le nombre moyen d'utilisateurs des succursales, le client de messagerie électronique (Outlook 2003 en mode mis en cache ou Outlook Web Access) et le nombre d'utilisateurs du site central. Ici encore, il s'agit d'informations de haut niveau qui peuvent être ajustées ultérieurement en utilisant l'éditeur de modèle. Dans ce cas, je déclarerai que chaque succursale compte 200 utilisateurs et que le site central en compte 500. Tous utilisent Outlook en mode mis en cache.
L'Assistant possède trois niveaux d'utilisation de messagerie par défaut : Élevé, moyen et faible. Chaque niveau correspond à une taille moyenne de boîte aux lettres, à un nombre de messages envoyés et reçus et à une taille moyenne par message électronique différents. Si aucun des types intégrés ne correspond au modèle d'utilisation attendu dans votre organisation, les valeurs individuelles peuvent être configurées pour chacune des quatre caractéristiques d'utilisation distinctes.
L'étape suivante est la configuration des préférences matérielles, comme indiqué sur la figure 3. SCCP permet de spécifier jusqu'à trois configurations d'UC et celles-ci seront utilisées pour modéliser le matériel pour les différents rôles de serveur. Les configurations d'UC s'étendent d'un processeur unique Pentium III Xeon 1 GHz jusqu'à des configurations à quatre processeurs Xeon MP 3,66 GHz. Exchange 2003 consiste en plusieurs rôles, à savoir banque de boîtes aux lettres, serveur pont et frontal, ainsi qu'un rôle de catalogue Global Active Directory® supplémentaire. Si le taux d'utilisation le permet, il est possible de consolider les rôles sur un nombre plus réduit de serveurs. Si la consolidation des serveurs n'est pas choisie, des serveurs distincts seront configurés pour chacun des rôles, même si le taux d'utilisation ne le nécessite pas. Autoriser SCCP à effectuer la consolidation fournira les meilleurs résultats.
Figure 3 Configuration des profils matériels des serveurs
Figure 3 Configuration des profils matériels des serveurs (Cliquer sur l'image pour la réduire)
Figure 3 Configuration des profils matériels des serveurs
Figure 3 Configuration des profils matériels des serveurs (Cliquer sur l'image pour l'agrandir)
Enfin, le type de disques disponibles peut être sélectionné en termes d'interface, de taille et de vitesse. Le nombre de disques n'est pas demandé car Capacity Planner le calculera pour moi. Capacity Planner peut également spécifier un réseau de stockage SAN, bien que la capacité de créer des clusters ne soit actuellement pas disponible.
L'étape suivante de l'Assistant est un récapitulatif du modèle calculé qui affiche le nombre de serveurs que SCCP calcule comme étant optimal, le rôle de chacun des serveurs et des détails tels que les configurations de processeur, mémoire et disque. Si un SAN avait été sélectionné, il serait également affiché.
Notez que parce que j'ai sélectionné plusieurs sites, il est tout à fait possible que les serveurs soient uniquement affichés pour un sous-ensemble des sites. C'est parce que SCCP a déterminé que l'utilisation de serveurs Exchange locaux sur certains sites n'est pas optimale et qu'au lieu de cela, les boîtes aux lettres tireront un avantage de l'utilisation d'un serveur de boîtes aux lettres Exchange distant, ce qui est le cas dans mon exemple indiqué sur la figure 4. Dans ce cas, les 400 utilisateurs des succursales ne disposent pas d'une banque de boîtes aux lettres Exchange locale, mais ont au lieu de cela été consolidés sur le serveur unique de banque de boîtes aux lettres Exchange du site de Dallas, qui compte maintenant 500 utilisateurs.
Figure 4 Récapitulatif de l'évaluation initiale de planification de capacité
Figure 4 Récapitulatif de l'évaluation initiale de planification de capacité (Cliquer sur l'image pour la réduire)
Figure 4 Récapitulatif de l'évaluation initiale de planification de capacité
Figure 4 Récapitulatif de l'évaluation initiale de planification de capacité (Cliquer sur l'image pour l'agrandir)
Jusqu'ici, dans l'Assistant, je peux cliquer sur les boutons Suivant et Précédent pour modifier les réponses et ajuster le récapitulatif du modèle (ou cliquer directement sur les pages de l'Assistant à l'aide du volet de navigation à gauche). Lorsque je suis satisfait de la configuration, je peux cliquer sur le bouton Terminer de la page Model Summary (Récapitulatif du modèle). Ceci ouvre le modèle dans l'éditeur de modèle, où une configuration de granularité plus fine est possible.

Ajustage du modèle
L'Assistant Modèle est un excellent outil pour la création d'un modèle de base. Cependant, à moins que les divers sites soient tous identiques et normalisés, un certain degré de personnalisation sera nécessaire pour le modèle afin qu'il soit véritablement utile comme base de calcul de l'utilisation. Il n'est pas inhabituel que les sites aient un nombre d'utilisateurs différent ou disposent d'une combinaison de clients de messagerie divers tels que Outlook 2003 en mode mis en cache comme Outlook Web Access (OWA). Bien qu'il ne soit pas possible d'obtenir ce niveau de détail dans l'Assistant Modèle, il est possible de le configurer à l'aide de l'éditeur de modèle. Cet outil est également utile lorsqu'il s'agit d'essayer de déterminer l'effet de la modification de certains aspects de l'environnement, comme par exemple l'ajout de sites ou de types d'utilisateurs supplémentaires.
L'éditeur de modèle, affiché dans la figure 5 enregistre et récupère les modèles des fichiers .sam, format propriétaire de cet outil. Il est recommandé, comme avec tout travail, d'enregistrer les modèles dans un fichier avant d'effectuer des modifications majeures et d'utiliser un nom descriptif pour s'assurer qu'aucun modèle de travail n'est perdu. Le menu Fichier dispose d'une option d'exportation qui crée un rapport récapitulatif détaillé au format Excel® et un diagramme de topologie Visio® du modèle.
Figure 5 Ajuster une configuration de modèle SAM dans l'éditeur de modèle
Figure 5 Ajuster une configuration de modèle SAM dans l'éditeur de modèle (Cliquer sur l'image pour la réduire)
Figure 5 Ajuster une configuration de modèle SAM dans l'éditeur de modèle
Figure 5 Ajuster une configuration de modèle SAM dans l'éditeur de modèle (Cliquer sur l'image pour l'agrandir)
Dans le volet de gauche de l'éditeur de modèle se situe une zone de navigation de base pour l'affichage de la topologie globale, de la topologie de site et du résumé d'un modèle. Global Topology (topologie globale) affiche le modèle d'architecture du point de vue d'un site avec les réseaux supplémentaires tels qu'Internet. L'affichage Site Topology (topologie de site) affiche les informations sur un site ou un réseau sélectionné. Model Summary (Récapitulatif du modèle) affiche un récapitulatif textuel de l'environnement, qui possède un format identique à celui que vous verrez affiché à la fin de l'Assistant Modèle.
Quelle que soit l'option sélectionnée, les détails sont affichés dans le volet central de l'éditeur de modèle. Le volet de droite, à l'image de la nouvelle version de la console MMC (Microsoft Management Console) livrée avec Windows Server 2003 R2 est une zone « d'actions » qui est découpée en deux sous-zones : La première partie fournit des actions en fonction du contexte qui changent selon l'affichage ou l'objet sélectionné, tandis que la partie inférieure contient des actions générales qui s'appliquent toujours. Ces dernières actions me permettent d'ajouter un nouveau site, de modifier les profils d'utilisation des utilisateurs et (la partie intéressante) d'exécuter une simulation.
Lorsque vous travaillez dans le volet central de l'éditeur de modèle, tous les éléments peuvent être sélectionnés. Après avoir sélectionné un élément, outre le fait que les actions d'éléments courants changent en fonction de l'objet sélectionné, je peux accéder plus en détail à cet objet. Par exemple, le fait de double cliquer sur un site basculera vers l'affichage de topologie de site et donnera des détails sur les objets modélisés pour ce site. Ainsi, un ou plusieurs serveurs, réseaux et utilisateurs sur place devraient être affichés pour un site servi localement. Ceci donne la possibilité, inversement, de double-cliquer sur l'objet sélectionné pour afficher ses propriétés détaillées et de les modifier ensuite selon les nécessités.
Les lignes qui connectent les sites représentent les réseaux entre les sites et peuvent être modifiées pour permettre une configuration précise du réseau. Par exemple, je peux spécifier des bandes passantes de liaison montante ou descendante différentes et le pourcentage de bande passante disponible. Je peux également configurer la latence de connexion qui peut être un attribut très important pour une communication stable. Les autres modifications courantes incluent l'ajout de types d'utilisateurs supplémentaires. Dans ce cas précis, disons que nous disposons d'un mélange de clients Outlook Web Access et Outlook 2003 servis par le site central. Après avoir ouvert Dallas dans son affichage de topologie de site, je sélectionnerais « Add a client profile » (Ajouter un profil de client) et ajouterais les informations concernant les utilisateurs OWA qui incluraient le serveur que les clients OWA utiliseront, le réseau à partir duquel les utilisateurs se connecteront et la bande passante dont ils disposeront, comme indiqué sur la figure 6.
Figure 6 L'ajout et la modification d'éléments dans un modèle sont faciles
Figure 6 L'ajout et la modification d'éléments dans un modèle sont faciles (Cliquer sur l'image pour la réduire)
Figure 6 L'ajout et la modification d'éléments dans un modèle sont faciles
Figure 6 L'ajout et la modification d'éléments dans un modèle sont faciles (Cliquer sur l'image pour l'agrandir)
Une fois que le modèle SAM reflète autant que possible l'infrastructure existante ou prévue, enregistrez-le et nommez-le en conséquence pour vous assurer qu'il est facilement identifiable comme point de départ de toute modification future. À ce stade, j'ai l'habitude d'exécuter une simulation pour obtenir un point de référence des performances du modèle avec les paramètres configurés. En fonction de ce point de référence, je peux modifier le modèle pour tester divers scénarios « Et si... » tels que l'ajout d'un nouveau site et de nouveaux utilisateurs, l'ajout ou la suppression de serveurs, l'ajout de nouveaux utilisateurs ou sites ou la modification du type de connexion ou de client de messagerie électronique. Une fois le modèle mis à jour avec ces nouveaux éléments, je peux exécuter une autre simulation pour voir comment se comporte la nouvelle configuration.

Simulation de l'utilisation réelle
L'exécution d'une simulation se résume à cliquer sur l'action générale ou le bouton de barre d'outils Run simulation (Exécuter la simulation). Une vérification essentielle du modèle est tout d'abord effectuée. Tout défaut du modèle est affiché avant que la simulation soit exécutée. Par exemple, si des clients OWA sont ajoutés à un modèle qui n'avait auparavant aucun client OWA et aucun serveur frontal configuré, un message d'erreur vous avertira qu'il n'existe aucun serveur frontal. En l'absence de défauts; l'état est affiché pendant que la simulation est exécutée.
Une fois la simulation terminée, un rapport contenant des informations détaillées sur le taux d'utilisation de chacun des composants est généré et les résultats de simulation s'affichent. Ils contiennent initialement un récapitulatif donnant des détails des taux d'utilisation d'UC, de stockage et de liaisons de connexion (qui sont des causes de goulot d'étranglement courantes), ainsi que les temps de transaction de latence les plus longs pouvant affecter les activités de l'utilisateur. Les détails sur l'utilisation exacte des serveurs, réseaux SAN, connexions locales et externes peuvent être affichés en sélectionnant des liens dans le volet de gauche des résultats de simulation, comme indiqué sur la figure 7.
Figure 7 Récapitulatif de résultats de simulation pour un modèle simple
Figure 7 Récapitulatif de résultats de simulation pour un modèle simple (Cliquer sur l'image pour la réduire)
Figure 7 Récapitulatif de résultats de simulation pour un modèle simple
Figure 7 Récapitulatif de résultats de simulation pour un modèle simple (Cliquer sur l'image pour l'agrandir)
En conservant le curseur de la souris sur les divers affichages graphiques, tels que l'analyse Bottleneck (Goulot d'étranglement), vous pourrez afficher le serveur et l'attribut du serveur qui provoque ce goulot d'étranglement. Notez les paramètres de seuil (Threshold) du volet de gauche. Cette catégorie me permet de définir ce que je considère comme un taux d'utilisation raisonnable avant de déclencher des avertissements, une fonctionnalité utile.
Les rapports de simulation détaillés sont excellents, non seulement pour les décisions d'achat de matériel mais également pour afficher la quantité de ressources réseau qui sera utilisée par les applications de messagerie. Par exemple, pour les utilisateurs se connectant à l'aide de connexions de réseau étendu lentes, le rapport indique si la liaison est assez rapide. Si ce n'est pas le cas, je peux déterminer si la vitesse de la liaison entre les emplacements devrait être améliorée ou si un serveur de banque de boîtes aux lettres local devrait être ajouté, simplement en modifiant le modèle et en réexécutant la simulation pour obtenir des résultats qui répondent à des critères spécifiques. De même, si les serveurs s'exécutent tous avec 5 % d'utilisation d'UC, je peux ignorer la spécification des serveurs. Grâce à la modification de modèle facile et la possibilité de réexécuter des simulations, je suis en fait libre de faire des essais avec différentes options pour la solution. Grâce aux mesures précises de tous les scénarios testés, je peux participer en toute confiance aux réunions de budget et planification.

Résumé
Je vous ai juste donné un aperçu général de la manière dont SCCP vous permet de simuler et d'analyser le déploiement d'Exchange. Gardez à l'esprit que SCCP permet également un niveau de modélisation et de simulation identique pour MOM. SCCP peut à l'heure actuelle être téléchargé dans le cadre des téléchargements MSDN® Premium ou Technet Plus. ¦

John Savill est directeur de l'infrastructure technique de Geniant. Il est CISSP, MCSE Sécurité et messagerie sur Windows Server 2003, huit fois MVP et instructeur de Krav Maga. Il est également l'auteur de Windows Server 2003 Active Directory Design and Implementation chez Packt Publishing.


 Administration: Inventaires de clients avanc&#233;s avec SMS
Administration Wes Dobry

Inventaires de clients avancés avec SMS
Vue d'ensemble:
  • Utilisation de l'Agent d'inventaire matériel de SMS 2003
  • Développement de l'inventaire avec les fichiers MIF
  • Comparaison entre les fichiers MOF dynamiques et statiques
Télécharger le code de cet article: DobrySMSInventory2007_04.exe (152KB)

Dans la vie de chaque administrateur, il arrive un moment où son patron lui demande certaines informations qui ne peuvent pas être recueillies sans déployer de gros efforts. Mais imaginez que vous êtes un administrateur dynamique
et que vous avez déjà recueilli ces données. Vous pourriez envoyer ces informations à votre patron immédiatement et éviter ainsi des temps d'arrêt inutiles et des heures de travail supplémentaires. Vous pourriez même économiser beaucoup d'argent à l'entreprise. Vous pourriez être un héros.
Dès l'installation, Microsoft® Systems Management (SMS) 2003 recueille une grande quantité d'informations. Mais il ne recueille pas tout. Par exemple, par défaut, SMS 2003 ne fait pas de rapport sur les groupes locaux et leurs membres ou leurs utilisateurs locaux et leurs attributs. L'absence de ces informations peut poser un problème si, par exemple, un technicien met des Utilisateurs de domaine ou, pire, met tout le monde dans le groupe des administrateurs locaux sur chaque système qu'il traite. Ou si une entreprise n'a aucun moyen d'identifier les listes d'exclusion de fichier et dossier locaux sur l'antivirus ou la solution de protection contre les logiciels espions de l'entreprise. Cela peut ne pas sembler un problème majeur, du moins jusqu'à ce qu'un informaticien se rende compte que les utilisateurs mettent c:\*.* dans la liste d'exclusion.
À l'aide de la bonne combinaison de connaissances en écriture de script, de Windows® Management Instrumentation (WMI) et de SMS, vous pouvez développer les inventaires de SMS de sorte à ce qu'ils contiennent pratiquement n'importe quelle information. Cela est rendu possible par l'utilisation des fichiers MIF (Management Information Format) et MOF (Management Object Format).

Inventaires
Avec SMS, les entreprises peuvent exécuter des déploiements personnalisés, contrôler les cibles et maintenir les systèmes déployés. En développant les inventaires de SMS, vous pouvez créer et gérer une cible beaucoup plus personnalisée. Par exemple, vous pouvez appliquer des stratégies de sécurité locale d'entreprise en déployant vos stratégies de sécurité vers des systèmes dont les stratégies ont été modifiées par un utilisateur. Vous pouvez également désactiver des comptes utilisateur locaux non approuvés et supprimer des administrateurs locaux superflus.
Bien sûr, les entreprises comptent également sur SMS pour obtenir des informations détaillées et au moment opportun sur les systèmes client. Le développement des inventaires vous permet de créer des rapports qui contiennent des informations complètement personnalisées qui ne sont pas facilement disponibles avec les seuls inventaires par défaut. Et les informations peuvent être très précises. Par exemple, vous pourriez créer un rapport contenant le compte de systèmes qui possèdent une clé de registre spécifique pointant vers une batterie de serveurs particulière. Cela permettrait aux administrateurs d'évaluer le nombre de clients pointant vers chaque batterie à un moment donné. De même, l'équipe de sécurité peut vérifier quels systèmes sur le réseau exécutent un processus spécifique qui est reconnu comme un logiciel espion.
La valeur de fichiers MIF et MOF provient de leur capacité à entrer des informations à partir de presque n'importe quelle source avec un peu de traduction. Tant que les informations sont basées sur du texte, elles peuvent être manipulées et placées dans le WMI avec un fichier MOF ou recueillies sous forme d'un fichier MIF et envoyées sur le cycle d'inventaire matériel suivant. L'implémentation d'une expansion d'inventaire nécessite des connaissances en VBScript ou en JScript®, ainsi que sur ce qui doit être collecté. Puisque n'importe quelle information peut être collectée, ces connaissances requises peuvent s'étendre du WMI à des connaissances avancées de SQL. Bien sûr, la compréhension de SQL est une obligation, quel que soit le type d'informations que vous collectez, puisque vous aurez besoin de cette connaissance quand il s'agit de faire un rapport sur les données recueillies.

Comment fonctionnent les inventaires
SMS contient deux types de processus d'inventaire : matériel et logiciel. Les inventaires logiciels s'occupent seulement des informations sur les fichiers, comme par exemple leur emplacement, leur version, leur taille et leurs autres attributs. Cependant, le processus d'inventaire logiciel vous permet également de recueillir des fichiers et de les enregistrer sur le serveur du site.
L'expansion de l'inventaire matériel est facile, parce que l'inventaire matériel contient la plus grande quantité d'informations sur un système. Les informations présentes dans les inventaires matériels sont en grande partie dérivées du WMI, du registre et du BIOS du système.
Les inventaires matériels sont recueillis sur une planification, qui est déterminée dans les paramètres de site de l'Agent d'inventaire matériel sur SMS 2003. Les collectes peuvent être paramétrées pour se produire à chaque minute ou seulement tous les X mois. En général, il vous faut trouver un équilibre pour collecter ces informations à la fréquence maximale demandée par l'administration, mais sans encombrer le réseau, les serveurs de site, les points de gestion ni les clients.
Lorsque l'Agent d'inventaire matériel est installé pour la première fois, il compile le fichier sms_def.mof. Ce fichier contient toutes les informations que SMS recueille initialement. Une fois ce fichier compilé, tous les espaces de noms de SMS et les classes associées requis pour l'Agent d'inventaire matériel sont créés dans le WMI. La plupart sont enregistrés dans l'espace de nom \\.\root\CIMv2\SMS. Après l'installation, l'Agent d'inventaire matériel examine la plupart de ces classes pour générer des informations qui sont ensuite envoyées au point de gestion, puis à la base de données du site.

Fichiers MIF
En plus d'extraire des informations sur ces classes WMI, l'Agent d'inventaire matériel cherche les fichiers MIF dans les dossiers de collection NOIDMIF et IDMIF. Tous les fichiers MIF trouvés par l'agent à ces emplacements sont traités dans l'inventaire matériel suivant.
Les fichiers MIF constituent la façon la plus facile de développer l'inventaire matériel de SMS. Il existe deux types de fichiers de MIF : les fichiers NOIDMIF et IDMIF. Ce sont des fichiers statiques de type XML qui peuvent contenir pratiquement n'importe quelle information qu'un utilisateur pourrait vouloir placer dans la base de données SMS. Ils peuvent être créés par n'importe quel moyen utilisé pour créer des fichiers texte ordinaires. Ainsi, ils peuvent être créés par la plupart des langages d'écriture de script, ou simplement à la main.
Généralement, les fichiers MIF sont utilisés si les informations ne figurent pas dans le registre ou le WMI, ou si elles doivent être saisies manuellement. Ces fichiers peuvent être créés, par exemple, lorsque votre équipe de déploiement de matériel livre un nouveau système. Le technicien de déploiement peut naviguer vers une application HTML sur le système et entrer toutes les informations d'évaluation utilisées pour la mise à jour d'une base de données de gestion d'évaluation. Cette application crée ensuite de façon dynamique un fichier NOIDMIF et permet au technicien de télécharger le fichier sur le dossier de collection de fichiers NOIDMIF. Ce fichier NOIDMIF peut contenir toutes les informations saisies par le technicien, et est incorporé dans la base de données SMS.
Les fichiers NOIDMIF et IDMIF possèdent seulement quelques différences. Un fichier IDMIF contient un en-tête unique qui fournit des informations sur l'architecture et une référence unique. Les fichiers IDMIF peuvent être utilisés pour intégrer des périphériques non système à SMS. Par exemple, un script peut être utilisé pour créer des systèmes dans SMS qui sont en fait des imprimantes et écrire des informations les concernant dans la base de données SMS.
Les fichiers NOIDMIF et IDMIF sont enregistrés dans les emplacements standard qui sont déterminés par les clés de registre. La plupart du temps, il s'agit de %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF et ...\IDMIF, en supposant que l'agent SMS ait été installé à l'emplacement par défaut. Si l'agent a été installé à un emplacement personnalisé, les annuaires MIF doivent se trouver dans %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF et ...\IDMIF. En cas de doute concernant l'emplacement de ces annuaires, vous le trouverez dans les clés de registre suivantes :
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
Les fichiers de MIF possèdent toujours le même format, indépendamment de l'information collectée. En observant le fichier MIF illustré par la figure 1, vous verrez que le fichier comprend un seul composant qui contient des groupes multiples et un seul attribut dans chaque groupe. Toutes les sections sont obligatoires, mais vous n'avez pas besoin d'avoir plus d'une entrée de groupe ou d'attribut. Vous pouvez considérer chaque groupe du fichier MIF comme une ligne dans les données de la section nommée dans l'inventaire matériel, et chaque attribut du groupe comme une colonne de cette ligne.
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
L'exemple LocalAdmin.vbs, illustré par la figure 2, est un VBScript assez simple. Il recherche l'annuaire NOIDMIF, supprime le fichier MIF temporaire s'il existe, crée le fichier MIF temporaire et écrit de manière récursive sur le fichier des informations recueillies à l'aide d'une requête WMI simple. Il supprime ensuite le fichier MIF qui existe dans le dossier de collection NOIDMIF et transfère enfin le NOIDMIF temporaire dans le dossier de collection NOIDMIF.
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
Si les fichiers MIF sont une manière simple d'étendre l'inventaire matériel SMS, leur utilisation peut poser des problèmes. Les MIF sont traités dans chaque cycle d'inventaire matériel. Mais étant donné que ces fichiers sont créés, recueillis et analysés avant d'être enfin ajoutés à l'inventaire, l'affichage dans l'inventaire des informations contenues dans un MIF peut connaître des délais pouvant aller jusqu'à un cycle d'inventaire matériel. Cela signifie que si une entreprise a des cycles d'inventaire matériel quotidiens, les données de leur base de données de site peuvent avoir jusqu'à deux jours de retard. Donc, il vous faut réfléchir soigneusement et déterminer le moment où les programmes qui créent les fichiers MIF sont publiés et où le cycle d'inventaire matériel est exécuté.
Disons qu'une entreprise appelée Contoso a des cycles d'inventaire quotidiens qui s'exécutent à minuit. Lundi à 1h du matin un VBScript s'exécute, créant un fichier NOIDMIF qui contient la production d'un scanneur de rootkit. Cette production est recueillie à minuit et publiée au point de gestion. L'administrateur SMS de Contoso examine ensuite les informations mercredi soir à environ 22h00 et découvre qu'elles datent de 45 heures. C'est parce que l'administrateur SMS n'a pas pensé à choisir soigneusement le moment auquel le programme utilisé pour créer le fichier NOIDMIF doit être publié.

Fichiers MOF
Les fichiers MOF sont plus compliqués que les fichiers MIF. Ils possèdent un avantage sur les MIF, parce qu'ils entrent leurs informations directement dans le WMI et sont intégrés dans le processus de collecte de données standard de l'agent d'inventaire matériel. Ainsi, vous n'avez pas besoin de publier un VBScript à plusieurs reprises pour obtenir des informations, ce qui vous fait gagner du temps et vous évite beaucoup de tracas. Vous pouvez vous contenter de publier le MOF une fois par ordinateur, puis il est ensuite compilé.
Les fichiers MOF ont également l'avantage de posséder des informations aussi actuelles que le reste des informations contenues dans l'inventaire matériel. Chaque fois que l'Agent d'inventaire matériel parcourt son cycle, les fichiers et les fournisseurs détaillés dans le fichier MOF sont interrogés et les informations sont renvoyées rapidement. Lorsque vous avez besoin rapidement d'informations, vous pouvez exécuter un package qui contient votre fichier MOF et un VBScript pour lancer un inventaire matériel. Les informations dont vous avez besoin sont ensuite acquises dans un délai très court, pouvant aller jusqu'à un cycle de stratégie de programme publié.
Il existe trois classifications de fichiers MOF : les fichiers MOF pour une classe WMI et un espace de noms existants, les fichiers MOF pour une classe supplémentaire avec un fournisseur WMI existant et les fichiers MOF pour une classe supplémentaire qui n'a pas de fournisseur WMI.
Les fichiers MOF comprennent deux parties. La première partie est la section de définition d'espace de noms. C'est l'emplacement où les informations sur le fournisseur WMI sont identifiées. La deuxième section contient les attributs de rapport SMS. Cette section indique à l'Agent d'inventaire matériel où chercher et traiter les informations contenues dans les classes de WMI mentionnées. Puisque les fichiers MOF traitent directement avec le WMI, je vous conseille de prendre un peu de temps pour consulter le Kit de développement logiciel (SDK) de Microsoft WMI, si vous prévoyez de travailler avec ces fichiers (voir go.microsoft.com/fwlink/?LinkID=83121 pour plus d'informations).
Chacune des classifications de fichiers MOF mentionnées ci-dessus peut être statique ou dynamique. Par exemple, un fichier MOF est statique si la procédure de génération de l'entreprise compile un fichier MOF contenant des informations concernant le créateur du système, la génération des serveurs utilisés, les versions de la génération initiale, la date de fabrication de la machine, etc. Ces informations n'ont pas besoin d'être mises à jour et peuvent donc être placées directement dans le fichier MOF et compilées dans WMI à l'aide de mofcomp.exe. Après cela, la zone de recherche de l'Agent d'Inventaire matériel doit être étendue en ajoutant les informations de groupe et de classe au fichier sms_def.mod sur le serveur de site.
Un fichier MOF dynamique est similaire à un fichier MOF statique, sauf qu'au lieu d'écrire les informations collectées directement dans le WMI, les données sont recueillies à l'aide d'un fournisseur WMI. Un fournisseur WMI est un plug-in qui permet à une application ou un service d'entrer des informations directement dans le WMI. Ce fournisseur autorise l'accès dynamique à d'autres zones du WMI et du système, telles que le registre, les emplacements de fichier et les informations de Windows Installer.
Pour ce qui est des fichiers MOF, la manière la plus simple d'étendre l'inventaire logiciel est de le forcer à cataloguer plus d'informations que n'en possède déjà le WMI. Pour cela, vous devez étendre le sms_def.mot ou activer des classes de publication supplémentaires qui sont actuellement désactivées. Le fichier sms_def.mof se trouve dans le dossier \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv. Tous les périphériques de l'entreprise importeront le nouveau sms_def.mof dans leur cycle de stratégie d'ordinateur suivant et commenceront à collecter et à publier les informations.
L'étape suivante consiste à utiliser un fournisseur WMI existant, mais en créant une nouvelle classe. Un exemple de cette approche est affiché dans la figure 3. Dans cet exemple, à l'aide du fournisseur de registre intégré, la classe CU_Desktop est créée avec une propriété dynamique interrogeant HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper sur le périphérique local. Une fois ce fichier MOF compilé sur le client, les informations contenues dans SMS_Def_Extension.mof (voir la figure 4) doivent être ajoutées à sms_def.mof. Le fichier contient des informations concernant leur publication ou non par SMS, le nom du groupe, l'identificateur de classe, la classe que l'Agent d'inventaire matériel doit consulter dans le WMI pour trouver les informations à publier, en enfin les valeurs réelles.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
Les fichiers MOF ont également la possibilité d'accéder aux informations fournies par les fournisseurs WMI qui ne sont pas incluses par défaut sur les systèmes. Afin d'utiliser ces fournisseurs, le fournisseur WMI doit être tout d'abord distribué et installé avant que le fichier MOF ne soit compilé sur le client et que sms_def.mob ne soit étendu.

Conclusion
Les fichiers MIF et MOF sont des outils puissants servant à effectuer une collecte d'informations rapide et substantielle. Ces formats de fichier fournissent une infrastructure permettant d'entrer facilement des informations dans la base de données SMS sans modifier directement les tableaux. Avec un peu d'imagination, tout (ou presque tout) peut être inventorié et publié. Mieux encore, des situations problématiques peuvent être évitées, car les administrateurs peuvent agir de manière proactive pour rassembler des informations vitales.
Il faut du temps pour comprendre les fichiers MIF et MOF. Cependant, il existe des ressources très utiles qui peuvent vous aider à apprendre à utiliser ces fichiers. Pour commencer, consultez la Documentation sur le WMI et le SDK, ainsi que le Guide d'utilisation de Systems Management Server 2003. Si vous consacrez du temps à ces concepts, vous tirerez de gros avantages des inventaires SMS étendus.

Wes Dobry habite à Orlando (Floride) où il travaille comme consultant et administrateur réseau pour une grande entreprise de services médicaux. Contactez-le à l'adresse suivante : derekm@desktopstandard.com.


 Gestion: D&#233;ploiement de mises &#224; jour de logiciels personnalis&#233;es avec&#160;SMS&#160;2003&#160;R2
Gestion Steve Rachui

Déploiement de mises à jour de logiciels personnalisées avec SMS 2003 R2
Vue d'ensemble:
  • Nouvelles fonctionnalités de gestion des mises à jour dans SMS 2003 R2
  • L'outil de publication des mises à jour personnalisées
  • L'outil d'inventaire pour les mises à jour personnalisées

Lorsque vous avez besoin de déployer des mises à jour personnalisées pour vos systèmes, par exemple pour le matériel ou les applications métier, vous ne disposez pas des avantages d'un processus géré et automatisé comme c'est le cas pour les mises à jour de Windows. Du moins, ce n'était pas le cas avant. Maintenant, grâce à
Systems Management Server (SMS) 2003 R2, vous pouvez utiliser ces mêmes fonctionnalités de gestion de mise à jour pour déployer vos propres mises à jour personnalisées. SMS 2003 R2 inclut plusieurs nouvelles fonctionnalités, y compris une mise à jour du Pack de gestion des appareils, des liens vers le pack de Déploiement de système d'exploitation (OSD) ainsi qu'un certain nombre de fonctionnalités qui améliorent le contrôle de la sécurité. Le produit possède un outil d'analyse de vulnérabilité qui est indispensable si l'on veut comprendre les vulnérabilités potentielles du système et du réseau, telles que les vulnérabilités de la configuration du système d'exploitation, des mots de passe utilisateur ainsi que des configurations d'IIS et de SQL Server™. Il inclut également un outil d'inventaire pour les mises à jour personnalisées (ITCU) et un outil de publication des mises à jour personnalisées (CUPT). Dans cet article, je me concentrerai sur ces deux outils pour vous aider à déployer facilement et efficacement vos propres mises à jour personnalisées.

Outil de publication des mises à jour personnalisées
Avant de pouvoir installer et utiliser SMS 2003 R2, la hiérarchie (clients compris) doit être mise à jour vers SMS 2003 Service Pack 2 (SP2). Pour utiliser le CUPT, vous avez besoin de mettre la console MMC (Microsoft® Management Console) à niveau vers la version 3.0. Vous n'avez pas besoin d'installer CUPT sur le serveur de site SMS, mais il doit être installé au moins sur Windows® XP et il nécessite SQL Server 2005 pour héberger sa base de données. SQL Server Express Edition doit être installé si SQL Server 2005 n'est pas encore disponible. L'outil CUPT est essentiel pour l'application et la gestion des mises à jour personnalisées dans le système SMS, et il propose également des fonctionnalités pour tester des catalogues créés avant leur publication dans SMS.
Les mises à jour personnalisées peuvent prendre deux formes : des mises à jour qui sont fournies par les fournisseurs tiers pour le logiciel qu'ils produisent et les mises à jour créées en interne qui sont uniques à un environnement particulier. CUPT est l'outil à utiliser pour gérer ces deux types. Il est le plus facile d'utiliser des mises à jour personnalisées fournies par un tiers ; commençons donc avec ça. Au moment où je rédige ce document, trois entreprises sont en train de produire des catalogues de mise à jour qui peuvent être utilisés pour analyser et distribuer des correctifs appropriés dans SMS : Adobe, 1e et Citrix. Les entreprises participantes peuvent être affichées en sélectionnant les catalogues partenaires des mises à jour personnalisées, comme l'illustre la figure 1.
Figure 1 CUPT en action
Figure 1 CUPT en action (Cliquer sur l'image pour la réduire)
Figure 1 CUPT en action
Figure 1 CUPT en action (Cliquer sur l'image pour l'agrandir)
L'utilisation des mises à jour fournies par les partenaires consiste simplement à télécharger les catalogues et à les ajouter à SMS. Téléchargez d'abord les mises à jour dont avez besoin, puis choisissez l'option dans le menu Action pour importer les mises à jour. Un assistant vous demandera l'emplacement des fichiers .cab que vous venez de télécharger. Une fois l'assistant terminé, les nouvelles mises à jour seront visibles dans l'outil CUPT pour une plus ample configuration et publication sur le serveur de site SMS. Veuillez noter, toutefois, que chaque mise à jour nécessaire doit être marquée pour la publication. Si une mise à jour n'est pas marquée, elle ne sera pas incluse lorsque la requête de publication sera faite. Vous pouvez accomplir cette action en bloc, comme indiqué dans la figure 2. Notez que le marqueur de la colonne située tout à fait à droite doit être activé pour que la mise à jour soit publiée.
Figure 2 Configuration du marqueur de publication
Figure 2 Configuration du marqueur de publication (Cliquer sur l'image pour la réduire)
Figure 2 Configuration du marqueur de publication
Figure 2 Configuration du marqueur de publication (Cliquer sur l'image pour l'agrandir)
Au besoin, vous pouvez personnaliser davantage chaque mise à jour téléchargée. Pour ce faire, sélectionnez simplement la mise à jour et choisissez Modifier. Lors de la personnalisation d'une mise à jour, soyez cependant attentif, car une erreur de configuration peut provoquer des résultats imprévus et pas du tout satisfaisants.
Après avoir marqué les mises à jour, il est temps de les publier. Pour ce faire, vous pouvez soit les publier vers un fichier .cab externe pour une utilisation ultérieure soit synchroniser des mises à jour sélectionnées avec la base de données du site SMS pour une utilisation immédiate. Pour les synchroniser avec la base de données de données du site SMS, vous devez fournir des informations de configuration telles que le nom du serveur de site et le chemin de source du package (voir la figure 3).
Figure 3 Informations sur la synchronisation
Figure 3 Informations sur la synchronisation (Cliquer sur l'image pour la réduire)
Figure 3 Informations sur la synchronisation
Figure 3 Informations sur la synchronisation (Cliquer sur l'image pour l'agrandir)
Vous pouvez rechercher cet écran en surlignant le nœud des mises à jour personnalisées, puis en choisissant Paramètres dans le menu Action. Après que vous avez fourni le nom du serveur de site accessible et le chemin pointant à l'annuaire de source pour l'outil d'inventaire pour les mises à jour personnalisées, le code du site et son état seront mis à jour.
Une fois les options de synchronisation paramétrées, l'outil CUPT est prêt pour la synchronisation avec le serveur du site SMS. Pour exécuter la synchronisation, sélectionnez l'option de publication des mises à jour dans le menu Action. Cela ouvrira l'assistant de publication. Pour publier les mises à jour dans la base de données SMS en vue d'une utilisation immédiate, assurez-vous que l'option de synchronisation avec la base de données du site Systems Management Server est sélectionnée. Fort heureusement, cette étape offre une certaine assistance visuelle : cette option sera grisée si les paramètres de synchronisation n'ont pas été configurés.
Une fois l'assistant terminé, les mises à jour personnalisées sont disponibles dans la console d'administration de SMS. Démarrez l'Assistant Distribution de mises à jour logicielles pour obtenir une option permettant de travailler avec les mises à jour personnalisées disponibles.
Maintenant que nous avons vu la procédure liée à la consommation et l'utilisation de mises à jour produites par un fournisseur pour des logiciels tiers, qu'en est-il des mises à jour personnalisées pour les logiciels fournis par un fournisseur tiers lorsque les mises à jour pré-emballées ne sont pas disponibles ? C'est dans ce cas de figure que l'outil CUPT se distingue le plus. Avec CUPT, vous pouvez créer des mises à jour personnalisées avec des critères de ciblage complets vous permettant de couvrir presque toutes les situations.
La création d'une mise à jour personnalisée n'est pas difficile, mais elle nécessite que l'administrateur comprenne comment réparer le logiciel, quels critères utiliser pour déterminer si un correctif est applicable et quelles règles de ciblage doivent être utilisées pour concentrer la mise à jour. Les règles de ciblage sont définies séparément du processus de création d'une mise à jour. Elles peuvent être affichées en sélectionnant l'option Gérer les règles dans le menu Action.
Pour initialiser la création d'une mise à jour personnalisée, sélectionnez l'élément Créer une mise à jour dans le menu Action. Il ouvre un assistant dans lequel vous fournirez les détails de la mise à jour personnalisée. La présentation détaillée de la création d'une mise à jour personnalisée n'est pas l'objet de cet article, mais il est utile de sélectionner des propriétés sur l'une des mises à jour personnalisées importées d'un tiers pour comprendre ce qui est nécessaire dans chaque champ pour générer votre propre mise à jour. Les propriétés d'une mise à jour de tiers configurée sont illustrées dans la figure 4.
Figure 4 Propriétés d'une mise à jour de tiers
Figure 4 Propriétés d'une mise à jour de tiers (Cliquer sur l'image pour la réduire)
Figure 4 Propriétés d'une mise à jour de tiers
Figure 4 Propriétés d'une mise à jour de tiers (Cliquer sur l'image pour l'agrandir)
En utilisant le processus de création des mises à jour personnalisées, vous pouvez aller au-delà de la création de mises à jour et configurer le logiciel de sorte à ce qu'il soit distribué aux systèmes client. Bien qu'elle fonctionne, il est important de noter que cette approche n'est pas recommandée et ne doit pas être utilisée avec l'outil CUPT.

Outil d'inventaire pour les mises à jour personnalisées (ITCU)
L'ITCU est un nouvel outil d'inventaire qui fonctionne avec les catalogues de mise à jour personnalisés. Comme les outils d'analyse qui le précèdent, l'ITCU crée des collections personnalisées, des packages et des publications qui sont utilisés pour déployer les outils d'analyse aux clients SMS dans l'entreprise. Et comme les outils d'analyse qui le précèdent, I'TCU récupère le catalogue, dans notre cas le catalogue des mises à jour personnalisées, à partir d'un point de distribution SMS accessible, il exécute l'analyse basée sur les données du catalogue, insère ensuite les résultats de cette analyse dans Windows Management Instrumentation (WMI) et publie les résultats à l'aide de l'inventaire matériel. La différence principale dans le processus d'analyse est le catalogue utilisé.
La présentation de SMS 2003 R2 ajoute un outil puissant à l'arsenal de sécurité de SMS existant. C'est la première fois que les administrateurs peuvent tirer parti de l'infrastructure SMS existante pour réparer des applications tierces et personnalisées. SMS R2 est un ajout très apprécié par l'administrateur de gestion des correctifs.
Vous disposez donc maintenant de deux outils pour contrôler les mises à jour logicielles provenant de sources autres que Microsoft. Grâce à la simplicité de gestion et au confort proposés par les outils CUPT et ITCU, vos mises à jour personnalisées seront aussi fluides que les mises à jour de Windows que vous utilisez déjà.
Ressources de gestion des mises à jour
  • TechNet : Gestion des mises à jour
  • Webcast : IT's Showtime - SMS 2003 R2
  • Dix principes de gestion des correctifs Microsoft

Steve Rachui est ingénieur au service Manageability Support Escalation du groupe des services de support technique chez Microsoft. Il a pris en charge SMS depuis sa version 1.2. Vous pouvez contacter Steve à l'adresse suivante : steverac@microsoft.com.


 Le mot du r&#233;dacteur en chef: Nous avons peut-&#234;tre tort...
Le mot du rédacteur en chef
Nous avons peut-être tort...

L'UNE DES PRINCIPALES DIFFÉRENCES entre une version papier et Web, c'est qu'une fois que quelque chose est imprimé, il est imprimé pour toujours. Lorsque vous mettez des informations sur le Web et que vous avez besoin de les mettre à jour plus tard, il vous suffit de modifier ce qui doit être changé. Peu de gens se rendent compte de ces modifications.
Il en va tout autrement pour la version papier. Une fois que nous envoyons quelque chose à imprimer, nous ne pouvons plus faire demi-tour. Plus de cent mille exemplaires sont imprimés, et quel que soit leur contenu, ils resteront en kiosques jusqu'à la fin des temps (où jusqu'à l'arrivée de l'édition suivante). De plus, les magazines papier subissent une évolution naturelle d'un mois à l'autre : vous savez que le dernier numéro paru contient les dernières informations et les articles les plus récents.
En revanche, nous publions désormais notre magazine en ligne dans son intégralité une fois qu'il est paru en version papier, et cela crée un tout autre problème. Pour une personne effectuant une recherche en ligne, tous les contenus présents sur notre site Web apparaissent en même temps, sans distinction de date de parution. Comment savoir donc si vous avez sous les yeux les instructions les plus récentes ?
Pour résoudre ce problème, nous avons conçu, il y a quelques années, une stratégie de modifications unique qui bonifie nos versions papier grâce à une fonctionnalité de recherche en ligne. Dans la page des corrections de TechNet Magazine, vous avez accès aux informations concernant toutes les modifications post-publication effectuées sur nos articles. Nous indiquons une des cinq raisons qui justifient la mise à jour d'un article à jour : technique, éditoriale, nouvelles informations, péremption ou sécurité.
Par exemple, l'article « Techniques visant à simplifier la création d'image de bureau » que nous avons publié en mai 2006 mentionnait un outil appelé CNIC qui n'était pas encore disponible. Lorsque le CNIC est sorti, nous avons ajouté une mise à jour dans les Pages de correction, ainsi qu'une mise à jour du rédacteur en chef de l'article publié en ligne. En cliquant sur le lien de la mise à jour du rédacteur en chef, vous accédez directement aux nouvelles informations.
Comme vous le voyez, même si chaque numéro de la version papier de TechNet Magazine est remplacé par un nouveau numéro chaque mois, notre politique de corrections nous aide à assurer la pertinence de nos articles malgré les dernières évolutions. -JOSHUA TRUPIN

Remerciements aux experts techniques Microsoft suivants : Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher et Alan von Weltin.


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

Synchronisation de fichiers et dossiers
Allway Sync
allwaysync.com

Quelle que soit la branche de l'informatique dans laquelle vous travaillez, il y a de fortes chances pour que vous passiez beaucoup de temps à déplacer des fichiers et dossiers d'un endroit à un autre, que ce soit de votre ordinateur à une clé USB ou d'un serveur à un autre sur le réseau. Il est souvent important de garder ces dossiers synchronisés pour vous assurer que vous ne créez pas de doublons inutiles et que vous disposez de la dernière version des fichiers. Il se peut que vous ayez parfois besoin de synchroniser des fichiers et des dossiers dans une multitude de machines, comme lors du déploiement de fichiers XML ou HTML statiques dans un groupe de serveurs Web. Allway Sync, un outil développé par Usov Lab, vous aidera à contrôler ce genre de tâches.
Allway Sync vous propose une vraie synchronisation multidirectionnelle, d'une réplication unidirectionnelle de fichiers ou dossier à une option multi-répertoires bidirectionnelle. L'application vous permet de conserver la synchronisation de vos lecteurs locaux et de vos ressources réseau, tout en prenant en charge la synchronisation automatique vers des périphériques amovibles tels que les clés USB et les lecteurs optiques réinscriptibles. Il est possible de configurer Allway Sync de sorte à ce qu'il se lance automatiquement lorsque le périphérique est connecté à votre machine.
Parmi les autres options de mise en route automatique de la synchronisation, nous citerons le démarrage lorsque des modifications de fichier sont détectées, lorsque vous vous connectez ou déconnectez, lorsque Allway Sync est lancé ou à des intervalles de temps spécifiés. Vous pouvez même lier la synchronisation à une tâche planifiée à l'aide de la GUI de l'application.
Synchronisation de fichiers et dossiers avec Allway Sync
Synchronisation de fichiers et dossiers avec Allway Sync (Cliquer sur l'image pour la réduire)
Synchronisation de fichiers et dossiers avec Allway Sync
Synchronisation de fichiers et dossiers avec Allway Sync (Cliquer sur l'image pour l'agrandir)
Toutes les modifications et suppressions de fichiers font l'objet d'un suivi dans la base de données locale de l'application, et Allway Sync propose de nombreuses options pour la gestion des versions des fichiers modifiés et la suppression des fichiers en conflit, dont la suppression permanente d'éléments ou leur déplacement vers la Corbeille ou vers un dossier spécifié.
Pour chaque tâche, vous pouvez spécifier plusieurs filtres d'inclusion ou d'exclusion pour obtenir uniquement les fichiers dont vous avez besoin. Vous pouvez personnaliser les mesures que doit prendre Allway Sync lorsqu'il rencontre des avertissements ou des erreurs et configurer une action différente pour chaque type d'avertissement ou d'erreur. Par exemple, vous pouvez choisir d'effectuer automatiquement un nouvel essai de copie en cas d'erreur, et vous pouvez configurer non seulement le nombre de nouvelles tentatives automatiques, mais également le délai entre les tentatives pour tenir compte des problèmes de temps de réponse du réseau ou de connectivité à court terme.
Vous pouvez configurer les commentaires de la fonction d'enregistrement de l'application pour vous assurer que vous recevez le maximum d'informations sur vos tâches. Les paramètres de l'application peuvent être importés et exportés en XML : il est donc facile de les sauvegarder ou de les transférer à un autre ordinateur. L'application fournit également une fonction amusante pour les curieux : une fenêtre de statistiques facile à utiliser (accessible à l'aide du menu Aide). Cet outil pratique vous permet de synchroniser vos fichiers en un clin d'œil.
Prix : Gratuit pour un usage privé. 29,99 $ pour un usage commercial.

Mappage et contrôle de votre réseau
LANState Pro
10-strike.com/lanstate

L'accès rapide à l'état et à la disponibilité des ressources de votre réseau est vital pour un environnement d'exploitation informatique dynamique. Lorsqu'un problème se présente, vous devez être le premier à le savoir. Grâce au logiciel de mappage et contrôle de réseau LANState Pro de 10-Strike Software, vous aurez accès à une visualisation rapide et à ses capacités de gestion LAN pour les réseaux basés sur Windows®.
Lorsque vous lancez l'application de contrôle sur votre réseau, vous pouvez choisir l'Assistant de mappage de réseau qui vous autorise à analyser votre Voisinage réseau ou une plage d'adresses IP pour les hôtes applicables. Si vous préférez, vous pouvez ajouter vos hôtes manuellement. Une fois votre mappage de réseau créé, LANState commence automatiquement les vérifications d'état que vous avez configurées, comme par exemple la vérification du port TCP ou de la commande ping ICMP. Les hôtes sensibles sont classés par couleur, alors que les hôtes qui ne répondent pas sont grisés. Vous pouvez ensuite arranger votre mappage en groupes logiques appropriés à votre configuration et modifier tous les éléments visuels, ajouter des descriptions, etc.
Création de groupes logiques de réseau avec LANState Pro
Création de groupes logiques de réseau avec LANState Pro (Cliquer sur l'image pour la réduire)
Création de groupes logiques de réseau avec LANState Pro
Création de groupes logiques de réseau avec LANState Pro (Cliquer sur l'image pour l'agrandir)
Les outils de dessin et de modification sont un peu compliqués, mais une fois votre mappage terminé, vous pouvez l'enregistrer dans un fichier et vous n'aurez pas à le recréer. Au-delà de la vérification de port TCP ou de ping ICMP, vous pouvez configurer le LANState Pro de sorte à ce qu'il vérifie l'existence d'un dossier ou d'un fichier, la taille d'un fichier ou la quantité d'espace disque libre sur un hôte distant à un intervalle et à un délai d'expiration configurables. En cliquant avec le bouton droit sur un hôte, vous affichez un menu contextuel qui vous permet de glaner plus d'informations système de l'hôte distant, d'effectuer un itinéraire de suivi, d'envoyer un ping, d'effectuer une vérification par défaut ou d'envoyer un message réseau.
Les informations système concernent les adresses de couche MAC, les adresses IP liées, les partages réseau, les services, les comptes locaux, etc. La plupart des informations liées au système d'exploitation nécessitent des autorisations et ouvrent des ports sur le système distant, mais vous pouvez obtenir un certain nombre de données par des appels RPC. Et, si vous avez ces autorisations, vous pouvez également envoyer des signaux d'allumage et d'arrêt aux hôtes distants.
Prix : 249,95 $ pour une licence utilisateur unique.

Script par ligne de commande
Critique
www.syngress.com

Les assistants interactifs et les GUI de configuration peuvent vraiment simplifier les tâches complexes. Mais lorsque vous êtes un informaticien professionnel, ces interfaces peuvent vous ralentir et elles ne fournissent pas toujours suffisamment de granularité ou de contrôle pour une tâche donnée. Fort heureusement, ce niveau de contrôle est presque toujours disponible à l'aide de l'interface de ligne de commande (CLI). En apprenant à connaître les outils inclus avec Windows et à personnaliser l'invite de commande pour rationnaliser les tâches administratives, vous pourrez gagner du temps, augmenter votre efficacité et proposer un contrôle plus précis. Le livre de Pawan K. Bhardwaj How to Cheat at Windows System Administration Using Command Line Scripts (publié en 2006 chez Syngress Publishing) peut vous aider à maîtriser les utilitaires CLI et du système d'exploitation.
Ce livre vous introduit à la personnalisation de la commande d'environnement, en utilisant des fichiers de commandes pour le traitement automatique et par lots, ainsi que pour l'administration CLI des tâches planifiées. Le livre vous présente ensuite les utilitaires inclus dans le système d'exploitation de Windows qui vous aident à gérer les disques, les fichiers, et les dossiers. Vous obtenez également un aperçu général des commandes du Services d'annuaire, telles que DSQuery et DSMod, qui, grâce aux compétences de traitement par lots que vous avez développées dans les chapitres précédents, peuvent vous faire gagner beaucoup de temps lors de la gestion de grandes structures de répertoire.
Vous apprenez également à connaître les commandes de la Gestion de réseau Windows qui sont à votre disposition, de Netstat à Pathping, et vous obtenez un aperçu général des outils de connexion à distance tels que TFTP, RSH, et RCP. En combinant ces outils avec les compétences que vous avez acquises au premier chapitre du livre, sur l'automatisation et les tâches planifiées, vous améliorerez sans aucun doute votre productivité. Bien qu'il n'aborde pas tous les utilitaires de Windows, ce livre de Bhardwaj devrait trouver sa place sur votre étagère de référence.
Prix : 39,95 $ (vente directe).

Test de fiabilité du matériel
BurnInTest
passmark.com/products/bit.htm

Si vous participez à la production de PC personnalisés, à la mise à jour de composants matériels pour votre base de clients ou à la construction d'une nouvelle plate-forme de bureau méga admin, vous devez absolument vous assurer que les nouveaux composants fonctionneront de façon fiable avant de les livrer à vos utilisateurs. C'est ce que le logiciel BurnInTest de PassMark peut faire pour vous en exécutant un certain nombre de tests de stress sur des composants que vous indiquez, afin de vous assurer qu'ils n'échoueront pas à la livraison.
Comme dans tous les tests du logiciel BurnIn, l'application essaie « d'exercer » le matériel, en appliquant une tension sur des composants système sélectionnés dans le but de simuler un long cycle d'activité dans un cours lapse de temps. L'idée est de découvrir toutes les erreurs cachées avant qu'un système ou périphérique ne soit mis en service. BurnInTest vous permet de tout tester, des processeurs à la mémoire des cartes graphiques, en passant par les disques durs et les graveurs de CD.
L'application est très facile à utiliser et configurer, et vous permet par exemple de modifier les cycles de travail et les préférences pour chaque test de composant dans une configuration particulière. Une fois vous avez paramétré votre configuration de test, vous pouvez enregistrer vos préférences, ce qui accélèrera tout test que vous pourriez éventuellement effectuer quelques mois plus tard.
Chaque test a un cycle de travail configurable : vous pouvez donc déterminer une valeur de charge comprise entre 1 et 100 pour chaque composant testé. Par exemple, vous pouvez tester les opérations de calcul du processeur à une charge de 75 %, tout en testant simultanément la mémoire système à une charge de 90 %. Vous pouvez également demander à BurnInTest de s'arrêter au bout d'un nombre de minutes ou de cycles de travail déterminé.
L'application vous permet de tester jusqu'à 20 disques durs, lecteurs de disquettes ou lecteurs optiques simultanément. Vous pouvez donc effectuer un test par lots avant de les distribuer dans votre environnement client. Vous gagnez ainsi beaucoup de temps lors de la mise à niveau d'un composant système, puisque vous pouvez tester chaque nouveau composant immédiatement sans avoir à tester chaque système séparément. Ce que j'aime dans ce programme, c'est qu'il propose une vérification de paramètres SMART.
La version Professional Edition prend en charge une variété de tests de bouclage pour les ports USB 2.0, parallèle et série. (Les périphériques de bouclage de matériel sont disponibles à l'achat chez PassMark). Cette version de BurnInTest peut être exécutée à partir d'un CD ou d'une clé USB, ce qui augmente la crédibilité des tests exécutés, tout en réduisant l'impact de l'application sur le système testé.
Prix : 49 $ pour la version Professional Edition ; 24 $ pour la version Standard Edition.

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.


 Forum aux questions SQL: Reconstruction d'index, longueur de mise en attente du disque, etc.
Forum aux questions SQL
Reconstruction d'index, longueur de mise en attente du disque, etc.
Par Nancy Michell

Q : Comment les index de SQL Server sont-ils reconstruits ? Je voudrais savoir pourquoi DBCC DBREINDEX consomme tout mon espace disque et pourquoi l'espace n'est pas libéré lorsque la commande échoue. La taille de ma base de données est de 90 Go et la plus grande table fait 70 Go.
Lorsque j'exécute DBCC DBREINDEX, en laissant 10 % d'espace libre, il consomme tout l'espace disque disponible et la commande échoue. Au départ, le fichier de base de données fait 90 Go, mais lorsque la commande DBCC échoue, il atteint 160 Go, et ces 70 Go supplémentaires ne sont jamais libérés : je dois rétrécir manuellement la base de données à plusieurs reprises pour la récupérer.
Lorsque la commande fonctionne, la taille du fichier de base de données est également de 160 Go, mais l'espace est automatiquement libéré quelques heures plus tard par réduction automatique. Serait-il acceptable d'effectuer une défragmentation plutôt qu'un DBREINDEX pour consommer moins d'espace ? Je n'ai pas d'index en cluster, et j'utilise le mode de récupération simple.
R : Au niveau le plus simple, vous reconstruisez les index en créant une nouvelle copie de l'index et en supprimant ensuite l'ancien index. Cela signifie que, pendant une courte période, il existe deux copies de l'index. La construction du nouvel index peut nécessiter autant d'espace de fichier de base de données que l'index original, et si la reconstruction exige une opération de tri, il vous faut 20 % de la taille de l'index en plus pour le tri.
Donc, dans le pire des cas, la reconstruction d'un index peut nécessiter jusqu'à 1,2 fois l'espace de l'ancien index. Si le fichier de base de données ne dispose pas de suffisamment d'espace, il devra grandir au cours de l'opération. Si la fonction de croissance automatique n'est pas activée, ou s'il n'y a pas assez d'espace libre sur le volume de disque, il est possible que l'espace disponible soit insuffisant et que l'opération de reconstruction échoue.
Que l'opération échoue ou non, l'espace disque supplémentaire alloué au fichier de base de données n'est pas libéré une fois l'opération de reconstruction terminée. L'hypothèse est que l'espace sera utilisé pour les opérations régulières de base de données.
L'exécution d'une réduction (que ce soit manuellement ou automatiquement) garantit pratiquement la fragmentation de l'index, en raison de la façon dont l'algorithme fonctionne. Pour plus de détails, voir le Moteur de stockage de SQL Server. La réduction automatique peut être particulièrement nuisible aux performances si la base de données a besoin de l'espace libre pour des opérations régulières, parce qu'il est possible qu'elle crée un cycle croissance automatique-réduction automatique-croissance automatique-réduction automatique qui peut faire des ravages sur la fragmentation et les performances.
L'utilisation de DBCC INDEXDEFRAG (ou ALTER INDEX ... REORGANIZE dans SQL Server™ 2005) a l'avantage de ne presque pas utiliser d'espace de fichier de base de données supplémentaire, mais cette opération peut être plus longue et risque de générer beaucoup plus d'enregistrements de transactions qu'une reconstruction d'index. DBCC INDEXDEFRAG est toujours entièrement enregistré, quel que soit le mode de récupération utilisé, tandis que dans le mode de récupération simple, une reconstruction d'index est enregistrée en bloc. Il existe de nombreux avantages et inconvénients pour chacune de ces deux méthodes ; ils sont expliqués plus en détails dans le livre blanc sur les méthodes recommandées pour la défragmentation d'index sous SQL Server.
Avant de prendre une décision sur la méthode de correction de la fragmentation, commencez par vous demander si vous souhaitez vraiment corriger la fragmentation. Selon le type d'opérations pour lesquelles l'index est utilisé, il se peut que la fragmentation n'ait aucun effet sur les performances, et sa correction pourrait constituer une perte de ressources. Le Livre blanc est très détaillé.
Conclusion : veillez à choisir la méthode de fragmentation la plus appropriée à votre environnement et à augmenter les performances des requêtes en effectuant une défragmentation.

Q : J'ai réussi à configurer la mise en miroir d'une base de données entre deux instances de SQL Server 2005. Mon application se connecte à SQL Server en utilisant une ouverture d'une session SQL Server, et elle est générée en utilisant ADO et le client natif de SQL. Ma chaîne de connexion et mes paramètres de connexion indiquent les bonnes informations, y compris le partenaire de basculement approprié. J'ai également créé sur le serveur miroir toutes les ouvertures de session présentes sur le serveur principal. Lors d'un test d'échec de la base de données, le miroir prend en charge le rôle principal avec succès et tout semble correct sur l'instance de SQL Server. (Je peux même me connecter au miroir en utilisant mon ouverture de session Windows®). Cependant, la reconnexion de l'application échoue avec l'erreur suivante :
Cannot open database "<db name>" requested by the login. The login failed.
Il semble que la connexion n'est pas associée à un utilisateur dans la nouvelle base de données (qui était au départ le miroir). J'exécute la commande sp_change_users_login pour synchroniser les utilisateurs et les sessions pour la base de données, et j'obtiens un message disant qu'elle a réparé de multiples utilisateurs orphelins. Mon application se reconnecte ensuite au nouveau serveur principal. J'ai essayé de nombreux basculements, et je vois à chaque fois le même problème : l'association entre la session et l'utilisateur se perd.
Existe-t-il une façon de paramétrer la configuration du miroir pour que éviter ce problème ?
R : Oui. Le problème vient du fait qu'il n'existe pas de correspondance entre les identificateurs de sécurité (les SID) pour les logins SQL Server sur chaque serveur, même si les logins possèdent le même nom. Ce problème ne concerne pas les logins utilisateur/groupe de Windows/domaine, parce que leurs SID sont créés en fonction du SID de domaine de chaque utilisateur/groupe, et ils sont donc identiques pour un utilisateur/groupe donné, quel que soit le serveur SQL auquel l'utilisateur ou le groupe est ajouté.
Pour pouvoir vous passer de l'étape de synchronisation sp_change_users_login, vous devez créer les logins SQL Server sur le serveur miroir avec non seulement le même nom, mais également le même SID que sur le serveur principal. Pour ce faire, utilisez la spécification SID dans la déclaration CREATE LOGIN, lors de la création des logins sur le serveur miroir, comme suit :
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
Vous pouvez récupérer le SID de chaque login du serveur principal en interrogeant le catalogue sys.sql_logins. La figure 1 illustre un exemple de requête qui produira une vraie déclaration CREATE LOGIN pour chaque login SQL Server/Windows sur un serveur donné.
Figure 1 Générer une déclaration CREATE LOGIN (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

Q : Quelle doit être la longueur moyenne de la file d'attente de mon disque ? Par exemple, si j'ai 20 piles physiques de disques séparées provenant d'un réseau de stockage (SAN) avec une configuration RAID 01, comment est-ce que je calcule la longueur moyenne de la file d'attente du disque ? Est-ce Longueur moyenne de la file d'attente du disque/20 ou Longueur moyenne de la file d'attente du disque/2 ?
R : Avant tout, vous devriez consulter la latence du disque avant de perdre du temps sur la longueur moyenne de la file d'attente du disque dans un environnement SAN. Mais cela dépend vraiment de ce que vous recherchez. Vous verrez pourquoi dans un moment.
L'explication de ce compteur (de Perfmon) est : « La longueur moyenne de la file d'attente du disque est le nombre moyen de requêtes, à la fois de lecture et d'écriture, qui ont été mises en attente pour le disque sélectionné pendant l'intervalle considéré. » Il s'agit d'un compteur de disque physique ou d'un compteur de disque logique ; donc le nombre que vous obtenez dépend de la présentation du stockage sous-jacent au système d'exploitation.
Penchons-nous sur votre cas. Vous avez 20 piles de disques dans une configuration RAID 01, ce qui signifie qu'ils sont agrégés par bande et mis en miroir (ou mis en miroir et agrégés par bande selon la façon dont vous lisez 01 ou 10). Le point important concernant votre tableau de stockage est qu'il y a 10 piles dans le jeu d'agrégats par bandes.
Mais il me manque des informations essentielles, comme la taille de l'agrégat par bande et de vos écritures, ainsi que le genre d'E/S que vous émettez (lecture, écriture, séquentielle ou aléatoire).
En ignorant les informations manquantes pour le moment, si la Longueur moyenne de la file d'attente du disque renvoie 10, c'est que le système d'exploitation a mis 10 E/S en attente dans le tableau du disque. Théoriquement, cela pourrait être une E/S pour chaque 10 jeux mis en miroir dans l'agrégat par bande, tout comme cela pourrait être 10 E/S pour un seul disque. Il est impossible de le savoir.
C'est là que les informations manquantes entrent en ligne de compte. Supposons que la taille de votre agrégat est 64 Ko, que votre taille d'écriture est 8 Ko, et vous vous apprêtez à faire un gros morceau d'écritures séquentielles. C'est un scénario typique pour l'activité de stockage de SQL Server. Dans ce cas, il y a de bonnes chances que 8 des E/S soient toutes allées au premier disque, et que les 2 E/S suivantes soient allées au disque suivant. Donc, si vous essayez de déterminer la longueur de file d'attente du disque par disque dans ce scénario, le résultat est 8 pour le premier disque, 2 pour le deuxième disque et 0 pour les huit autres disques dans le tableau.
Modifions maintenant ce scénario, avec une taille théorique de 8 Ko pour l'agrégat, et une taille d'écriture de bloc de 64 Ko, tout en conservant une longueur de file d'attente de disque de 10. Dans ce cas, chaque bloc de 64 Ko est réparti sur 8 disques, donc une E/S est écrite sur 8 disques et les 10 E/S mises en file d'attente sont réparties sur 80 écritures de disque, sur l'ensemble des 10 disques dans le tableau. Si vous essayez de calculer la longueur de file d'attente du disque par disque dans le tableau, elle sera de 8.
Soyons réalistes et ajoutons un autre niveau d'incertitude. Dans la plupart des cas, votre stockage SAN sera connecté au serveur utilisant un ou plusieurs HBA dans le serveur, un certain nombre de fibres pour relier le HBA au SAN, un certain nombre de ports sur la face avant du SAN, et peut-être un commutateur de fibre dans la structure entre le serveur et le SAN. Il nous faut alors nous pencher sur l'architecture interne des bus dans le SAN, et sur la façon dont les disques sont connectés aux ports sur le devant du SAN.
Toute file d'attente qui apparaît dans Perfmon peut être un symptôme de latence élevée, ou d'une mise en file d'attente à l'un de ces points situés entre l'emplacement de la mesure de la file d'attente par le système d'exploitation et la surface des disques. C'est pourquoi vous devriez examiner la latence et baser vos décisions sur ce compteur, plutôt que sur la longueur moyenne de file d'attente du disque.

Q : J'utilise la réplication transactionnelle, et je sais que beaucoup de lignes ont été modifiées manuellement dans un tableau au niveau de l'abonné. J'obtiens donc des erreurs lorsque l'éditeur tente de mettre à jour une ligne qui n'existe plus dans l'abonné.
J'ai besoin de savoir s'il existe une façon, grâce à la réplication, de réinitialiser simplement ce tableau unique à partir de l'éditeur, au lieu d'appliquer une nouvelle fois un instantané tout entier. J'ai examiné la fonction tablediff qui semble pouvoir faire tout ce que je veux, mais je me demande comment elle interagit avec la réplication.
Par exemple, est-ce que tablediff prend un instantané du tableau de l'éditeur et le compare à l'équivalent de l'abonnement ? Ai-je besoin d'arrêter la réplication pour utiliser l'utilitaire tablediff et assurer la cohérence des données ? Il y a-t-il autre chose que je dois savoir ?
R : Tout d'abord, tablediff ne prend pas un instantané au sens littérale, ni du tableau de l'éditeur ni de celui de l'abonné. En ce qui concerne votre scénario, il y a quelques options que vous pourriez considérer.
La première est un arrêt temporaire de la réplication et l'exécution de l'utilitaire. Si vous êtes inquiet des tentatives de modification des données par des utilisateurs, vous pouvez utiliser les paramètres -sourcelocked et -destinationlocked, qui effectueront un verrouillage exclusif des deux tableaux pendant l'exécution de l'utilitaire. Si ce n'est pas possible, vous pourriez également consulter les paramètres -rc et -ri tout en laissant la réplication s'exécuter. Cela exécutera tablediff une fois, puis le lancera sur les erreurs qu'il détecte, en éliminant les erreurs qui pourraient être provoquées par des retards de propagation de réplication. Mais attention : avec cette option, selon votre retard de réplication, il est possible que vous ne trouviez pas toutes les lignes modifiées sur l'abonné.

Merci aux informaticiens Microsoft ci-dessous pour l'apport de leur expertise technique : Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe et Steven Wort.


 Coup de projecteur sur les utilitaires: Autoruns
Coup de projecteur sur les utilitaires
Autoruns
Lance Whitney
Télécharger le code de cet article: Autoruns (490KB)

Un ordinateur typique fonctionnant sous Windows® charge un grand nombre d'éléments au démarrage, y compris des fichiers, des pilotes, des tâches et des services. À un certain moment, il est tout à fait probable que vous ayez besoin d'afficher et peut-être de désactiver certains éléments du démarrage, pour régler un conflit de démarrage, dépister les logiciels malveillants dans la séquence de démarrage automatique, réduire le temps de lancement de Windows ou dégager de la mémoire et des ressources système.
L'utilitaire de configuration de système (msconfig.exe) vous permet d'afficher et de désactiver un certain nombre de fichiers et services de démarrage, mais il y en a beaucoup qu'il n'examine pas : les barres d'outils, les objets de l'assistant du navigateur ou encore les extensions de noyau d'explorateur Windows. De plus, msconfig ne communique pas beaucoup de détails sur ces éléments. Pour voir et gérer tout se qui charge au démarrage, il existe une meilleure solution : le programme Autoruns de Sysinternals.
Écrit par Mark Russinovich et Bryce Cogswell, Autoruns est un utilitaire gratuit qui dévoile chaque élément du démarrage (également appelé image) sur ordinateur fonctionnant sous Windows. Vous pouvez afficher toutes les images enregistrées dans les dossiers de démarrage, dans le registre et dans les autres zones où ils aiment se cacher (voir la figure 1).
Figure 1 Affichage des éléments de démarrage avec Autoruns
Figure 1 Affichage des éléments de démarrage avec Autoruns (Cliquer sur l'image pour la réduire)
Figure 1 Affichage des éléments de démarrage avec Autoruns
Figure 1 Affichage des éléments de démarrage avec Autoruns (Cliquer sur l'image pour l'agrandir)
Autoruns vous indique le nom et l'emplacement de chaque image. Pour les fichiers, il affiche le chemin d'accès, et pour les entrées de registre, vous obtenez la clé exacte. Autoruns fournit également le nom de l'éditeur et une brève description basée les données de la version de l'élément. Double-cliquez sur une entrée pour vous rendre directement à son répertoire ou à sa clé de registre. Cliquez avec le bouton droit pour ouvrir une fenêtre contextuelle comportant d'autres d'options, dont une commande Properties qui affiche une fenêtre File Properties contenant toutes les informations sur sa version. Une option « Include Empty Locations » affiche toutes les zones de démarrage de l'ordinateur, qu'elles hébergent ou non des entrées à l'heure actuelle. Vous pouvez sélectionner également d'autres comptes utilisateur sur l'ordinateur pour voir leurs environnements de démarrage.
Vous pouvez vérifier la signature numérique d'une entrée avec la commande Verify qui interroge des sites Web avec les listes de révocation de certificats (CRL) pour déterminer si une image est signée numériquement et si la signature est valide. Une autre option, « Hide Signed Microsoft Entries », exclut les entrées déjà signées par Microsoft, ce qui vous permet de vous concentrer sur les images de tiers.
La liste entière des éléments de démarrage peut être exportée vers un fichier texte, ce qui est pratique si vous voulez désactiver un élément et que vous avez besoin d'un instantané de votre environnement de démarrage avant d'y faire des tests. Vous pouvez ensuite comparer le fichier texte exporté avec votre configuration de démarrage révisée pour voir vos modifications.
Voici une partie des catégories de démarrage qu'Autoruns couvre :
Ouverture de session inclut l'utilisateur et tous dossiers démarrage des utilisateurs, ainsi que les clés d'exécution trouvées dans le registre.
Explorateur inclut une liste d'extensions de noyau d'Explorer, les barres d'outils et les exécutions d'installation actives.
Internet Explorer inclut des Objets de l'assistant du navigateur ainsi que les barres d'outils et les extensions d'Internet Explorer®.
Fournisseurs LSA incluent l'authentification de l'autorité de sécurité locale, la notification et les packages de sécurité.
Dans Autoruns, vous pouvez supprimer de façon permanente un élément de démarrage ou simplement le désactiver. Une option Online Search (Recherche en ligne) vous aide à trouver les éléments que vous pouvez désactiver en toute sécurité. Cette option exécute une recherche sur Internet pour les pages Web qui décrivent un élément ou sa catégorie et vous conseille de le supprimer ou non du démarrage. Lorsque vous désactivez un élément, Autoruns le transfère à un emplacement de sauvegarde dans le Registre ou sur le disque dur.
Autoruns fonctionne sous toutes les versions de Windows, y compris les éditions 64 bits de Windows XP et de Windows Server® 2003. Téléchargez le logiciel à l'adresse microsoft.com/technet/technetmag/code07.aspx.

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


 Le petit c&#226;bleur: Param&#232;tres de strat&#233;gies de groupe sans fil pour Windows Vista
Le petit câbleur
Paramètres de stratégies de groupe sans fil pour Windows Vista
Joseph Davies
Cet article contient des informations de version bêta liées à Windows Server « Longhorn » et susceptibles d'être modifiées.

En tant qu'administrateur, votre tâche serait probablement un peu plus facile si vous pouviez configurer et distribuer de façon centralisée les paramètres de réseau sans fil à tous les ordinateurs dans votre réseau Active Directory réseau. Fort heureusement, Windows prend en charge une extension spéciale de stratégie de groupe pour la configuration de l'ordinateur qui vous permet d'accomplit cette tâche. Il s'agit
de l'extension des Stratégies de réseau sans fil (IEEE 802.11), prise en charge par les ordinateurs exécutant Windows Vista™, Windows® XP, Windows Server® 2003, ainsi que la prochaine version de Windows Server, baptisée « Longhorn ».
Voici comment elle fonctionne. En rejoignant le domaine ou au démarrage (et sur une base continue après cela), ces systèmes d'exploitation téléchargent automatiquement les paramètres sans fil dans cette extension de stratégie de groupe et les appliquent. Vous pouvez configurer des stratégies sans fil pour un objet de stratégie de groupe basée sur un domaine à partir du nœud suivant dans le composant logiciel enfichable de l'éditeur d'objet de stratégie de groupe : Configuration de l'ordinateur | Paramètres Windows | Paramètres de Sécurité | Stratégies de réseau sans fil (IEEE 802.11).
La figure 1 indique l'emplacement du nœud des stratégies de réseau sans fil (IEEE 802.11) d'un domaine de nœud de Stratégies pour un domaine de Windows Server baptisé « Longhorn » ou pour un domaine de Windows Server 2003 dont le schéma a été étendu à l'aide des fichiers d'extension de schéma 802.11Schema.ldf et 802.3Schema.ldf (décrits dans microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Figure 1 Nœud de stratégies de réseau sans fil (IEEE 802.11)
Figure 1 Nœud de stratégies de réseau sans fil (IEEE 802.11) (Cliquer sur l'image pour la réduire)
Figure 1 Nœud de stratégies de réseau sans fil (IEEE 802.11)
Figure 1 Nœud de stratégies de réseau sans fil (IEEE 802.11) (Cliquer sur l'image pour l'agrandir)
Par défaut, il n'existe pas de stratégie de réseau sans fil (IEEE 802.11). Pour créer une nouvelle stratégie, cliquez avec le bouton droit sur Stratégies de réseau sans fil (IEEE 802.11) dans l'arborescence de la console, puis cliquez sur Créer une nouvelle stratégie Windows XP ou sur Créer une nouvelle stratégie Windows Vista. Pour chaque type de stratégie, vous ne pouvez créer qu'une seule stratégie, mais chaque stratégie peut contenir des paramètres pour plusieurs réseaux sans fil.
Pour la stratégie Windows XP, les paramètres de stratégie sont très similaires à ceux décrits dans mon article de juillet 2003. Cependant, il existe de nouvelles options pour les réseaux sans fil de non-diffusion, des méthodes d'authentification pour Wi-Fi Protected Access 2 (WPA2) et des paramètres itinérants rapides pour l'authentification de WPA2. Pour prendre en charge ces nouveaux paramètres, les ordinateurs exécutant Windows XP Service Pack 2 (SP2) doivent installer la mise à jour client sans fil pour Windows XP SP2 disponible sur support.microsoft.com/kb/917021.
La stratégie sans fil Windows Vista contient des paramètres de stratégie spécifiques aux clients sans fil de Windows Vista et Windows Server « Longhorn ». Si les deux types de stratégies sans fil sont configurés, les clients de Windows XP sans fil utiliseront seulement leurs propres paramètres de stratégie et les clients sans fil de Windows Vista utiliseront seulement leurs propres paramètres de stratégie. S'il n'y a pas de paramètre de stratégie Windows Vista, les clients sans fil de Windows Vista utiliseront les paramètres de Windows XP. Cet article décrit les paramètres qui peuvent être configurés avec la stratégie sans fil Windows Vista.
Dans l'onglet Général d'une stratégie de réseau sans fil Windows Vista, vous pouvez configurer un nom et une description pour la stratégie, spécifier si le service de configuration automatique WLAN est activé et configurer la liste de profils du réseau sans fil et leurs paramètres dans l'ordre de préférence (voir la figure 2). Vous pouvez également exporter un profil sous un fichier XML en sélectionnant le profil et en cliquant sur Exporter. Pour importer un fichier XML en tant que profil sans fil, cliquez sur Importer et indiquez l'emplacement du fichier.
Figure 2 Propriétés de la stratégie de réseau sans fil
Figure 2 Propriétés de la stratégie de réseau sans fil (Cliquer sur l'image pour la réduire)
Figure 2 Propriétés de la stratégie de réseau sans fil
Figure 2 Propriétés de la stratégie de réseau sans fil (Cliquer sur l'image pour l'agrandir)
La figure 3 illustre l'onglet Autorisations réseau pour une stratégie de réseau sans fil Windows Vista, avec ses paramètres par défaut. Cet onglet est nouveau pour Windows Vista, et il vous permet d'indiquer des réseaux sans fil par leur nom, ainsi que de leur autoriser ou refuser l'accès. Par exemple, vous pouvez créer une liste de permissions contenant le nom de réseaux sans fil, également appelés SSID (Service Set Identifiers), auxquels un client sans fil Windows Vista est autorisé à se connecter. Ceci est utile pour les administrateurs réseau qui souhaitent connecter un ordinateur portable de l'entreprise à un ensemble de réseaux sans fil qui peut inclure le réseau sans fil de l'entreprise et les fournisseurs d'accès Internet.
Figure 3 Onglet Autorisations réseau
Figure 3 Onglet Autorisations réseau (Cliquer sur l'image pour la réduire)
Figure 3 Onglet Autorisations réseau
Figure 3 Onglet Autorisations réseau (Cliquer sur l'image pour l'agrandir)
La liste des noms refusés permet d'indiquer, par leur nom, l'ensemble des réseaux sans fil auxquels le client sans fil n'a pas le droit de se connecter. Il est ainsi possible d'empêcher des ordinateurs portables gérés de se connecter à d'autres réseaux sans fil accessibles (par exemple, lorsque une entreprise occupe un étage d'un bâtiment et qu'il existe des réseaux sans fil d'autres entreprises aux étages voisins). Vous pouvez également empêcher des ordinateurs portables gérés de se connecter aux réseaux sans fil non sécurisés connus à l'aide d'une liste de noms refusés. Pour créer l'une ou l'autre de ces listes ou indiquer les réseaux sans fil individuels auxquels vous voulez accorder ou refuser l'accès, cliquez sur Ajouter pour ajouter un réseau sans fil par son nom et spécifier s'il est autorisé ou refusé.
Sur l'onglet Autorisations réseau figurent également des paramètres pour empêcher des connexions aux réseaux sans fil de mode ad hoc ou d'infrastructure. Vous pouvez aussi permettre aux utilisateurs d'afficher les réseaux sans fil configurés comme refusés et permettre à chaque utilisateur de créer un profil entièrement utilisateur. Un tel profil peut être utilisé pour se connecter à un réseau sans fil spécifique par n'importe quel utilisateur possédant un compte sur l'ordinateur. Si ce paramètre est désactivé, seuls les utilisateurs des groupes Administrateurs réseau ou Opérateurs réseau pourront créer des profils sans fil utilisateur sur l'ordinateur.

Propriétés du profil réseau sans fil
Pour gérer un profil réseau sans fil à partir de l'onglet Général de la stratégie sans fil Windows Vista, sélectionnez un profil existant et cliquez sur Modifier ou cliquez sur Ajouter puis indiquez si le nouveau profil sans fil est pour un réseau sans fil de mode ad hoc ou d'infrastructure.
Pour créer un nouveau profil sans fil, commencez par ouvrir l'onglet Connexion, puis nommez le profil et créez une liste de noms de réseaux sans fil auxquels il s'applique (voir la figure 4). Vous pouvez ajouter de nouveaux noms en les entrant dans les SSID et en cliquant sur Ajouter. Vous pouvez également spécifier si le client sans fil utilisant ce profil tentera automatiquement de se connecter aux réseaux sans fil nommés dans le profil lorsque ces réseaux sont accessibles (selon l'ordre de préférence de la liste des profils sans fil dans l'onglet Général de la stratégie Windows Vista). De plus, vous pouvez indiquer si l'ordinateur doit se déconnecter automatiquement de ce réseau sans fil si un réseau sans fil supérieur dans l'ordre de préférence devient accessible, et spécifier que les réseaux sans fil dans ce profil sont des réseaux de non-diffusion (également appelés réseaux masqués).
Figure 4 Onglet Connexion
Figure 4 Onglet Connexion (Cliquer sur l'image pour la réduire)
Figure 4 Onglet Connexion
Figure 4 Onglet Connexion (Cliquer sur l'image pour l'agrandir)
A partir de l'onglet Sécurité, affiché dans la figure 5, vous pouvez configurer les méthodes d'authentification et de chiffrage pour les réseaux sans fil dans le profil. Le choix des méthodes de chiffrage dépend du choix de votre méthode d'authentification. Les choix pour chaque méthode sont listés dans la figure 6.
Figure 6 Méthodes de sécurité (Close Figure 6)

Méthodes d'authentification
Ouvrir
Partagé
WPA (Wi-Fi Protected Access)-Personal
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Ouvrir avec 802,1X
Méthodes de chiffrage
Wired Equivalent Privacy (WEP)
Temporal Key Integrity Protocol (TKIP)
Advanced Encryption Standard (AES)
Figure 5 Onglet Sécurité
Figure 5 Onglet Sécurité (Cliquer sur l'image pour la réduire)
Figure 5 Onglet Sécurité
Figure 5 Onglet Sécurité (Cliquer sur l'image pour l'agrandir)
Si vous décidez de sélectionner WPA-Enterprise, WPA2-Enterprise, ou Ouvrir avec 802.1X comme méthode d'authentification, vous pouvez également configurer la méthode d'authentification du réseau (le type d'EAP [Extensible Authentication Protocol]), le mode d'authentification (la ré-authentification de l'utilisateur, l'authentification de l'ordinateur, l'authentification de l'utilisateur ou l'authentification d'invité), ainsi que le nombre d'échecs de tentatives d'authentification avant que l'authentification ne soit abandonnée et si les données utilisateur doivent être mises en cache pour les connexions ultérieures. Ce dernier paramètre indique que lorsque l'utilisateur ferme la session, les informations d'identification de l'utilisateur sont supprimées du registre. Donc, lors de la prochaine ouverture de session, l'utilisateur sera invité à saisir ses informations d'authentification (telles que son nom d'utilisateur et son mot de passe).
Pour configurer les paramètres de sécurité avancée des méthodes d'authentification WPA-ENTREPRISE, WPA2-Enterprise ou Ouvrir avec 802.1X, cliquez sur Avancé. La figure 7 affiche la boîte de dialogue des paramètres de sécurité avancée par défaut.
Figure 7 Boîte de dialogue des paramètres de sécurité avancée
Figure 7 Boîte de dialogue des paramètres de sécurité avancée (Cliquer sur l'image pour la réduire)
Figure 7 Boîte de dialogue des paramètres de sécurité avancée
Figure 7 Boîte de dialogue des paramètres de sécurité avancée (Cliquer sur l'image pour l'agrandir)
Dans la section IEEE 802.1X, vous pouvez spécifier le nombre de messages d'EAP sur LAN (EAPOL)-Start successifs envoyés sans réponse aux messages EAPOL-Start reçus, ainsi que l'intervalle temporel entre les retransmissions de messages EAPOL-Start lorsqu'aucune réponse n'a été reçue pour le dernier message EAPOL-Start reçu. Vous pouvez aussi déterminer la période pour laquelle le client qui s'authentifie n'exécutera pas d'authentification 802.1X après avoir reçu une indication d'échec d'authentification de l'authentificateur, et l'intervalle d'attente du client pour retransmettre des requêtes 802.1X après l'initialisation de l'authentification 802.1X de bout en bout.
L'authentification unique (SSO) vous permet de configurer l'authentification 802.1X par rapport à l'ouverture de session utilisateur et d'intégrer des informations d'ouverture de session utilisateur et d'authentification 802.1X sur le serveur d'ouverture de session de Windows. Dans la section SSO, il existe des paramètres permettant d'exécuter l'authentification sans fil immédiatement avant ou après le processus d'ouverture de session utilisateur, et pour spécifier le délai de la connectivité en secondes qui précède le démarrage du processus. Vous pouvez également indiquer s'il faut ou non inviter l'utilisateur à remplir des champs d'entrée supplémentaires, si la méthode d'authentification le nécessite, la durée de l'affichage de ces champs et si les réseaux sans fil pour ce profil utilisent un LAN virtuel (VLAN) différent pour l'authentification de l'ordinateur et de l'utilisateur.
Dans la section Itinérance rapide, vous pouvez configurer la mise en cache de la clé PMK (Pariwise Master Key) et les options de pré-authentification. La section Itinérance rapide apparaît seulement lorsque vous sélectionnez WPA2-Enterprise comme méthode d'authentification. Avec la mise en cache de la clé PMK, les clients sans fil et les points d'accès sans fil (AP) mettent en cache les résultats des authentifications 802.1X. L'accès est donc beaucoup plus rapide lorsqu'un client sans fil fait un retour itinérant à un AP sans fil auquel il s'est déjà authentifié. Vous pouvez configurer un temps maximal de conservation des entrées dans le cache de PMK et le nombre maximal d'entrées. Avec la pré-authentification, un client sans fil peut exécuter une authentification 802.1X avec d'autres AP sans fil accessibles pendant qu'il est toujours connecté à son AP sans fil actuel. Si le client sans fil passe à un AP sans fil avec lequel il a été pré-authentifié, le temps d'accès est substantiellement réduit. Vous pouvez configurer le nombre maximal de tentatives de pré-authentification avec un AP sans fil.
Pour plus d'informations sur la prise en charge sans fil dans Windows, voir microsoft.com/wifi. Pour plus d'informations sur la stratégie de groupe Windows, voir les ressources sur microsoft.com/gp.

Joseph Davies est 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 on lui doit la chronique en ligne mensuelle Le petit câbleur de TechNet.


 Windows PowerShell: Filtrage et formatage de donn&#233;es
Windows PowerShell
Filtrage et formatage de données
Don Jones

Il ne fait pas de doute que Windows PowerShell peur retourner un grand nombre d'informations intéressantes, et ce sans trop d'efforts de votre part. Par exemple, considérez le simple cmdlet Get-WMIObject, qui peut être utilisé pour retourner une liste de services sur l'ordinateur local. L'affichage par défaut, qui liste l'état, le nom et le mode de démarrage des
services s'exécutant, est essentiellement un affichage de lignes de commande de la console de Services. Windows PowerShell™ vous permet d'y accéder plus facilement.
Mais il existe beaucoup plus d'informations disponibles pour les services que celles qui sont indiquées dans l'affichage par défaut. Essayez cette commande :
$s = get-wmiobject win32_service
$s[0] | gm
La première ligne de la commande retourne une collection de tous les services (ou, plus précisément, de toutes les instances de la classe Win32_Service de WMI classe de Windows® Management Instrumentation, ou WMI), et les enregistrent dans la variable $s. La deuxième ligne prend le premier service dans cette collection (le zéro de numéro ordinal, indiqué dans les crochets) et le transmet au cmdlet Get-Member, que j'ai abrégé en utilisant son alias, gm. Le résultat affiche toutes les propriétés et les méthodes disponibles pour ce type de données. J'ai décidé d'utiliser la classe Win32_Service dans WMI, au lieu du cmdlet Get-Service intégré à Windows PowerShell, parce que WMI révèle en fait plus d'informations que l'objet Service-Controller de Microsoft®.NET, y compris la propriété StartName. Cette propriété m'indique le nom du compte utilisateur sous lequel le service est exécuté. Vous pouvez vérifier le nom d'une instance unique, telle que la première, comme suit :
PS C:\> $s[0].StartName
LocalSystem
Cependant, il n'est pas très utile de se référer aux services par leur ordinal dans la collection, puisque les services n'apparaissent pas dans un ordre particulier. (Ils sont d'habitude listés par ordre alphabétique, mais pas toujours.) Du point de vue de la gestion, vous serez probablement plus intéressé par une liste de tous services, ainsi que le compte que chaque service utilise pour se connecter. Ce serait pratique pour un audit de conformité, par exemple. Donc faisons une pause pour regarder ce que WMI propose par défaut. J'utiliserai l'alias de Get-WMIObject, gwmi (voir la figure 1).
Figure 1 Utilisation de gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
C'est évidemment juste un exemple, mais vous pouvez voir que le résultat n'est pas remarquable pour un rapport de gestion. Ce que je cherche, c'est le nom du service et le StartName, qui est le compte sur lequel le service s'exécute. J'aimerais également que le rapport s'affiche dans un format plus clair, au lieu de cette liste difficile à lire. C'est là où les géniaux cmdlets de formatage et de filtrage de données de Windows PowerShell entrent en jeu.

Obtention des données dont vous avez besoin
Je commence par filtrer les données de Get-WMIObject pour que les propriétés qui m'intéressent s'affichent. La meilleure façon de le faire, c'est d'utiliser le cmdlet Select-Object de Windows PowerShell ou son alias abrégé, select. Select est conçu pour accepter une collection d'objets, comme la collection renvoyée par Get-WMIObject, et afficher uniquement les propriétés désirées de ces objets. Cela signifie que je peux canaliser la production de gwmi pour sélectionner et spécifier les deux propriétés qui m'intéressent. La figure 2 indique les résultats, qui incluent les propriétés Name et StartName bien formatées sous forme de tableau.
Figure 2 Affichage uniquement des propriétés Name et StartName dans un tableau
Figure 2 Affichage uniquement des propriétés Name et StartName dans un tableau (Cliquer sur l'image pour la réduire)
Figure 2 Affichage uniquement des propriétés Name et StartName dans un tableau
Figure 2 Affichage uniquement des propriétés Name et StartName dans un tableau (Cliquer sur l'image pour l'agrandir)
Toutefois, si je produisais ce rapport pour un audit de conformité, il contiendrait vraiment trop d'informations. Certains des services sont désactivés : il est probable qu'une personne lisant ces résultats ne s'intéresserait pas au compte que les services désactivés utiliseraient théoriquement. Ainsi, j'aimerais éliminer tous services qui ont un type de démarrage de Disabled, la propriété StartMode de la classe Win32_Service.
Windows PowerShell exécute un filtrage d'objets en utilisant le cmdlet Where-Object, ou son alias abrégé, where. Le cmdlet where accepte une collection d'objets d'entrée et les passe chacun dans un scriptblock pour déterminer si chaque objet sera présent dans la production du cmdlet, en se basant sur une série de critères définis. Chaque objet qui répond aux critères produit une comparaison True, et il est inclus dans la production ; les objets qui produisent une valeur False sont exclus.
J'ai donc décidé qu'il me fallait uniquement les objets dont la propriété StartMode est égale à Disabled. Sous Windows PowerShell, cette évaluation ressemble à ceci :
$object.StartMode –eq “Disabled”
Bien sûr, $object n'est qu'un exemple. Je n'écris pas vraiment un script, donc je n'ai pas de variable appelée $object. Dans le scriptblock utilisé par where, cependant, je peux utiliser une variable spéciale nommée $_, qui représente l'objet en cours d'évaluation par le cmdlet. Donc mon scriptblock de where pourrait avoir l'air de ceci :
$_.StartMode –eq “Disabled”
Il m'est assez facile de le tester :
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Bien sûr, dans ce test rapide, la production est présentée dans le style de liste par défaut. Et, pour gagner de l'espace, j'y ai inclus un seul service. Mais vous remarquerez que ce résultat est à l'envers. J'ai inclus les services désactivés, au lieu de les exclure. C'est parce que je me suis trompé de sens dans mon scriptblock : je dois inclure tous les services dont le StartMode est différent de Disabled, comme indiqué par cette modification à mon exemple :
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
C'est mieux ! Maintenant que la production contient seulement les services qui m'intéressent, je peux de nouveau canaliser la production pour sélectionner et spécifier uniquement les propriétés que je veux :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
Cette canalisation des données d'un cmdlet à un autre, puis encore à un autre, sert juste à illustrer les capacités de Windows PowerShell. Je n'ai toujours pas écrit de script, mais j'ai réussi à filtrer un grand ensemble de données pour obtenir uniquement la production que je voulais.

La bonne présentation
N'oubliez pas que la production de select consiste toujours en un paquet d'objets. Lorsque je récupère un tableau bien formaté en utilisant Windows PowerShell, il s'agit simplement de l'interprétation faite par PowerShell.exe de ces objets. En d'autres termes, Windows PowerShell sait que, en pauvre humain, je ne peux pas voir les objets, donc il les affiche sous la forme de texte. Dans ce cas, il a affiché les objets sous la forme d'un tableau, avec une colonne pour chaque propriété, comme illustré dans la figure 2.
Ce sera peut-être suffisant pour mon objectif d'audit. Ou peut-être pas, après tout ! Tout le monde a des besoins différents et Windows PowerShell ne prétend pas savoir quels sont vos besoins spécifiques. Au lieu de cela, il vous fournit les outils qui vous serviront à formater la sortie à votre guise. Quatre cmdlets incorporés (Format-List, Format-Custom, Format-Table et Format-Wide) sont conçus pour accepter une collection d'objets (comme la collection renvoyée par select) et formater ces objets de diverses façons. Format-Table est en fait ce qu'utilise déjà Windows PowerShell pour formater la production de mon cmdlet select. Pour une présentation différente, essayons Format-List :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
Le résultat ressemble un peu à cet exemple :
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Le cmdlet Format-Large est conçu pour produire par défaut une liste à plusieurs colonnes de la première propriété de chaque objet. Prenez cette ligne, par exemple :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Il produit une liste de noms de service, mais ce n'est pas ce que je veux. Il manque le StartName dans le résultat (voir la figure 3), alors que c'est une information importante dont j'ai besoin pour mon rapport d'audit.
Figure 3 Le résultat affiché à l'aide du cmdlet Format-Wide n'inclut pas une information clé : le StartName.
Figure 3 Le résultat affiché à l'aide du cmdlet Format-Wide n'inclut pas une information clé : le StartName. (Cliquer sur l'image pour la réduire)
Figure 3 Le résultat affiché à l'aide du cmdlet Format-Wide n'inclut pas une information clé : le StartName.
Figure 3 Le résultat affiché à l'aide du cmdlet Format-Wide n'inclut pas une information clé : le StartName. (Cliquer sur l'image pour l'agrandir)
Puisque je m'occupe seulement de deux propriétés, il est probable que Format-Table ou Format-List soient acceptables. Mais il est peu probable qu'un auditeur soit content de lire ces informations sur l'écran. Il préférerait probablement un fichier.

Exportation des données
Alors, sous quelle forme un auditeur souhaiterait-il voir les données ? Il suffirait probablement d'exporter la liste des services et des identifiants de connexion vers un fichier CSV (valeurs séparées par une virgule), car ce fichier pourrait ensuite être ouvert dans Microsoft Excel®. Pour créer un fichier CSV, canalisez simplement votre sortie vers le cmdlet Export-CSV de Windows PowerShell :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Bien sûr, un fichier CSV semble un peu démodé, de nos jours. Peut-être que vos auditeurs préféreraient que les données soient affichées sous la forme d'une page Web sur un serveur intranet. Pour ce faire, commencez par convertir la production en HTML, en utilisant le cmdlet ConvertTo-HTML :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
Le HTML brut est difficile à lire : il vous faudra donc écrire la sortie dans un fichier :
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
Le résultat, illustré dans la figure 4, est une page HTML bien formatée qui peut être publiée sur n'importe quel serveur Web sans modification supplémentaire.
Figure 4 Production affichée sous la forme d'une page HTML bien formatée
Figure 4 Production affichée sous la forme d'une page HTML bien formatée (Cliquer sur l'image pour la réduire)
Figure 4 Production affichée sous la forme d'une page HTML bien formatée
Figure 4 Production affichée sous la forme d'une page HTML bien formatée (Cliquer sur l'image pour l'agrandir)

Les faits, rien que les faits (pertinents)
Windows PowerShell vous fournit un accès rapide à une grande plage de données de gestion. Cependant, ces données dans leur état brut ne sont pas toujours utiles pour une utilisation professionnelle.
En filtrant les données (à l'aide de where), en choisissant les propriétés d'objet désirées (à l'aide de select) et en appliquant une option de formatage appropriée (comme Format-Table ou Format-List), vous pouvez transformer rapidement ces données de gestion en informations utiles avec très peu d'efforts. Et ensuite, en exportant les données dans un format de fichier pouvant être facilement partagé, vous pouvez transmettre ces informations au-delà de votre propre ordinateur et communiquer de précieuses informations aux autres employés de votre entreprise.

Don Jones est directeur des projets et services de SAPIEN Technologies et co-auteur de Windows PowerShell : TFM (SAPIEN Press). Pour contacter Don, rendez-vous sur son site Web à l'adresse suivante : www.ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: Approche na&#239;ve des utilisateurs et groupes locaux
Hé, vous le scripteur !
Approche naïve des utilisateurs et groupes locaux
Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_04.exe (151KB)

Comment gérer des descripteurs de sécurité sur les fichiers et les dossiers ?

Croyez-le si vous voulez , il fut un temps (il y a longtemps, bien sûr) où les scripteurs n'étaient pas si intelligents que ça. Nous savons que c'est dur à croire, mais£comment ça, ce n’est pas difficile à croire ? Et qu'est-ce que vous voulez dire par « c'était pas il y a si longtemps que ça » ? Vous avez dû voir l'un des scripteurs essayer de brancher une télévision l'autre jour.
En fait, ce scripteur pourrait de défendre en affirmant que brancher une nouvelle TV, ce n'est pas de la physique quantique : c'est pire que de la physique quantique. Juste pour brancher la télé, il faut trois câbles vidéo et deux câbles audio, et il vous faut rajouter un magnétoscope, un lecteur de DVD et une Xbox®, et je ne parle même pas du fait d'appuyer sur un nombre aléatoire de boutons sur la télécommande dite « universelle » pour essayer de lui faire reconnaître tous ces appareils. En comparaison, placer un satellite en orbite autour de Mars, c'est du gâteau.
Chose incroyable, le scripteur a fini par réussir à tout brancher correctement. Mais lorsqu'il a tout allumé, rien ne s'est produit. Consciencieux qu'il était, il a vérifié deux fois, puis trois fois tous les branchements. Il a lu toutes les notices, et il est même allé vérifier sur le Web s'il ne manquait pas d'informations. Mais rien. Il était prêt à sacrifier un lecteur MP3 au nom du dieu de l'électronique, lorsqu'il a remarqué qu'il avait oublié une étape clé : brancher le câble d'alimentation de la TV à la prise murale.
Remarque : Vous pensez peut-être que s'il est si difficile de brancher tous les appareils de la famille du scripteur, c'est peut-être parce que la famille du scripteur a trop d'appareils. En fait, le scripteur serait d'accord avec vous. Mais à chaque fois que la famille vote sur l'acquisition d'autres d'appareils, le scripteur perde toujours 2-0 au vote. Et non, il ne perd pas 2-1, c'est bien 2-0. Pour une raison obscure, le vote du Papa scripteur n'a jamais l'air de compter dans le vote familial, et il n'existe pas d'archives papier.
En réponse à votre question suivante, oui, il a essayé. Mais jusqu'ici, les Nations-Unies ont refusé d'envoyer des observateurs à la maison du scripteur pour superviser le vote.
Bien sûr, maintenant que nous y réfléchissons, ce n'est pas tant que les scripteurs (enfin, surtout celui de la TV) sont stupides : c'est juste qu'ils sont naïfs. Par exemple, lorsqu'ils préparaient le Guide du script pour Microsoft® Windows® 2000, ils ont sollicité l'aide de plusieurs..., hum, experts...au moment où il fallait finaliser les chapitres du livre. L'un des chapitres qui ont été coupés au montage était celui qui concernait la gestion des utilisateurs et groupes locaux. « Gestion des utilisateurs et des groupes locaux ? !? », ont déclaré les experts. « Je comprends pas qu'on ait pu considérer ça ! Ça intéresse qui, la gestion des utilisateurs et groupes locaux ? »
Eh bien, à notre grand regret, nous avons découvert depuis que tout le monde (à l'exception peut-être de nos « experts » internes) s'intéressait aux utilisateurs et groupes locaux. Nous recevons chaque semaine des tonnes de messages électroniques de personnes qui nous demandent, par exemple, comment faire pour ajouter un utilisateur à un groupe local, supprimer un utilisateur d'un groupe local ou modifier le mot de passe de l'administrateur local sur un ordinateur.
Bien sûr, le Référentiel de scripts du Script Center propose certains modèles de script qui indiquent comment effectuer ces actions, mais la plupart de ces scripts ne fonctionnent que sur un ordinateur à la fois. Ça ne suffit pas, c'est clair : les gens veulent savoir comment le faire sur plusieurs machines, et sur toutes les machines en même temps. Modifier le mot de passe de l'administrateur local sur un seul ordinateur ? Revenez sur Terre, les scripteurs : on veut le faire sur tous nos ordinateurs, ou sur tous les ordinateurs d'une UO, ou sur tous les serveurs de messagerie électronique, ou sur... Enfin, vous avez compris.
Vu que le Guide du script a été publié en 2003, cela veut dire que ça fait pratiquement quatre ans que nous sommes assiégés par ces messages électroniques. « Voici un autre lecteur qui demande comment il peut lire des noms d'ordinateur sur un tableur Excel®, puis changer le mot de passe l'administrateur local sur chacun de ces ordinateurs », remarquait récemment l'un des scripteurs. « Mais que peut-on bien faire à ce sujet ? »
Bon, ça nous a pris quatre ans, mais on a fini par trouver. La figure 1 indique exactement ce que nous pouvons faire.
Figure 1 Nous avons enfin trouvé (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Remarque : Comme vous le voyez, l'écriture de ce script ne nous a pas pris quatre ans parce que c'était difficile : ça nous a pris quatre ans parce que c'est globalement le temps qu'il nous faut pour faire quoi que ce soit. C'est pour ça qu'il ne faut jamais manquer une fête du Jour de l'An des scripteurs : on ne sait jamais quand aura lieu la prochaine fête annuelle, ni s'il y en aura une.
Le résultat, c'est un script qui prend le nom de tous les ordinateurs à partir d'un tableur, puis modifie le mot de passe de l'administrateur local sur chacune de ces machines. Pour ce petit tour de magie, nous commençons tranquillement, en supposant que vous avez un petit tableur très simple, qui ressemble à quelque chose comme la figure 2. (Si ce n'est pas le cas, créez-en un maintenant).
Figure 2 Liste obligatoire des ordinateurs
Figure 2 Liste obligatoire des ordinateurs (Cliquer sur l'image pour la réduire)
Figure 2 Liste obligatoire des ordinateurs
Figure 2 Liste obligatoire des ordinateurs (Cliquer sur l'image pour l'agrandir)
Comme vous pouvez voir, il n'y a rien de spécial ici. Dans la colonne 1 (la colonne A), nous énumérons le nom de tous les ordinateurs qui ont un mot de passe que nous devons modifier. Dans la colonne 2 (la colonne B), nous prenons simplement note de la date et de l'heure de la dernière modification du mot de passe de l'administrateur sur chaque ordinateur. Ça facilite le suivi pour savoir si vos mots de passe administrateur sont tous synchronisés.
Quant au script lui-même, nous commençons par l'instruction On Error Resume Next. D'habitude, on ne s'embête pas avec la gestion des erreurs dans nos scripts. Ce n'est pas parce que nous sommes opposés à la gestion des erreurs, mais plutôt parce que nous essayons de garder nos scripts aussi courts et faciles à suivre que possible. Dans ce cas, cependant, la déclaration On Error Resume Next est cruciale. Après tout, notre script va essayer de se connecter à un grand nombre d'ordinateurs différents. Qu'est-ce qui se passe si l'un de ces ordinateurs est éteint ? Eh bien, avec la gestion des erreurs, rien ne se passe. Alors, bien sûr, une erreur se produira, mais le script pourra l'ignorer et continuer son travail. Sans la gestion des erreurs, vous obtiendriez probablement la même chose que notre scripteur quand il a allumé sa télé pour la première fois : rien.
Ensuite, nous utilisons le bloc de code suivant pour créer une instance de l'objet Excel.Application, faire apparaître cette instance d'Excel à l'écran et ouvrir le tableur C:\Scripts\Test.xls :
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
Dernière étape, mais pas des moindres : nous attribuons la valeur 2 à une variable de compteur nommée i. Nous utiliserons cette variable pour faire un suivi de notre colonne actuelle dans le tableur.
Remarque : Alors pourquoi est-ce qu'on attribue une valeur de 2 à i ? Rien de plus simple : Si vous regardez le tableur de près, vous verrez que nos données commencent en fait à la ligne 2. La ligne 1 est simplement une ligne d'en-tête.
Vous voyez ? Nous ne sommes peut-être pas très bons dans le branchement de prises péritel, mais, en script, on s'y connaît.
Enfin, parfois.
Nous sommes maintenant prêts à commencer le travail. Tout d'abord, nous paramétrons une boucle Do Until qui fonctionnera jusqu'à ce que le script rencontre une cellule vide dans la colonne 1. Et oui, ça veut dire que vous ne devez absolument pas laisser de ligne vide dans la colonne 1. Si votre script rencontre une ligne vide, il supposera qu'il a atteint la fin des données, et la boucle (donc le script) s'arrêtera. Et s'il existe des façons de contourner ce problème, il est beaucoup plus simple d'éviter d'avoir des lignes vierges dans votre tableur.
À l'intérieur de la boucle, nous commençons en attribuant la valeur recherchée dans la cellule de la ligne i et de la colonne 1 à une variable nommée strComputer. (Rappelez-vous que la première fois qu'il passe dans la boucle, i est égal à 2 ; donc nous allons travailler avec la valeur contenue dans la cellule de la ligne 2, colonne 1.) Nous utilisons ensuite cette ligne de code pour créer une référence objet (objUser) au compte de l'administrateur local sur l'ordinateur représenté par la variable strComputer :
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
Si une erreur se produit dans le script, c'est ici que ça sautera. Supposons par exemple qu'il y ait des problèmes de réseau, que l'ordinateur est éteint, ou que l'un des scripteurs ait mal branché son lecteur de DVD, provoquant un black-out dans tout l'Ouest des États-Unis. Si l'un de ces évènements se produisait, il serait impossible de se connecter à l'ordinateur en question. C'est pourquoi on vérifie tout de suite la valeur de l'objet Err de VBScript :
If Err = 0 Then
Si l'objet Err est égal à 0, c'est que nous avons réussi à nous connecter à l'ordinateur (et au compte de l'administrateur) sans aucun problème. Si Err a une autre valeur que 0, cela ne peut vouloir dire qu'une seule chose : notre tentative de connexion a échoué. Dans ce cas, nous n'allons même pas essayer de modifier le mot de passe sur cet ordinateur. Il va sans dire que si nous ne pouvons pas nous y connecter, nous ne pourrons pas modifier le mot de passe.
En supposant que tout se passe bien et qu'aucune erreur ne se produise, nous exécutons ensuite les deux lignes de code suivantes :
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
Dans la ligne 1, nous utilisons la méthode SetPassword pour attribuer un nouveau mot de passe (egTY634!alK2) au compte de l'administrateur local. (Et oui, on le sait : on n’est pas censé utiliser le nom de son enfant comme un mot de passe). Dans la ligne 2, nous écrivons ensuite la date et l'heure actuelles (en utilisant la fonction VBScript Now) dans la cellule de la ligne i, colonne 2. Notez que nous ne mettons à jour la colonne Password Changed (mot de passe modifié) que si nous avons réussi à nous connecter à l'ordinateur distant et à modifier le mot de passe. Si nous ne parvenons pas à nous connecter à un ordinateur, son champ Password Changed ne sera jamais mis à jour ; c'est comme ça que nous pourrons faire la distinction entre les opérations qui ont réussi et celles qui ont échoué.
Qu’est-ce que ça signifie ? Ça veut dire que, pour le premier passage dans la boucle, notre tableur ressemblera à la figure 3.
Figure 3 Liste des ordinateurs après la réinitialisation du premier mot de passe
Figure 3 Liste des ordinateurs après la réinitialisation du premier mot de passe (Cliquer sur l'image pour la réduire)
Figure 3 Liste des ordinateurs après la réinitialisation du premier mot de passe
Figure 3 Liste des ordinateurs après la réinitialisation du premier mot de passe (Cliquer sur l'image pour l'agrandir)
Voilà, c'est fait pour l'ordinateur 1. Maintenant, il nous faut faire un peu de ménage avant de continuer :
Err.Clear
i = i + 1
Ces lignes de code ont beau être courtes, elles n'en sont pas moins très importantes. (Comme si les scripteurs écrivaient des lignes de code superflues !) La première ligne réinitialise l'objet Err à 0. Si aucune erreur ne s'est produite, c'est redondant : dans ce cas, Err est déjà égal à 0. Mais si une erreur s'est produite, la valeur de Err sera différente de 0. Dans ce cas, il est crucial que nous réinitialisions manuellement l'objet Err. Pourquoi ? Parce que c'est l'objet Erreur : il prend seulement note des erreurs, pas des succès. Prenons un exemple : un problème survient avec l'ordinateur 1 et nous ne parvenons pas à nous connecter. Disons, à titre d'exemple, que ce problème a eu pour conséquence de régler l'objet Err sur 99.
Imaginons maintenant que nous passions à la boucle suivante et que nous réussissions à nous connecter à l'ordinateur 2. A ce moment-là, quelle sera la valeur de Err ? Bingo. Err sera toujours égale à 99, que ça vous plaise ou non, parce que la valeur de l'objet Err n'est modifié que si une erreur se produit. Mais si aucune erreur ne survient, l'objet Err restera indéfiniment à sa valeur actuelle.
Et c'est important ? Eh bien oui. Car, techniquement, nous ne modifions pas le mot de passe sur un ordinateur si nous réussissons à nous connecter : en fait, nous modifions le mot de passe seulement si Err est égal à 0. Et (une seconde, on ouvre la Calculatrice) oui, nous avions raison : 99 n'est pas égal à 0 (sauf, bien sûr, dans les votes de la famille du scripteur, où 99 votes de Papa scripteur comptent pour 0). Et c'est important pour nous parce que, même si nous avons réussi à nous connecter à l'ordinateur 2, Err n'est pas égal à 0. Et puisque Err n'est pas égal à 0, nous n'essayons même pas de modifier le mot de passe de l'administrateur local.
En d'autres termes, si la valeur de Err ne change jamais, vous devrez réinitialiser cette valeur à 0 ; autrement, à partir de ce moment-là, votre script croira qu'une erreur est survenue. Et comment réinitialise-t-on la valeur de l'objet Err à 0 ? Vous l'avez deviné : avec une simple invocation de Err.Clear.
Ensuite, nous incrémentons la valeur de i par 1. Pourquoi ? Eh bien, la première fois qu'elle passe dans la boucle, la variable i était égale à 2 ; c'est parce que nous voulions nous connecter à l'ordinateur listé à la ligne 2, colonne 1. La deuxième fois qu'elle passe dans la boucle, nous voulons nous connecter à l'ordinateur listé à la ligne 3, colonne 1. Comme i est la variable qui indique la ligne avec laquelle nous voulons travailler, nous devons faire en sorte que i soit égale à 3. Et, comme tout le monde sait, 2 + 1 = 3. (Heureusement qu'on n'avait pas fermé la Calculatrice, hein ?) C'est seulement à ce moment-là que nous ferons une nouvelle boucle et que nous répéterons le processus avec l'ordinateur suivant dans le tableur.
Maintenant, c'est sympa, mais comme nous ne sommes plus aussi naïfs que nous l'étions, nous sommes bien conscients que ce script, à lui seul, ne fera pas grand chose pour le problème évoqué dans le message électronique que nous avons reçu. « Bon, c'était bien sympa votre truc avec Excel », dira-t-on, « mais j'ai toujours besoin de modifier le mot de passe de l'administrateur local pour tous les ordinateurs dans une UO, ou pour tous les ordinateurs listés dans un fichier texte. Ou peut-être que j'aimerais pouvoir ouvrir un menu contextuel avec la liste des ordinateurs et pouvoir en sélectionner un à partir d'une zone de liste. Ou peut-être que j'aimerais aussi... »
On se calme. Les scripteurs sont là pour exaucer vos vœux. (En supposant que vous vouliez bien attendre quatre ans...) Il se trouve que nous avons de multiples modèles informatiques publiés sur le Script Center qui permettent d'exécuter facilement un script sur plusieurs machines. Par exemple, supposons que vous vouliez modifier le mot de passe de l'administrateur local pour tous les ordinateurs dans une UO. Aucun problème. Le modèle pour exécuter un script sur tous les ordinateurs d'une UO ressemble à la figure 4.
Figure 4 Exécution d'un script sur une UO (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
Vous voyez la section dans le modèle appelée « Insert your code here » ? Tout ce que vous avez à faire, c'est supprimer l'exemple de code de cette section et le remplacer par le code servant à modifier le mot de passe de l'administrateur local (que vous pouvez copier à partir de cet article). En d'autres termes, remplacez l'exemple de code par le code suivant :
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
Cet exemple particulier n'enregistrera pas les résultats pour vous, mais vous pouvez facilement ajouter ce code tout seul. Remplacez l'exemple de code, modifiez la chaîne de connexion LDAP://OU=Finance,dc=fabrikam,dc=com pour qu'elle pointe à l'une de vos UO, et c'est parti.
Pour tout vous dire, en fait nous avons publié ces modèles il y a plus d'un an, en pensant qu'ils feraient partie des éléments qui rencontreraient le plus grand succès parmi tous ceux que nous avons mis sur le Script Center. Nous avions tort : ils ne sont jamais utilisés, même si on nous écrit presque tous les jours en nous demandant grosso modo comment exécuter des scripts sur de multiples machines. Nous supposons que personne ne savait que ces modèles existaient. Mais maintenant, vous êtes au courant. Ou vous le serez si nous vous disons où les trouver : microsoft.com/technet/scriptcenter/scripts/templates. Humm, c'est peut-être pour ça que personne n'a jamais utilisé ces modèles...
Donc maintenant que les scripteurs ne sont plus aussi naïfs qu'avant, est-ce que ça signifie qu'ils ne sont plus aussi stupides et maladroits qu'ils ne l'étaient ? Disons qu'il il n'y a pas si longtemps, l'un des scripteurs avait décidé de passer son week-end à bricoler chez lui. Quand il est revenu au bureau lundi matin, il avait un pouce écrasé qui n'arrêtait pas de saigner et une grande entaille à la jambe.
Ce qui, en fait, n'était pas si mal que ça. Du moins pour un scripteur.

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


 Vigilance s&#233;curit&#233;: L'Assistant de configuration de s&#233;curit&#233;
Vigilance sécurité
L'Assistant de configuration de sécurité
John Morello
Cet article comprend des informations relatives à la version bêta de Windows Server « Longhorn ». Ces informations sont susceptibles d'être modifiées.

Pour de nombreuses organisations informatiques, la sécurisation efficace et permanente des serveurs tient du véritable défi, surtout lorsque ces organisations disposent d'un important parc de machines séparées par de nombreuses frontières et autres limites organisationnelles. Si le renforcement d'un serveur unique représente une tâche relativement simple pour tout administrateur qualifié, le renforcement de dizaines, de centaines, voire de milliers de serveurs
s'avère une autre paire de manches. Au fil du temps, de nombreuses organisations ont élaboré leurs propres listes de vérification ou normes internes en matière de sécurité de serveur ou ont suivi les conseils fournis par Microsoft, le National Institute of Standards and Technology ou d'autres sociétés tierces. Bien que potentiellement très utiles, ces conseils sous forme de documentation ne sont pas, à eux seuls, suffisants pour permettre aux organisations d'appliquer concrètement à leurs réseaux ces méthodes recommandées. Par conséquent, de nombreuses organisations ont choisi de se contenter des paramètres d'installation par défaut ou de consacrer beaucoup de temps et d'efforts à l'élaboration de leurs propres scripts et stratégies pour renforcer les systèmes.
Avec l'arrivée de l'Assistant de configuration de sécurité (SCW) dans Windows Server® 2003 Service Pack 1 (SP1), Microsoft propose désormais une méthode simple et prise en charge pour renforcer les serveurs et réduire leur surface d'attaque, en fonction de leurs rôles respectifs. En combinant les avantages du SCW avec le déploiement centralisé et les fonctionnalités de gestion d'une stratégie de groupe, il est possible d'adapter le SCW aux plus grandes entreprises informatiques. Dans la chronique de ce mois, je vais expliquer comment les organisations informatiques peuvent utiliser le SCW et la stratégie de groupe afin de gérer leurs serveurs de manière plus sécurisée et cohérente tout en réduisant les frais de déploiement et d'exploitation.

Qu'est-ce que le SCW ?
Le SCW est un composant facultatif, installé par le biais de l'option Ajouter/Supprimer des composants Windows® du Panneau de configuration, disponible sur tous les membres de la famille Windows Server 2003 SP1, y compris Windows Server 2003 R2. Un administrateur commence par exécuter le SCW sur un serveur cible pour identifier les rôles remplis par le serveur en question. Le SCW aide ensuite l'administrateur à créer une stratégie de sécurité qui renforce l'ordinateur en utilisant un modèle de moindre privilège. En d'autres termes, le SCW veille à ne rendre disponibles que les services, les fonctionnalités d'applications et les ports nécessaires pour que le serveur puisse remplir ses fonctions ; tout élément non expressément requis pour les rôles du serveur sera désactivé. Cette approche permet de réduire la surface d'attaque du serveur cible. Si vous exécutez des services dont le serveur n'a pas besoin pour jouer son rôle, vous exposez le serveur à un plus grand risque net sans pour autant gagner en capacité ou fonctionnalité. La désactivation de ces services diminue le risque et peut également améliorer les performances du serveur.
Bien que Microsoft ait nettement fait progresser la sécurité avec Windows Server 2003, en réduisant considérablement la surface globale d'attaque par rapport aux précédentes versions de Windows Server, l'architecture de Windows Server 2003 ne repose pas sur un cœur aux multiples composants comparable à celui de Windows Vista™ et de la prochaine version de Windows Server, répondant au nom de code « Longhorn ». Par conséquent, une installation par défaut de Windows Server 2003 peut entraîner l'activation et l'exécution de services n'étant pas requis pour toutes les configurations de rôles du serveur. Par exemple, le service Spouleur d'impressions est activé par défaut mais n'est pas requis pour un ordinateur faisant uniquement office de serveur de base de données.

Concrétisation de la sécurité basée sur les rôles
Au cours de ces dernières années, Microsoft a publié d'innombrables documentations centrées sur la sécurité pour aider les administrateurs à comprendre quels services étaient requis dans divers rôles de serveur et pour fournir des modèles pré-construits pour des rôles bien connus comme les serveurs Web. Toutefois, des conseils comme ceux dispensés par le Guide sur la sécurité de Windows Server 2003 peuvent s'avérer difficiles à appliquer dans des environnements de grande taille, particulièrement lorsque les applications utilisées dans ce type d'environnements sont plus complexes que les installations serveur IIS ou SQL Server de base. La multitude d'applications tierces utilisées par les entreprises complique encore plus la question ; nombreuses sont celles qui présentent des dépendances envers plusieurs rôles de serveur et dont l'application ainsi que la configuration de service requise ne sont pas toujours clairement définies.
Le SCW aborde ces problèmes en encapsulant dans un assistant piloté par l'administrateur toutes les connaissances et méthodes recommandées qui ont trait aux dépendances et sont contenues dans les guides. Par exemple, si un administrateur déploie une nouvelle application métier qui requiert à la fois SQL Server™ et IIS, il n'a plus besoin de consacrer beaucoup de temps à l'exploration du Guide sur la sécurité ni au développement de sa propre liste de dépendances personnalisées. À la place, il peut installer l'application sur le serveur et lancer le SCW. Le SCW détecte les services en cours d'exécution et propose à l'administrateur une liste de rôles à choisir pour le serveur. En fonction du choix de l'administrateur, le SCW génère une stratégie qui désactivera tous les services non requis par la matrice de dépendances pour les rôles. Le SCW fournit également des options pour renforcer le registre, bloquer toute communication réseau superflue et appliquer une stratégie d'audit efficace. Après l'exécution du SCW, l'administrateur peut enregistrer la stratégie du SCW sous forme de fichier XML et l'appliquer à tout autre serveur exécutant la même application métier.
Par conséquent, l'exécution du SCW comporte trois avantages majeurs par rapport aux méthodes classiques, moins automatisées, de sécurisation de Windows Server. Premièrement, l'administrateur a nettement moins besoin (pour ne pas dire plus besoin) de consulter en permanence la documentation du produit afin de déterminer les services et paramètres requis pour une charge de travail donnée. Cette connaissance est intégrée au SCW et l'administrateur peut facilement se procurer les détails nécessaires grâce à une interface à base de questions. Deuxièmement, le SCW regroupe des conseils abordant plusieurs domaines tels que le renforcement des services, la réduction de la surface d'attaque des réseaux, le renforcement des services LDAP et SMB ainsi que le verrouillage du IIS. Auparavant, l'exécution de ces tâches de configuration nécessitait des utilitaires distincts disposant chacun de leurs propres interface et approche. Pour finir, le SCW redirige ses paramètres dans un fichier de stratégie XML et peut, par conséquent, être utilisé dans des scénarios du type « créez une fois, appliquez plusieurs fois ». Que vous déployiez 1 ou 100 serveurs pour prendre en charge une application métier spécifique, la même stratégie SCW peut facilement être appliquée à chacun d'entre eux. Ceci rend les paramètres de sécurité plus cohérents et permet de diminuer les frais d'exploitation. Ceci simplifie également l'annulation de stratégies SCW.

Composants du SCW
Malgré toutes ses fonctionnalités et tous ses avantages, le SCW reste en fait un outil assez simple qui se compose de trois éléments principaux : l'interface de l'Assistant, l'interface de ligne de commande et la base de données de configuration de la sécurité (SCD). Les administrateurs des petites ou moyennes entreprises auront probablement uniquement besoin d'interagir avec l'interface de l'Assistant. Dans des environnements plus grands ou plus complexes, les administrateurs peuvent en revanche utiliser l'interface de ligne de commande pour faciliter l'automatisation des tâches du SCW, comme la transformation d'une stratégie SCW en objet de stratégie de groupe (GPO). En règle générale, seuls les administrateurs avancés souhaitant créer leurs propres rôles SCW personnalisés modifient la SCD.
L'interface de l'Assistant, illustrée à la figure 1, permet aux administrateurs de créer, de modifier, d'appliquer et d'annuler des paramètres de sécurité sur un serveur cible. Elle propose aux administrateurs des choix dans un flux de travail cohérent qui examine les services et paramètres avant d'examiner la connectivité réseau, les stratégies d'audit de sécurité et, en dernier lieu, les paramètres IIS.
Figure 1 Interface du SCW
Figure 1 Interface du SCW (Cliquer sur l'image pour la réduire)
Figure 1 Interface du SCW
Figure 1 Interface du SCW (Cliquer sur l'image pour l'agrandir)
L'interface de ligne de commande du SCW fournit trois fonctions fondamentales. Elle permet aux administrateurs d'analyser et de configurer plusieurs serveurs (aussi bien locaux que distants) mais aussi d'annuler des stratégies. Elle peut être utilisée pour convertir automatiquement une stratégie SCW basée sur le XML en un GPO pouvant être utilisé de manière native dans des outils de gestion de GPO standard, comme la Console de gestion des stratégies de groupe. L'outil de ligne de commande du SCW, illustré à la figure 2, est enfin utilisé pour enregistrer toute nouvelle extension de la base de données de configuration de la sécurité.
Figure 2 Outil de ligne de commande du SCW
Figure 2 Outil de ligne de commande du SCW (Cliquer sur l'image pour la réduire)
Figure 2 Outil de ligne de commande du SCW
Figure 2 Outil de ligne de commande du SCW (Cliquer sur l'image pour l'agrandir)
La SCD est simplement un ensemble de fichiers XML qui décrivent en détail les services et paramètres spécifiques requis pour chaque rôle SCW. Ces fichiers se trouvent dans %windir%\security\msscw\kbs. Le SCW est fourni par défaut avec plusieurs rôles Windows Server fondamentaux et 12 rôles d'application prédéfinis, dont : BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server et Systems Management Server. Chaque rôle a son propre fichier XML (voir figure 3). Chaque fois qu'une nouvelle définition de rôle est créée, le fichier XML correspondant est placé dans ce répertoire. Ces fichiers XML standard peuvent être lus avec toute visionneuse de texte ou autre application prenant en charge le XML (voir figure 4).
Figure 3 Rôles prédéfinis
Figure 3 Rôles prédéfinis (Cliquer sur l'image pour la réduire)
Figure 3 Rôles prédéfinis
Figure 3 Rôles prédéfinis (Cliquer sur l'image pour l'agrandir)
Figure 4 Fichier de configuration du rôle
Figure 4 Fichier de configuration du rôle (Cliquer sur l'image pour la réduire)
Figure 4 Fichier de configuration du rôle
Figure 4 Fichier de configuration du rôle (Cliquer sur l'image pour l'agrandir)

Association du SCW et de la stratégie de groupe
Le SCW est en soi un formidable outil, mais ce n'est que lorsqu'on le combine à une stratégie de groupe que sa véritable puissance est intégralement dévoilée. Depuis le lancement de Windows® 2000, les recommandations de Microsoft, en matière de sécurisation des serveurs Windows, se concentrent sur l'utilisation d'une stratégie de groupe afin de fournir une application de stratégie cohérente, permanente et gérée de manière centralisée. En regroupant des serveurs en unités d'organisation (UO) en fonction de leurs rôles, les administrateurs peuvent déployer des configurations de sécurité standard dans toute l'entreprise plutôt que de les déployer au niveau individuel des ordinateurs. En misant sur la logique d'accumulation et d'application d'une stratégie de groupe standard, les organisations peuvent concevoir une hiérarchie de rôles de serveur à plusieurs niveaux au sein de laquelle une poignée de stratégies maîtres peuvent sécuriser des centaines, voire des milliers de serveurs individuels. Lorsque des rôles de serveur uniques exigent des modifications des stratégies maîtres, de petites stratégies delta, ciblées sur les rôles, peuvent être créées plus « étroitement » dans la hiérarchie d'UO, sur les serveurs-mêmes. Ceci permet d'effectuer de petits changements afin d'activer des fonctionnalités spécifiques au rôle, sans avoir à dupliquer intégralement la stratégie maître. Cette approche confère aux grandes entreprises les avantages d'une stratégie à gestion centralisée mais aussi une flexibilité permettant de s'adapter, le cas échéant, à des applications spécifiques.
Le véritable défi de cette approche réside dans sa concrétisation. Pour les grandes organisations avec beaucoup d'applications et de rôles de serveur différents, la création du jeu de stratégies approprié est longue et difficile, ou du moins l'était avant l'avènement du SCW. Utiliser le SCW pour générer des stratégies puis attacher ensuite ces stratégies à l'UO appropriée permet de réduire considérablement le temps nécessaire pour déployer une sécurité basée sur les rôles et hébergée dans des répertoires, aussi bien pour les charges de travail existantes que pour celles risquant d'être adoptées plus tard. Pour mieux illustrer comment une organisation peut mettre ceci en place, examinons l'implémentation du SCW et de GPO basés sur les rôles dans une grande entreprise.

Le SCW dans l'entreprise
Pour cet exemple, j'utiliserai le réseau fictif de Contoso. Contoso possède une grande entreprise informatique, complexe et géographiquement dispersée. Espérant réduire ses frais d'exploitation tout en renforçant la sécurité de ses serveurs, Contoso suit les conseils de Microsoft préconisant la création d'une hiérarchie d'UO basée sur les rôles qui sépare et organise les serveurs, sur la base de la charge de travail. Pour créer les stratégies à attacher à ces UO, Contoso utilise le SCW.
Comme le SCW n'est pas installé par défaut, Contoso doit expressément activer le composant du SCW dans son image d'installation autonome. Pour ce faire, l'entreprise ajoute la nouvelle ligne SCW=On à la section [Components] de Unattend.txt. Par la suite, tous les nouveaux systèmes créés avec cette image installeront le composant du SCW lors de l'installation. Notez que le fait de simplement configurer le SCW devant être installé n'applique aucune stratégie sur les ordinateurs puisque les stratégies sont en cours d'élaboration.
Pour appliquer une stratégie par défaut lors du processus d'installation, Contoso modifie dans l'image la section [Commands] du fichier cmdlines.txt afin d'appeler scwcmd avec les options suivantes :
scwcmd configure /p:ContosoBaselinePolicy.xml
Le fichier texte et le fichier XML doivent tous les deux se trouver dans le répertoire $OEM$ de l'image. Pourquoi Contoso appliquerait-elle une stratégie de référence au moment de la création au lieu de simplement utiliser la stratégie associée à l'UO du niveau supérieur dans le répertoire ? En appliquant une stratégie au moment de la création, Contoso peut garantir la cohérence de la base, que les ordinateurs aient été ajoutés à Active Directory® ou non. Si un serveur est par exemple conçu à des fins de test, l'application de la stratégie de référence au cours du processus de génération garantit au moins la conformité du serveur à la stratégie de sécurité standard de l'organisation, même s'il n'est jamais ajouté à Active Directory de production. Si le serveur est ajouté à Active Directory ultérieurement, l'algorithme de priorité et d'application de la stratégie de groupe remplacera les paramètres locaux par ceux du domaine ou du niveau de l'UO (N'oubliez pas l'ordre de priorité pour l'application des stratégies : local, site, domaine et UO).
Une fois le SCW installé, Contoso peut commencer à créer sa stratégie de référence. La stratégie de référence doit être celle qui est déployée au niveau supérieur de la hiérarchie d'UO de la sécurité basée sur les rôles. Elle est généralement la stratégie la plus restrictive de la hiérarchie. L'idée consiste à avoir une situation par défaut aussi sécurisée que possible, puis d'ouvrir uniquement les services et ports pour les charges de travail individuelles comme l'exigent les rôles de serveur correspondants. Pour ce faire, la stratégie de référence doit être générée en prenant un quelconque serveur nouvellement créé, en y ajoutant l'ensemble standard d'outils et d'utilitaires de gestion de Contoso puis en y exécutant le SCW. Une fois l'installation de base de Windows terminée, Contoso installe par exemple sur le serveur (manuellement ou via le fichier cmdlines.txt) ses outils standard : antivirus, outil de sauvegarde, outil de gestion et outil de surveillance. Puisque chacun de ces outils crée vraisemblablement ses propres services Windows, leur présence sur le serveur avant la création de la stratégie de référence permet au SCW de les prendre en compte au cours de la phase de verrouillage des services.
Une fois le serveur créé, Contoso y exécute le SCW. Le SCW peut être exécuté localement ou à distance et toute personne l'exécutant doit être membre du groupe Administrateurs locaux de l'ordinateur. Si le SCW est exécuté à distance, il fournit une option afin de spécifier le compte utilisateur sous lequel l'exécuter sur l'hôte distant ; si le SCW est exécuté localement, vous pouvez utiliser runas.exe pour accomplir la même chose. La première tâche qu'entreprend le SCW consiste à évaluer les services s'exécutant sur l'ordinateur local et à afficher les rôles actuellement installés (voir figure 5).
Figure 5 Sélectionner et afficher les rôles de serveur
Figure 5 Sélectionner et afficher les rôles de serveur (Cliquer sur l'image pour la réduire)
Figure 5 Sélectionner et afficher les rôles de serveur
Figure 5 Sélectionner et afficher les rôles de serveur (Cliquer sur l'image pour l'agrandir)
Aucun rôle ne doit être sélectionné sur le serveur de référence de Contoso car l'ordinateur est conçu pour être dans un état extrêmement restreint. Une fois que les rôles exécutés par le serveur ont été sélectionnés, l'étape suivante consiste à identifier les fonctionnalités client requises pour activer des fonctions telles que les mises à jour automatiques, Active Directory ou le client FTP. Pour la majorité des organisations, l'acceptation des paramètres par défaut du SCW (comme illustré dans la figure 6) fournit des fonctionnalités importantes (comme la possibilité d'ajouter un domaine) mais interdit également des fonctions moins cruciales (comme le client FTP).
Figure 6 Fonctionnalités installées
Figure 6 Fonctionnalités installées (Cliquer sur l'image pour la réduire)
Figure 6 Fonctionnalités installées
Figure 6 Fonctionnalités installées (Cliquer sur l'image pour l'agrandir)
Le SCW poursuit ensuite en vous laissant choisir les outils d'administration spécifiques et les services, autres que ceux par défaut, à autoriser. Ces options de service expliquent pourquoi vous devez exécuter le SCW après l'installation de l'ensemble standard de gestion de serveur de Contoso. Lorsque l'antivirus, l'application de sauvegarde et les applications associées sont installées, le SCW peut alors avoir connaissance de ces services et, par conséquent, les inclure dans ses paramètres de stratégie résultants.
La dernière question de la section Renforcement des services est la suivante : comment gérer des services non spécifiés ? Il s'agit de services pouvant être rencontrés sur d'autres ordinateurs sur lesquels la stratégie du SCW est appliquée, même s'ils ne sont pas exécutés sur l'ordinateur sur lequel la stratégie a été initialement créée. Par exemple, si la stratégie de référence est appliquée à un nouveau serveur avec une nouvelle application tierce, tout service installé par cette application est géré selon le choix effectué ici par l'administrateur. Le SCW autorise l'administrateur à ne pas modifier le mode de démarrage du service ou à le désactiver. La désactivation constitue le choix le plus sûr mais elle doit être utilisée avec précaution car tout service dont l'exécution n'est pas explicitement autorisée ne pourra pas s'exécuter. Pour cette raison, cette option convient le mieux aux environnements haute sécurité bien gérés. Le choix consistant à ne pas changer le mode de démarrage est recommandé pour les autres parties d'une organisation. C'est ainsi l'option choisie dans le cas de Contoso. Avant de mener à bien la partie « Renforcement des services » de ses tâches, le SCW soumet à l'administrateur un rapport mentionnant les services qui seront modifiés.
Une fois le renforcement des services terminé, le SCW fournit des options pour limiter l'accès réseau entrant. A l'instar de la liste des services requis pour un rôle donné, la liste des ports requis pour une charge de travail donnée est incluse dans la base de données XML du SCW.
En fonction des besoins, les administrateurs peuvent configurer des ports supplémentaires et également établir des règles de port par service, comme le montre la figure 7. Pour le serveur de référence de Contoso, seuls les services les plus simples, tels que le Bureau à distance, doivent être autorisés. Toutes les autres exceptions seront configurées dans les stratégies basées sur les rôles, plus bas dans la hiérarchie d'UO.
Figure 7 Afficher et autoriser des ports
Figure 7 Afficher et autoriser des ports (Cliquer sur l'image pour la réduire)
Figure 7 Afficher et autoriser des ports
Figure 7 Afficher et autoriser des ports (Cliquer sur l'image pour l'agrandir)
Le SCW permet ensuite à l'administrateur de sélectionner des options de registre, comme la signature du trafic de fichiers et d'impression. Encore une fois, dans la configuration de référence, il est idéalement recommandé de choisir les paramètres par défaut les plus sécurisés.
La prochaine série de choix concerne la stratégie d'audit du système. Sur la majorité des systèmes, il est préférable de sélectionner l'option Auditer les activités exécutées avec succès ; l'audit de toutes les activités exige plus de ressources processeur et génère une importante quantité de données dans le journal d'audit. En cas d'attaque présumée ou lorsqu'une analyse plus détaillée est requise, l'audit des échecs peut être activé sur la machine concernée.
Enfin, le SCW propose à l'administrateur des options pour renforcer le IIS. Ces options sont similaires à celles disponibles dans l'outil de verrouillage IIS et sont désormais directement intégrées dans la stratégie SCW.
Une fois toutes les étapes effectuées, le SCW invite l'administrateur à enregistrer le fichier XML. Le fichier enregistré doit alors être converti en un format compris, en mode natif, par la stratégie de groupe. Scwcmd.exe est utilisé pour transformer le fichier XML enregistré en GPO. Voici la commande à entrer :
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
Cette stratégie est automatiquement créée dans Active Directory et peut être attachée au sommet de la hiérarchie d'UO de renforcement, basée sur les rôles, de Contoso.
Une fois cette stratégie appliquée au niveau supérieur de la hiérarchie, tout ordinateur ajouté à la hiérarchie d'UO héritera de ses paramètres. Lorsque l'ajout d'un ordinateur implique de modifier cette stratégie (comme un serveur IIS nécessitant l'exécution du service W3SVC), les administrateurs de Contoso exécuteront à nouveau le SCW pour ce nouveau rôle de serveur, transformeront cette nouvelle stratégie en GPO puis lieront ce GPO à une nouvelle sous-UO contenant le ou les serveur(s). Comme le GPO le plus proche du serveur a la préséance, tous les paramètres de base seront par conséquent en place, à l'exception de ceux devant être modifiés afin d'activer la fonctionnalité de rôle désirée pour cette UO (voir figure 8).
Figure 8 Application de la stratégie au niveau de Contoso
Figure 8 Application de la stratégie au niveau de Contoso (Cliquer sur l'image pour la réduire)
Figure 8 Application de la stratégie au niveau de Contoso
Figure 8 Application de la stratégie au niveau de Contoso (Cliquer sur l'image pour l'agrandir)
La véritable puissance de cette approche apparaît clairement au sein des plus grandes organisations ou lorsque de nombreux serveurs sont déployés. Après que la stratégie SCW initiale a été créée et qu'elle a été attachée à une UO, les futurs serveurs ont juste besoin d'être ajoutés à cette UO : ils hériteront automatiquement de la stratégie de sécurité appropriée. Par conséquent, une fois le jeu de stratégies initial créé puis ajouté à Active Directory, le déploiement de nouveaux serveurs ou le remplacement de serveurs existants devient un processus simple et rapide.

À l’horizon
Dans la prochaine version de Windows Server « Longhorn », Microsoft a considérablement multiplié les composants du système d'exploitation, ce qui se traduit par une surface d'attaque réduite et rationalisée, dès l'installation. Au lieu de se concentrer sur le verrouillage de l'installation minimale par défaut, les administrateurs utiliseront plutôt l'outil Gestionnaire de serveur pour ajouter les charges de travail et rôles requis sur chaque serveur. Le fonctionnement du Gestionnaire de serveur ressemble beaucoup à celui du SCW : le Gestionnaire est doté d'une base de données de dépendances interne qui permet au programme d'installation d'ajouter uniquement les fonctionnalités requises pour fournir le service du rôle désiré. De plus, la sécurité basée sur les rôles, gérée de manière centralisée et utilisant une stratégie de groupe, abordée dans cet article, est encore renforcée par le développement considérable de l'ensemble de fonctionnalités contrôlées par GPO. Pour résumer, Windows Server « Longhorn » fait franchir une étape supplémentaire au concept du SCW en le dotant d'une plus grande flexibilité et d'une méthode de sécurité renforcée et ce, dès l'installation.
Ressources SCW
Les pages Web suivantes vous aideront pour commencer à utiliser le SCW :
  • Documentation de l'Assistant de configuration de sécurité
  • Assistant de configuration de sécurité pour Windows Server 2003
  • Windows Server « Longhorn »

John Morello est diplômé de 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 senior de programme dans le groupe Windows Server qui se consacre aux technologies de sécurité et d’accès distant.


 Histoires de Bureau: x64 et moi, et moi, et moi
Histoires de Bureau
x64 et moi, et moi, et moi
Wes Miller

Windows XP est disponible de manière native pour les architectures 64 bits depuis plus de cinq ans. Mais, à moins que vous ne soyez parmi ceux qui ont adopté très tôt un processeur Itanium d'Intel (Windows XP pour Itanium est sorti le même jour que Windows XP), vous avez probablement entendu parler plus récemment de sa disponibilité avec Windows XP et Windows.
Versions de Windows Server 2003 pour systèmes x64. x64, auquel il est également fait référence dans l'industrie par le nom x86-64, est le nom générique de l'architecture AMD64 d'AMD et EM64T d'Intel. Si vous avez acheté un nouveau PC plus ou moins au cours de l'année précédente, il y a de bonnes chances qu'il soit 64 bits, même s'il est actuellement utilisé comme un 32 bits (comme c'est le cas pour la plupart).
Je travaille de nos jours pour une junior entreprise d'Austin, au Texas. En raison de l'architecture de l'un de nos produits, nous souhaitons tirer parti de certains avantages très spécifiques à l'architecture x64, à l'image de l'équipe Microsoft® Exchange 2007 qui a pris la décision ferme de livrer uniquement une version pour l'architecture x64. De même, l'équipe de développement et de test que je dirige est uniquement déployée sur des versions x64 de Windows® XP et Windows Server® 2003 pour les postes de travail de développement, les portables, les serveurs et les serveurs de production. En outre, j'utilise Windows XP édition professionnelle x64 sur mon portable personnel afin de tester et de déboguer notre produit.
Curieusement, la première réaction que j'obtiens de la plupart des personnes lorsque je mentionne que j'utilise Windows 64 bits, en particulier sur mon ordinateur portable, est un regard plutôt troublé. Si ces personnes connaissent l'informatique 64 bits, c'est un peu une expression d'incrédulité mélangée à de l'amusement, en raison de la supposition habituelle qu'il est difficile de trouver des pilotes de périphériques pour systèmes 64 bits. Dans la rubrique de ce mois-ci, j'expliquerai pourquoi et comment j'utilise Windows XP et Windows Server 2003 sur des systèmes x64 en mode 64 bits et je décrirai certains avantages de ce déploiement (et les obstacles possibles) auxquels vous pouvez vous attendre. J'examinerai également des aspects de la prise en charge, de la migration et du déploiement de Windows Vista™ x64.

Un peu d'histoire
Comme je l'ai indiqué précédemment, l'origine de la prise en charge du 64 bits dans Windows a vraiment commencé avec la prise en charge du processeur Itanium d'Intel. (Même si Windows était disponible pour le processeur Alpha 64 bits, Windows n'était en fait jamais exécuté en mode 64 bits sur l'Alpha) Il n'y a pas de prise en charge de l'Itanium dans Windows XP et Windows Vista, et l'architecture x64 porte actuellement le flambeau de l'informatique cliente Windows 64 bits. Une sélection plus étendue d'éditions de Windows Server 2003 est actuellement disponible pour les processeurs x64 que les processeurs Itanium (qui ont été essentiellement relégués aux charges de travail de haut niveau des datacenters), une tendance qui, selon moi, se poursuivra avec la prochaine version de Windows Server, nom de code « Longhorn », à sa sortie.
La prise en charge de Windows sur la plate-forme x64 est devenue disponible à la sortie de Windows Server 2003 Service Pack 1 (SP1). Bien que cela prête un peu à confusion, c'est également à cette époque que la version x64 de Windows XP est devenue disponible, ce qui signifie que les produits Windows XP 32 bits et 64 bits dérivaient de trois arborescences de code différentes de Windows. Alors que les produits 32 bits disposent actuellement d'un deuxième Service Pack, la version 64 bits de Windows XP n'a techniquement aucun niveau de Service Pack (il est également possible de le considérer comme ayant le SP1 pour Windows Server 2003 déjà intégré).
La configuration requise pour utiliser Windows 64 bits est la même, qu'il s'agisse de Windows XP, Windows Server 2003, Windows Vista ou Windows « Longhorn ». Évidemment, il est avant tout nécessaire de disposer d'un processeur 64 bits. Dans le cas des processeurs AMD, ceci signifie qu'il faut disposer d'un processeur simple, double ou quadruple cœur affichant une compatibilité AMD64 (voir amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Pour Intel, ceci revient à chercher un système simple, double ou quadruple cœur compatible EM64T ou prenant en charge l'architecture Intel 64 (voir intel.com/technology/intel64). Notez que toute la nuance se dissimule ici dans les détails. Un système Intel Core Duo, par exemple, n'est pas 64 bits. Un système Intel Core 2 Duo est 64 bits, même s'il peut y être simplement fait référence comme à un Centrino Duo (comme c'est le cas pour mon portable).

Vivre avec x64
Une fois vous avez déterminé si votre système prendra en charge une version 64 bits de Windows en mode natif, vous devrez vous occuper de la prise en charge des périphériques. Malheureusement, même si Microsoft a encouragé les fournisseurs et les OEM (durant au moins deux années de sessions WinHEC) à créer et à certifier des pilotes 64 bits pour leurs périphériques et systèmes, le plus grand défi auquel vous devez faire face si vous utilisez Windows x64 est la recherche de pilotes pour les périphériques matériels ou le logiciel. D'après mon expérience, votre utilisation de x64 sera optimale lorsque la prise en charge de périphériques nécessaire est limitée et que cette utilisation offre les avantages les plus logiques.
Il est plus difficile de trouver des pilotes pour les systèmes de bureautique et mobiles. Généralement, vous aurez le plus de chance avec un fournisseur OEM majeur ou un système créé à base de composants de qualité d'entreprise (où il est probable que l'utilisation professionnelle incite le fournisseur ou l'OEM à créer et à signer des pilotes compatibles x64).
Pour Windows Vista, la situation est heureusement bien meilleure. Au lieu d'un monde où x86 est l'architecture de choix et x64 est l'architecture négligée avec des pilotes disponibles en nombre limité pour la majorité des matériels, la situation est inversée. Pour Windows Vista, les fournisseurs de périphériques doivent soumettre leurs pilotes x64 pour les tests de compatibilité. En fait, les pilotes x86 n'ont pas besoin d'être aussi inclus, mais peuvent certainement l'être. Du point de vue conceptuel, ceci signifie que certains matériels, surtout les périphériques qui profitent des nouvelles capacités de Windows Vista, peuvent offrir uniquement la prise en charge de Windows x64 et non x86.
En réalité, les pilotes ne sont qu'un des problèmes que vous rencontrerez lorsque vous tenterez d'exécuter Windows 64 bits en mode natif. Le plus gros problème est, pour commencer, d'y parvenir (d'effectuer la migration), mais j'aborderai cela plus tard.

Pourquoi 64 bits ?
AMD, Intel et Microsoft ne sont bien entendu pas passés à une architecture 64 bits pour le plaisir. Le passage à 64 bits offre plusieurs avantages essentiels. Comme vous pouvez le voir dans la figure 1, l'amélioration la plus importante apportée par l'architecture x64 est la capacité d'adresser beaucoup plus de mémoire (jusqu'à 16 téraoctets (To)) par rapport aux 4 Go que Windows 32 bits peut adresser. Notez que bien que les pointeurs 64 bits puissent adresser jusqu'à 16 To, les applications ont seulement accès à environ 8 To maximum.
Figure 1 Limites de l'espace d'adressage mémoire (Close Figure 1)

Espace d'adressage | Windows 64 bits | Windows 32 bits
Mémoire Virtuelle | 16 To | 4 Go
Fichier d'échange | 512 To | 16 To
Réserve paginée | 128 Go | 470 Mo
Réserve non paginée | 128 Go | 256 Mo
Cache système | 1 To | 1 Go
En outre, les versions x64 de Windows permettent d'utiliser l'interdiction de l'exécution de données (Data Execution Prevention, DEP), également disponible sur les systèmes x86 avec prise en charge de NX (No Execute). Ceci permet d'obtenir une solution à base de matériel que Windows utilise pour empêcher les saturations de tampons. Elle empêche l'exécution de code des pages de données en mémoire (voir support.microsoft.com/kb/875352, en anglais, pour plus d'informations sur ce sujet).
Les versions x64 de Windows permettent la prise en charge native des unités centrales multiprocesseur ou multicœur, comme le font les versions x86 de Windows. Mais l'une des plus grandes difficultés de création d'image d'un système Windows XP est éliminée par l'utilisation d'une couche d'abstraction matérielle unique (Hardware Abstraction Layer, HAL) sur toutes les installations Windows x64, sans avoir à batailler pour identifier la couche HAL utilisée sur les systèmes non ACPI ou avec une seule UC.
Fondamentalement, Windows x64 en tant qu'architecture vous permet d'utiliser votre infrastructure de gestion existante et vos logiciels 32 bits existants (par émulation) ainsi que tout logiciel 64 bits, avec la capacité d'accéder à une mémoire étendue. En fait, les seuls effets secondaires désagréables du passage à Windows x64 sont : l'absence complète de prise en charge des applications 16 bits (y compris les applications 32 bits avec des programmes d'installation 16 bits), les problèmes avec les applications qui ne s'exécutent pas avec fiabilité lorsque la fonction DEP matérielle est activée (bien que DEP puisse être désactivé en fonction de chaque processus et que l'équipe Windows Application Compatibility ajuste certaines applications qui ne s'exécutent pas correctement avec DEP activé) et, finalement, le fait que dans Windows Vista 64 bits tous les pilotes doivent être signés numériquement.
Ce dernier élément a été ajouté pour empêcher l'altération du noyau Windows en mémoire, une technique souvent utilisé par rootkits. Le raisonnement est que, puisque x64 est l'architecture pour laquelle Microsoft encourage les fournisseurs à développer des pilotes avant tout (afin d'obtenir des pilotes passant par les tests de compatibilité matérielle Windows), les conditions requises ne sont pas aussi effrayantes qu'elles ont pu l'être par le passé.
Il y a quelques autres points à ne pas oublier si vous envisagez d'utiliser Windows pour les systèmes x64. Il n'y a pas aucune version de Windows XP pour systèmes x64 comprenant les fonctionnalités offertes par Windows Media® Center Edition ou Windows Tablet PC Edition. Cependant, ceci est différent dans Windows Vista, avec lequel les versions x64 de Windows disposent des mêmes fonctionnalités que la version x86.

Virtualisation
Je n'ai pas jusqu'ici mentionné la virtualisation. Je ne parle pas de Microsoft Virtual PC ou des produits de virtualisation PC de VMWare ; je parle de la virtualisation de système d'exploitation pour les programmes exécutables 32 bits. Dans les versions 32 bits de Windows, les applications 16 bits s'exécutent toutes dans le contexte NTVDM, une machine virtuelle MS-DOS®. Comme je l'ai dit précédemment, il n'y a pas de prise en charge des applications 16 bits dans les versions 64 bits de Windows. Par contre, bien que la plupart des composants intégrés à Windows s'exécutent en mode natif comme programmes binaires 64 bits, certains composants et de nombreux programmes de sociétés tierces s'exécutent comme applications 32 bits.
Windows vous donne une couche d'émulation toute nouvelle appelée Windows On Windows (WOW) pour permettre à ces applications 32 bits de disposer d'une vue différente du système d'exploitation, en s'exécutant en fait sur une version 32 bits de Windows. Sous WOW, les applications x86 voient Program Files (X86) comme étant simplement Program Files. De même, %WINDIR%\SysWOW64 apparaît pour les applications x86 comme étant %WINDIR%\System32. Les applications x86 voient la clé de registre HKLM\SOFTWARE\Wow6432Node comme ils verraient le nœud HKLM\SOFTWARE.
En utilisant l'outil Process Explorer, vous pouvez explorer une autre perspective de virtualisation. De nombreuses applications 32 bits s'attendant à interagir avec des programmes binaires 32 bits Windows, nombre de ces programmes binaires sont fournis dans les versions 64 comme 32 bits. En ajoutant une colonne supplémentaire à Process Explorer, vous pourrez facilement le constater. Dans la figure 2, vous remarquerez deux instances de cmd.exe, une version 32 bits et une version 64 bits. Vous noterez, dans l'instance 32 bits, plusieurs DLL wow64* chargées dans le processus 32 bits. Celles-ci témoignent de la virtualisation à l'œuvre, qui permet aux applications 32 bits de fonctionner sous Windows 64 bits. Notez également le répertoire de travail (Path) utilisé par les versions 64 et 32 bits de cmd.exe.
Figure 2 Process Explorer montre les versions 32 bits et 64 bits de cmd.exe
Figure 2 Process Explorer montre les versions 32 bits et 64 bits de cmd.exe (Cliquer sur l'image pour la réduire)
Figure 2 Process Explorer montre les versions 32 bits et 64 bits de cmd.exe
Figure 2 Process Explorer montre les versions 32 bits et 64 bits de cmd.exe (Cliquer sur l'image pour l'agrandir)
Une remarque finale importante au sujet de la virtualisation : Windows exécute explorer.exe comme une application 64 bits native, ce qui a des avantages comme des inconvénients. Le plus gros inconvénient est que toute extension du shell de l'Explorateur Windows doit être recompilée pour x64 afin de fonctionner (ce qui n'a pas été effectué pour la majorité d'entre elles).
C'est l'inverse pour Internet Explorer® : il s'exécute de manière native avec la version 32 bits. Ceci a été conçu principalement pour que la multitude de contrôles ActiveX® sur Internet et déjà utilisés à l'heure actuelle continuent à fonctionner tels quels. Sans cela, comme les applications 64 bits ne peuvent pas charger de DLL ou de pilotes 32 bits intra-processus, il n'y a aucune manière efficace de charger les contrôles ActiveX 32 bits (ce qui inclut pratiquement tous les contrôles ActiveX actuellement disponibles) sur un explorateur 64 bits, et signifie qu'une grande partie du contenu d'Internet devient inaccessible. Pour voir ceci dans la pratique, essayez de charger C:\Program Files\Internet Explorer\iexplore.exe sur un système Windows 64 bits et de visiter un site quelconque chargeant un contenu avec contrôle ActiveX (même Windows Update), le résultat sera un niveau variable de défaillance. Windows Update (voir la figure 3) a maintenant mis à jour son environnement pour ouvrir une instance 32 bits d'Internet Explorer dans ces circonstances. À l'avenir, il y aura très certainement des contenus avec contrôles ActiveX mis à jour pour profiter d'Internet Explorer 64 bits. Mais comme la majorité des systèmes Windows utilisent une version purement 32 bits, la nécessité d'une mise à jour du contenu avec contrôles ActiveX jour n'est pas critique. Je ne pense pas que cela changera avant quelques temps.
Figure 3 Les contrôles ActiveX 32 bits échouent dans Internet Explorer 64 bits
Figure 3 Les contrôles ActiveX 32 bits échouent dans Internet Explorer 64 bits (Cliquer sur l'image pour la réduire)
Figure 3 Les contrôles ActiveX 32 bits échouent dans Internet Explorer 64 bits
Figure 3 Les contrôles ActiveX 32 bits échouent dans Internet Explorer 64 bits (Cliquer sur l'image pour l'agrandir)

Windows x64 chez Pluck
J'ai indiqué au début de cet article que nous avons commencé la transition vers Windows x64 chez Pluck. Nous y avons procédé avec trois versions différentes de Windows : Windows XP édition professionnelle x64, Windows Server 2003 Enterprise x64 Edition et Windows Vista x64.
La petite taille de notre organisation nous a permis, alors que nous commencions le développement de notre produit le plus récent, de commencer à effectuer la migration vers Windows x64 pour profiter de ses avantages. En procédant ainsi, nous avons pu nous assurer que tout nouveau matériel commandé était compatible x64. En fait, ce sont les capacités étendues en termes de mémoire de x64 conjointement à la virtualisation qui nous permettent d'utiliser notre produit comme nous le faisons. Tous nos serveurs physiques sont exécutés comme serveurs 64 bits virtuels sur un serveur hôte 64 bits. Chaque serveur hôte dispose de 16 Go de RAM répartis entre les serveurs virtuels hébergés dessus (en général 2 Go pour chaque machine virtuelle simulée, ou VM, et 3 Go pour chaque VM de production).
En utilisant également des systèmes de premier niveau et un matériel virtualisé, nous avons réussi à obtenir une prise en charge des périphériques proche de 100 pourcent. Mon portable, par exemple, compte trois périphériques qui ne disposent pas de pilote x64. Ils semblent tous être des périphériques d'arrière-plan non essentiels et le système fonctionne parfaitement en leur absence. Curieusement, une installation de Windows Vista RC1 x64 a donné exactement les mêmes résultats de prise en charge de périphériques, bien que mon système porte le logo Windows Vista Capable. Il ne fait aucun doute que le fournisseur mettra très bientôt ces pilotes manquants à disposition.
Puisque notre utilisation des systèmes est principalement limitée à Microsoft Office, Visual Studio® et plusieurs outils supplémentaires utilisés dans nos processus de développement et de génération, nous avons peu d'applications héritées provoquant des problèmes de compatibilité dans notre migration. Bien qu'une grande partie de notre organisation utilise des versions 32 bits de Windows, nous avons commencé la migration vers le 64 bits avec le nouveau matériel, ce qui a été une expérience relativement sans accroc.

Déploiement et migration vers x64
Il y a quelques éléments à prendre en compte en ce qui concerne le déploiement. Microsoft fournit une version de Windows Preinstallation Environment (Windows PE) réservée à l'architecture x64. Cependant, en raison de la parité avec x86 sur les systèmes x64, vous pourriez très bien vouloir utiliser Windows PE x86 pour le déploiement, en particulier si vous utilisez une solution de création d'image. Si vous déployez Windows XP avec une l'installation sans assistance, Windows PE dépendra de l'architecture utilisée, car winnt32.exe doit s'exécuter sous une architecture identique à celle qu'il déploie. Puisque Windows PE ne dispose pas d'une couche de compatibilité 32 bits et que winnt32.exe sous x64 est une application 64 bits, Windows 32 bits nécessite Windows PE 32 bits. C'est également le cas pour les versions 64 bits de Windows, qui nécessitent Windows PE 64 bits.
Les services d'installation à distance (RIS) différent en ce point et c'est pourquoi nous utilisons RIS chez Pluck. RIS, qui a fait ses débuts avec Windows Server 2003 SP1, peut déployer les architectures Windows x64 comme x86 ou Itanium. Lorsqu'un système x64 se connecte à un serveur RIS, le serveur (dans la configuration par défaut) lui proposera des images RISetup ou RIPrep x86 et x64. RIS peut également être configuré pour proposer aux clients x64 des images exclusivement x86 ou x64. Ce choix est proposé par défaut afin d'offrir l'environnement le plus adapté au matériel x64.
Vous remarquerez que je n'ai pas encore parlé de mise à niveau. C'est pour une bonne raison. Malheureusement, la mise à niveau d'un système d'exploitation complet de x86 vers x64 est une entreprise énorme. Pour cette raison et étant donné le déploiement limité de Windows XP édition professionnelle x64; il n'est pas possible d'effectuer la mise à niveau vers Windows XP x64 à partir d'une version x86 quelconque, ni de mettre à niveau depuis une version quelconque de Windows XP (x86 ou x64) vers Windows Vista x64. Windows Vista sur les systèmes x64 est, comme Windows XP édition professionnelle x64, un produit pouvant uniquement être installé comme nouvelle installation. Pour cette raison, beaucoup d'organisations envisagent uniquement la migration vers x64 lorsqu'un renouvellement de matériel est effectué, ce qui constitue une stratégie similaire à celle qui est attendue de la part de nombreuses organisations avec Windows Vista (ce qui rend cette double opération simultanée logique).
Mais cela ne signifie pas du tout qu'aucun outil n'est à la disposition des personnes ou des organisations effectuant la mise à niveau de Windows x86 vers Windows x64. Les versions de l'outil de migration de l'état des utilisateurs (USMT, User State Migration Tool) pour Windows XP et Windows Vista ont toutes deux été étendues pour prendre en charge la migration (par opposition à une mise à niveau intrabande du système d'exploitation) d'une installation de Windows vers une autre. Il s'agit de la méthode prédominante utilisée de nos jours par la plupart des organisations pour le déploiement de Windows (effacer et recharger), même sur un même PC, et l'utilisation du même mécanisme pour le passage à Windows sur une architecture entièrement nouvelle ne doit pas présenter d'obstacles plus importants qu'auparavant.

Conclusion
Bien que la migration graduelle de notre petite organisation vers x64 puisse être considérablement plus facile que le vaste processus de migration auquel font face les plus grandes organisations, tout informaticien professionnel doit envisager le passage tôt ou tard à une architecture x64. Même si en réalité l'architecture x86 et les versions x86 natives de Windows seront toujours présentes au cours de la prochaine décennie, l'architecture x64 est certainement l'avenir de l'informatique d'entreprise. Alors que Microsoft fait le passage complet vers les capacités x64 avec Exchange Server et d'autres produits, vous devriez tout d'abord commencer à trouver la place des systèmes x64 dans votre architecture et dans votre projet de migration Windows Vista, que vous utilisiez ou non de nos jours Windows XP ou Windows Server 2003 en mode natif sur vos systèmes x64.

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


 Microsoft.com au jour le jour: Utilisation des services ADFS (Active&#160;Directory&#160;Federation&#160;Services)
Microsoft.com au jour le jour
Utilisation des services ADFS (Active Directory Federation Services)
Jim Guthrie

À Microsoft, nous disposons d'un extranet permettant à nos partenaires commerciaux d'accéder aux ressources internes. L'architecture de l'extranet nécessite que chaque participant externe à l'entreprise possède un compte de domaine unique pour cet espace. Ce compte est créé et géré par les employés de Microsoft plutôt que par ses
partenaires, pour des raisons évidentes. Toutefois, et bien que fonctionnel, ce système est peut-être moins satisfaisant du point de vue de l'expérience l'utilisateur ; de plus, il monopolise un certain nombre de ressources de Microsoft, qui doit gérer tous les utilisateurs partenaires.
Voici comment l'extranet fonctionne actuellement. Lorsqu'un client ou partenaire s'inscrit dans une application, il doit saisir ses informations d'authentification. Au cours de la même session, si cet utilisateur décide d'accéder à une ressource différente, il devra de nouveau saisir ses informations d'authentification. Et ces informations lui seront demandées à chaque fois qu'il voudra accéder à d'autres ressources. Si l'utilisateur ouvrait une session dans une application unique qui utilise des ressources multiples, par exemple une base de données financière, il devrait s'authentifier indépendamment pour chaque ressource. Un tel système n'est pas très pratique et risque d'irriter les utilisateurs.
Fort heureusement, grâce à Active Directory® Federation Services (AFDS), nous pouvons résoudre facilement le problème des authentifications multiples, et vous aussi. ADFS est un composant de Windows Server® 2003 R2 qui permet à plusieurs entreprises de partager des ressources tout en conservant la capacité de chacune à gérer ses propres utilisateurs. Dans cet article, j'illustre la manière dont Microsoft prépare l'utilisation d'ADFS pour résoudre ce problème d'extranet à ressources multiples, ce qui vous fournira les informations dont vous aurez besoin pour mettre en œuvre une solution similaire. Cependant, avant d'entrer dans les détails, jetez un coup d'œil sur la figure 1 pour vous familiariser avec certains termes ADFS de base.
Figure 1 Terminologie ADFS (Close Figure 1)

Terme | Définition
Fédération | Une paire de domaines qui ont établi une approbation de fédération Active Directory.
Federation Service Resource (FS-R) | Achemine les demandes d'authentification vers le FS-A et les ressources désirées.
Federation Service Accounts (FS-A) | Fournit un jeton de compte qui doit être authentifié sur le FS-R.
Federation Service Proxy (FS-P) | Fournit une couche de séparation pour les serveurs FS à partir du trafic Internet entrant.
Déclaration | Information fournie par le serveur concernant un client (par exemple, nom, identité, clé, groupe, privilèges ou fonctionnalités).
Découverte de domaine | Chaque FS-A possède un domaine dans lequel les informations d'identification sont enregistrées. La découverte de domaine détermine le FS-A qui est utilisé pour la session ADFS.

Une solution ADFS
Lorsqu'un utilisateur tente d'accéder à une application gérant ADFS, le navigateur est envoyé au FS-R (Federation Service Resource) pour la découverte de domaine. C'est ici que l'utilisateur sélectionnera la série d'informations d'authentification qu'il utilisera pendant la session. Selon le domaine que le client a choisi, l'utilisateur sera ensuite redirigé vers le serveur FS-A (Federation Service Accounts). C'est dans ce serveur qu'il recevra un jeton de compte valide (dans un cookie) qui sera basé sur les informations d'authentification qu'il a saisies sous forme d'un ID Windows Live™ (qui remplace le compte Passeport), d'une authentification intégrée de Windows ou d'une authentification SSL (voir la figure 2). Dans ce modèle, ce sont les entreprises individuelles qui doivent gérer leur propre serveur de fédération de comptes. Dans le cas des serveurs des partenaires de Microsoft, ce système permet de soulager Microsoft.com de la gestion de ces comptes dans l'environnement. Bien sûr, lorsque l'on met en œuvre ce niveau de responsabilité, il faut sélectionner soigneusement les entreprises avec lesquelles on construit cette fédération et s'assurer qu'elles gèrent leurs informations de comptes de façon active.
Figure 2 Flux ADFS
Figure 2 Flux ADFS (Cliquer sur l'image pour la réduire)
Figure 2 Flux ADFS
Figure 2 Flux ADFS (Cliquer sur l'image pour l'agrandir)
L'étape suivante consiste à retourner au serveur FS-R pour échanger le jeton de compte contre un jeton de ressources. Dans notre configuration, ce jeton contient une liste complète des autorisations qui ont été accordées à l'utilisateur par un système de déclarations et de mappage effectué sur le serveur FS-R. Une fois le jeton reçu, cet utilisateur obtient la fonctionnalité d'authentification unique (SSO) sur les applications gérant l'ADFS valide pour toute la durée de la session ou jusqu'à 24 heures par défaut (cette durée est configurable). Le résultat est que vous avez activé le SSO pour ces applications gérant l'ADFS, ce qui aboutit à une expérience client plus sûre et plus efficace. Pour une description étape par étape du processus d'authentification ADFS, voir l'article de Matt Steele publié dans le numéro de juillet 2006 de TechNet Magazine et intitulé « Simplification de l'authentification unique avec ADFS ».
Afin d'assurer la sécurité des ressources de l'entreprise Microsoft, nous avons isolé le côté orienté Internet de l'extranet du côté de l'entreprise, ce qui signifie que tous les serveurs sont potentiellement doubles. Nous autorisons une approbation à sens unique des utilisateurs internes de l'entreprise et nous utilisons les serveurs pour fournir la protection nécessaire. Nous possédons également un domaine séparé pour l'espace de l'extranet dans lequel nous fournissons aux utilisateurs externes l'accès aux ressources dont ils ont besoin.
Les deux problèmes principaux auxquels nous avons été confrontés pendant sa mise en œuvre étaient l'équilibrage de la charge et les modifications des fichiers de stratégie ADFS. L'équilibrage de la charge était un défi au niveau global et au niveau local. Au début dans la production, nous utiliserons l'équilibrage de la charge globale d'Akamai ou Savvis, nos partenaires CDN (Content Delivery Network), pour les clusters de serveurs Web frontaux dans deux régions. Nous assurons ainsi la disponibilité du système aux utilisateurs finaux, même dans le cas peu probable où deux serveurs régionaux viendraient à être déconnectés. Pour ce faire, nous utilisons le principe du basculement automatique basé sur les vérifications de l'état du serveur fournis par les CDN. De plus, nous pouvons facilement ajouter d'autres clusters à l'avenir. Etant donné l'objectif de réduction de coût, nos déploiements de pré-production n'utiliseront pas le service CDN.
Au niveau régional, nous avons associé les serveurs pour un basculement local grâce au clustering NLB (Network Load Balancing). Nous n'utilisons pas de fonctionnalité d'équilibrage de charge particulière : nous aurions donc tout aussi bien pu accomplir cela à l'aide de matériel. Toutefois, et vu que l'objectif est de réduire les coûts, nous utilisons le NLB. Cette configuration nous permettra d'assurer 99,9 % de disponibilité de fonctionnement dans tous les environnements pris en charge.
Autre défi auquel nous devions faire face : le fichier de stratégie ADFS, la colonne vertébrale de l'ADFS, doit être correctement distribué à travers notre environnement et les modifications qui lui sont apportées doivent être également copiées. Pour ce faire, nous nous servons d'une autre fonctionnalité intégrée à Windows Server 2003 R2, la DFS-R (Distributed File System Replication), un nouveau moteur de réplication multi maître basé sur l'état. Sur chacun des serveurs principaux, nous avons activé une appartenance au groupe de DFS-R avec une réplication à maille pleine de 24 heures. Les modifications apportées au fichier de stratégie seront distribuées à tous les serveurs. Tant que nous contrôlons la modification des fichiers, nous avons un service stable et hautement disponible.
Nous avons essayé de nous assurer que toutes les modifications soient effectuées par le composant logiciel enfichable ADFS. Cependant, dans la pratique, nous nous sommes rendu compte que nous devions de temps en temps mettre ce fichier à jour manuellement. Lors d'une mise à jour manuelle, il est important de se rappeler que l'ADFS assure le suivi de la version de ce fichier. Vous devez donc incrémenter le fichier pour que vos modifications soient reflétées dans l'environnement :
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
Il vous faut également vous souvenir que, comme tout XML, le fichier XML de stratégie est sensible à la casse. Ce fichier renferme de nombreuses références aux applications ou aux autres serveurs ADFS, et elles doivent toutes être copiées mot à mot de serveur à serveur. Veuillez noter les exemples communs suivants, la première référence, RevocationCheckFlags, ayant été entrée manuellement et la seconde étant l'URL d'une application de confiance modifiée par l'Interface utilisateur :
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
Pour renforcer la sécurité, nous utilisons un autre composant de l'ADFS, le FS-P (Federation Service Proxy), qui s'assure que les FS-R restent inaccessibles aux requêtes directes provenant d'Internet. Chez Microsoft.com, nous avons trouvé une façon innovante d'implémenter les proxys en utilisant une seule série de proxys pour héberger plusieurs environnements ADFS dans notre zone de pré-production. Fait intéressant, lors de nos premiers tâtonnements avec cette technologie, nous avons découvert qu'il nous suffisait de modifier une clé de registre pour y parvenir. La clé en question se situe dans HKLM\Software\Microsoft\WebSSO. Une simple modification de la valeur de l'annuaire initial dans cette clé vous permettra d'utiliser le proxy pour plusieurs environnements. La valeur par défaut était :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Pour basculer entre environnements, vous devez modifier la clé comme suit :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
La création d'un fichier de commandes peut simplifier la gestion de ce processus. Malheureusement, la version actuelle du composant logiciel enfichable MMC pour ADFS ne prend pas en charge les basculements entre environnements, car il existe une relation de type un à un entre le proxy et le serveur de ressource ou compte. C'est le seul moyen d'optimiser l'utilisation des serveurs proxy. Le résultat final est une énorme réduction des coûts, car il limite le nombre de serveurs physiques nécessaires, quel que soit le nombre d'environnements différents que vous choisissez d'héberger.
D'un point de vue architectural, nous exécutons notre environnement de pré-production avec des machines virtuelles, ce qui représente une économie de coûts supplémentaire. Ceci élimine le besoin d'acheter et d'héberger six serveurs supplémentaires. A ce jour, nous n'avons eu aucun problème de performances. Cependant, pour répondre à la demande sans cesse croissante dans l'environnement de production, nous avons choisi d'utiliser des machines physiques hautes performances.

Pas uniquement pour Active Directory
Microsoft.com ne se contente pas d'utiliser des comptes Active Directory pour l'authentification : nous avons également intégré les comptes Windows Live ID. Nous avons trouvé qu'en utilisant Windows Live ID (WLID) 4.5, nous pouvions utiliser un compte WLID unique pour déléguer l'accès aux ressources de Microsoft utilisant une transformation de déclarations personnalisée. C'est un énorme avantage pour effectuer l'authentification SSO, car nous n'avons plus besoin d'un compte de domaine spécifique.

Défis restants
Le plus grand défi auquel nous sommes aujourd'hui confrontés est la gestion d'ADFS pour le partage de certificats de signature de jetons. Nous utilisons des certificats standard qui restent valides typiquement pendant une année avant de nécessiter un renouvellement. Au moment du renouvellement, chacun des serveurs appropriés devra être mis à jour en conséquence, ce qui aura un impact considérable sur les FS-R. Si la situation est à peu près gérable pour 15 ou 20 fédérations, elle devient vraiment problématique à l'échelle que envisageons, c'est-à-dire au moins des centaines, voire des milliers de fédérations. Cela nécessiterait une équipe à temps complet dédiée à la gestion de certificats de SSL pour un seul environnement. Nous avons plusieurs équipes qui réfléchissent à la meilleure façon d'automatiser cette solution, mais qui ne sont pas encore parvenue à une conclusion satisfaisante.
Autre défi : les applications ne gèrent pas toutes l'ADFS dès l'installation. Nous aurons besoin de programmation pour que les sites profitent de l'opportunité fournie par l'ADFS. Nous travaillons en étroite collaboration avec l'équipe de Microsoft® Office SharePoint® Services pour veiller à ce que la version de SharePoint nouvelle génération prenne en charge nos besoins d'implémentation pour ADFS.

Conclusion
Avant de prendre la décision de passer à un modèle ADFS, vous devez prendre en considération plusieurs facteurs. L'un d'eux concerne les ressources auxquelles les clients accèderont. Le processus de création d'une confiance fédérée entre les entreprises peut être une tâche triviale, mais l'écriture, la relecture et l'exécution de stratégies d'accès acceptables nécessitent du temps et des efforts. Donc s'il n'existe qu'une seule ressource à laquelle vos clients auront accès, vous devrez décider si le jeu en vaut la chandelle. Cependant, à mesure que le nombre de ressources grandit, les avantages augmentent.
Pour plus d'informations, voir Introduction à ADFS et Active Directory Federation Services : vers une identité et une gestion d'accès fédérées.

Jim Guthrietravaille au sein de l'équipe d'exploitation informatique Microsoft.com. Outre sa contribution aux services ADFS, il est ingénieur système dans l'équipe de support à la plateforme du portail d'entreprise.


 Sur le terrain: L'apprentissage dans la joie (et la douleur)
Sur le terrain
L'apprentissage dans la joie (et la douleur)
Mark D. Scott

Je me souviens de ce que je ressentais à la sortie d'un nouveau logiciel : le frisson de joie de pouvoir mettre la main sur la dernière technologie avant tout le monde, de l'explorer sous tous ses angles, de comprendre comment elle fonctionnait et de la faire marcher. J'adorais être l'un des premiers acquéreurs, être dans le secret, le magicien vers qui l'on se tournait pour obtenir cette connaissance sacrée.
Mais, au bout d'un moment, cette joie s'est estompée. Je ne sais pas trop ce qui s'est passé. Peut-être que je l'ai perdue à cause des frustrations nées des tentatives de faire marcher des applications vitales à trois heures du matin. Ou peut-être qu'elle s'est égarée dans la documentation produit que j'avais mal lue alors que le serveur de messagerie de l'entreprise se détériorait (à l'époque où un seul serveur suffisait). Peut-être je que je vieillis et que je deviens cynique. Bref. Travailler toute la nuit ne m'amuse plus autant qu'il y a dix ans. Mais ça ne veut pas dire qu'il est acceptable d'arrêter d'apprendre. Un évènement récent est venu me le rappeler.
Je viens de passer à Microsoft® Outlook® 2007 et j'ai vraiment apprécié cette expérience. Mais comme j'ai également un abonnement MSN® Premium, mon FAI fournit un abonnement compris dans son service. Sous la version précédente d'Outlook, j'avais besoin d'un petit logiciel spécial appelé connecteur pour accéder à mon adresse de messagerie MSN. Ce connecteur de logiciel ne fonctionnait pas avec Outlook 2007 : j'ai donc contacté MSN. MSN m'a dit de contacter mon FAI, qui m'a répondu, finalement, qu'il ne prenait pas en charge le connecteur MSN Outlook sur Outlook 2007. Chacun se renvoyait la balle, et à force de courriers électroniques, de chats et d'appels, et d'une sacrée dose de patience, j'ai réussi à obtenir les informations que je cherchais.
Et puis, d'un coup, une pensée m'a traversé : peut-être que je n'avais plus besoin d'un connecteur. J'ai démarré Outlook 2007 et j'ai configuré une nouvelle connexion à MSN, sans utiliser le logiciel du connecteur. Outlook est allé sur Internet, a trouvé le serveur et a configuré le compte sans aucune difficulté. J'ai ensuite reproduit l'expérience pour mes autres comptes POP3. J'ai obtenu l'accès à mes messages électroniques, tout en apprenant une nouvelle fonctionnalité géniale du logiciel.
Voici la morale de mon histoire. Si quelqu'un du support technique avait pris la peine d'essayer le nouveau produit, il m'aurait probablement dit que je n'avais pas besoin du connecteur, et il nous aurait fait gagner beaucoup de temps à tous les deux.
Ou encore : si, moi, je l'avais essayé dès le départ, j'aurais probablement trouvé la solution tout seul. Mais au lieu de cela, je voulais que quelqu'un d'autre me donne la réponse. Et parce que personne n'avait pris le temps d'essayer un outil qui est, après tout, important dans notre vie de tous les jours, nous avons tous les deux perdu plus de temps que si nous avions tous les deux cherché et trouvé la solution chacun de notre côté.
L'évolution de la technologie met nos hypothèses en échec. Pour être des informaticiens professionnels, nous devons nous débarrasser de nos idées préconçues. Les connaissances que nous obtenons à grands coups d'efforts sont celles que la nouvelle technologie va supplanter, parce que c'est en remplaçant ces connaissances que la technologie devient plus facile à utiliser. Nous ne pourrons pas toujours nous servir de ces connaissances d'initiés comme avantage compétitif. Le futur de l'informatique n'appartient pas à ceux qui accumulent des connaissances poussiéreuses sur la façon dont la technologie fonctionnait avant, mais plutôt à ceux qui ont la capacité de maîtriser de nouveaux concepts et de nouvelles techniques. En apprenant continuellement, en intégrant cet apprentissage dans notre routine, nous aiguisons ces compétences. Étant donnée la vitesse vertigineuse à laquelle les nouveaux logiciels se créent et se distribuent, l'apprentissage doit demeurer notre mode de vie.
Alors, si vous cherchez à me joindre, vous pouvez m'envoyer un message électronique sur mon compte Microsoft ou mon compte MSN : je peux lire mes deux messageries avec Outlook 2007 !

Mark D. Scott est un consultant senior dans l'équipe Microsoft Consulting Services. Il travaille étroitement avec les clients pour aider à la conception et à la construction d'applications à grande échelle et orientées données. Vous pouvez joindre Mark à l'adresse suivante : granddaddy2002@msn.com ou mascott@microsoft.com.


 La vie secr&#232;te de Windows: Le pouvoir des bogues
La vie secrète de Windows
Le pouvoir des bogues
Raymond Chen

Dans Windows 95 , vous pouviez aller sur la page Dépannage et sélectionner Désactiver les validations de tampon synchrone. Mais savez-vous ce que faisait cette case ? Ou pourquoi elle faisait ce qu'elle faisait ?
Le comportement normal de la fonction de validation de MS-DOS® consistait à vider sur le disque toutes les données qui n'étaient pas écrites, et à attendre que l'écriture des données ait été validée avant le retour. Une fois l'option Désactiver les validations de tampon synchrone cochée, l'appel était immédiatement retourné, au lieu d'attendre que les données soient écrites. Cela était bien sûr une violation de la spécification fonctionnelle qui nécessite que l'appel ne soit pas retourné avec que les données n'aient été écrites. Cela augmentait le risque de ce que l'article 139669 de la Base de connaissance qualifie avec euphémisme de « problèmes d'intégrité du fichier », puisqu'il faisait croire au programme de vidage que les données étaient bien sur le disque alors que ce n'est pas le cas.
Un programme de base de données peut utiliser la fonction de validation pour établir des points auxquels l'état du fichier sur le disque est en accord avec ce que le programme s'attend à trouver sur le disque. Si l'ordinateur perd de la puissance pendant une mise à jour, le programme de la base de données peut utiliser les informations enregistrées au dernier point de validation pour rétablir l'intégrité de la base de données. Si la validation répondait immédiatement, avant que la validation ne soit terminée, ce point de contrôle d'intégrité était perdu. Par conséquent, votre base de données devenait corrompue.
Pourquoi cette option était-elle disponible si les conséquences étaient si terribles ? En voici la raison : un bogue dans Windows® 3.11.
Figure 1 Activation d'un comportement bogué dans Windows Server 2003
Figure 1 Activation d'un comportement bogué dans Windows Server 2003 (Cliquer sur l'image pour la réduire)
Figure 1 Activation d'un comportement bogué dans Windows Server 2003
Figure 1 Activation d'un comportement bogué dans Windows Server 2003 (Cliquer sur l'image pour l'agrandir)
Windows 3.11 proposait un « accès aux fichiers 32 bits », qui était une implémentation 32 bits de l'interface E/S du fichier de niveau inférieur. Mais l'implémentation de la fonction de validation contenait un bogue qui ignorait en fait les requêtes de vidage des tampons de fichier. Si vous preniez un programme qui vidait ses tampons de fichier et que vous le faisiez fonctionner sur Windows 3.11, l'appel de vidage n'avait aucun effet. Par conséquent, si vous perdiez de la puissance au mauvais moment, vous vous retrouviez avec une base de données corrompue.
L'équipe qui travaillait sur le système de fichiers de Windows 95 a réparé ce bogue, mais de nouveaux rapports sur les bogues ont commencé à apparaître. Le programme des comptes fournisseurs d'un utilisateur commençait à fonctionner vraiment lentement. Ensuite, c'était au tour d'un programme de base de données d'un autre utilisateur de tourner au ralenti. Qu'est-ce qui se passait ?
On s'est rendu compte que ces programmes faisaient sans arrêt des appels de vidage. Les programmeurs ont remarqué que ces appels de vidage étaient vraiment rapides sur Windows 3.11 : ils en ont donc mis un peu partout dans leurs programmes. Écrire un octet, vider. Écrire une chaîne, vider. Puisque les vidages étaient si rapides, l'application validait les données sur le disque après chaque opération, sans apparente dégradation des performances. Mais une fois que Windows 95 avait réparé le bogue, ces programmes ont commencé à fonctionner très lentement puisque les appels de validation se mettaient à vraiment fonctionner.
Bien sûr, si l'équipe du système de fichiers n'avait rien fait, ces programmes auraient continué à fonctionner lentement et les utilisateurs en auraient directement conclu que le problème venait de Windows 95. Ils se seraient empressés de dire à tout le monde : « Windows 95 marche comme un unijambiste ». D'un autre côté, si le système de fichiers était revenu à l'ancien comportement de Windows 3.11, les programmeurs auraient réintroduit un bogue qui pouvait provoquer ces fameux « problèmes d'intégrité du fichier ».
Ils ont finalement décidé de laisser la correction du bogue, mais d'ajouter une case à cocher (bien cachée dans la page Dépannage), pour retourner au comportement de Windows 3.11 pour les utilisateurs qui faisaient tourner des programmes sujets aux erreurs en raison de la correction du bogue.
Il s'est trouvé que l'histoire s'est répétée. Dans Windows Server® 2003, les gens de l'interface E/S ont découvert un bogue à cause duquel des requêtes appelées Forced Unit Access (FUA) perdaient leur balise FUA et fonctionnaient comme une E/S normale. C'est une version moderne du fait d'ignorer les requêtes de vidage ! Ils ont réparé le bogue mais ont laissé une option qui permet de revenir à l'ancien comportement bogué. La version Windows Server 2003 de cette case à cocher est appelée « Activer les performances avancées », mais vous savez maintenant ce qu'elle signifie vraiment : « Restaurer l'ancien comportement bogué ».

Raymond Chen possède un site Web, The Old New Thing, ainsi qu'un livre portant le même nom (éditions Addison-Wesley, 2007) qui traitent de l'historique de Windows et de la programmation Win32. Il ne passe pas son temps à chercher... le petit bogue.