 TechNet Magazine November 2007

TechNet Magazine November 2007

Administration de Windows: Modifications apportées aux fichiers hors connexion dans Windows Vista

C'est un problème courant : comment permettre aux utilisateurs de travailler sur des fichiers stockés sur le réseau lorsqu'ils disposent d'une connexion peu fiable ou inexistante, et éviter les problèmes de gestion des versions ? Une telle continuité est essentielle pour offrir une expérience transparente. Découvrez comment des améliorations apportées à Windows Vista offre une meilleure approche de l'utilisation des fichiers hors connexion.

Jeremy Moskowitz Déploiement de postes de travail: Un déploiement simple et évolutif avec BDD 2007

Vous ne possédez pas SMS 2003 ? Pas de problème. Il existe une autre solution pour créer des déploiements de postes de travail simples. Ce guide détaillé qui vous aidera à utiliser BDD 2007 et SQL Server pour créer des déploiements évolutifs nécessitant très peu d'entrées manuelles, voire aucune.

Adam Shepherd Communications: Serveurs de transport Edge Exchange chez Microsoft 2ème partie

Les serveurs de transport Edge Exchange peuvent vous aider à créer un environnement de messagerie plus fiable et plus sûr. Nous vous avons montré comment configurer ces serveurs dans la première partie et allons maintenant vous présenter quelques exemples détaillés illustrant la façon dont les fonctionnalités clés peuvent améliorer votre environnement de messagerie.

Kay Unkroth Mise en réseau: Configuration de l'accès à distance au VPN à l'aide d'ISA Server 2006

Un réseau privé virtuel peut permettre d'améliorer la connectivité et d'augmenter la productivité, sans être nécessairement difficile à implémenter et à gérer. Découvrez comment vous pouvez utiliser ISA Server 2006 pour résoudre deux scénarios de réseau privé virtuel courants.

Alan Maddison SQL Server: Optimisation des performances des requêtes SQL Server

Lorsque vous optimisez les performances de base de données, le réglage des requêtes individuelles est tout aussi important que le réglage du matériel des serveurs et des configurations logicielles. Une seule requête rebelle suffit à faire tomber une base de données. Voici un guide sur la création, l'analyse et la modification des plans d'exécution en vue de l'optimisation des performances de vos requêtes SQL Server.

Maciej Pilecki Le mot du rédacteur en chef: L'énergie entre vos mains

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

Greg Steen Questions et réponses sur la file d'attente Exchange: Protocoles de courrier électronique sécurisés, courrier indésirable mystérieux, et bien plus encore

Dans l'article de ce mois, l'équipe d'Exchange évoque le protocole TLS (Transport Layer Security) pour SMTP, la façon d'empêcher les rapports de non-remise trafiqués d'encombrer vos files d'attente et de la manière de résoudre diverses difficultés liées à l'installation.

Nino Bilic and Scott Landry Coup de projecteur sur les utilitaires: Applets de commande SMS pour Windows PowerShell

Découvrez comment vous pouvez utiliser les applets de commande de Windows PowerShell pour gérer les clients SMS 2003 à partir de la ligne de commande.

Don Brown Le petit câbleur: Authentification unique sans fil

L'authentification unique offre de nombreux d'avantages pour les utilisateurs finaux et les administrateurs. Examinons comment l'authentification unique peut simplifier l'implémentation de l'authentification sans fil pour votre réseau.

Joseph Davies Notes de recherche: Utilisation de l'informatique hautes performances dans la lutte contre le VIH

Découvrez comment l'équipe eScience de Microsoft Research collabore avec des chercheurs en médecine et utilise l'informatique hautes performances pour aider à trouver un remède contre le VIH.

Kristin Firth and Mia Matusow Windows PowerShell: Écriture d'expressions régulières

Avec une expression régulière bien écrite, un script Windows PowerShell peut déterminer si des données sont conformes ou non à un format valide. Découvrez comment utiliser les expressions régulières dans Windows PowerShell.

Don Jones Hé, vous le scripteur !: Secrets de gestion des ordinateurs de bureau d'outre-tombe

Les scripteurs montrent ici comment utiliser le service Gestion à distance de Windows pour récupérer les propriétés et les instances de classes sur un ordinateur distant. Oh, et il y a aussi une énigme amusante.

The Microsoft Scripting Guys Vigilance sécurité: Accès à distance sécurisé

Découvrez quelles sont les considérations de conception relatives à la sécurité et au réseau entrant dans la création d'une solution d'accès à distance utilisant des composants Terminal Server, ainsi que des méthodes pratiques et recommandées pour le développement d'une solution à l'aide de Windows Server 2008.

John Morello Histoires de Bureau: La vérité sur la défragmentation

Les mythes entourant les pièges de la défragmentation ont empêché plus d'un administrateur d'exécuter cette importante tâche de maintenance. Découvrez quels problèmes sont réels, ceux qui sont peu probables et comment les éviter.

Wes Miller Sur le terrain: Le Cod de conduite

Lorsque les membres d'une communauté commencent à faire des bêtises, peut-être avez-vous simplement besoin d'un gros poisson. Découvrez comment l'ingénierie sociale a aidé à sauver Live QnA.

Betsy Aoki La vie secrète de Windows: Le paradoxe du système de fichiers

Vous êtes-vous jamais demandé pourquoi il est nécessaire d'avoir un pilote du système de fichiers miniature intégré aux fichiers de démarrage importants ?

Raymond Chen


 Administration de Windows: Modifications apport&#233;es aux fichiers hors connexion dans Windows&#160;Vista
Administration de Windows Jeremy Moskowitz

Modifications apportées aux fichiers hors connexion dans Windows Vista
Vue d'ensemble:
  • Continuité en ligne et hors connexion
  • Disponibilité des fichiers
  • Évolution des dossiers hors connexion

L'un des problèmes principaux de la gestion des ordinateurs de bureau est de permettre aux utilisateurs hors connexion de travailler comme s'ils étaient en ligne. Ce besoin est bien plus important que vous ne pourriez le penser : les utilisateurs sont beaucoup plus mobiles qu'ils ne l'étaient il y a cinq ans. Bien que l'on puisse citer plusieurs cas où vous pourriez avoir besoin de travailler
hors connexion, les trois situations les plus courantes sont : lorsque vous déconnectez votre portable du réseau du bureau et partez en déplacements, lorsque vous vous connectez sur une liaison lente ou intermittente et lorsque votre succursale perd la connexion au site principal.
Dans ces circonstances, comment faire pour conserver une copie d'un fichier sur l'ordinateur hors connexion alors que l'original est toujours sur le serveur principal ? Plus important encore, comment résoudre un conflit si un utilisateur du site principal modifie le fichier sur le serveur alors qu'un utilisateur itinérant le modifie pendant un déplacement ? La bonne nouvelle est que ces problèmes sont gérés par le moteur de fichiers hors connexion intégré à Windows® 2000, Windows XP et Windows Vista®.

La solution réside dans la mise en cache
Le moteur de fichiers hors connexion est en réalité une machine de mise en cache géante. En effet, dans les coulisses (et chez Microsoft), il est appelé mise en cache côté client (CSC, Client-Side Caching). Le moteur de fichiers hors connexion est suffisamment configurable et flexible pour permettre aux utilisateurs de décider ce qu'ils veulent mettre en cache et vous aider à faire en sorte que le système mette en cache ce que vous souhaitez. Il permet d'accéder aux mêmes fichiers hors connexion qu'en ligne, sans que l'espace de noms ne change. En d'autres termes, les fichiers sont accessibles via le même chemin d'accès UNC ou la même lettre de lecteur, que vous travailliez en ligne ou hors connexion.
Vous pouvez configurer les fichiers de sorte qu'ils soient mis en cache manuellement ou automatiquement. Si vous savez que vous utilisez souvent des fichiers ou des dossiers particuliers lorsque vous êtes en déplacement, vous pouvez désigner un fichier ou un dossier comme devant être disponible. Pour ce faire, dans Windows XP, vous devez cliquer avec le bouton droit de la souris sur un fichier stocké localement ou sur un partage réseau, puis sélectionner l'option permettant de rendre les fichiers disponibles hors connexion (voir figure 1). Dans Windows Vista, cette option est appelée Toujours disponible hors connexion. L'opération consistant à rendre un fichier disponible hors connexion est parfois appelée « épinglage de fichier ».
Figure 1 Mise à disposition d'un fichier hors connexion
Figure 1 Mise à disposition d'un fichier hors connexion
Figure 1a Dossier des fichiers hors connexion
Figure 1a Dossier des fichiers hors connexion
Le partage que vous utilisez peut être connecté à l'aide du chemin d'accès UNC ou mappé sur une lettre de lecteur. En effet, le fichier n'a même pas besoin d'être stocké sur un ordinateur exécutant Windows Server®. Il peut résider dans tout emplacement compatible avec le protocole SMB (Server Message Block), tel qu'un serveur Samba ou un périphérique NAS (à quelques rares exceptions près), qui adhèrent également au protocole SMB.
La première fois que vous choisissez d'épingler un fichier, Windows XP vous guide tout au long d'une série d'écrans d'Assistant pour vous permettre de déterminer quand vous voulez effectuer la synchronisation. Si vous cliquez sur Suivant dans chaque écran et que vous acceptez les configurations par défaut, la synchronisation se produit chaque fois que vous ouvrez ou fermez une session, ainsi qu'en arrière-plan en mode inactif. Lorsque l'Assistant est terminé, une icône change pour indiquer que le fichier est maintenant disponible hors connexion.
Lorsque vous vous déconnectez du réseau, tous les autres fichiers du partage deviennent indisponibles, sauf ceux que vous avez choisis pour une utilisation hors connexion. Cela peut parfois s'avérer problématique : l'icône indique quels fichiers sont toujours disponibles hors connexion, mais vous ne savez pas toujours avant de vous déconnecter que les autres fichiers ne sont pas tous accessibles. J'aborderai ceci plus en détails plus loin dans l'article.
La mise à disposition manuelle des fichiers hors connexion présente des avantages, mais il peut être préférable de le faire de façon plus automatisée. J'explorerai ce scénario ci-dessous, en utilisant ce que l'on appelle souvent la mise en cache automatique.

Avantages de la mise en cache automatique par rapport à la mise en cache manuelle
La mise en cache automatique est configurée pour chaque partage d'un serveur. Par conséquent, si vous disposez d'un partage appelé Ventes et que souhaitez permettre aux vendeurs d'utiliser leurs fichiers lors de leurs déplacements, vous pouvez indiquer au moteur CSC de les rendre disponibles. La figure 2 illustre la boîte de dialogue Paramètres hors connexion qui apparaît lorsque vous cliquez sur l'onglet Mise en cache dans Windows Server 2003. Les paramètres sont expliqués à la figure 3.
Figure 3 Paramètres de mise en cache automatique (Close Figure 3)

Paramètre | Description
Seuls les fichiers et les programmes spécifiés par utilisateurs sont disponibles hors connexion. | Permet aux utilisateurs de spécifier manuellement les fichiers devant être disponibles hors connexion. Il s'agit du comportement par défaut.
Tous les fichiers et les programmes ouverts par les utilisateurs à partir de la ressource partagée seront automatiquement disponibles hors connexion. | Permet la mise en cache automatique de tous les fichiers et programmes touchés par l'Explorateur Windows. Le paramètre Optimisé pour les performances est utilisé lors de la mise en cache des programmes et non des documents, mais il n'a pas généralement d'effet sur les performances et peut être ignoré dans la plupart des cas. Il est complètement ignoré par Windows Vista.
Les fichiers ou les programmes de la ressource partagée ne seront pas disponibles hors connexion. | Bloque l'accès utilisateur à l'option Rendre disponible hors connexion lorsqu'elle est utilisée sur un client Windows 2000, Windows XP, ou Windows Vista.
Figure 2 Boîte de dialogue Paramètres hors connexion de Windows Server 2003
Figure 2 Boîte de dialogue Paramètres hors connexion de Windows Server 2003
Pour comprendre comment la mise en cache automatique fonctionne, supposons que vous avez un partage appelé Ventes contenant 10 fichiers (Ventes01.txt à Ventes10.txt) et que vous avez activé le paramètre appelé Tous les fichiers, et que les programmes que les utilisateurs ouvrent sur le partage sont automatiquement disponibles hors connexion. Les résultats ne sont pas tout de suite évidents. Rien n'indique à l'utilisateur que des fichiers supplémentaires sont disponibles hors connexion. De plus, seuls les fichiers qui sont ouverts par Windows (et donc mis en cache) sont disponibles pour être utilisés hors connexion. En bref, vous devez d'abord ouvrir en ligne les fichiers que vous voulez utiliser hors connexion avant de vous déconnecter du réseau. Á défaut, ils ne seront pas disponibles hors connexion lorsque vous en aurez besoin.
De plus, les fichiers qui sont mis en cache automatiquement ne resteront pas nécessairement très longtemps en cache. Windows XP et Windows Vista ont une façon différente de gérer cet espace temporaire, mais ce qui est important, c'est que les fichiers peuvent être supprimés du cache en fonction des contraintes d'espace. Les fichiers sont conservés suivant leur utilisation. Ceux qui n'ont pas été ouverts pendant un certain temps sont supprimés pour laisser la place aux nouveaux fichiers à mesure qu'ils sont ouverts. Par conséquent, bien qu'il y ait une grande probabilité qu'un fichier ouvert récemment soit encore en cache, la mise en cache automatique ne garantit pas qu'un fichier soit disponible. Si vous voulez être sûr qu'un fichier est disponible, vous devez l'épingler. En tant qu'administrateur, vous pouvez également utiliser la stratégie de groupe pour épingler des fichiers à l'aide du paramètre Fichiers hors connexion assignés administrativement.
Examinons un exemple réel. Supposons qu'un utilisateur de Windows XP nommé UtilisateurVentesEst1 ait ouvert un fichier nommé Ventes05.txt et qu'un utilisateur de Windows Vista nommé UtilisateurVentesEst2 ait ouvert Ventes05.txt sur le partage \\server\ventes.
Dans la mesure où la mise en cache automatique a été définie sur le partage Ventes, lorsque l'utilisateur UtilisateurVentesEst11 (sous Windows XP) et l'utilisateur UtilisateurVentesEst2 (sous Windows Vista) se sont déconnectés, ces fichiers sont restés accessibles. Windows a conservé une copie de ces fichiers dans le cache de fichiers hors connexion. Qu'en est-il des autres fichiers que les utilisateurs n'ont pas encore utilisés ?
Windows XP et Windows Vista gèrent différemment les fichiers non ouverts, comme vous pouvez le voir aux figures 4 et 5. Windows XP ne donne aucune indication que certains fichiers n'ont pas été mis en cache. Lorsque vous vous déconnectez, ces fichiers disparaissent tout simplement, ce qui peut être quelque peu déroutant. Windows Vista, en revanche, comprend superposition d'image sur icône et affiche un petit X grisé en regard des fichiers qui ne sont pas en cache. Il s'agit d'un énorme progrès au niveau de l'affichage des fichiers disponibles hors connexion. Le seul problème est que vous ne le voyez qu'après vous être déconnecté, et non pendant la session en ligne. Il serait donc utile de rendre l'état d'un fichier plus explicite.
Figure 4 Windows XP indique uniquement les fichiers disponibles une fois que vous vous déconnectez.
Figure 4 Windows XP indique uniquement les fichiers disponibles une fois que vous vous déconnectez.
Figure 5 Windows Vista affiche les fichiers non disponibles lorsque vous êtes déconnecté.
Figure 5 Windows Vista affiche les fichiers non disponibles lorsque vous êtes déconnecté.

Disponibilité ou non disponibilité
Certains administrateurs hésitent à tirer parti des fichiers hors connexion précisément à cause de cette confusion potentielle : quels fichiers sont véritablement disponibles hors connexion et lesquels ne le sont pas, et comment les reconnaître. Á la figure 5, l'icône de cercle verte sur le fichier Ventes01.txt indique que le fichier est disponible (encore une fois, lorsque les fichiers sont épinglés, cela signifie que le fichier sera toujours disponible hors connexion).
Cependant, comme j'ai expliqué, Ventes05.txt, qui a été mis à disposition hors connexion grâce à la mise en cache automatique dans Windows XP et Windows Vista, n'est pas nécessairement disponible hors connexion. Rappelez-vous, seuls les fichiers que vous touchez deviennent disponibles hors connexion. Il serait donc préférable que le système indique que les fichiers sont temporairement ou éventuellement disponibles hors connexion. Puisqu'il n'y a pas d'icône les différenciant, il peut être difficile de déterminer quels fichiers seront disponibles hors connexion. Bien que l'interface utilisateur de Windows Vista soit meilleure, il faut avoir un œil aiguisé pour le voir. Une propriété de l'Explorateur de Windows Vista appelée Disponibilité hors connexion fournit les informations de disponibilité. Cette propriété s'affiche dans le volet d'aperçu lorsqu'un élément est sélectionné. Si l'élément est épinglé, sa valeur est « Toujours disponible ». S'il n'est pas épinglé mais qu'il est mis en cache, sa valeur est « Disponible ».
Le concept des fichiers temporairement disponibles hors connexion est similaire dans Windows XP et Windows Vista, mais sa mise en œuvre est légèrement différente. La figure 6 illustre la façon dont Windows XP et Windows Vista gèrent les fichiers hors connexion.
Figure 6 Zones de fichiers hors connexion dans Windows XP et Windows Vista
Figure 6 Zones de fichiers hors connexion dans Windows XP et Windows Vista
En deux mots, Windows XP et Windows Vista disposent d'un emplacement dans lequel les fichiers hors connexion sont conservés, mais les fichiers hors connexion toujours disponibles et les fichiers temporairement disponibles hors connexion sont enregistrés de façon différente pour chaque système d'exploitation.
Sous Windows XP, les fichiers qui sont toujours disponibles hors connexion (indiqués par le changement d'icône comme illustré à la figure 1) sont placés à un endroit où ils sont conservés de façon permanente. Si vous épinglez 10 Go de fichiers manuellement, les rendant ainsi toujours disponibles hors connexion, les 10 Go seront toujours disponibles. Il n'y a pas de limite au nombre de fichiers qu'un utilisateur peut épingler (en dehors de la taille de partition maximale). Cependant, Windows XP définit un maximum de 2 Go pour les fichiers mis en cache automatiquement. L'idée est que seuls les fichiers qui sont régulièrement ouverts sont stockés à cet endroit tandis que ceux qui n'ont pas été utilisés pendant un certain temps sont supprimés lorsque c'est nécessaire. Par défaut, le cache des fichiers temporairement disponibles se voit attribuer 10 % de l'espace libre sur le disque dur, comme illustré à la figure 7. Ce paramètre est uniquement disponible pour les administrateurs sous Windows XP.
Figure 7 Définition de l'espace disque pour les fichiers hors connexion sous Windows XP
Figure 7 Définition de l'espace disque pour les fichiers hors connexion sous Windows XP
Windows Vista peut également enregistrer des fichiers de façon permanente ou temporaire. Cependant, il existe une différence. Le cache de fichiers temporaires est contenu dans le cache général. Par défaut, le cache entier (à la fois Fichiers temporaires et Fichiers hors connexion toujours disponibles) est limité à 25 % de l'espace libre sur le disque dur. La raison pour laquelle ceci a été modifié est que sous Windows XP, un utilisateur pouvait continuer à mettre en cache manuellement des fichiers (peut-être plusieurs dizaines de giga-octets) et ne plus avoir d'espace disponible sur le disque dur. Dans le nouveau schéma, l'administrateur met de côté une quantité spécifique d'espace pour le cache entier de façon à ce que cela ne puisse pas arriver. Si vous observez la figure 8, vous remarquerez que 25 % de l'espace libre sur le lecteur est indiqué comme 15,2 % du lecteur entier. Notez également que le deuxième curseur, qui détermine l'espace temporaire, ne peut jamais être défini sur une valeur plus élevée que le premier curseur, qui détermine l'espace maximal de tous les fichiers hors connexion. Ces curseurs Limites d'utilisation du disque par les fichiers hors connexion sont accessibles en cliquant sur l'option Modifier les limites, mais sachez que vous devez fournir les informations d'identification d'administrateur.
Figure 8 Espace disponible pour les fichiers hors connexion sous Windows Vista
Figure 8 Espace disponible pour les fichiers hors connexion sous Windows Vista

Comment empêcher la mise en cache d'une trop grande quantité de fichiers
La redirection de dossiers est une autre fonctionnalité de Windows qui vous permet de faire en sorte que ces certains dossiers clé normalement stockés localement sur l'ordinateur soient enregistrés sur les serveurs. L'idée est que vous n'avez pas à vous inquiéter si cet ordinateur local tombe en panne ; vous disposez d'une copie des fichiers importants sur un partage réseau.
Supposons que vous disposez d'un dossier Mes Documents (Windows XP) ou d'un dossier Documents (Windows Vista) redirigé. Dans ce cas (et en fait pour tout dossier redirigé), le système d'exploitation suppose que vous voulez toujours rendre ces fichiers disponibles hors connexion et chaque fichier du dossier redirigé est marqué du symbole illustré à la figure 1. L'inconvénient est que si vous êtes sur un réseau bien connecté et toujours en ligne et que vous passez sur un nouvel ordinateur, vous mettez en cache le contenu entier du dossier redirigé sur le nouvel ordinateur, même si vous aviez seulement l'intention de l'utiliser pour une session. Cela représente non seulement une perte d'espace, mais aussi un risque en matière de sécurité si cela n'est pas correctement contrôlé.
Un autre cas où les fichiers sont automatiquement mis en cache sans que vous ne le sachiez est lorsque vous utilisez l'Explorateur Windows pour parcourir les fichiers sur un partage. Si vous parcourez une poignée de fichiers graphiques sur un partage réseau avec l'Explorateur et que la mise en cache automatique est activée, il est très probable que ces fichiers seront automatiquement téléchargés et placés dans votre cache. Cela est dû au fait qu'une simple manipulation d'un fichier avec l'Explorateur suffit pour le mettre dans le cache hors connexion temporaire. Il arrive souvent que tous les fichiers d'un partage soient touchés lorsque vous affichez des métadonnées telles que la taille des fichiers ou un aperçu d'une image. Si cette situation se produit avec une liaison rapide et fiable, cela ne pose pas vraiment de problème. Windows met rapidement en cache le fichier pour une utilisation ultérieure. Cependant, lorsque vous êtes connecté à ce partage réseau avec la mise en cache automatique sur une liaison lente, les choses peuvent se détériorer. La situation est fondamentalement identique par défaut qu'il s'agisse de l'Explorateur Windows XP ou Windows Vista. La bonne nouvelle, c'est que le moteur de mise en cache hors connexion de Windows Vista peut être défini pour mieux reconnaître une liaison lente.

Fichiers hors connexion avec la stratégie de groupe
Modifications importantes apportées aux fichiers hors connexion dans Windows Vista
Nous aimerions vous faire part de toutes les modifications apportées aux fichiers hors connexion, mais nous ne pouvons pas toutes les explorer dans cet article. Par conséquent, voici un résumé des principales modifications apportées aux fichiers hors connexion :
  1. La transition transparente entre l'état en ligne et l'état hors connexion se traduit par le fait que les descripteurs ouverts ne bloquent plus cette transition.
  2. Granularité hors connexion par fichier pour que le partage hors connexion n'occupe plus le serveur entier hors connexion.
  3. Mode hors connexion forcé à l'aide d'un bouton Travailler en ligne\hors connexion dans l'Explorateur Windows.
  4. Chiffrement par utilisateur du contenu mis en cache.
  5. Nouveau moteur de synchronisation pouvant détecter et analyser les modifications beaucoup plus rapidement.
  6. Intégration avec Windows Search permettant l'indexation des dossiers redirigés.
  7. Synchronisation locale/distante capable d'utiliser la fonctionnalité de transfert Bitmap différentiel
  8. Résolution différée des conflits à l'aide du Centre de synchronisation.
  9. Suppression des info-bulles gênant l'utilisateur.
  10. Nouvelle prise en charge complète de l'API COM et de WMI pour la gestion ; celle-ci est décrite sur MSDN® à l'adresse msdn2.microsoft.com/bb530662.
  11. Prise en charge de script par l'intermédiaire d'un fournisseur WMI (qui sera bientôt décrite sur MSDN).
  12. Nouvelles propriétés de l'élément d'environnement de ligne de commande État hors connexion et Disponibilité hors connexion.
  13. Duplication permettant de représenter les éléments d'espace de noms non disponibles hors connexion. L'Explorateur les affiche sous forme d'un X gris superposé sur des éléments grisés pour éviter d'avoir des modifications radicales de l'affichage du dossier shell lors du passage de l'état en ligne à l'état hors ligne.
  14. Nouvelle applet du Panneau de configuration.
Vous trouverez des informations supplémentaires sur ces fonctions dans mon livre et dans la documentation Microsoft.

Comme nous l'avons noté, lorsqu'un utilisateur (ou l'Explorateur) touche un fichier, le fichier entier est placé dans le cache. Et si ce fichier est un document Visio® ou Word de 80 Mo, tant pis. Windows XP et Windows Vista comprennent le concept de liaison lente. En effet, par défaut, Windows XP pense qu'une liaison lente correspond à 64 Kbps. Si la vitesse de connexion est supérieure à celle-ci et que le client est Windows XP, ce fichier est téléchargé via cette liaison lente lors de l'ouverture de session, à la grande consternation de l'utilisateur. Il est donc préférable de configurer Windows pour mieux gérer les ralentissements de liaison. Comme nous allons le voir dans un moment, vous pouvez pour cela utiliser la Stratégie de groupe en créant un objet de stratégie de groupe (GPO) à lier à une unité d'organisation contenant les comptes ciblés (Windows XP ou Windows Vista).
Lorsque l'utilisateur se connecte sur une liaison lente, Windows XP tente d'utiliser les fichiers mis en cache localement avant de tenter d'utiliser la copie sur le réseau, ce qui est logique. En revanche, Windows XP présente un autre comportement qui peut sembler plus surprenant : il télécharge dans le cache les fichiers volumineux qui n'y sont pas encore présents si l'utilisateur les ouvre à partir du réseau ou si l'Explorateur les touche. Ergh. Et d'après mon expérience, si la synchronisation est planifiée pour se produire lors de la déconnexion (par défaut), le reste de ces fichiers est ensuite téléchargé sur la liaison lente et mis en cache. (Deux fois Ergh.)
Le comportement de Windows Vista est différent. Il ne reconnaît aucune situation comme lente par défaut. En effet, même si vous vous connectez sur une liaison de 1 bit par seconde, Windows Vista traite cette connexion comme rapide et utilise la copie des fichiers sur le réseau. Toutefois, Windows Vista peut apprendre à reconnaitre quels partages vous souhaitez désigner pour la transition hors connexion lorsque la connexion est lente. Lorsqu’un tel scénario se produit, les choses s'améliorent un peu. Le comportement de Windows Vista (une fois configuré à l'aide de la Stratégie de groupe) est tel que le contenu de ces partages définis par liaison lente est simplement non disponible avec une liaison lente utilisant des opérations de fichier normales et de l'Explorateur.
La synchronisation d'arrière-plan exécutée par les fichiers hors connexion n'a pas lieu sur une connexion lente. Cependant, il est important de noter que la synchronisation manuelle peut être exécutée à l'aide du Centre de synchronisation.
Pour configurer Windows Vista afin de modifier sa gestion des liaisons lentes, vous devez utiliser le paramètre de Stratégie de groupe Configurer le mode de liaison lente (à ne pas confondre avec le paramètre Windows XP Configurer la vitesse de la liaison lente). Le paramètre Configurer le mode de liaison lente peut prendre les valeurs suivantes : le nom des serveurs et partages qui doivent effectuer automatiquement la transition hors connexion lorsque la connexion est lente, et quelle vitesse cette connexion doit atteindre pour que cette combinaison serveur\partage soit disponible hors connexion. La combinaison serveur\partage peut être toute combinaison \\server\partage ou tout simplement une seule étoile (*) pour indiquer tous les partages de tous les serveurs. La deuxième série de valeurs est la déclaration du débit (en Kbits/s) et la latence (en millisecondes) qui doivent être atteintes pour que la connexion soit déclarée lente. La « bonne » nouvelle, c'est que la plus utile des deux (débit) n'est pas vérifiée lors du téléchargement de fichiers. Par conséquent, si vous avez 10 Go de fichiers dans un dossier Documents redirigé et que vous utilisez une connexion lente sur un portable qui ne contient pas encore ces fichiers, soyez prêt à attendre un certain temps. Cependant, si vous l'associez à une vérification de la latence, et que la latence passe au-dessous de la valeur prescrite, le partage passe à l'état hors connexion, épargnant à l'utilisateur de longs temps d'attente.
Le correctif pour Windows Vista de l'article 934202 de la base de connaissances (modification dont l'inclusion est prévue avec Windows Vista Service Pack 1) devrait améliorer les performances dans certaines conditions de VPN lentes (cet article est disponible en ligne à l'adresse support.microsoft.com/kb/934202) En fait, ce correctif devrait permettre la vérification de la valeur de débit lorsque le téléchargement a lieu sur une connexion lente.

Conflits de synchronisation
Vous vous demandez probablement ce qui arrive si quelqu'un modifie un fichier hors connexion (lors d'un déplacement par exemple), alors qu'une autre personne le modifie en ligne (sur le site principal). Cette situation est gérée au niveau du client. Lorsque vous passez de l'état en ligne à l'état hors connexion, la synchronisation en arrière-plan des fichiers hors connexion de Windows Vista se produit immédiatement. Vous êtes ensuite invité à indiquer quelle action vous souhaitez entreprendre (via une entrée du Centre de synchronisation après qu'une icône apparaît dans la zone de notification de la barre des tâches). L'interface utilisateur a été repensée pour indiquer qu'un fichier semble être nouveau et afficher plus d'informations sur la collision. Lors de l'enregistrement des fichiers sur le serveur, les utilisateurs peuvent conserver des fichiers avec des collisions en choisissant de renommer le fichier qui se situe actuellement uniquement sur leur ordinateur, comme illustré à la figure 9.
Figure 9 Notification de conflit de modification de fichier dans Windows Vista
Figure 9 Notification de conflit de modification de fichier dans Windows Vista

Vous souhaitez en savoir plus ?
Les fichiers hors connexion sont une fonctionnalité très utile pour vous et vos utilisateurs. En effet, si vous utilisez la redirection de dossiers, vous utilisez déjà cette fonctionnalité et son amélioration ne peut être que dans votre intérêt. J'ai mentionné plusieurs modifications des fichiers hors connexion dans Windows Vista, mais pas toutes. Pour plus d'informations, consultez l'encadré sur les principales modifications des fichiers hors connexion dans Windows Vista.
Vous trouverez de plus amples informations sur les fichiers hors connexion à l'adresse go.microsoft.com/fwlink/?LinkId=98141 pour Windows XP et go.microsoft.com/fwlink/?LinkId=98138 pour Windows Vista.
Mon livre contient également une large section consacrée aux fichiers hors connexion, où est décrit en détail chaque paramètre de la Stratégie de groupe (voir la bibliographie à la fin de l'article). Enfin, si vous souhaitez obtenir encore plus d'informations et partager vos expériences des fichiers hors connexion avec d'autres personnes, visitez le site GPanswers.com, dont le forum de communauté contient une section consacrée à ce sujet.

Jeremy Moskowitz MCSE et MVP Group Policy, administre GPanswers.com, un forum communautaire sur la Stratégie de groupe. Il est également responsable d’un ensemble d’ateliers de formation intensive sur la Stratégie de groupe. Son dernier ouvrage est intitulé Group Policy: Management, Troubleshooting and Security (Sybex, 2007). Pour en savoir plus, vous pouvez contacter Jeremy à l'adresse www.GPanswers.com.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 D&#233;ploiement de postes de travail: Un d&#233;ploiement simple et &#233;volutif avec BDD&#160;2007
Déploiement de postes de travail Adam Shepherd

Un déploiement simple et évolutif avec BDD 2007
Vue d'ensemble:
  • Fonctionnalités de base de BDD 2007
  • Intégration à SQL Server
  • Création d'une solution de déploiement évolutive

La plupart des personnes impliquées dans le déploiement de Windows ont entendu parler de Microsoft Solution Accelerator for Business Desktop Deployment. Également connu sous le nom de BDD, il s'agit d'un ensemble de bonnes pratiques et d'outils
développés pour vous aider à déployer Windows® sur les postes de travail clients. Windows Vista® comprend une mise à jour de Solution Accelerator sous la forme de BDD 2007. Cette version contient une nouvelle version de Microsoft® Management Console (MMC) et un séquenceur de tâches provenant de System Center Configuration Manager 2007, le successeur de Systems Management Server (SMS) 2003.
L'une des fonctionnalités les moins comprises de BDD 2007 est sa capacité à fonctionner comme une solution de déploiement complète. Dans les versions précédentes, BDD vous aidait à créer et à assurer la maintenance des images de postes de travail de façon facilement gérable et reproductible. BDD 2007 vous offre maintenant la possibilité supplémentaire de générer une solution de déploiement évolutive en combinant BDD avec les Services de déploiement Windows (WDS), SQL ServerTM et le service de réplication de système de fichiers (DFS-R) de Windows Server® 2003.
Mais attendez ... l'utilisation de SMS 2003 avec le Pack de déploiement de système d'exploitation (OSD) ne constitue-t-elle pas la pratique recommandée pour le déploiement du client Windows ?
Effectivement, si vous possédez déjà une infrastructure SMS 2003, vous devez utiliser BDD 2007, SMS 2003 et le Pack de déploiement de système d'exploitation pour le déploiement. C'est actuellement la façon la plus complète de réaliser un déploiement « zero-touch » et de réduire véritablement les coûts de configuration, d'installation et de gestion de Windows dans votre entreprise.
Cependant, un grand nombre de clients ne disposent pas de SMS 2003 ou d'une solution de déploiement logiciel équivalente. Pour ces clients, il existe une autre possibilité que je vais expliquer dans cet article.

Concepts de base de BDD 2007
BDD 2007 propose deux principales méthodes de déploiement. La première, l'installation Lite Touch (LTI), utilise uniquement BDD 2007 pour le déploiement du client. Dès l'installation, vous disposez d'un ensemble d'Assistants qui apparaissent au moment de la création pour capturer les informations relatives au déploiement, telles que le nom d'ordinateur à attribuer au client (voir la figure 1), la configuration du clavier et le fuseau horaire, etc. Cette méthode est appelée « Lite Touch » car, en général, elle ne requiert qu'un minimum d'entrées manuelles pour recueillir ces informations avant d'entamer le processus de création.
Figure 1 Assistant de déploiement LTI de BDD 2007
Figure 1 Assistant de déploiement LTI de BDD 2007
La deuxième méthode, l'installation « Zero-touch » (ZTI), s'appuie sur les fonctionnalités de SMS 2003 avec Pack de déploiement de système d'exploitation en s'intégrant à BDD 2007. Cette configuration peut offrir une solution de déploiement sans intervention, entièrement automatisée, évolutive et gérable.
Lors de la création, pendant l'une des premières étapes d'un déploiement de système d'exploitation client, BDD 2007 rassemble les informations issues de toute une série de sources différentes, telles que les appels WMI et les fichiers de configuration BDD 2007, Bootstrap.ini et CustomSettings.ini. Les informations sont recueillies et enregistrées sous forme de variables utilisées tout au long du déploiement. Dans un scénario LTI, les fichiers Bootstrap.ini et CustomSettings.ini permettent de prédéfinir toutes les informations qui sont habituellement recueillies par les saisies manuelles dans les Assistants de déploiement.
La possibilité de spécifier à l'avance toutes les informations que les Assistants LTI doivent sinon capturer au moment de la création vous permet d'automatiser l'ensemble du processus de déploiement LTI et d'évoluer vers une solution ZTI dans les environnements qui ne sont pas pris en charge par SMS 2003. Vous pouvez par exemple choisir de prédéfinir des informations telles que ComputerName=RDG0001VST pour attribuer à l'ordinateur un nom de RDG0001VDT ou TimeZoneName = GMT pour vous assurer que le fuseau horaire de l'ordinateur est réglé sur GMT - Heure de Greenwich. Toutes les propriétés disponibles pouvant être utilisées au cours d'un déploiement avec BDD sont très clairement décrites dans une référence de configuration disponible à l'adresse technet.microsoft.com/library/bb490302.aspx.
Pour plus d'informations sur la configuration et l'utilisation de BDD 2007, reportez-vous à l'article « Déploiement de Windows Vista avec BDD 2007 » du numéro de septembre 2007 de TechNet Magazine (technetmagazine.com/issues/2007/09/BDD).

BDD et SQL Server
Pourquoi utiliser une base de données avec BDD 2007 ? La réponse réside dans la façon dont vous fournissez dynamiquement les détails pendant un déploiement au cours duquel vous devriez sinon faire une saisie manuelle via les Assistants d'installation LTI. Comme je l'ai indiqué, vous pouvez le faire à l'aide du fichier CustomSettings.ini. Le problème est que dans un déploiement grandeur nature, ces détails changent en fonction de la machine sur laquelle s'effectue le déploiement. Par ailleurs, le fichier CustomSettings.ini peut rapidement devenir ingérable si vous essayez de définir des options et des paramètres spécifiques pour 500 machines différentes. En associant une base de données principale à la console BDD, vous ajoutez une solution beaucoup plus gérable, à la fois dynamique et évolutive.
Voyons maintenant comment SQL Server s'intègre à BDD 2007. Vous devez tout d'abord vous assurer que SQL Server (de préférence SQL Server 2005 ou ultérieur) est installé sur votre serveur de déploiement. Heureusement, les étapes de création de la base de données dans BDD 2007 sont simples : Il vous suffit de cliquer avec le bouton droit sur le nœud Database dans BDD 2007 Deployment Workbench, de cliquer sur New et de suivre les instructions (voir la figure 2). L'équipe de BDD s'est donnée beaucoup de peine pour proposer des Assistants qui vous permettent d'être rapidement et facilement opérationnel.
Figure 2 Configuration de la base de données de déploiement pour BDD 2007
Figure 2 Configuration de la base de données de déploiement pour BDD 2007
Une fois la base de données créée, vous pouvez commencer à explorer ses fonctionnalités. Les entrées de la base de données sont divisées en quatre catégories principales : Computer (Ordinateur), Role (Rôle), Location (Emplacement), et Make and Model (Marque et Modèle). Chaque catégorie vous permet de définir des entrées et, pour chaque entrée que vous définissez, d'indiquer des variables BDD 2007, d'attribuer des applications et de fournir d'autres paramètres essentiels (voir la figure 3).
Figure 3 Attribution des propriétés de déploiement
Figure 3 Attribution des propriétés de déploiement
Il est intéressant d'examiner ces quatre catégories en deux groupes distincts. Les catégories Computer (Ordinateur), Location (Emplacement), et (Make and Model (Marque et Modèle) offrent différentes méthodes d'identification des ordinateurs au moment de la création. Chaque ordinateur identifié peut ensuite être associé à un Rôle spécifique dans la base de données s'il est configuré pour un but spécifique, tel que la vente, le marketing ou la finance. Chaque rôle garantit que la ligne d'applications métier pertinentes est installée.
Utilisez la section Computer (Ordinateur)) pour identifier les ordinateurs en utilisant une adresse MAC, un numéro d'identification, un identificateur unique universel (UUID) ou un numéro de série. Du fait du grand nombre d'entrées qui seront probablement créées dans cette section, une pour chaque ordinateur de votre entreprise, n'ajoutez que des propriétés très spécifiques telles que ComputerName dans chaque entrée.
Utilisez la section Location (Emplacement) afin de créer des entrées pour les emplacements géographiques propres à votre entreprise. Chaque entrée est identifiée par la passerelle par défaut à cet emplacement. Ce mode d'identification peut être particulièrement utile si vous possédez des unités d'organisation (UO) basées sur l'emplacement dans Active Directory® et souhaitez que les ordinateurs créés dans l'emplacement soient ajoutés au domaine dans l'UO correspondant à cet emplacement.
Utilisez la section Make and Model (Marque et Modèle) pour créer des entrées pour chacun des types de matériel devant être pris en charge par votre déploiement. BDD 2007 les fait correspondre aux informations trouvées par les appels WMI. Dans les environnements de développement, la section Make and Model (Marque et Modèle) est souvent utilisée pour créer une entrée visant à déterminer si la machine est un ordinateur virtuel Virtual PC 2007 ou Virtual Server 2005 en vérifiant respectivement les propriétés Make et Model (Marque et Modèle) de « Microsoft Corporation » et de « Ordinateur virtuel ». Si vous rapprochez ces propriétés lors de la création, vous pouvez indiquer à BDD qu'il doit installer l'application Virtual Machine Additions lors du déploiement en ajoutant simplement l'application à l'entrée Make and Model (Marque et Modèle).
Maintenant que vous avez fourni des méthodes d'identification des ordinateurs, utilisez la section Rôles pour créer les entrées correspondant à chaque rôle de déploiement que vous voulez configurer. Il peut par exemple s'agir d'une entrée pour un rôle Windows XP ou un rôle Windows Vista configuré en ajoutant la propriété BuildID qui correspond à la build Windows XP ou Vista définie dans BDD à chaque entrée. Une autre approche consiste à spécifier des rôles départementaux tels que Comptabilité, Vente, Finance. J'ai tendance à renseigner la majorité des propriétés de BDD dans cette section (fuseau horaire, paramètres régionaux, informations organisationnelles, etc.). Cela permet de limiter au maximum l'administration de la base de données puisque les entrées ne sont pas liées à une machine, un matériel ou un emplacement spécifique.
Nous devons indiquer à BDD 2007 qu'au moment du déploiement, il doit rechercher dans la base de données toutes les entrées correspondant à l'ordinateur en cours de création. Pour configurer BDD afin d'utiliser la base de données pendant un déploiement, cliquez avec le bouton droit sur votre point de déploiement, puis cliquez sur Configure DB (Configuration de base de données). Vous êtes alors guidé à travers une série d'Assistants qui remplissent le fichier CustomSettings.ini avec les entrées qui commandent au processus d'installation LTI d'interroger la base de données pour obtenir les informations.

Rendre votre déploiement évolutif
Vous disposez maintenant d'un serveur de déploiement capable d'automatiser l'installation LTI et de configurer dynamiquement chaque ordinateur pour fonctionner dans un rôle d'entreprise spécifique. Mais comment pouvez-vous étendre cette solution ?
L'architecture de la solution est articulée autour d'une topologie hub-and-spoke telle qu'illustrée à la figure 4. Le premier serveur de déploiement que vous configurez est le serveur de déploiement parent, c'est à dire le concentrateur (hub). Chacun des serveurs de déploiement enfants servent de rayons (spokes).
Figure 4 Architecture de déploiement hub-and-spoke
Figure 4 Architecture de déploiement hub-and-spoke
Pour activer cette architecture, vous devez utiliser DFS-R afin de répliquer le partage de distribution sur chacun de vos serveurs de déploiement. Utilisez ensuite, la réplication de capture instantanée SQL Server pour configurer une copie de la base de données de déploiement BDD sur chacun des serveurs de déploiement enfants. Cette solution est intéressante car les serveurs de déploiement enfants nécessitent une configuration logicielle minimale : il suffit que SQL Server Express, WDS et DFS-R soient installés sur chaque ordinateur pour permettre le déploiement.
Du fait des grandes quantités de données qui peuvent être enregistrées dans le partage de distribution BDD 2007, je recommande l'utilisation de DFS-R dans Windows Server 2003 R2 au lieu des services de réplication de fichiers de la version précédente de Windows Server. DFS-R n'utilise la compression différentielle à distance (RDC) que pour répliquer les modifications différentielles (delta) des fichiers entre les membres du groupe de réplication. Ceci peut avoir un grand impact sur la quantité de trafic de réplication lorsqu'une petite modification, telle qu'un nouveau pilote, est apportée à votre fichier d'image personnalisé. Avec DFS-R, le trafic de réplication équivaut seulement à la taille des modifications effectuées et non à la redistribution du fichier d'image entier.
Une foule d'informations sur DFS figurent sur le site Web de Microsoft. Vous pouvez commencer par consulter microsoft.com/windowsserver2003/technologies/storage/dfs, mais je décrirai les étapes d'installation et de configuration de base nécessaires pour vous donner un aperçu du processus dans le contexte du déploiement à l'aide de BDD.
Notez que si vos serveurs exécutent Active Directory sous une installation de Windows Server 2003 antérieure à R2, il se peut que le schéma d'Active Directory doive être mis à jour pour accepter DFS-R car le service de réplication nécessite de nouvelles classes d'objets. Pour des informations complètes sur l'extension du schéma d'Active Directory dans Windows Server 2003 R2, consultez l'article go.microsoft.com/fwlink/?LinkId=99936.
La première étape consiste à installer les composants DFS sur votre serveur de déploiement Windows Server 2003 R2. Vous pouvez procéder de plusieurs façons, l'une des plus simples étant d'utiliser l'Assistant Ajouter/Supprimer des composants Windows. Une fois cela fait, vous devez configurer un groupe de réplication à l'aide de la console de gestion DFS illustrée à la figure 5.
Figure 5 Console de gestion DFS
Figure 5 Console de gestion DFS
Pour étendre votre solution de déploiement BDD 2007, vous devez répliquer deux dossiers spécifiques. Le premier est le partage de distribution BDD 2007 qui contient tous les fichiers de configuration et source BDD. Ces fichiers doivent être disponibles sur chaque serveur de déploiement.
Le deuxième est le dossier Boot utilisé par WDS pour stocker le fichier LiteTouch_x86.wim. Il s'agit de l'environnement de démarrage BDD qui est fourni par WDS à vos ordinateurs de bureau clients pour démarrer le processus de déploiement. Vous devez répliquer ce fichier de sorte que, lorsqu'une modification est apportée à l'environnement de démarrage sur votre serveur de déploiement parent, les modifications soient répliquées sur le reste de l'infrastructure de déploiement.
Les chemins à répliquer sont X:\Distribution (où X est la lettre de l'unité que vous spécifiez au moment de l'installation de BDD 2007) et Y:\RemoteInstall\boot (où Y est la lettre de l'unité du volume contenant le partage RemoteInstall WDS).
La réplication dans DFS-R est multimaître. Il n'est donc pas possible de créer une topologie de réplication unidirectionnelle. Pour cette raison, afin de permettre une gestion centralisée du partage de distribution, vous devez configurer le dossier de distribution sur chacun de vos serveurs de déploiement enfants pour qu'il soit en lecture seule. Ainsi, seule la réplication DFS-R peut écrire dans le dossier (puisqu'elle utilise les droits de sauvegarde et de restauration). Les ordinateurs clients créés à partir de ces serveurs enfants ne devront jamais écrire dans ce dossier. Il n'est donc pas nécessaire de leur accorder des privilèges plus élevés que les autorisations de lecture.
La dernière étape de configuration pour terminer la réplication des données à l'aide de DFS-R consiste à déterminer la stratégie d'actualisation du magasin des données de configuration de démarrage (BCD) dans WDS. Ainsi, toute modification apportée à votre environnement de démarrage sera répercutée sur chaque serveur de déploiement enfant. Cette modification de configuration doit être effectuée sur tous les serveurs WDS. Je vous recommande de l'intégrer dans votre processus de création et de configuration d'un serveur de déploiement.
Pour chaque serveur de déploiement, exécutez la commande suivante :
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
La période d'actualisation de l'heure dépend de la fréquence d'actualisation des données sur les serveurs de déploiement. Si vous configurez DFS-R pour une réplication toutes les heures, il semble logique de configurer la stratégie d'actualisation du magasin BCD pour une actualisation toutes les 60 minutes.

Réplication SQL Server
Jusqu'ici, vous avez étendu BDD 2007 pour répliquer le partage de distribution BDD et l'image de démarrage WDS de votre serveur de déploiement principal sur chacun de vos serveurs de déploiement enfants. Vous devez maintenant terminer le processus et répliquer la base de données Deployment Workbench BDD 2007 de sorte qu'elle soit disponible localement sur chaque serveur de déploiement.
SQL Server utilise une méthodologie de réplication que la documentation produit décrit comme assez proche du mode de publication des magazines. Dans le cas d'un magazine, l'éditeur produit le magazine, les distributeurs distribuent le magazine pour l'éditeur et les abonnés s'abonnent au magazine et le reçoivent. SQL Server utilise cette même terminologie pour ses fonctionnalités de réplication intégrées.
Notez que, pour être éditeur de base de données SQL Server, le serveur ne doit pas exécuter SQL Server Express Edition, mais utiliser une version complète de SQL Server. Pour le serveur de déploiement principal, j'utilise le SQL Server 2005 (bien que le SQL Server 2000 soit également pris en charge). Pour chaque serveur de déploiement enfant, vous pouvez utiliser SQL Server 2005 ou SQL Server 2005 Express.
Avant de commencer à configurer la réplication SQL Server, vous devez effectuer quelques étapes afin de vérifier que SQL Server est correctement configuré pour prendre en charge la réplication. Lorsque vous configurez vos serveurs de déploiement, assurez-vous que les composants de réplication sont inclus durant l'installation de SQL Server 2005 ou SQL Server 2005 Express Edition. Par défaut, SQL Server Express n'installe pas les composants de réplication.
Ensuite, pour permettre la connexion de l'environnement de démarrage LTI à SQL Server, les connexions à distance doivent être activées dans SQL Server. Pour configurer SQL Server pour les connexions à distance, lancez l'outil Configuration de la surface d'exposition SQL Server, sélectionnez Configuration de la surface d'exposition pour les services et les connexions et configurez le serveur pour qu'il accepte les connexions locales et distantes à partir de TCP/IP et des canaux nommés.
Sur le serveur de déploiement principal, créez ensuite un dossier partagé pour contenir les données de capture instantanée de réplication qui seront lues par les agents de réplication sur chaque serveur de déploiement enfant. Je reviendrai sur ce dossier partagé ultérieurement. En général, je place ce dossier sur le même volume que le reste de mon contenu de déploiement.
Les dernières étapes de configuration ne sont nécessaires que pour SQL Server Express Edition sur vos serveurs de déploiement enfants. Par défaut, le service Explorateur de SQL Server est désactivé. Pour permettre la réplication, ce service doit être défini sur automatique, et lancé. Utilisez l'outil Gestionnaire de Configuration de SQL Server pour configurer ce service. Vous devez également créer une base de données sur les serveurs enfants sur lesquels vous répliquez le contenu. Conservez le même nom de base de données que le nom de votre base de données BDD 2007 sur le serveur de déploiement principal de façon à limiter les tâches de configuration supplémentaires.

Configuration de la réplication
Vous êtes maintenant prêt à configurer la réplication SQL Server. Pour commencer, sur le serveur de déploiement maître qui doit exécuter la version complète de SQL Server 2005, lancez SQL Server Management Studio. La première étape consiste à créer et à configurer une distribution. Pour ce faire, naviguez jusqu'au dossier Réplication de la console de gestion, comme illustré à la figure 6. Cliquez avec le bouton droit sur le dossier Réplication et sélectionnez Configurer la distribution pour lancer l'Assistant de distribution.
Figure 6 SQL Server Management Studio : Réplication
Figure 6 SQL Server Management Studio : Réplication
Dans l'Assistant, confirmez que le serveur de déploiement principal doit jouer le rôle de son propre distributeur. Définissez le dossier racine de capture instantanée comme le chemin UNC du partage de réplication SQL Server créé précédemment. Enfin, définissez le serveur de déploiement principal comme devant être configuré en tant qu'éditeur.
Lorsque cet Assistant a terminé de configurer le serveur en tant qu'éditeur et distributeur, vous devez indiquer à SQL Server la base de données à publier. Pour ce faire, cliquez avec le bouton droit sur le dossier Réplication et cliquez sur les Propriétés du serveur de publication. Dans la boîte de dialogue des propriétés, sélectionnez Bases de données de publication et choisissez votre base de données BDD 2007 pour la réplication transactionnelle, comme illustré à la figure 7. Vous n'utilisez pas réellement la réplication transactionnelle, mais cette même option est sélectionnée que votre intention soit une réplication de capture instantanée ou transactionnelle.
Figure 7 Publication de votre base de données
Figure 7 Publication de votre base de données
Vous devez maintenant créer une publication à laquelle peuvent s'abonner vos serveurs de déploiement enfants. Dans le dossier Réplication, cliquez avec le bouton droit sur Publications locales, puis cliquez sur Nouvelle publication pour lancer l'Assistant de publication. Sélectionnez la base de données BDD comme base de données à publier. Sélectionnez la réplication de capture instantanée comme type de publication et spécifiez toutes les tables, procédures enregistrées et vues à répliquer. Il est recommandé de choisir de créer une capture instantanée initiale immédiatement. Pour la planification de l'agent de capture instantanée, il est plus que suffisant de l'exécuter par défaut une fois par jour, à moins que vous ne prévoyiez de modifier fréquemment la base de données.
L'étape finale consiste à abonner chacun de vos serveurs de déploiement enfants à cette publication. SQL Server est ainsi programmé pour transmettre une copie de la base de données à chaque serveur de déploiement enfant à intervalles spécifiés. Dans le sous-dossier Publications locales du dossier Réplication, localisez la publication qui vient d'être créée, cliquez dessus avec le bouton droit et sélectionnez Nouveaux abonnements pour lancer l'Assistant Nouvel abonnement. Dans cet Assistant, sélectionnez la publication BDD créée dans les étapes précédentes comme publication choisie. Choisissez d'exécuter tous les agents au moment de la distribution pour activer la topologie de réplication en tant qu'abonnement par émission de données. Ajoutez ensuite chaque serveur de déploiement enfant en tant qu'abonné et désignez la base de données que vous avez créée sur chaque serveur pour qu'elle reçoive la copie des données répliquées (souvenez-vous que cette base de données doit porter le même nom que la base de données de déploiement principale). Enfin, configurez un compte à utiliser pour les connexions et définissez la planification à utiliser pour la réplication. Cette planification doit refléter celle que vous avez choisie pour l'agent de capture instantanée. Je vous ai donné un bref aperçu de ce dont vous avez besoin pour rendre la réplication SQL Server opérationnelle. Vous devriez maintenant commencer à voir vos données se répliquer en un rien de temps !

Configuration de BDD 2007
Jusqu'ici, vous avez configuré BDD 2007 pour utiliser une base de données et pour configurer la réplication de la base de données et le partage de distribution BDD 2007 sur vos serveurs de déploiement enfants. Pour compléter la solution de déploiement, vous devez configurer BDD 2007 de sorte que, lorsqu'un client télécharge l'environnement de démarrage BDD, il se connecte automatiquement à serveur de déploiement local.
Lorsque vous démarrez dans l'environnement Windows PE LTI, si le client a démarré à partir d'un serveur WDS, une valeur de Registre est définie dans Windows PE, qui enregistre le nom du serveur à partir duquel le client vient de télécharger l'environnement de démarrage. Les scripts de déploiement BDD 2007 initiaux récupèrent cette valeur et l'enregistrent dans une variable d'environnement appelée %WDSServer%.
Notez que, si vous utilisez la version BDD 2007 initiale, il se peut que cette valeur ne soit pas convenablement renseignée dans le Registre de Windows PE. Une mise à jour permettant de corriger ce comportement est disponible à l'adresse support.microsoft.com/kb/937191.
Pour configurer BDD 2007, il vous suffit de modifier les fichiers de configuration BootStrap.ini et CustomSettings.ini de sorte que toutes les références au serveur de déploiement soient remplacées par %WDSServer%. En principe, cela implique de remplacer les valeurs du nom d'instance SQL Server, ainsi que la valeur de DeploymentRoot, le serveur contenant le partage de distribution. Un exemple de Bootstrap.ini et un extrait d'un fichier CustomSettings.ini sont illustrés à la figure 8 et la figure 9.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 BootStrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
Notez que cette solution nécessite la présence de WDS sur le même serveur que celui qui stocke la base de données BDD 2007 répliquée et le partage de distribution BDD 2007 répliqué. Les raisons doivent vous sembler évidentes : cela vous permet d'utiliser la variable %WDSServer% pour fournir une façon sûre et simple d'indiquer à votre ordinateur client où se trouve son serveur de déploiement local et lui éviter de répondre sur le réseau étendu.

Considérations supplémentaires
L'un des aspects les plus intéressants de BDD 2007 réside dans son évolutivité, si bien qu'il existe de nombreux autres éléments pouvant être pris en compte pour l'extension de cette solution. Par exemple, vous pouvez utiliser les fonctionnalités intégrées pour contrôler SQL Server et DFS-R, concevoir des méthodes pour peupler les ordinateurs de votre environnement avec des informations issues d'une base de données de gestion des actifs, ou même utiliser une procédure SQL stockée pour récupérer ces informations. Malheureusement, je n'ai pas la place pour traiter tous ces sujets. Mais j'espère vous avoir donné suffisamment d'éléments pour que vous puissiez exploiter les fonctionnalités de BDD dans votre propre organisation.

Adam Shepherdest consultant pour Microsoft Consulting Services au Royaume-Uni. Il est spécialisé dans le déploiement, la maintenance et la gestion du client Windows. Vous pouvez le contacter à l'adresse suivante : adamshep@microsoft.com.


 Communications: Serveurs de transport Edge Exchange chez Microsoft 2&#232;me partie
Communications Kay Unkroth

Serveurs de transport Edge Exchange chez Microsoft 2ème partie
Vue d'ensemble:
  • Utilisation des journaux et des suivis de transport Edge
  • Configuration anti-courrier indésirable avec des scripts
  • Tests de scénarios de courrier indésirable typiques
Télécharger le code de cet article: Edge2007_11.exe (161KB)

Face au déluge de courrier indésirable et d'autres contenus malveillants circulant sur Internet, comment garantissez-vous une messagerie fiable et sûre aux utilisateurs de votre organisation ? L'une des méthodes, que j'ai commencé à décrire le mois dernier dans la première partie de cette série d'articles, consiste à déployer
des serveurs de transport Edge Exchange Server 2007 et Forefront Security for Exchange Server dans un réseau de périmètre entre Internet et votre environnement de production.
Dans cette deuxième et dernière partie de ma série de deux articles, j'expliquerai comment analyser les agents de transport Edge en action en utilisant les fonctionnalités de journalisation et de suivi d'agent standard d'Exchange Server 2007. J'utiliserai également une méthode personnalisée pour transférer tous les objets d'événements du pipeline de transport vers des fichiers XML. J'illustrerai ensuite la façon d'appliquer des paramètres anti-courrier indésirable à un laboratoire de test de transport Edge selon la configuration que Microsoft utilise dans son propre environnement de production d'entreprise. Pour terminer, je conclurai avec quelques scénarios de test réalistes intéressants pour voir comment les agents de transport Edge réagissent face aux diverses situations de courrier indésirable.
Pour plus d'informations sur l'installation du laboratoire de test de transport Edge et l'architecture de transport Edge générale, consultez le premier article de cette série dans le numéro d'octobre 2007 de TECHNET Magazine, disponible sur technetmagazine.com/issues/2007/10/Edge.
J'ai recours à des scripts et des fichiers de commandes de façon intensive pour automatiser les tâches de configuration les plus importantes. Vous pourrez trouver ces scripts dans le téléchargement de code qui accompagne cet article (sur technetmagazine.com/code07.aspx). Par ailleurs, pour des informations générales plus détaillées sur la configuration des agents de transport Edge de Microsoft IT, je recommande la lecture du livre blanc technique « Protection du transport Edge et de la messagerie Microsoft® Exchange Server 2007 » rédigé pour Microsoft IT Showcase. Vous pouvez télécharger ce livre blanc IT Showcase à l'adresse microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Journalisation et suivi
Exchange Server 2007 inclut plusieurs fonctionnalités de suivi et de journalisation, notamment la journalisation de protocole, la journalisation d'agent et le suivi de pipeline, qui facilitent le diagnostic et le dépannage des problèmes liées aux agents de transport. Bien que je ne procède pas exactement au dépannage des agents de transport dans cet article, la journalisation et le suivi des informations sont utiles pour l'examen de la façon dont fonctionnent les agents de transport Edge.
Si vous souhaitez effectuer le suivi des informations concernant les activités d'envoi et de réception SMTP, vous devez activer la journalisation de protocole pour les connecteurs d'envoi et de réception. Dans l'environnement de test que j'ai configuré dans la première partie de cette série d'articles (voir la figure 1), j'ai activé la journalisation de protocole à l'aide du paramètre suivant sur les applets de commande New-SendConnector et New-ReceiveConnector :
Figure 1 Environnement de test
Figure 1 Environnement de test
–ProtocolLoggingLevel: Verbose
Vous trouverez les fichiers journaux SMTP par défaut dans les sous-dossiers de %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.
La journalisation de protocole est utile si vous voulez analyser les conversations SMTP, mais les agents anti-courrier indésirable n'interfèrent pas toujours avec la session SMTP. Par exemple, l'agent de filtrage de contenu peut n'estampiller que les messages entrants avec une valeur de seuil de probabilité de courrier indésirable (SCL). Tant que la valeur SCL se situe en-deçà d'un seuil spécifié (par défaut 7), l'agent de filtrage de contenu ne provoque pas le rejet du message par le processus de transport Edge. La conversation SMTP n'est par conséquent pas affectée.
Pour analyser les actions exécutées par les agents anti-courrier indésirable (filtrage des connexions, filtrage de contenu, application de règles de transport Edge, filtrage des destinataires, filtrage des expéditeurs et identification d'expéditeur) sur les messages qui transitent par le pipeline de transport, vous devez vérifier les journaux d'agent au lieu des journaux de protocole. La journalisation d'agent est habituellement activée avec le paramètre AgentLogEnabled du fichier EdgeTransport.exe.config. Par défaut, les journaux d'agent sont situés dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Vous pouvez ouvrir les journaux dans le Bloc-Notes, mais l'applet de commande Get-AgentLog affiche les informations de journaux d'agents de façon plus intuitive dans Exchange Management Shell.
Le suivi de pipeline est une autre fonctionnalité utile. Elle vous permet de capturer des instantanés des messages d'un expéditeur particulier lorsque que les messages transitent par le pipeline de transport. Le concept est relativement simple : le processus Transport Edge crée un instantané de chaque message avant et après avoir invoqué les agents de réception et de routage SMTP inscrits pour les événements OnEndofData, OnSubmittedMessage et OnRoutedMessage En comparant les instantanés de messages, vous pouvez voir comment chaque agent modifie chaque message. Il est bien sûr impératif que vous activiez cette précieuse fonctionnalité dans l'environnement de test.
L'utilisation suivante de l'applet de commande Set-TransportServer active le suivi de pipeline pour un utilisateur de test. Le paramètre PipelineTracingEnable défini sur $true active le suivi de pipeline, comme vous pouviez vous y attendre. L'adresse de messagerie de l'utilisateur de test est définie dans le paramètre PipelineTracingSenderAddress :
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Lorsque le suivi de pipeline est activé, vous pouvez trouver les fichiers d'instantané de message correspondant à chaque message de l'expéditeur spécifié (dans ce cas, il s'agit de Contoso.User@contoso.com) dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Il s'agit du dossier par défaut. Pour chaque message, les fichiers d'instantanés sont situés dans un sous-répertoire dont le nom est défini par le GUID attribué au message. Notez que vous pouvez trouver le message d'origine dans un fichier portant le nom Original.eml et les copies du message dans les fichiers .eml qui commencent par SmtpReceive ou Routing, en fonction des événements rencontrés et des agents installés. Pour analyser le traitement des agents anti-courrier indésirable inscrits pour les événements de réception SMTP OnEndofData et OnEndOfHeaders, consultez les fichiers SmtpReceive*.eml. Pour analyser le traitement de l'agent antivirus et des autres agents inscrits pour les événements OnSubmittedMessage et OnRoutedMessage, utilisez plutôt les fichiers Routing*.eml.

Vidange de pipeline personnalisée
Les fonctionnalités de journalisation et de suivi d'agent standard d'Exchange Server 2007 répondent à tous les besoins de dépannage, malgré le fait que les fonctionnalités standard ne couvrent pas tous les événements de transport. Par exemple, le suivi de pipeline ne peut pas capturer les informations concernant OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand et les événements de transport similaires parce que l'hôte expéditeur n'a pas encore transféré de messages pouvant être écrits dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Si vous voulez capturer des informations détaillées sur ces événements, vous devez mettre en place un agent personnalisé qui vidange les données d'événement dans des fichiers du système de fichiers.
Comme je l'ai brièvement décrit dans mon article précédent, il n'est pas compliqué de créer des agents personnalisés. Je n'ai donc pas pu m'empêcher de créer un agent de réception et un agent de routage SMTP pour vidanger tous les objets d'événements du pipeline de transport dans des fichiers XML. Vous trouverez un projet Microsoft Visual Studio® 2005 correspondant, PipelineXMLDump, dans le téléchargement disponible pour cet article. Les deux fichiers importants sont DumpAgents.Cs, qui implémente les fabriques d'agent et les agents, et XMLDump.CS, qui implémente une classe d'assistance pour l'écriture des champs des objets source d'événement et argument d'événement dans les fichiers XML. Si vous compilez le code source et copiez le fichier PipelineXMLDump.dll résultant dans un dossier nommé C:\PipelineXMLDump sur le serveur de test de transport Edge, vous pouvez inscrire et activer les agents personnalisés en utilisant les scripts RegisterPipelineXMLDump.ps1 et EnableDumpAgents.ps1. Les scripts sont inclus dans le dossier de projet PipelineXMLDump du téléchargement. Bien sûr, mes agents personnalisés ont un but explicatif uniquement, n'ont pas été suffisamment testés et ne doivent jamais être installés sur un serveur de production. Vous utilisez ces agents à vos risques et périls.
DumpAgents.cs vous montre comment implémenter tous les gestionnaires d'événements de réception et de routage SMTP pris en charge par le pipeline de transport. Ceci peut constituer un bon point de départ si vous voulez implémenter vos propres agents personnalisés. Mes agents de vidange écrivent des fichiers XML dans les sous-dossiers de %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump qui correspondent à l'identificateur de la session SMTP (agent de réception SMTP) ou à l'identificateur de message (agent de routage). La figure 2 illustre un exemple d'informations d'argument d'événement transmises à l'agent de réception SMTP dans le gestionnaire OnConnectEvent. Cet exemple révèle le point de terminaison IP local (l'adresse IP et le port) qui a accepté une demande de connexion entrante.
Figure 2 Informations d'argument vidangées pendant l'événement OnConnect
Figure 2 Informations d'argument vidangées pendant l'événement OnConnect

Préparation des séries de tests
Assez de théorie sur la journalisation, le suivi et la vidange. Préparons-nous à exécuter quelques séries de tests qui montreront les agents anti-courrier indésirable en action. Vous trouverez ci-après un bref récapitulatif reflétant aussi fidèlement que possible la configuration de Microsoft IT dans votre environnement de test. Comme mentionné précédemment, des informations générales sont disponibles dans le livre blanc technique « Protection du transport Edge et de la messagerie Microsoft Exchange Server 2007 ».
Commencez par désactiver les agents de réécriture d'adresses pour les messages entrants, de filtrage de pièce jointe et de réécriture d'adresses pour les messages sortants en exécutant le script EDGE01_disable_agents.ps1 du téléchargement d'accompagnement. La réécriture d'adresses n'est pas nécessaire car les destinataires utilisent les mêmes adresses de messagerie en interne et en externe. Je n'utilise pas l'agent de filtrage de pièce jointe car des fonctionnalités de filtrage de pièce jointe plus évoluées sont disponibles dans Forefront Security.
L'environnement de test n'est pas connecté à Internet. Ceci complique les tests de l'agent de filtrage des connexions. Pour remédier à ce problème, vous pouvez créer une liste rouge d'IP sur l'hôte Internet en exécutant le fichier INTERNET01_create_IP_block_list.bat. Vérifiez que les outils de support de Windows® sont installés, car ceux-ci incluent l'outil de ligne de commande DNS (dnscmd.exe). Si ce n'est pas le cas, vous devrez passer du temps à créer manuellement les enregistrements de DNS à l'aide de la console DNS.
Vous pouvez maintenant configurer l'agent de filtrage des connexions en exécutant le script EDGE01_add_block_list_provider.ps1. Ce script ajoute un fournisseur de liste rouge d'IP pour ip-bl.consolidatedmessenger.com. Il s'agit de la liste rouge d'IP de Consolidated Messenger, créée auparavant dans l'environnement de test en exécutant le fichier INTERNET01_create_IP_block_list.bat sur l'hôte Internet, comme mentionné précédemment. Microsoft IT utilise également la liste rouge et la liste verte d'IP locales, mais ces fonctionnalités ne nécessitent pas une configuration manuelle. Il est important de noter que Microsoft IT n'utilise pas de fournisseurs de liste verte d'IP.
Maintenant, configurez l'agent de filtrage des destinataires en exécutant le script EDGE01_recipient_filter.ps1 pour bloquer les messages aux destinataires inexistants ainsi que les messages aux boîtes aux lettres et aux listes de distribution globales qui sont réservées à l'utilisation interne ou sortante uniquement.
L'agent de filtrage des expéditeurs nécessite également une mise à jour de la configuration. Microsoft IT utilise le filtrage des expéditeurs comme contre-mesure aux attaques par inondation de courrier électronique provenant d'adresses d'expéditeurs spécifiques, et pour bloquer certains serveurs de listes et des sources similaires qui ne sont pas considérées comme pertinentes pour les activités professionnelles. Microsoft IT utilise en outre le filtrage des expéditeurs pour bloquer les messages avec des informations d'expéditeur non valides ou manquantes. Appliquons cette configuration à l'environnement de test en exécutant le script EDGE01_sender_filter.ps1 sur le serveur de transport Edge.
Vous devez également configurer les enregistrements SPF (Sender Policy Framework) dans le DNS pour refléter la configuration de Microsoft IT. Pour créer un enregistrement SPF qui atteste de l'autorité de votre serveur de transport Edge pour les messages de votre domaine, adventure-works.com, vous pouvez utiliser l'Assistant d'enregistrements SPF de Microsoft Sender ID Framework à l'adresse microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Essayez en indiquant un nom de domaine Internet existant. Dans l'environnement de test, vous pouvez exécuter le fichier INTERNET01_create_SPF_record.bat sur l'hôte Internet.
Et voilà. Aucun autre paramètre ne nécessite d'être configuré car la plupart des agents sont fournis avec des paramètres par défaut acceptables. Pour effectuer une vérification rapide des paramètres par défaut les plus importants pour les agents d'application de règles de transport Edge, d'identification d'expéditeur, d'analyse de protocole et de filtrage de contenu, exécutez le script EDGE01_check_defaults.ps1 sur le serveur de transport Edge.

Agents de transport Edge en action
Mettons maintenant les agents de transport Edge à l'œuvre dans quelques scénarios de messagerie réalistes. Pour envoyer des messages de test au serveur de transport Edge, j'utilise les services SMTP et POP3 inclus dans Windows Server 2003, et Outlook® Express comme client de messagerie, en utilisant la plupart du temps les paramètres par défaut. Assurez-vous toutefois que la journalisation est activée.
Mais, pour commencer, un avertissement : ne suivez aucune des étapes et n'exécutez aucun des scripts décrits dans cette section si votre environnement de test possède des connexions à un système de production ou à Internet. Vous effectuez les tests à vos risques et périls.
Le premier agent que je vais tester est l'agent de filtrage des connexions. Il mérite d'être testé en premier car il est l'agent le plus sollicité sur un serveur de transport Edge. Chez Microsoft, l'agent de filtrage des connexions bloque à peu près 88 % de tous les messages envoyés depuis Internet. Sur 13 millions d'envois tentés chaque jour ouvrable ordinaire, seuls à peu près 1,5 million proviennent d'expéditeurs légitimes.
Envoyons donc un message électronique en tant que Fabrikam.User@Fabrikam.com à Administrator@adventure-works.com. Si les choses fonctionnent correctement, l'administrateur ne doit pas recevoir le message. Au lieu de cela, Fabrikam.User doit recevoir une notification d'état de remise (DSN) déclarant que la remise au destinataire a échoué. Fabrikam.user vérifie que l'adresse de messagerie est correcte, renvoie le même message et Fabrikam.User reçoit à nouveau une DSN. Ensuite, Fabrikam.User appelle le support technique et fait état du problème. Il n'est pas le premier. En fait, personne chez Fabrikam ne peut communiquer avec Adventure Works. Il s'est passé quelque chose. Le problème est urgent. Pour tenter de le résoudre rapidement, vous vérifiez les journaux SMTP du dossier %systemroot%\system32\Logfiles\SMTPSVC1 sur INTERNET01 et, comme indiqué par le texte en rouge de la figure 3, la voilà !
Figure 3 Les journaux SMTP montrent le problème (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
La réponse d'erreur 550 vous indique que Consolidated Messenger a placé l'adresse IP de l'hôte Internet sur une liste rouge d'IP. Soit. Vous contactez Consolidated Messenger pour être supprimé de cette liste. Il se trouve qu'il est plus facile de figurer sur la liste rouge de Consolidated Messenger que d'en être supprimé. La résolution de ce problème nécessitera plusieurs jours, voire plusieurs semaines.
Vous avez besoin d'aide plus rapidement, et vous contactez donc Adventure Works à l'adresse de messagerie cmipbl@adventure-works.com. Vous envoyez un message électronique en tant que Fabrikam.Admin@Fabrikam.com, en décrivant la situation et en demandant le déblocage de l'adresse IP de votre hôte Internet (dans ce cas 192.168.1.100). Après avoir vérifié votre identité, Adventure Works débloque l'adresse en utilisant la commande suivante pour accorder une exception temporaire qui expire automatiquement après 30 jours :
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Trente jours devraient vous donner suffisamment de temps pour résoudre le problème auprès de Consolidated Messenger, si bien qu'Adventure Works ne doit pas passer du temps à maintenir l'exception manuellement. En accordant des exceptions à expiration automatique, Adventure Works maintient la charge administrative associée à la maintenance des listes vertes d'IP à un minimum.

Expéditeurs fiables
Maintenant, testons la détection d'expéditeurs fiables du filtrage de contenu, une nouvelle fonctionnalité très intéressante qui augmente la précision du filtrage de courrier indésirable. EdgeSync propage les informations d'expéditeurs fiables aux serveurs de transport Edge sous une forme chiffrée et hachée à partir de l'environnement interne. L'agent de filtrage de contenu utilise ces informations pendant le processus de filtrage pour prendre des décisions pertinentes. Il vous suffit d'entrer les informations d'expéditeur fiable (c'est-à-dire, la liste des expéditeurs fiables, la liste des destinataires fiables, la liste rouge d'expéditeurs et les contacts externes) dans Active Directory® en utilisant l'applet de commande Update-SafeList et en répliquant ensuite les informations sur le serveur de transport Edge à l'aide de l'applet de commande Start-EdgeSynchronization. Microsoft IT exécute l'applet de commande Update-SafeList suivant un calendrier établi, en dehors des heures de pointe. Dans notre environnement de test, il suffit d'exécuter manuellement un script correspondant (HUB-MBX-01_update_safelist.ps1).
Pour commencer, nettoyez l'environnement de test en exécutant le script EDGE01_clean_up.ps1 sur le serveur de transport Edge pour supprimer l'entrée de liste verte d'IP précédemment créée. Ceci est nécessaire car l'agent de filtrage de contenu n'a aucun effet sur les messages des sources qui figurent sur cette liste. Ensuite, supprimez l'entrée de liste rouge d'IP pour 100.1.168.192.ip-bl.consolidatedmessenger.com dans la liste rouge de Consolidated Messenger en exécutant le fichier INTERNET01_clean_up.bat sur l'hôte Internet. Á défaut, l'hôte Internet simulé ne pourra pas envoyer de messages, comme démontré précédemment.
Enfin, envoyez un message que l'agent de filtrage de contenu considèrera certainement comme étant du courrier indésirable. C'est difficile car l'agent de filtrage de contenu utilisera le seuil de rejet de SCL par défaut pour remettre la plupart des messages aux utilisateurs afin de réduire le nombre de faux positifs. Pourtant, après quelques essais, j'ai trouvé une version de message qui élève le contrôle d'accès SCL jusqu'au niveau de rejet. Pour envoyer le message en tant que Contoso.User@Contoso.com, exécutez le script INTERNET01_contoso_msg.vbs sur l'hôte Internet.
Mon script utilise une connexion SMTP anonyme pour soumettre le message au service SMTP sur INTERNET01. Pour qu'il fonctionne, vous devez configurer le service SMTP de sorte qu'il relaie les messages des utilisateurs anonymes. Dans le Gestionnaire IIS, ouvrez les propriétés du serveur virtuel SMTP par défaut. Sur l'onglet Accès, cliquez sur le bouton Relais et sélectionnez ensuite Tout sauf la liste ci-dessous. Je couvrirai dans un instant les implications de cette configuration.
Lorsque vous exécutez le script pour envoyer ce message, Contoso.User doit recevoir un DSN indiquant que cette remise a échoué avec : Code de diagnostic : smtp;550 5.7.1 Message rejeté en raison de restrictions de contenu. Vous pouvez également voir cette réponse dans le journal SMTP de l'hôte Internet et, si vous exécutez la commande Get-AgentLog | Select-Object -Last 1 sur le serveur de transport Edge pour afficher la dernière entrée du journal de l'agent, vous devriez pouvoir voir que le message a été rejeté car son contrôle d'accès SCL était 7, comme illustré à la figure 4.
Figure 4 Le message a été bloqué en raison de restrictions de contenu
Figure 4 Le message a été bloqué en raison de restrictions de contenu
Contoso.User n'est cependant pas un expéditeur de courrier indésirable. Il est malheureux que son message n'ait pas pu aboutir dans ce cas-ci, mais Contoso.User peut habituellement communiquer avec les destinataires d'Adventure Works. Contoso.User informe donc l'administrateur dans un autre message électronique que son message d'origine a été bloqué par erreur. L'administrateur connaît Contoso.User et, pour s'assurer que les filtres de courrier indésirable ne bloquent plus ses messages à l'avenir, l'administrateur ajoute Contoso.User à la liste des expéditeurs fiables. Pour effectuer cette opération dans Office Outlook 2007, cliquez avec le bouton droit sur un message reçu de Contoso.User, pointez sur Courrier indésirable et cliquez sur Ajouter l'expéditeur à la liste des expéditeurs approuvés.
À intervalles réguliers, l'applet de commande Update-SafeList s'exécute pour actualiser les informations de liste d'utilisateurs fiables dans Active Directory et après la synchronisation Edge suivante, Contoso.User pourra communiquer avec l'administrateur sans générer de faux positifs. Pour simuler cette procédure, exécutez le script HUB-MBX-01_update_safelist.ps1.
Exécutez maintenant le script INTERNET01_contoso_msg.vbs pour renvoyer le message Contoso.User. Vérifiez ensuite le journal de l'agent sur le serveur de transport Edge en utilisant la commande Get-AgentLog | Select-Object -Last 1 et vous pourrez voir sous ReasonData que le filtre de contenu a maintenant été contourné. Contoso.User. ne génère plus de faux positifs !

Attaque de courrier indésirable
Pour conclure les séries de tests, allons plus loin. Comme vous l'avez sans aucun doute remarqué, durant le test précédent, j'ai configuré l'hôte Internet en tant que relais ouvert, ce qui ouvre la porte aux expéditeurs de courrier indésirable. Voyons donc maintenant ce qui se passe si Spam.Sender@cohovineyards.com remarque cette configuration vulnérable et exploite l'hôte pour envoyer des milliers de messages indésirables à Adventure Works. Le script INTERNET01_spam_msg.vbs n'envoie qu'un seul message indésirable, mais vous pouvez modifier le script et modifier la valeur de max_loop pour en produire davantage.
Pour simuler une attaque de courrier indésirable, j'ai envoyé 1 000 messages à mon hôte compromis devant être relayés au serveur de transport Edge. Le service SMTP limite le nombre de messages par connexion sortante à 20 et il a donc fallu un certain temps pour relayer un nombre de messages indésirables suffisant pour que l'agent d'analyse de protocole réagisse.
L'agent d'analyse de protocole aide l'agent de filtrage des connexions en assurant automatiquement la gestion des entrées de liste rouge d'IP en fonction de l'analyse de protocole SMTP et des mises à jour de réputation d'IP de Microsoft Update. En l'occurrence, l'analyse de protocole SMTP a détecté les messages électroniques indésirables. L'agent d'analyse de protocole prend note de la note SCL de chaque message pour calculer une valeur SCL moyenne qu'il utilise pour déterminer un niveau de réputation d'expéditeur (SRL). Comme une multitude de messages illégitimes sont arrivés pendant ma campagne de courrier indésirable simulée, le SRL de l'hôte Internet a augmenté jusqu'à dépasser le seuil de blocage SRL. Par conséquent, l'hôte s'est retrouvé pendant 24 heures sur la liste rouge d'IP. Plus de courrier indésirable de cet hôte ! Ceci s'est produit automatiquement. Aucune intervention de l'administrateur n'a été nécessaire.
La figure 5 illustre l'entrée de liste rouge d'IP résultante et les modifications correspondantes dans la gestion des messages. Avant le blocage de l'hôte, le serveur de transport Edge rejetait chaque message indésirable pendant l'événement OnEndOfData car l'agent de filtrage de contenu agissait pour chaque message en fonction du seuil SCL (pour référence, voir la figure 4). Le message était soumis, bien qu'en vain. Après le blocage de mon hôte, la connexion a été rejetée pendant l'événement OnMailCommand par l'agent de filtrage des connexions. Les messages ne sont plus soumis. Ceci permet d'économiser la bande passante du réseau et les ressources de traitement pour déconnecter les expéditeurs de courrier indésirable avant la soumission de messages.
Figure 5 Arrêt d'un hôte Internet nuisible
Figure 5 Arrêt d'un hôte Internet nuisible

Autres tests
Il existe bien sûr de nombreux autres scénarios et fonctionnalités d'agent pouvant être testés. Par exemple, vous pouvez tester le filtrage des expéditeurs en envoyant des messages en tant que Blocked.User@Contoso.com ou Blocked.User@Fabrikam.com. Vous pouvez tester le filtrage des destinataires en envoyant des messages à Blocked.User@adventure-works.com. Vous pouvez également utiliser Telnet pour simuler des attaques DHA (directory harvesting) avec différents intervalles de délai de connexions entrantes. Microsoft IT utilise l'intervalle par défaut de cinq secondes pour les réponses SMTP 5yz sur le connecteur de réception exposé à Internet, ce qui constitue une durée suffisante pour que Microsoft IT rende les attaques DHA peu commodes pour les expéditeurs de courrier indésirable. Mais vous pouvez appliquer des valeurs différentes avec l'applet de commande Set-ReceiveConnector, comme démontré dans le script EDGE01_tarpitting.ps1.
Vous pouvez également aller plus loin en examinant les fichiers d'instantanés créés par le suivi de pipeline pour les messages de Contoso.User@Contoso.com. Examinez les tampons antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, utilisé par Forefront Security pour marquer les messages comme vérifiés. Lorsque Forefront Security, situé sur le serveur de transport Hub, trouve ce tampon avec des informations de version récente, il ne doit pas vérifier le message une deuxième fois. Si vous essayez de tromper Forefront Security en insérant des tampons d'antivirus falsifiés dans vos messages de test, vous pouvez voir le pare-feu d'en-tête en action. Il supprime ces tampons juste après l'événement OnDataCommand, longtemps avant que l'événement OnSubmittedMessage soit déclenché pour invoquer l'agent de routage FSE.
Pendant que vous examinez les en-têtes de messages dans les fichiers d'instantanés, vous voudrez peut-être créer un enregistrement de test SPF pour Contoso.com qui identifie une mauvaise adresse IP comme un expéditeur légitime. L'une des façons d'y parvenir consiste à exécuter le fichier INTERNET01_wrong_SPF_record.bat sur l'hôte Internet. Vous devez ensuite envoyer un message de test en tant que Contoso.User@Contoso.com et examiner X-MS-Exchange-Organization-SenderIdResult et l'en-tête Received-SPF :
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusion
Comme vous l'avez vu dans cet article et dans mon article précédent, les serveurs de transport Exchange sont fournis avec un jeu d'agents de transport complet pour l'implémentation de fonctionnalités anti-courrier indésirable de pointe fiables, notamment le filtrage des connexions, l'analyse de protocole et le filtrage de contenu. L'architecture de transport est extensible et prend en charge l'implémentation d'autres agents pour la prise en charge de fonctionnalités supplémentaires. L'agent de routage FSE est un bon exemple d'agent supplémentaire intégrant Forefront Security for Exchange Server dans l'architecture de transport.
Associé à des fonctionnalités supplémentaires, telles que le délai de connexion, le pare-feu d'en-tête, la sécurité de couche de transport et l'authentification, les serveurs de transport Edge fournissent les moyens nécessaires pour atteindre un niveau très élevé de protection de messagerie à plusieurs niveaux, sans point de défaillance unique. En déployant des serveurs de transport Edge et Forefront Security dans un réseau de périmètre, strictement séparé de votre organisation Exchange Server interne, vous pouvez maintenir le flux des contenus illégitimes et malveillants à l'écart de votre environnement de messagerie tout en remettant les messages légitimes à vos utilisateurs avec un faible taux de faux positifs.

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


 Mise en r&#233;seau: Configuration de l'acc&#232;s &#224; distance au VPN &#224; l'aide d'ISA&#160;Server&#160;2006
Mise en réseau Alan Maddison

Configuration de l'accès à distance au VPN à l'aide d'ISA Server 2006
Vue d'ensemble:
  • Protocoles VPN
  • Configuration d'une connexion VPN de site à site
  • Configuration d'une connexion VPN d'accès à distance
  • Nouvelles fonctionnalité d'ISA Server 2006

Les réseaux privés virtuels (VPN) offrent un haut niveau d'adaptabilité, d'évolutivité et de contrôle sur la connectivité réseau. En plus d'améliorer la sécurité, ils permettent des économies de coût significatives
par rapport aux connexions point-à-point dédiées traditionnelles. De plus, ils sont flexibles.
Il existe un grand nombre de types de VPN. Certains sont utilisés pour connecter des utilisateurs mobiles au réseau de l'entreprise ; d'autres pour connecter deux réseaux qui sont séparés géographiquement. Les protocoles utilisés par ces VPN et les fonctionnalités qu'ils offrent varient. Certains fournissent des fonctionnalités de sécurité, telles que l'authentification et le chiffrement, tandis que d'autres peuvent n'intégrer aucun composant de sécurité. Certains sont par conséquent plus faciles à configurer et à gérer que d'autres.
Dans cet article, j'examinerai comment vous pouvez implémenter un VPN en utilisant Internet Security and Acceleration (ISA) Server 2006. En particulier, je porterai mon attention sur la façon dont la fonctionnalité VPN d'ISA peut être utilisée pour résoudre deux scénarios courants : fournir des connexions VPN d'accès à distance aux utilisateurs et fournir des connexions VPN de site à site. Les deux implémentations incluent des composants de sécurité pour garantir la confidentialité des données et assurer la protection des ressources réseau internes.
Dans le premier scénario (connexion VPN d'accès à distance), un client à distance établit une connexion VPN à votre ISA Server via Internet. ISA Server connecte ensuite le client à distance à votre réseau interne, fournissant ainsi à l'utilisateur un accès transparent aux ressources réseau internes, y compris aux données et applications. Le second scénario (connexion VPN de site à site), est un peu plus complexe en raison de l'utilisation d'un routeur, qui peut être ISA lui-même. Cependant, ce type de connexion fournit la possibilité de connecter de façon transparente différents bureaux ou succursales entre eux ou à un bureau central.
L'utilisation d'Isa Server 2006 pour implémenter un VPN présente plusieurs autres avantages. L'un des plus importants est dû à la nature intégrée d'ISA Server, ce qui signifie que la fonctionnalité VPN et la fonctionnalité de pare-feu fonctionnent de façon conjointe. De plus, ISA Server fournit une fonctionnalité de quarantaine VPN qui utilise la fonctionnalité Contrôle de quarantaine pour clients distants de Windows Server® 2003 pour mettre en quarantaine un ordinateur d'accès distant jusqu'à ce que sa configuration soit validée par un script côté serveur. Cette fonctionnalité ajoute une autre couche de protection car elle fournit un moyen de vérifier des aspects tels que l'état des définitions d'antivirus et la stratégie de pare-feu locale sur l'ordinateur distant avant que vous n'autorisiez son accès à vos ressources réseau internes.
Les avantages administratifs principaux offerts par ISA Server comme solution VPN incluent la gestion centralisée des stratégies, la surveillance, la journalisation et la création de rapports. Pour vos responsabilités administratives quotidiennes, ces fonctionnalités peuvent se révéler une aide précieuse. En particulier, la surveillance en temps réel et le filtrage des journaux permettent de disposer d'informations clés sur le trafic réseau et les connexions passant par ISA Server.

Protocoles VPN
Les principaux protocoles de tunnel utilisés dans une connexion VPN ISA fournissent la première ligne de défense pour la sécurisation des connexions. ISA Server prend en charge trois protocoles : L2TP (Layer 2 Tunneling Protocol) sur IPsec, PPTP (Point-to-Point Tunneling Protocol) et le mode tunnel IPsec. Ce dernier protocole est uniquement pris en charge pour les connexions de site à site et est principalement utilisé pour l'interopérabilité avec les routeurs et d'autres systèmes d'exploitation qui ne prennent pas en charge L2TP ou PPTP.
L2TP est associé à IPsec parce que L2TP n'a pas de mécanisme propre permettant d'assurer la confidentialité de données. Associé à IPsec, qui offre des méthodes d'authentification et de chiffrement robustes, il constitue une solution attrayante. PPTP utilise soit MS CHAP (Microsoft® Challenge Handshake Authentication Protocol) version 2, soit EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) pour l'authentification et Microsoft Point-to-point (MPPE) pour, comme vous pouvez le deviner, le chiffrement.
Le choix entre L2TP sur IPsec ou PPTP dépend souvent de facteurs qui sont spécifiques à chaque organisation. L2TP sur IPsec vous permet d'utiliser un chiffrement plus complexe et sophistiqué et prend en charge un plus grand nombre de types de réseaux (notamment IP, X.25, Frame Relay et ATM). Cependant, PPTP est plus facile à implémenter et est généralement assorti de moins d'exigences. Cela dit, dans les situations où il n'y a pas de contraintes organisationnelles, il est considéré comme une meilleure pratique d'implémenter L2TP sur IPsec.

Connexions VPN de site à site
Isa Server 2006 a permis de simplifier considérablement l'installation d'un VPN de site à site. Dans les versions précédentes, l'installation impliquait un bien plus grand nombre d'étapes. Pour cet exemple, j'examinerai le cas d'un site distant unique qui se connecte à un bureau central en utilisant L2TP sur IPsec à l'aide d'un ISA Server sur les deux sites. Ce processus nécessite que vous configuriez l'instance ISA Server du bureau central avant de configurer le site distant.
La première étape du processus consiste à configurer les comptes utilisateur locaux qui sont requis sur les deux ISA Server. Cette identité utilisateur fournit le contexte de sécurité dans lequel la connexion à l'ISA Server distant ou principal est effectuée. Le nom de ce compte doit correspondre au nom de la connexion VPN que vous créez dans la console d'administration ISA. Par exemple, une bonne convention d'affectation de noms serait de configurer le nom d'utilisateur « VPN de site » sur le serveur ISA Server situé au siège principal (pointant vers le site distant) et « VPN du siège » sur le serveur ISA Server distant. Après avoir créé ces comptes, vous devez accéder aux propriétés du compte, ouvrir l'onglet Appel entrant et vous assurer que l'option Autoriser l'accès est sélectionnée.
Une fois le compte utilisateur local créé, l'étape suivante consiste à créer le certificat d'infrastructure de clé publique (PKI) qui sera utilisé pour l'authentification entre les deux sites. Vous pouvez utiliser une clé pré-partagée, mais l'utilisation d'un certificat est toujours préférable. La façon la plus simple d'installer un certificat pour une connexion VPN est de vous connecter directement à votre propre autorité de certification d'entreprise et de demander un certificat par le biais du site Web du serveur de certificat. Il se peut que vous deviez pour cela créer une règle d'accès pour autoriser votre ISA Server à se connecter au serveur de certificat via HTTP.
Si vous connaissez les versions précédentes d'ISA Server, vous remarquerez que l'interface d'Isa Server 2006, illustrée à la figure 1, est beaucoup plus intuitive. Lorsque vous sélectionnez le VPN dans le volet de gauche, des options de configuration et de tâche contextuelles s'affichent dans les volets du centre et de droite.
Figure 1 Isa Server 2006 a une interface plus intuitive
Figure 1 Isa Server 2006 a une interface plus intuitive
Lancez l'Assistant VPN de site à site en cliquant sur la tâche Créer une connexion VPN de site à site dans le volet de droite. Lorsque l'Assistant démarre, il demande un nom de réseau de site à site ; ce nom doit correspondre au nom du compte utilisateur que vous avez créé plus tôt. Après avoir entré le nom, cliquez sur le bouton Suivant. Sur l'écran suivant (voir figure 2), sélectionnez le protocole VPN à utiliser (dans mon exemple, L2TP sur IPsec). Lorsque vous cliquez sur Suivant, l'Assistant vous avertit qu'un compte utilisateur correspondant au nom de réseau doit être disponible ; dans la mesure où c'est le cas, vous pouvez cliquer sur OK pour aller à l'écran suivant.
Figure 2 Sélectionnez le protocole VPN que vous voulez utiliser
Figure 2 Sélectionnez le protocole VPN que vous voulez utiliser
Vous devez à présent créer un pool d'adresses IP. Deux choix s'offrent à vous : vous pouvez créer un pool d'adresses statiques sur le serveur ISA Server ou vous pouvez utiliser votre serveur DHCP existant pour contrôler l'attribution d'adresses. Comme les deux méthodes sont acceptables, votre décision doit être basée sur les procédures de votre entreprise concernant cette option particulière. L'écran vous demande maintenant d'entrer le nom du serveur distant. Entrez le nom de domaine pleinement qualifié (FQDN) du serveur distant, puis les informations d'authentification de l'utilisateur pour la connexion. N'oubliez pas que vous devez entrer les informations du compte utilisateur que vous avez créé sur l'ISA Server distant. Dans notre exemple, il s'agit du compte utilisateur VPN du siège, comme illustré à la figure 3.
Figure 3 Entrez le FQDN du serveur distant
Figure 3 Entrez le FQDN du serveur distant
Sur l'écran suivant, sélectionnez la méthode d'authentification sortante (comme je l'ai mentionné précédemment, il est toujours préférable d'utiliser un certificat). Ensuite, entrez la plage d'adresses d'IP utilisée sur le réseau interne du site distant.
Après cela, si vous utilisez ISA Server 2006 Enterprise Edition, l'Assistant vous permet de configurer les adresses IP d'équilibrage de la charge réseau dédiées du site distant Si vous utilisez ISA Server 2006 Standard Edition, ignorez l'étape d'équilibrage de charge et allez directement à l'écran suivant (voir figure 4), qui permet de créer la règle réseau utilisée pour acheminer le trafic du site distant vers le réseau local.
Figure 4 Création de la règle réseau acheminant le trafic
Figure 4 Création de la règle réseau acheminant le trafic
L'étape suivante du processus consiste à créer une règle d'accès. Lorsque vous configurez la règle d'accès, vous avez trois options pour autoriser l'utilisation des protocoles : vous pouvez choisir d'autoriser tout le trafic sortant, tout le trafic sortant à l'exception de certains protocoles ou autoriser seulement certains protocoles. Dans la plupart des cas, vous pouvez sélectionner l'option autorisant tout le trafic sortant.
Le processus est presque terminé. À ce stade, l'Assistant présente un résumé de votre configuration et lorsque vous cliquez sur le bouton Terminer, la connexion VPN de site à site est créée. Une boîte de dialogue vous indique qu'une règle de stratégie système doit être activée pour les téléchargements de liste de révocation des certificats ; cliquez sur Oui pour activer cette règle. L'Assistant fournit ensuite des informations sur les éventuelles étapes de configuration supplémentaires pouvant être nécessaires. Lorsque vous avez terminé la configuration d'ISA Server sur le site principal, vous devez suivre les mêmes étapes pour configurer le site distant Une fois les deux étapes terminées, les utilisateurs des deux sites pourront communiquer via le VPN.

Connexion VPN d'accès à distance
La configuration d'une connexion VPN d'accès à distance pour l'accès client est beaucoup plus simple (voir figure 5). La première étape consiste à sélectionner le VPN dans le volet de gauche de la console d'administration d'ISA Server. Ensuite, sélectionnez la tâche Activer l'accès des clients VPN dans le volet de droite. Vous recevez un avertissement indiquant que cette opération peut causer le redémarrage du service Routage et accès distant (étant donné que cela peut provoquer des problèmes de connexion, il peut être préférable d'implémenter cette modification pendant une fenêtre de maintenance planifiée). Cliquez sur OK pour ignorer cet avertissement ; ISA Server active une stratégie système qui autorise le trafic client VPN à accéder au serveur ISA Server. Vous pouvez afficher cette règle en sélectionnant Stratégie de pare-feu dans la console d'administration d'ISA Server, puis en sélectionnant la tâche Afficher les règles de stratégie système.
Figure 5 Configuration d'une connexion VPN d'accès à distance
Figure 5 Configuration d'une connexion VPN d'accès à distance
Une règle réseau par défaut est également activée pour autoriser le routage entre le réseau interne et les deux réseaux VPN (clients VPN et clients VPN en quarantaine). Vous pouvez afficher ou modifier cette règle réseau en sélectionnant Réseaux dans le volet gauche et en ouvrant l'onglet Règles de réseaux dans le volet du centre.
Vous devez à présent configurer l'accès client VPN. Il y a trois paramètres supplémentaires à configurer : les groupes de sécurité Windows ayant une autorisation d'accès, les protocoles pouvant être utilisés par les clients et la mise en correspondance des utilisateurs. La boîte de dialogue de configuration de ces paramètres est illustrée à la figure 6.
Figure 6 Configuration de l'accès client VPN
Figure 6 Configuration de l'accès client VPN
Dans l'onglet Groupes, sélectionnez les groupes Windows qui doivent avoir l'autorisation d'accès à distance via le VPN. D'un point de vue administratif, je pense qu'il est préférable de créer un seul groupe ayant l'autorisation d'accès. Cela facilite la gestion de l'accès à distance.
L'onglet Protocoles indique que seul PPTP est activé par défaut. Vous devez activer L2TP sur IPsec si c'est faisable dans votre environnement.
La mise en correspondance des utilisateurs vous permet de faire correspondre les comptes utilisateur depuis les espaces de noms, tels que le service RADIUS (Remote Authentication Dial-in User Service), vers les comptes Windows pour vous assurer que les stratégies d'accès sont correctement appliquées. Lorsque vous avez défini ces options de configuration et appliqué les modifications à ISA Server, le processus est terminé. Les clients devraient maintenant pouvoir accéder de façon transparente à vos données et applications réseau internes via une connexion VPN.

Améliorations apportées à ISA Server 2006
ISA Server 2006 introduit un grand nombre d'améliorations qui en font un outil encore plus puissant et performant que les versions précédentes. Ces fonctionnalités, parmi lesquelles la compression HTTP, la prise en charge du service de transfert intelligent en arrière-plan (BITS) et la qualité de service (QoS), offrent plusieurs techniques d'optimisation de l'utilisation du réseau. Bien sûr, même avec ces techniques, vous devez continuer d'utiliser les technologies d'optimisation de bande passante courantes qui sont à la base d'ISA Server, notamment la mise en cache.
La compression HTTP est déjà prise en charge depuis un certain temps dans plusieurs produits Microsoft, tels qu'Internet Explorer® depuis la version 4 et Windows Server depuis Windows® 2000. Cependant, c'est la première version d'ISA Server à prendre en charge la compression HTTP ainsi que les algorithmes GZIP standard et Deflate.
Qu'est-ce que cela signifie ? Avec la prise en charge de la compression HTTP, un navigateur Web conforme à la norme HTTP 1.1 peut demander du contenu compressé depuis n'importe quel site Web. N'oubliez pas cependant que seules les réponses sont compressées, et non les connexions sortantes initiales du client.
La compression HTTP est un paramètre de stratégie HTTP globale qui s'applique à tout le trafic HTTP qui passe par ISA Server, et non à celui associé à une règle réseau spécifique. Vous avez cependant la possibilité d'implémenter une compression HTTP par port d'écoute, en utilisant l'Assistant de port d'écoute Web.
La compression HTTP, accessible à l'aide de l'option Général du volet de gauche, est activée par défaut. Mais comme l'illustre la figure 7, vous devez configurer les éléments réseau pour lesquels la compression doit être utilisée. Si l'on reprend l'exemple du VPN de site à site, vous devez sélectionner l'onglet Renvoyer des données compressées et ajouter l'élément réseau VPN de site que vous avez créé plus tôt. À ce stade, vous avez également la possibilité de configurer les types de contenu qui doivent être compressés. Isa Server 2006 est fourni avec une liste de types de contenu standard, mais vous pouvez ajouter des types de contenu personnalisés à l'aide du volet Stratégie de Pare-feu de l'onglet Boîte à outils. N'oubliez pas que l'onglet Renvoyer des données compressées se réfère au fait qu'ISA Server compresse les données avant qu'elles ne soient renvoyées au client. Si vous voulez qu'ISA Server demande qu'un serveur Web traite la compression de données avant que les données ne soient envoyées à ISA Server, vous devez utiliser l'onglet Demander des données compressées.
Figure 7 Configuration de la compression HTTP
Figure 7 Configuration de la compression HTTP
Le service BITS est un service de transfert de fichiers asynchrone pour le trafic HTTP et HTTPS. Windows Server 2003 inclut BITS version 1.5, qui prend en charge les téléchargements en aval et en amont, bien ces derniers puissent nécessiter Internet Information Services (IIS) version 5.0 ou supérieure. En tant que service intelligent de transfert de fichiers, BITS a la possibilité d'examiner le trafic réseau et d'utiliser uniquement la portion inactive de votre bande passante du réseau. De plus, le transfert de fichiers est dynamique et BITS répond aux pics de trafic réseau normal en limitant l'utilisation de réseau. L'avantage est que BITS vérifie que les téléchargements en aval et en amont de fichiers volumineux n'ont pas un impact négatif sur d'autres utilisations du réseau. Du point de vue d'un administrateur, cela signifie que vous devriez recevoir beaucoup moins appels signalant des performances réseau médiocres. Bonne nouvelle !
BITS offre d'autres avantages qui peuvent améliorer l'expérience utilisateur et les performances réseau. Par exemple, un transfert de fichiers qui utilise BITS est binaire, c'est-à-dire que BITS peut reprendre les transferts de fichiers (sans recommencer à zéro) qui ont été interrompus par des facteurs tels qu'une panne du réseau. En outre, ISA Server 2006 inclut la prise en charge intégrée d'une fonctionnalité de mise en cache Microsoft Update qui utilise la mise en cache BITS pour optimiser les mises à jour.
Le protocole DiffServ (Differentiated Services) active la stratégie de priorité des paquets (ou QoS) pour le trafic HTTP et HTTPS. En d'autres termes, selon votre configuration ISA Server, certains trafics auront la priorité. Cette fonction est utile pour les réseaux qui ont une bande passante limitée, en raison du volume de trafic ou de la vitesse de connexion réseau. Selon l'IETF (Internet Engineering Task Force), DiffServ est un mécanisme de gestion du trafic basé sur les classes. Ainsi, DiffServ peut distinguer les types de trafic et les gérer en conséquence, et s'assurer que le trafic prioritaire obtient la préférence.
Pour offrir cette fonctionnalité, ISA Server fonctionne conjointement avec les routeurs qui prennent en charge QoS. Il est important de s'assurer que les éléments DiffServ d'ISA Server correspondent aux priorités sur vos routeurs si vous voulez que les paquets soient acheminés avec les mêmes priorités.
Dans ISA Server, ce type de priorisation des paquets est un paramètre de stratégie HTTP global et est appliqué à tout le trafic HTTP qui passe par ISA Server 2006 en utilisant un filtre Web DiffServ. Ceci signifie qu'ISA Server ne prend pas en charge DiffServ pour d'autres protocoles et peut même ignorer les morceaux DiffServ existants ou tout trafic non HTTP.
Comme l'illustre la figure 8, DiffServ est implémenté en tant que filtre Web et est accessible en sélectionnant Compléments dans le volet gauche. Il est important que vous ne modifiiez pas les paramètres par défaut ni la commande de priorité du filtre de DiffServ car ISA Server doit inspecter la taille de la requête/réponse au moment de son traitement.
Figure 8 Affichage du filtre Web DiffServ
Figure 8 Affichage du filtre Web DiffServ
Si vous examinez la figure 8, vous remarquerez que le filtre DiffServ n'est pas activé par défaut. Pour activer le filtre, il suffit de sélectionner Activer les filtres sélectionnés dans le volet Tâches, puis de configurer le filtre. Comme la priorisation des paquets DiffServ dans ISA Server est basée sur des URL ou des domaines spécifiques, vous devez ajouter ces informations aux préférences DiffServ. Pour cela, sélectionnez Général dans le volet gauche de la console de gestion, puis, dans Paramètres de stratégie HTTP globale, sélectionnez Spécifier les préférences DiffServ. Lorsque vous spécifiez ces préférences, vous devez définir les priorités ainsi que les URL et domaines qui doivent être priorisés. Isa Server 2006 offre de nouvelles fonctionnalités puissantes pour la configuration de l'accès à distance pour les clients VPN ou la création de VPN de site à site. C'est l'outil le plus approprié si vous envisagez d'implémenter une solution VPN.

Alan Maddison est consultant senior dans le département de technologie Microsoft chez MTI Technology Corporation. Ses domaines de spécialisation sont Active Directory, Exchange Server et la virtualisation.


 SQL&#160;Server: Optimisation des performances des requ&#234;tes SQL&#160;Server
SQL Server Maciej Pilecki

Optimisation des performances des requêtes SQL Server
Vue d'ensemble:
  • Analyse des plans d'exécution
  • Optimisation des requêtes
  • Identification des requêtes à régler

Lors de l'optimisation de votre serveur de base de données, vous devez régler les performances des requêtes individuelles. C'est aussi important, voire plus important, que le réglage d'autres aspects de votre installation de serveur affectant les performances, tels que le matériel et les configurations logicielles.
Même si votre serveur de base de données s'exécute sur le matériel le plus puissant disponible, ses performances peuvent être affectées par une poignée de requêtes au comportement indésirable. En fait, une seule mauvaise requête, parfois appelée « requête rebelle », peut provoquer des problèmes de performances sérieux pour votre base de données.
À l'inverse, les performances globales de votre base de données peuvent être fortement améliorées en réglant une série de requêtes plus coûteuses ou très fréquemment exécutées. Dans cet article, j'examinerai quelques unes des techniques auxquelles vous pouvez recourir pour identifier et régler les requêtes les plus coûteuses et les moins performantes sur votre serveur.

Analyse des plans d'exécution
Lors du réglage d'une requête individuelle, vous commencez habituellement par examiner le plan d'exécution de cette requête. Le plan d'exécution décrit la séquence des opérations, physiques et logiques, que SQL ServerTM exécutera afin de satisfaire la requête et de produire le jeu de résultats souhaité. Le plan d'exécution est produit par un composant du moteur de base de données appelé optimiseur de requête pendant la phase d'optimisation du traitement de requête. Celui-ci tient compte d'un grand nombre de facteurs différents, tels que les prédicats de recherche utilisés dans la requête, les tables impliquées et leurs conditions de jointure, la liste des colonnes renvoyées et la présence d'index utiles qui peuvent servir de chemins d'accès efficaces aux données.
Pour les requêtes complexes, le nombre de permutations possibles peut être énorme, c'est pourquoi l'optimiseur de requête n'évalue pas toutes les possibilités mais essaie plutôt de rechercher un plan « suffisamment bon » pour une requête donnée. En effet, il peut ne pas toujours être possible de trouver un plan parfait et, même lorsque c'est possible, le coût de l'évaluation de toutes les possibilités pour la recherche du plan parfait peut facilement dépasser les gains de performances. Du point de vue de l'administrateur de base de données, il est important de comprendre le processus et ses restrictions.
Il existe plusieurs façons de récupérer un plan d'exécution pour une requête :
  • Management Studio fournit les fonctionnalités d'affichage du plan d'exécution réel et du plan d'exécution estimé, qui présentent le plan sous forme graphique. Ces fonctionnalités offrent la solution la plus adaptée pour un examen direct et représentent de loin l'approche la plus souvent utilisée pour l'affichage et l'analyse des plans d'exécution. (Dans cet article, j'utiliserai des plans graphiques produits de cette façon pour illustrer mes exemples)
  • Les diverses options de SET, telles que SHOWPLAN_XML et SHOWPLAN_ALL, renvoient le plan d'exécution sous forme de document XML décrivant le plan avec un schéma spécial, ou de jeu de lignes avec description textuelle de chacune des opérations du plan d'exécution.
  • Les classes d'événement du Générateur de profils SQL Server, telles que Showplan XML, vous permettent de rassembler les plans d'exécution d'instructions recueillies par un suivi.
Bien qu'une représentation XML du plan d'exécution ne soit peut-être pas le format le plus facile à lire pour un humain, cette option vous permet d'écrire des procédures et des utilitaires capables d'analyser vos plans d'exécution en recherchant les signes de problèmes de performance et de plans non optimaux. Une représentation XML peut également être enregistrée dans un fichier avec une extension .sqlplan et être ensuite ouverte dans Management Studio pour produire une représentation graphique. Ces fichiers peuvent également être enregistrés pour analyse ultérieure, ce qui élimine bien sûr le besoin de reproduire le plan d'exécution chaque fois que vous voulez l'analyser. Cette fonction est particulièrement utile lorsque vous voulez comparer vos plans pour examiner leur évolution au fil du temps.

Coût d'exécution estimé
La première chose à comprendre concernant les plans d'exécution est la façon dont ils sont générés. SQL Server utilise un optimiseur de requête basé sur le coût, c'est-à-dire qu'il essaie de produire un plan d'exécution avec le coût estimé le plus bas. L'estimation est basée sur les statistiques de distribution des données accessibles à l'optimiseur lorsqu'il évalue chaque table impliquée dans la requête. Si ces statistiques sont absentes ou périmées, l'optimiseur de requête ne disposera pas des informations vitales dont il a besoin pour le processus d'optimisation de requête et ses estimations seront probablement erronées. Dans de tels cas, l'optimiseur choisira un plan moins optimal en surestimant ou en sous-estimant les coûts d'exécution des différents plans.
Le coût d'exécution estimé fait l'objet de nombreuses suppositions inexactes. En particulier, il est souvent supposé que le coût d'exécution estimé est un bon indicateur de la durée nécessaire à l'exécution d'une requête et que cette estimation permet de distinguer les bons plans des mauvais plans. Ce n'est pas vrai. Premièrement, nous disposons de nombreuses informations sur les unités qui expriment le coût estimé et sur une éventuelle relation directe avec la durée d'exécution. Deuxièmement, puisqu'il s'agit d'estimations qui peuvent être incorrectes, les plans avec des coûts estimés élevés peuvent parfois être beaucoup plus efficaces en termes de processeur, d'E/S et de temps d'exécution, malgré leur estimation élevée. C'est souvent le cas avec les requêtes qui impliquent des variables de table. Puisque aucune statistique n'est disponible pour les variables de table, l'optimiseur de requête suppose toujours qu'une variable de table contient une seule ligne, même si elle en contient beaucoup plus. Par conséquent, l'optimiseur de requête choisira un plan basé sur une estimation inexacte. Donc, lors de la comparaison des plans d'exécution de vos requêtes, vous ne devez pas uniquement vous fier au coût de requête estimé. Incluez plutôt le résultat des options STATISTICS I/O et STATISTICS TIME dans l'analyse pour comprendre à quoi correspond réellement le coût d'exécution en termes d'E/S et de temps de processeur.
Un type spécial de plan d'exécution, portant le nom de plan parallèle, mérite d'être mentionné ici. Si vous exécutez votre requête sur un serveur multiprocesseur et que votre requête peut faire l'objet d'un travail en parallèle, un plan parallèle peut être choisi. (Généralement, l'optimiseur de requête prendra uniquement en compte un plan parallèle pour une requête dont le coût dépasse un certain seuil configurable) En raison des surcharges liées à la gestion des threads d'exécution parallèles multiples (ce qui signifie distribuer le travail entre des threads, exécuter la synchronisation et rassembler les résultats), les projets parallèles coûtent davantage à l'exécution et ceci se reflète dans leur coût estimé. Pourquoi sont-ils alors privilégiés par rapport aux plans non parallèles et moins coûteux ? Grâce à l'utilisation de la puissance de traitement de processeurs multiples, les plans parallèles ont tendance à produire des résultats plus rapidement que les plans standard. En fonction de votre scénario spécifique, notamment des variables telles que les ressources disponibles et la charge simultanée des autres requêtes, cette situation peut être souhaitable pour votre installation. Le cas échéant, vous devez identifier les requêtes pouvant produire des plans parallèles et le nombre de processeurs pouvant être utilisés par chacune. Pour ce faire, vous devez définir l'option Degré maximum de parallélisme au niveau du serveur et la remplacer au niveau des requêtes individuelles par OPTION (MAXDOP n) selon les besoins.

Analyse d'un plan d'exécution
Je vais maintenant examiner une requête simple, son plan d'exécution et certaines méthodes d'amélioration de ses performances. Disons que j'exécute cette requête à l'aide de Management Studio avec l'option Inclure le plan d'exécution réel activée dans l'exemple de base de données Adventure Works sur SQL Server 2005 :
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
Le résultat est le plan d'exécution illustré dans la figure 1. Cette requête simple calcule la quantité totale de commandes passées par chaque client d'Adventure Works. En examinant le plan d'exécution, vous pouvez voir comment le moteur de base de données traite la requête et produit le résultat. Les plans d'exécution graphiques doivent être lus du haut vers le bas et de la droite vers la gauche. Chaque icône représente une opération logique et physique exécutée et les flèches indiquent le flux de données entre les opérations. L'épaisseur des flèches représente le nombre de lignes transmises entre les opérations. Plus la flèche est épaisse et plus le nombre de lignes impliquées est important. Si vous placez votre pointeur sur une des icônes d'opérateur, une info-bulle jaune (telle que celle illustrée à la figure 2) indique les détails de cette opération particulière.
Figure 1 Exemple de plan d'exécution
Figure 1 Exemple de plan d'exécution
Figure 2 Détails d'une opération
Figure 2 Détails d'une opération
En examinant chacun des opérateurs, vous pouvez analyser la séquence des opérations exécutées :
  1. le moteur de base de données exécute une opération Clustered Index Scan sur la table Sales.Customer et renvoie la colonne CustomerID pour toutes les lignes de cette table.
  2. Il exécute ensuite une opération Index Scan (ce qui correspond à une analyse de table non cluster) sur l'un des index de la table Sales.SalesOrderHeader. Il s'agit d'un index sur la colonne CustomerID, qui inclut également implicitement la colonne SalesOrderID (la clé de table non cluster). Les valeurs de ces deux colonnes sont renvoyées par l'analyse.
  3. Le résultat des deux analyses est réuni sur la colonne CustomerID à l'aide de l'opérateur physique Merge Join. (Il s'agit de l'une des trois méthodes physiques d'exécution d'une opération de jointure logique) Cette opération est rapide mais nécessite que les deux entrées soient triées dans une colonne jointe. En l'occurrence, les deux opérations d'analyse ont déjà renvoyé les lignes triées sur CustomerID et il n'est donc pas nécessaire d'effectuer une opération de tri supplémentaire).
  4. Ensuite, le moteur de base de données exécute une analyse de l'index en cluster sur la table Sales.SalesOrderDetail, et récupére les valeurs des quatre colonnes (SalesOrderID, OrderQty, UnitPrice et UnitPriceDiscount) à partir de toutes les lignes de cette table. (Il y avait 123 317 lignes estimées comme devant être renvoyées par cette opération et ce nombre de lignes a effectivement été renvoyé, comme vous pouvez le constater dans les propriétés Estimated Number of Rows et Actual Number of Rows de la figure 2 ; l'estimation était donc très précise.)
  5. Les lignes générées par l'analyse d'index en cluster sont transmises au premier opérateur Compute Scalar, si bien que la valeur de la colonne calculée LineTotal peut être calculée pour chaque ligne, sur la base des colonnes OrderQty, UnitPrice et UnitPriceDiscount impliquées dans la formule.
  6. Le second opérateur Compute Scalar applique la fonction ISNULL au résultat du calcul précédent, comme requis par la formule de colonne calculée. Cette opération termine le calcul de la colonne LineTotal et renvoie le résultat, avec la colonne SalesOrderID, à l'opérateur suivant.
  7. Le résultat de l'opérateur Merge Join de l'étape 3 est joint au résultat de l'opérateur Compute Scalar de l'étape 6, à l'aide de l'opérateur physique Hash Match.
  8. Un autre opérateur Hash Match est ensuite appliqué pour regrouper les lignes renvoyées depuis Merge Join par la valeur de colonne CustomerID et l'agrégat SUM calculé de la colonne LineTotal.
  9. Le dernier nœud, SELECT, n'est pas un opérateur physique ou logique mais plutôt un emplacement réservé qui représente les résultats et le coût globaux de la requête.
Sur mon portable, ce plan d'exécution présentait un coût estimé de 3,31365 (comme illustré à la figure 3). Lorsqu'elle a été exécutée avec STATISTICS I/O ON, la requête a fait état d'un total de 1 388 opérations de lecture logiques sur les trois tables impliquées. Les pourcentages affichés sous chacun des opérateurs représentent le coût de chaque opérateur individuel par rapport au coût global estimé du plan d'exécution dans son ensemble. En examinant le plan de la figure 1, vous pouvez voir que l'essentiel du coût total du plan d'exécution complet est associé aux trois opérateurs suivants : l'opérateur Clustered Index Scan de la table Sales.SalesOrderDetail et les deux opérateurs Hash Match. Mais avant d'essayer d'optimiser ceux-ci, j'aimerais attirer l'attention d'une modification très simple de ma requête qui me permettra d'éliminer complètement deux des opérateurs.
Figure 3 Coût total d'exécution estimé de la requête
Figure 3 Coût total d'exécution estimé de la requête
Puisque la seule colonne que je renvoie à partir de la table Sales.Customer table est CustomerID, et que cette colonne est également incluse en tant que clé étrangère dans la table Sales.SalesOrderHeaderTable, je peux éliminer complètement la table Customer de la requête sans modifier le sens logique ou le résultat produit par notre requête en utilisant ce code :
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Ceci se traduit par un plan d'exécution différent, illustré à la figure 4.
Figure 4 Plan d'exécution après élimination de la table Customer de la requête
Figure 4 Plan d'exécution après élimination de la table Customer de la requête
Deux opérations ont été entièrement éliminées : l'opération Clustered Index Scan sur la table Customer et l'opération Merge Join entre Customer et SalesOrderHeader. L'opération Hash Match a été remplacée par une opération Merge Join beaucoup plus efficace. Cependant, pour utiliser Merge Join entre les tables SalesOrderHeader et SalesOrderDetail, les lignes des deux tables ont dû être renvoyées triées selon la colonne de jointure SalesOrderID. Pour atteindre cet objectif, l'optimiseur de requête a décidé d'exécuter une opération Clustered Index Scan sur la table SalesOrderHeader, au lieu d'utiliser une opération Non-Clustered Index Scan qui aurait été plus économique en termes des E/S impliquées. Il s'agit d'une bonne démonstration pratique du fonctionnement de l'optimiseur de requête, puisque les économies résultant de la méthode physique d'exécution de l'opération de jointure ont été supérieures au coût d'E/S supplémentaires généré par l'opération Clustered Index Scan. L'optimiseur de requête a choisi la combinaison d'opérateurs résultante car elle offrait le coût total d'exécution estimé le plus bas. Sur mon portable, bien que le nombre de lectures logiques ait augmenté (jusqu'à 1 941), le temps de processeur consommé était en fait inférieur et le coût d'exécution estimé de cette requête avait diminué de près de 13 % (2,89548).
Imaginons que je souhaite encore améliorer les performances de cette requête. J'examine maintenant l'opération Clustered Index Scan sur la table SalesOrderHeader, qui est devenue l'opérateur le plus cher de ce plan d'exécution. Dans la mesure où je n'ai besoin que de deux colonnes de cette table pour remplir la requête, je peux créer un index sans cluster contenant uniquement ces deux colonnes, ce qui remplace l'analyse de la table entière par une analyse de l'index sans cluster largement plus petit. La définition d'index pourrait ressembler à ceci :
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Remarquez que l'index que j'ai créé inclut une colonne calculée. Ce n'est pas toujours possible, en fonction de la définition de la colonne calculée.
Après avoir créé cet index et exécuté la même requête, j'obtiens le nouveau plan d'exécution illustré à la figure 5.
Figure 5 Plan d'exécution optimisé
Figure 5 Plan d'exécution optimisé
L'opération Clustered Index Scan sur la table SalesOrderDetail a été remplacée par une opération non-Clustered Index Scan avec coût nettement inférieur en termes d'E/S. J'ai également éliminé l'un des opérateurs Compute Scalar, car mon index inclut déjà une valeur calculée de la colonne LineTotal. Le coût estimé du plan d'exécution est maintenant 2,28112 et la requête effectue 1 125 lectures logiques lorsqu'elle est exécutée.

Index de couverture
Exercice de requête de commandes client
Q Voici exercice de requête de commandes client : Essayez de déterminer la définition d'index, c'est-à-dire les colonnes qu'il doit contenir pour devenir index de couverture pour cette requête, et si l'ordre des colonnes dans la définition d'index entraînerait une différence au niveau des performances.
R Je vous ai mis au défi de trouver l'index de couverture le plus optimal à créer sur la table Sales.SalesOrderHeader pour la requête d'exemple de mon article. Pour y arriver, la première chose que vous devriez remarquer est que la requête utilise seulement deux colonnes de la table : CustomerID et SalesOrderID. Si vous avez lu mon article attentivement, vous aurez remarqué que dans le cas de la table SalesOrderHeader, il existe déjà un index qui couvre cette requête. Il s'agit de l'index sur CustomerID, qui contient implicitement la colonne SalesOrderID, clé de clustering de la table.
Bien sûr, j'ai également expliqué pourquoi l'optimiseur de requête a décidé de ne pas utiliser cet index. Oui, vous pourriez forcer l'optimiseur de requête à utiliser cet index, mais la solution serait moins efficace que le plan existant qui utilise les opérateurs Clustered Index Scan et Merge Join. En effet, vous forceriez l'optimiseur de requête à faire un choix entre l'exécution d'une opération Sort supplémentaire afin de pouvoir toujours utiliser Merge Join ou revenir à l'utilisation d'une opération Hash Join moins efficace. Les deux options ont un coût d'exécution estimé plus élevé que le plan existant (la version avec l'opération Sort offrirait des performances particulièrement médiocres), et l'optimiseur de requête ne les utilisera pas à moins qu'il soit forcé à le faire. Par conséquent, dans cette situation, le seul index qui offrira de meilleures performances que Clustered Index Scan est un index sans cluster sur SalesOrderID, CustomerID. Mais il est important de noter que les colonnes doivent être dans cet ordre particulier :
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Si vous créez cet index, le plan d'exécution contiendra l'opérateur Index Scan au lieu de l'opérateur Clustered Index Scan. Il s'agit d'une différence significative. Dans ce cas, l'index sans cluster contenant seulement deux colonnes est beaucoup plus petit que la table entière sous forme d'index avec cluster. Par conséquent, elle nécessitera moins d'E/S pour lire les données nécessaires.
Cet exemple démontre également que l'ordre des colonnes de votre index peut avoir un impact significatif sur son utilité pour l'optimiseur de requête. Gardez ceci à l'esprit lorsque vous concevez des index multi-colonnes.

L'index que j'ai créé sur SalesOrderDetail est un exemple de ce que l'on appelle « index de couverture ». Il s'agit d'un index sans cluster qui contient toutes les colonnes nécessaires à l'exécution de la requête, éliminant ainsi la nécessité d'analyser la table entière avec les opérateurs Table Scan ou Clustered Index Scan. L'index est essentiellement une copie plus réduite de la table, contenant un sous-ensemble des colonnes de la table. Seules les colonnes nécessaires pour répondre à la requête (ou aux requêtes) sont incluses dans l'index. En d'autres termes, l'index contient juste ce dont il a besoin pour « couvrir » la requête.
La création d'index de couverture pour les requêtes les plus fréquemment exécutées est l'une des tâches les plus simples et les plus courantes utilisées dans le réglage de requêtes. Elle fonctionne particulièrement bien dans les situations où la table contient un nombre de colonnes réduit mais où peu d'entre elles sont souvent référencées par les requêtes. En créant un ou plusieurs index de couverture, vous pouvez améliorer fortement les performances des requêtes concernées, car elles accéderont à une quantité de données beaucoup plus réduite qui, à leur tour, provoqueront moins d'E/S. Il y a, cependant, un coût masqué lié à la maintenance des index supplémentaires pendant les opérations de modification de données (INSERT, UPDATE et DELETE). En fonction de votre environnement et du rapport entre les requêtes SELECT et les modifications de données, vous devez juger avec précaution si ces surcharges de maintenance d'index supplémentaires sont justifiées par les améliorations de performances de requêtes.
Ne craignez pas de créer des index multi-colonnes, par opposition à des index à colonne unique. Ceux-ci ont tendance à être beaucoup plus utiles que les index à colonne unique et l'optimiseur de requête est plus susceptible de les utiliser pour couvrir la requête. La plupart des index de couverture sont des index multi-colonnes.
Dans le cas de mon exemple de requête, celle-ci peut toujours être améliorée et cette requête pourrait être optimisée davantage en plaçant un index de couverture sur la table SalesOrderHeader. Ceci élimine l'opération Clustered Index Scan en la remplaçant par une opération Non-Clustered Index Scan Je vous laisse ceci comme exercice. Essayez de déterminer la définition d'index, c'est-à-dire les colonnes qu'il doit contenir pour devenir index de couverture pour cette requête et si l'ordre des colonnes dans la définition d'index provoquerait une différence pour les performances. Voir l'encadré "Exercice de requête de commandes client" pour la solution.

Vues indexées
Si les performances de ma requête d'exemple sont très importantes, je peux aller plus loin et créer une vue indexée qui enregistre physiquement les résultats matérialisés de la requête. Les vues indexées s'accompagnent de certaines conditions préalables et restrictions, mais s'il est possible d'en utiliser, celles-ci peuvent améliorer considérablement les performances. Gardez à l'esprit que les vues indexées sont synonymes de coût de maintenance plus élevé que les index standard. Par conséquent, soyez prudent lorsque vous les utilisez. Dans ce cas, la définition d'index pourrait ressembler à ceci :
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Vous remarquerez l'option WITH SCHEMABINDING, qui est une condition préalable pour créer un index sur une telle vue et la fonction COUNT_BIG(*), qui est nécessaire si notre définition d'index contient une fonction d'agrégat (dans cet exemple, SUM). Après avoir créé cette vue, je peux créer un index sur celle-ci, comme ceci :
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
Lorsque je crée cet index, le résultat de la requête incluse dans la définition de la vue est matérialisé et enregistré physiquement sur le disque dans l'index. Notez que toutes les opérations de modification de données sur les tables de base mettent ensuite automatiquement à jour les valeurs dans la vue conformément à sa définition.
Si je réexécute maintenant la requête, ce qui se produit dépend de l'édition de SQL Server que j'exécute. Dans les éditions Enterprise ou Developer, l'optimiseur de requête fait automatiquement correspondre cette requête à la définition de vue indexée et utilise la vue indexée au lieu d'interroger les tables de la base impliquées. La figure 6 illustre le plan d'exécution généré dans ce cas. Il consiste en une seule opération : un Clustered Index Scan de l'index que j'ai créé sur la vue. Le coût d'exécution estimé est seulement 0,09023 et il effectue seulement 92 lectures logiques.
Figure 6 Plan d'exécution avec utilisation de la vue indexée
Figure 6 Plan d'exécution avec utilisation de la vue indexée
Vous pouvez toujours créer et utiliser cette vue indexée dans les autres éditions de SQL Server, mais pour arriver au même résultat, vous devez modifier la requête pour référencer la vue directement en utilisant l'indicateur NOEXPAND, comme ceci :
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Comme vous pouvez le voir, les vues indexées peuvent constituer une fonctionnalité très puissante si elles sont convenablement utilisées. Elles sont particulièrement utiles pour optimiser les requêtes qui réalisent des agrégations sur de grandes quantités de données. Si elles sont utilisées dans Enterprise Edition, elles peuvent profiter à de nombreuses requêtes sans nécessiter de modifications de votre code.

Identification des requêtes à régler
Comment puis-je identifier les requêtes qui valent la peine d'être réglées ? Je recherche les requêtes qui sont fréquemment exécutées. Elles peuvent ne pas avoir un coût d'exécution unique élevé, mais le coût agrégé d'exécution peut être beaucoup plus élevé que celui d'une grande requête rarement exécutée. Je ne dis pas qu'il n'est pas nécessaire de régler les grandes requêtes, mais je pense juste que vous devriez d'abord vous concentrer sur les requêtes les plus fréquemment exécutées. Mais alors, comment les identifier ?
Malheureusement, la méthode la plus fiable est quelque peu compliquée et implique l'exécution d'un suivi de toutes les requêtes exécutées pour votre serveur et leur regroupement en fonction de leur signature. (C'est-à-dire, le texte de requête avec les valeurs de paramètre réelles remplacées par des espaces réservés afin d'identifier le même type de requête, même s'il a été exécuté avec des valeurs de paramètre différentes) Ce processus est compliqué, car les signatures de requête sont difficiles à générer. Itzik Ben-Gan décrit une solution utilisant des fonctions CLR définies par l'utilisateur et des expressions régulières dans son livre Inside Microsoft SQL Server 2005: T-SQL Querying.
Il existe une autre méthode beaucoup plus simple, bien qu'un peu moins fiable. Vous pouvez vous appuyer sur les statistiques conservées dans le cache de plan d'exécution pour toutes les requêtes, et les interroger en utilisant des vues de gestion dynamiques. La figure 7 contient un exemple de requête qui vous montre le texte et le plan d'exécution des 20 requêtes de votre cache avec le nombre cumulé le plus élevé de lectures logiques. Cette requête est très pratique pour identifier rapidement les requêtes qui génèrent le plus grand nombre de lectures logiques, mais elle s'accompagne de restrictions. En effet, elle affichera uniquement les requêtes dont le plan est mis en cache au moment où vous exécutez la requête. Si une opération n'est pas mise en cache, vous la manquerez.
Figure 7 Identification des 20 requêtes les plus coûteuses en termes d'E/S de lecture (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
Après avoir identifié ces éléments peu performants, prenez le temps d'examiner leur plan de requête et recherchez des moyens d'améliorer leurs performances en utilisant certaines techniques d'indexation que j'ai décrites dans cet article. Si vous réussissez, ce sera du temps bien investi.
Bon réglage !

Maciej Pilecki est mentor associé chez Solid Quality Mentors, une entreprise internationale spécialisée dans la formation, l'encadrement et la consultation. Il est Microsoft Certified Trainer (MCT) et Most Valuable Professional (MVP) SQL Server, et participe fréquemment à des cours et des conférences sur de nombreux aspects de SQL Server et du développement d'applications.


 Le mot du r&#233;dacteur en chef: L'&#233;nergie entre vos mains
Le mot du rédacteur en chef
L'énergie entre vos mains

Le numéro du mois dernier a déclenché ce qui j'espère sera un dialogue continu sur le sujet de l'informatique écologique. Il est vrai que ce sujet n'est toujours pas bien défini. (Ça veut dire quoi écologique ? Si ma voiture consomme moins d'essence, est-ce écologique ? Ce n'est pas que j'aie une voiture, ceci-dit. J'habite à New York. Tout le monde marche).
Il semblerait que toutes les entreprises essaient de donner un aspect écolo à leurs produits ou services. Mais il y a une bonne raison à cela, et c'est pour ça que le sujet figurait sur notre propre couverture le mois dernier : le potentiel est énorme.
Nous savons tous qu'il s'agit autant de générer des revenus que d'aider l'environnement. Le fait est qu'une attitude écologique fait vendre et engendre de vrais résultats. (« Ca s'appelle l'économie, abruti ! ») Si une entreprise automobile peut vendre plus de voitures en les rendant plus efficaces, super ! En fin de compte, espérons que nous pouvons avoir une économie saine dans un environnement sain et durable.
Comment ceci influence-t-il les professionnels de l'informatique ? Dr. Jonathan Koomey, scientifique au Lawrence Berkeley National Laboratory et professeur à l'Université de Stanford, a récemment publié une étude estimant la consommation énergétique totale des serveurs aux États-Unis et dans le monde entier. En 2005, les centres de données (des serveurs avec leur infrastructure, par exemple les systèmes de refroidissement) étaient responsables de 1,2 % de la consommation énergétique totale des États-Unis : ceci correspond à l'ensemble de la production de cinq centrales électriques de 1000 mégawatts (MW), pour un coût de 2,7 milliards de dollars. Pour le monde entier, ce coût s'élève à 7,2 milliards de dollars (soit toute la production de 14 centrales électriques de 1000 MW). Il y a là d'énormes économies potentielles à faire, à la fois d'argent et d'énergie, et l'essentiel de ce travail peut commencer dans le centre de données.
Comment planifier la capacité d'un centre de données ? Comment ajuster la capacité pour tenir compte de la demande, sans avoir à fonctionner à 100 % constamment ? (Un indice : virtualisation.) Nous contrôlons des serveurs pour la connectivité réseau, l'utilisation de la mémoire, et ainsi de suite, mais qui s'occupe de la consommation ? Les serveurs les plus anciens consomment-ils beaucoup plus d'énergie que les modèles plus récents ? Cette différence de coût est-elle supérieure au coût d'une nouvelle machine ?
Dans les mois à venir, un de nos experts permanents, Dave Ohara (auteur de l'article du mois dernier, qui est maintenant en ligne sur technetmagazine.com), vous montrera ce que l'on fait ici, chez Microsoft, avec la construction de nos propres centres de données écologiques à Quincy, Washington, et San Antonio, Texas, et comment nous répondons à certaines de ces questions. Nous aimerions aussi savoir comment vous résolvez ces problèmes (ou si vous choisissez de ne pas les résoudre, dites-nous pourquoi). Envoyez-nous un message électronique à tnmag@microsoft.com ou visitez notre blog à l'adresse blogs.technet.com/tnmag. —Joshua Hoffman

Remerciements aux experts techniques Microsoft suivants : Tim Carroll, Omesh Desai, Steve Jenness, Sam Kroonenburg, Mutlu Kurtoglu, KC Lemson, Tim Mintner, Jim Truher, Lutter Woody et Sudarshan Yadav.


 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

Capture d'écran vidéo
My Screen Recorder Pro
deskshare.com/msrpro.aspx
Supposons que vous avez une réunion dans 20 minutes et que vous devez préparer une présentation sur la nouvelle configuration du système. À moins que vous n'utilisiez le même didacticiel d'application presque tous les jours avec des utilisateurs différents ? Si ça vous rappelle quelque chose, un conseil : jetez un œil à My Screen Recorder Pro de DeskShare.
Comme son nom l'indique, cette application vous permet d'enregistrer l'activité se déroulant sur votre bureau sous la forme d'une vidéo, si bien que vous pouvez réaliser une présentation à la dernière minute ou disposer d'un didacticiel réutilisable pour vos clients. My Screen Recorder Pro prend également en charge l'enregistrement audio, vous permettant ainsi d'apporter vos commentaires à la présentation. (Conseil : créez un script ou un plan avant de commencer l'enregistrement).
La création d'une nouvelle vidéo est très simple. Sélectionnez la zone que vous souhaitez enregistrer (l'ensemble de votre bureau, une partie personnalisable du bureau, une partie fixe du bureau ou une fenêtre d'application particulière), puis cliquez sur le bouton d'enregistrement.
L'application peut enregistrer dans les formats AVI, Windows Media® Video (WMV) ou Flash ; vous pourrez ainsi classer vos résultats relativement facilement et même intégrer vos vidéos dans des pages Web ou les diffuser à un public plus large. Vous pouvez aussi créer un fichier exécutable pour votre vidéo afin de la lire localement sur la plupart des ordinateurs Windows®. La vidéo sera alors intégrée dans l'exécutable, ce qui simplifie la distribution et rend la lecture extrêmement intuitive pour l'utilisateur final.
Si votre didacticiel ou présentation se rapporte à plusieurs segments, vous pouvez rassembler plusieurs prises dans une vidéo. Si vous devez apporter des modifications à la vidéo, vous pouvez fractionner ou couper l'enregistrement en fonction de vos besoins.
Bien que vous puissiez généralement utiliser la configuration par défaut, l'application vous permet de modifier la fréquence d'images, la qualité audio et les paramètres de compression en fonction de votre environnement. Cela peu être utile pour répondre aux contraintes de taille ou de bande passante que vous pouvez rencontrer. Vous pouvez également créer un enregistrement en utilisant un mode chronocinématographique simple, ce qui vous permet de compresser des parties de votre enregistrement qui durent longtemps (par exemple, une barre de progression lente). Une autre fonctionnalité intéressante vous permet de modifier le curseur de la souris pour l'enregistrement et d'ajouter des effets de pointeur pour attirer l'attention sur les actions survenant pendant la session d'enregistrement. Vous pouvez par exemple agrandir le pointeur ou faire apparaître des anneaux autour de lui lorsque vous cliquez le bouton de la souris. Par ailleurs, vous pouvez ajouter une légende et un horodatage à l'enregistrement pour l'archivage.
Si vous êtes tordu, parano ou méfiant, My Screen Recorder Pro vous permet de programmer des enregistrements et le programme peut être exécuté à partir de la ligne de commande ; vous pouvez ainsi surveiller les activités qui se déroulent sur un poste de travail en toute discrétion. Enfin, l'application possède des fonctionnalités intégrées pour la publication de vos vidéos sur un site FTP. Associée au programmateur, cette option peut être utile à des fins d'audit.

Prix : 99 USD (vente directe) pour une licence unique.
Créez une présentation en enregistrant ce qui se déroule sur votre bureau
Créez une présentation en enregistrant ce qui se déroule sur votre bureau

Disk Defrag
PerfectDisk 8
raxco.com/products/PerfectDisk2k
La défragmentation de disque dur est essentielle pour n'importe quel système Windows. Si vous êtes comme moi, vous êtes constamment en train d'ajouter et de supprimer des applications, des fonctionnalités et des mises à jour logicielles. Il existe plusieurs utilitaires de défragmentation de disque ; j'ai d'ailleurs parlé de l'un d'eux le mois dernier. Mais la défragmentation est indispensable et PerfectDisk 8 de Raxco Software mérite incontestablement d'être présenté. Bien que toutes les versions de Windows incluent un outil de défragmentation, vous pouvez parfois avoir besoin d'un utilitaire qui offre un contrôle plus précis sur l'opération de défragmentation. Si c'est le cas, examinez PerfectDisk.
Comme on peut s'y attendre pour n'importe quel outil de défragmentation Windows, PerfectDisk 8 peut défragmenter les lecteurs FAT16, FAT32 et NTFS et vous permet également de défragmenter les lecteurs RAID. Disponible dans les versions bureau et serveur, PerfectDisk 8 est certifié pour Windows Vista® et prend en charge d'autres versions de Windows, y compris Windows Server® 2003 et Windows 2000. Il existe même une version pour Exchange.
La société est fière de sa technologie SMARTPlacement, qui tente d'organiser la structure des fichiers sur le disque de façon à accélérer les vitesses d'accès. Par exemple, sur les systèmes Windows XP, la technologie SMARTPlacement se charge de la gestion de vos fichiers de démarrage et layout.ini en les triant de sorte à réduire les temps de recherche sur disque lors du démarrage du système. En plus de défragmenter un lecteur entier, vous pouvez également choisir de défragmenter un seul fichier, ce qui est utile lorsque vous venez de télécharger un fichier ISO de grande taille, par exemple.
Pour s'attaquer à ces sacrés fichiers système auxquels vous ne pouvez normalement pas accéder pendant l'exécution du système d'exploitation, l'application utilise un mode hors connexion qui peut s'exécuter au démarrage suivant du système ou, si les conditions sont réunies, l'application peut essayer de démonter le disque pour exécuter la défragmentation. Autre fonctionnalité pratique : le mode de défragmentation sur économiseur d'écran de PerfectDisk, qui vous permet de commencer automatiquement la défragmentation lorsque l'économiseur d'écran est exécuté.
PerfectDisk inclut également une version de ligne de commande qui vous permet de programmer aisément la défragmentation par le biais de votre planificateur de tâches préféré et d'activer l'exécution à distance grâce aux agents de gestion de système exécutés sur le système. Si vous gérez de grands déploiements, téléchargez gratuitement PerfectDisk Command center, qui vous permet de déployer, mettre à jour, programmer et configurer à distance l'application de poste de travail à l'échelle de l'entreprise.

Prix : PerfectDisk 8 Professional (pour poste de travail) est disponible à partir de 39,99 USD pour une licence unique. PerfectDisk 8 Server est disponible à partir de 239,99 USD pour une licence unique.
PerfectDisk offre un certain nombre d'options de configuration
PerfectDisk offre un certain nombre d'options de configuration

Critique
Network Warrior
oreilly.com
Si votre organisation est équipée de produits Cisco, procurez-vous le livre Network Warrior de Gary Donahue (O'Reilly, 2007). Il peut être utile à tout un tas de lecteurs, que vous fassiez vos débuts dans le domaine de la mise en réseau, que vous ayez reçu récemment votre certification CCNA ou que vous soyez un administrateur système très compétent cherchant à actualiser ses compétences de mise en réseau.
Ce qui me plaît surtout c'est le fait que ce livre se base sur l'application réelle de la technologie de mise en réseau et qu'il vous donne une référence rapide à de nombreuses tâches courantes que vous rencontrez dans vos activités de tous les jours en tant que professionnel des réseaux. Le livre commence par les bases, en définissant exactement en quoi consistent les réseaux les plus élémentaires. Il poursuit en offrant un aperçu général des concentrateurs, des commutateurs, des VLAN, du tronçonnage et du protocole VTP (VLAN Trunk Protocol), ainsi que des arborescences avec le protocole STP (Spanning Tree Protocol) et de la technologie EtherChannel de Cisco System.
Au fil des pages de Network Warrior, vous trouverez des exemples de base utilisant des commandes IOS (Internetwork Operating System) et CLI CatOS, accompagnés d'explications des méthodes et technologies. J'aime que le livre donne un petit historique des méthodologies actuelles, ce qui donne un côté amusant à sa lecture (par exemple, pourquoi il reste un CatOS mais plus d'IOS).
Ce livre inclut une discussion sur les routeurs et le routage en général ; vous y apprendrez les principes de base du routage, des mesures aux distances administratives des différents protocoles de routage. Vous découvrirez également un aperçu de protocoles tels qu'OSPF (Open Shortest Path First), BGP (Border Gateway Protocol) et RIP (Routing Information Protocol).
Dans la section consacrée au protocole HSRP (Hot Standby Router Protocol) de Cisco, l'auteur aborde la disponibilité et propose des configurations de base offrant une protection contre les interruptions de service dans votre infrastructure réseau. S'ensuit une analyse des fonctionnalités de certains commutateurs multicouches Cisco, notamment le Cisco 6500 et le Catalyst 3750, et une discussion de certaines des configurations de base que vous pourriez rencontrer.
J'ai trouvé les informations se rapportant au monde des télécommunications particulièrement utiles. Ce livre vous enseigne quelques rudiments du jargon de la mise en réseau pour vous éviter d'avoir l'air bête la prochaine fois que vous serez confronté à la terminologie spécifique. Vous en apprendrez assez sur CSU/DSU (Channel Service Unit/Data Service Unit), la configuration des connexions DS3 et les relais de trames multinœuds pour pouvoir communiquer avec des techniciens en télécommunications.
Une large section est consacrée à la sécurité et aux pare-feu ; vous y découvrirez comment concevoir et configurer des listes de contrôle d'accès (ACL). L'authentification, les zones démilitarisées et des options de configuration de pare-feu PIX spécifiques sont également abordées. À noter également le bref paragraphe sur la théorie des pare-feu qui souligne des aphorismes de bonnes pratiques tels que celui qui vous encourage à tout refuser tout en autorisant ce dont vous avez besoin ou celui selon lequel « la sécurité est un compromis entre commodité et paranoïa ».
La dernière section de Network Warrior se penche sur la conception de réseaux : les principes de base des conceptions d'infrastructure réseau courantes, tels que la configuration de commerce électronique sur trois niveaux et un réseau réduit sans couche de distribution, sont développés et soulignent l'importance de la documentation et des conventions d'affectation de noms.

Prix : 44,99 USD.

Gestion des verrous de fichiers
WhoLockMe
dr-hoiby.com/WhoLockMe
Si seulement toutes les applications fermaient les fichiers correctement. Malheureusement, ce n'est pas le cas. Les violations de partage peuvent être une véritable plaie et il peut être encore plus compliqué de trouver quel processus est responsable du verrouillage d'un fichier. Je ne sais pas ce que vous en pensez, mais je déteste fermer les applications une par une dans le but unique d'obtenir le contrôle d'un fichier. Heureusement, une extension de l'Explorateur Windows simple et gratuite, appelée WhoLockMe, vient à la rescousse.
Disponible pour Windows NT®, Windows 2000, Windows Server 2003 et Windows XP, cette application vous permet de trouver le processus responsable du verrouillage d'un fichier. Il vous suffit de cliquer avec le bouton droit de la souris et de sélectionner dans votre menu contextuel de l'Explorateur Windows.
WhoLockMe vous indique le nom du processus qui verrouille le fichier, son identificateur de processus (PID), le chemin d'accès du fichier ouvert, le domaine et l'utilisateur du contexte d'exécution du processus et le chemin d'accès complet du coupable. Si vous êtes téméraire, vous pouvez choisir d'arrêter le processus directement depuis l'interface utilisateur.
Malheureusement, WhoLockMe n'a pas été mis à jour depuis un moment et ne fonctionne pas sous Windows Vista. Néanmoins, si vous exécutez une version précédente de Windows, cette application est un outil rapide et efficace pour découvrir d'où provient le verrouillage du fichier que vous avez besoin de déplacer, supprimer ou modifier.

Prix : gratuit

Outils DNS
DNSStuff.com
www.dnsstuff.com
Si vous travaillez avec des applications ou réseaux Internet, vous dépendez certainement du DNS pour vous aider à les gérer, à garantir leur bon fonctionnement et à permettre aux étrangers de savoir où vous et vos applications résidez. J'utilise un jeu d'outils provenant de DNSstuff.com lorsque j'ai un problème de DNS. Cet ensemble d'outils Web peut être très utile pour dépanner et vérifier vos configurations d'infrastructure.
Le site fournit des outils pour les problèmes de domaine, d'IP, de nom d'hôte, de messagerie électronique, de site Web et les problèmes réseau en général, soit plus de 45 outils de requête différents qui peuvent vous aider à tout faire, de la validation de votre configuration de serveur de messagerie à la vérification de la vitesse de votre hébergement DNS. Vous pouvez certainement trouver les équivalents de la plupart de ces outils dans votre infrastructure, mais une vérification externe peut fournir des informations clés pour le dépannage. Et vous n'aurez pas besoin de demander à votre ami qui travaille dans la société d'à côté de faire une recherche DNS inversée pour vous.
L'un des outils les plus puissants et complets du site est DNSreport. Il vous suffit d'entrer un nom de domaine, de cliquer sur le bouton et vous obtiendrez une multitude d'informations sur votre installation. Chaque élément de ligne de test affiche un état identifiable par sa couleur, ce qui est très pratique pour analyser rapidement les résultats de test afin de vérifier la présence éventuelle de problèmes. Le rapport vérifie les zones parents du domaine, en affichant des détails tels que les enregistrements de serveur de noms et en indiquant s'ils envoient ou non l'adresse IP et le nom de l'hôte. Le rapport vérifie également les failles de sécurité potentielles et s'assure que vos serveurs DNS ne sont pas des serveurs ouverts, qu'ils ont des enregistrements de serveur de noms identiques et qu'il n'y a pas de fuite des enregistrements de serveur de noms dans les demandes non NS.
Vous vous ferez également une idée de la disponibilité de votre installation puisque DNSreport teste plusieurs serveurs de noms, les liaisons IP publiques et les serveurs de noms manquants tout en vérifiant les points de défaillance uniques. De plus, DNSreport vérifie vos détails SOA (Start of Authority), renvoie les valeurs de numéro de série SOA, d'actualisation, d'expiration, de nouvelle tentative et de durée de vie (TTL) minimale, tout en réalisant une vérification de vos enregistrements MNAME et RNAME.
Les vérifications des enregistrements MX du rapport valident les entrées DNS inverses, et s'assurent que vous n'avez pas d'enregistrements en double et que vos enregistrements ont des noms d'hôtes valides. En outre, l'outil essaie de se connecter à votre serveur de messagerie et de vérifier par exemple si le nom d'hôte de votre serveur de messagerie figure dans le message d'accueil, s'il accepte les messages abus@votredomaine (comme spécifié dans divers RFC) et si le serveur SMTP est actuellement configuré en tant que relais ouvert (et donc en tant qu'aimant pour les spammeurs du monde entier). Enfin, DNSreport renvoie votre enregistrement www A, vérifie que toutes les adresses IP sont publiques et détermine si votre configuration CNAME provoquera une recherche de DNS supplémentaire.
Si DNSreport ne suffit pas, le site vous permet également d'utiliser un outil de recherche pour vérifier si un serveur de messagerie est répertorié dans une série de bases de données d'expéditeurs de courrier indésirable connus, et un autre outil pour trouver le contact en cas d'abus pour un domaine. Vous pouvez faire des recherches d'IP Whois, de détermination d'itinéraire et de Ping, ainsi que des recherches de DNS général et mis en cache chez des FAI majeurs. Vous pouvez même faire des recherches d'IP NETGEO, des vérifications d'adresses MAC et des vidages de fichiers zones complets si vous vous abonnez. En résumé, il s'agit d'un jeu d'outils très utile.

Prix : 3 USD par mois pour un abonnement utilisateur unique (accès complet et recherches illimitées).
DNSstuff.com fournit toute une série d'outils de surveillance pratiques
DNSstuff.com fournit toute une série d'outils de surveillance pratiques

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


 Questions et r&#233;ponses sur la file d'attente Exchange: Protocoles de courrier &#233;lectronique s&#233;curis&#233;s, courrier ind&#233;sirable myst&#233;rieux, et bien plus encore
Questions et réponses sur la file d'attente Exchange
Protocoles de courrier électronique sécurisés, courrier indésirable mystérieux, et bien plus encore
Nino Bilic and Scott Landry
Cette chronique est partiellement basée sur une version bêta de Windows Server 2008. Toutes les informations contenues dans cet article sont susceptibles d’être modifiées.

Q Je veux utiliser le protocole SMTP sécurisé. Comment faire pour qu'Exchange Server écoute SMTP sur le port 465 ?
R Je suis désolé, mais c'est impossible. Oui, vous pouvez faire en sorte que n'importe quel serveur virtuel SMTP ou connecteur de réception écoute sur le port 465, mais vous n'atteindrez pas votre objectif de SMTP sécurisé (SMTPS).
Pourquoi ? Bon, remontons quelque peu aux origines pour comprendre la situation. Il existe deux types de SSL : explicite et implicite. Au début, la plupart du trafic SSL était implicite, c'est-à-dire qu'un port dédié à SSL était utilisé. Par exemple, HTTP est sur le port 80 par défaut, mais HTTPS (HTTP avec SSL) est sur le port 443. Il y a plusieurs années, la communauté Internet a décidé qu'il n'était pas nécessaire d'utiliser un port dédié pour SSL. C'est ainsi que le SSL explicite est né.
Netscape avait déjà choisi 465 comme port SMTPS, mais Exchange Server ne disposait pas de la fonctionnalité SSL dans SMTP. Cependant, l'équipe d'Exchange a compris l'avantage du SSL explicite (à savoir qu'il pouvait être utilisé de la même façon par les clients et les serveurs) et a choisi de prendre en charge le SSL explicite pour SMTP.
Dans le cas du SMTP, le SSL explicite utilise la commande STARTTLS ESMTP pour signaler que le socket existant est sur le point d'être sécurisé. La plupart des autres fournisseurs de serveurs et clients SMTP ont également implémenté la commande STARTTLS, si bien qu'il n'a pas vraiment été nécessaire de prendre en charge le port 465 qui, de toute façon, n'était pas une norme Internet officielle.
Aujourd'hui encore, aucune version d'Exchange Server ne prend en charge le SSL implicite pour SMTP. Demander à un connecteur de réception Exchange ou à un serveur virtuel SMTP d'écouter sur le port 465 ne modifie pas cet état de chose. Vous devez donc utiliser un client qui prend en charge STARTTLS sur le port 25. Si vous ne pouvez pas utiliser le port 25, le choix logique suivant est 587, qui est le port standard pour les soumissions SMTP des clients. La plupart des clients modernes prennent en charge STARTTLS sur 25, c'est pourquoi l'ajout de la prise en charge du SSL implicite n'a pas été nécessaire.
À propos, les protocoles Exchange POP3 et IMAP4 ont toujours pris en charge le SSL implicite. Mais dans Exchange Server 2007, une prise en charge du SSL explicite a également été ajoutée pour ces deux protocoles. Dans la mesure où peu de clients prennent actuellement en charge cette toute nouvelle norme, le SSL implicite continuera d'être utilisé pendant un certain temps encore.

Q J'ai une grande quantité de courrier en file d'attente dans un certain nombre de domaines et aucun de mes utilisateurs n'a envoyé ce courrier. Comment cela se fait-il et comment empêcher que cela ne se reproduise ?
R Vous n'êtes pas le seul dans ce cas. Quiconque possède un serveur sur Internet est susceptible de rencontrer ce problème. En fait, il existe deux causes possibles. La première est que vous avez ouvert vous-même votre serveur en tant que relais (reportez-vous à support.microsoft.com/kb/304897). Mais bien sûr vous ne feriez pas cela, n'est-ce pas ? (Les relais ouverts sont désactivés par défaut depuis Exchange Server 2000.) Il est donc plus probable que vous soyez confronté à du courrier indésirable sous forme de rapport de non-remise (NDR). Dans le processus d'envoi de courrier publicitaire non sollicité (UCE), les expéditeurs de courrier indésirable envoient souvent leurs messages à des adresses inexistantes dans votre domaine. Votre serveur essaie de faire comprendre à l'expéditeur de courrier indésirable que les utilisateurs n'existent pas, mais bien sûr, l'expéditeur de courrier indésirable a trafiqué l'adresse de retour. L'expéditeur de courrier indésirable peut trafiquer une adresse non valide (dans ce cas le rapport de non-remise est en instance jusqu'à l'expiration du délai) ou peut essayer de faire envoyer par votre serveur un courrier indésirable à un autre domaine, en tant que pièce jointe du rapport de non-remise généré par votre serveur.
Vous pouvez désactiver les rapports de non-remise, mais si un utilisateur légitime fait une faute de frappe dans une adresse par erreur, votre serveur ne l'informera jamais de la non-remise du message électronique et des messages importants risquent d'être perdus. Voici une meilleure solution.
Vérifiez tout d'abord que vous n'avez pas ouvert le relais. (Il fallait que je le dise, car on ne sait jamais.) Activez ensuite un type de filtrage anti-courrier indésirable quelconque, tel que le filtre de message intelligent ou le filtre de contenu d'Exchange Server 2007, ainsi que quelques listes rouges en temps réel. Ces éléments peuvent se trouver soit dans le rôle serveur de transport Edge, soit dans le rôle serveur de transport Hub. Quoi qu'il en soit, cette opération doit s'effectuer au niveau du tout premier tronçon, car plus de 90 % du volume de courrier est vraisemblablement indésirable et vous ne voulez pas encombrer vos serveurs avec ce courrier indésirable).
Enfin, activez le filtrage du destinataire sur le premier serveur Exchange Server qui accepte la réception du courrier dans votre environnement. Votre serveur peut ainsi rejeter un message avant qu'il ne pénètre dans votre réseau. Les fautes de frappe dans l'adresse légitimes feront l'objet d'un rapport de non-remise, mais qui sera généré par le serveur de l'expéditeur.

Q J'utilisais un serveur exécutant Exchange Server 2000 et un autre exécutant Exchange Server 2003. Les deux parvenaient à envoyer du courrier via Internet. J'ai ensuite installé Exchange Server 2007 et maintenant, les boîtes aux lettres sur chaque serveur ne parviennent plus à envoyer le courrier.
R Si vous n'aviez qu'un seul serveur Exchange Server par le passé, vous ne connaissez peut-être pas le concept des connecteurs. Les connecteurs d'échange sont des objets de configuration de routage logiques qui indiquent à Exchange où diriger le message électronique. Lorsque vous introduisez Exchange Server 2007 dans une organisation existante, pour acheminer le courrier, vous devez absolument disposer de connecteurs de groupe de routage et d'un connecteur SMTP.
Vous avez besoin de deux connecteurs de groupe de routage, un allant du groupe de routage Exchange Server 2007 vers le groupe de routage Exchange Server 2003 et vice-versa. Vous pouvez effectuer cette configuration dans le cadre du processus d'installation, mais si vous ne l'avez pas fait ou si vous n'en êtes pas sûr, vous pouvez vérifier en utilisant Exchange Management Shell d'où vous pouvez corriger le problème. À défaut, vous ne pourrez pas envoyer de courrier entre vos serveurs. Les messages finiront dans des files d'attente de destination inaccessibles.
Pour acheminer le courrier Internet, vous n'avez besoin que d'un seul connecteur SMTP, également appelé « connecteur d'envoi » dans Exchange Server 2007. Vous devez en avoir un dans Exchange Server 2000 et Exchange Server 2003, mais vous n'avez peut-être jamais eu à vous en servir. L'espace d'adresse doit être SMTP:* pour tous les domaines et vous pouvez spécifier l'utilisation d'un hôte intelligent ou d'un DNS pour la remise du courrier. Vous choisissez si vous souhaitez que le courrier Internet sortant soit géré par le serveur Exchange Server 2007 ou le serveur plus ancien, ou vous pouvez en créer un sur les deux groupes de routage si vous voulez que chaque serveur gère son propre courrier. Vous pouvez également créer l'un des connecteurs dans le cadre du processus Edgesync si vous avez installé un rôle de serveur de transport Edge.
Si vous avez précédemment installé un hôte intelligent sur le serveur virtuel SMTP, c'est le moment de le supprimer. Il ne doit se trouver que sur le connecteur SMTP, jamais sur le serveur virtuel car cela bloque le connecteur de groupe de routage.
Vous devez également savoir que le courrier électronique entrant est contrôlé par votre enregistrement MX ou par l'IP vers laquelle le pare-feu effectue le transfert. Côté Exchange, la configuration est minime, mais ce document devrait vous aider si vous rencontrez des problèmes : msexchangeteam.com/archive/2006/11/17/431555.aspx.

Q Pourquoi est-ce que j'obtiens plusieurs rapports de journal pour le même message dans Exchange Server 2007 ?
R L'agent de journalisation de transport Exchange Server 2007 effectue une journalisation des messages après catégorisation. Il existe de nombreuses raisons pour lesquelles le catégoriseur peut faire bifurquer un message (c'est-à-dire copier le corps du message et mettre différents destinataires d'enveloppe sur les différentes copies). Voici un exemple : dans la mesure où la journalisation peut maintenant vous indiquer l'appartenance d'un groupe de distribution à l'heure où le message a été envoyé, dans le cas d'un groupe de distribution imbriqué, vous pouvez obtenir plusieurs rapports.
Grâce à cette fonctionnalité supplémentaire de la création des rapports, vous pouvez obtenir plusieurs copies du même message, chacune avec un rapport unique. Cela ne garantit pas de façon certaine que tous les rapports correspondant à un message sont arrivés, mais si vous faites de l'archivage, vous devrez collaborer avec votre fournisseur d'archives pour vous assurer qu'il est conscient des modifications.

Q Où est passée la fonction de transfert des messages non résolus vers l'hôte dans Exchange Server 2007 ? Que dois-je faire maintenant ?
R Elle a disparu.
En fait, cette fonction spécifique ne fonctionnait pas correctement lorsque vous disposiez de plusieurs serveurs Exchange Server. Exchange disposait déjà une autre méthode beaucoup plus puissante pour accomplir la même tâche. En particulier, vous avez la possibilité de partager des domaines SMTP individuels avec autres systèmes. Donc la fonction « transfert non résolu » a été abandonnée et le concept de domaine partagé a été implémenté et simplifié. Dans Exchange Server 2007, il vous suffit d'accéder à Organisation | Transport Hub | Domaines acceptés et de modifier le type de domaine de Faisant autorité à Relais interne. C'est en fait un peu plus complexe que cela pour certains environnements et nous travaillons à la mise à jour de la documentation. Mais ceci devrait vous aider entre temps.

Q J'essaie de préparer mon domaine racine pour l'installation d'Exchange Server 2007. Le serveur à partir lequel j'essaie d'exécuter l'installation d'Exchange Server 2007, est déjà équipé du Gestionnaire système Exchange d'Exchange Server 2003 et l'installation échoue. Quel est le problème ?
En résumé, l'exécution de toute partie de l'installation d'Exchange Server 2007 sur une machine sur laquelle sont installés des composants Exchange Server 2000 ou 2003 n'est pas prise en charge. Comme le Gestionnaire système Exchange d'Exchange Server 2003 est installé, l'installation d'Exchange Server 2007 le voit et la vérification préalable à l'installation échoue. Le message suivant s'affiche : « Une version précédente d'Exchange Server est déjà installée sur cet ordinateur. Exécutez le programme d'installation Exchange 2007 depuis un autre ordinateur ou supprimez la version précédente d'Exchange Server ».
La façon la plus simple de contourner ce problème consiste probablement à exécuter l'installation Exchange Server 2007 à partir d'un autre serveur dans le domaine racine et de préparer votre domaine de cette façon. Si ce n'est pas possible, vous devez désinstaller le composant Exchange Server 2003 avant de poursuivre l'installation d'Exchange Server 2007.
N'oubliez pas que vous pouvez utiliser la version 32 bits d'Exchange Server 2007 pour préparer le domaine. Ainsi vous pouvez utiliser n'importe quel serveur 32 bits dans le domaine racine. Pour plus d'informations, consultez l'article à l'adresse technet.microsoft.com/library/bb232170.aspx.
À propos, cela signifie que vous ne pouvez pas installer le Gestionnaire système Exchange d'Exchange Server 2003 et la console de gestion Exchange d'Exchange Server 2007 sur le même ordinateur. En effet, la coexistence des outils de gestion d'Exchange Server 2003 et Exchange Server 2007 sur le même ordinateur n'est pas prise en charge. Exchange Server 2007 bloque l'installation si vous tentez de l'installer sur un ordinateur sur lequel un composant Exchange Server 2000 ou Exchange Server 2003 est installé.
Notez enfin que vous ne devez pas essayer d'installer d'abord les outils de gestion Exchange Server 2007, puis les outils Exchange Server 2003 sur le même ordinateur. Cette méthode vous place dans une configuration qui n'a pas été testée et qui peut donner des résultats imprévus lorsque vous essayez de gérer vos serveurs. Si vous voulez gérer les deux versions de serveur à partir d'un seul ordinateur, vous pouvez utiliser le bureau à distance pour vous connecter à une version, ou utiliser une machine virtuelle pour héberger une version différente des outils de gestion dans un environnement isolé.

Q Quand donc pourrai-je enfin exécuter les outils de gestion d'Exchange Server 2007 sur mon poste de travail Windows Vista® ?
R La prise en charge officielle des outils de gestion d'Exchange Server 2007 sur Windows Vista est prévue dans le Service Pack 1 d'Exchange Server 2007. Un package contenant les outils de gestion d'Exchange Server 2007 SP1 pourra être téléchargé dès la commercialisation d'Exchange Server 2007 SP1.

Q Qu'en est-il du Gestionnaire système Exchange d'Exchange Server 2003 sur Windows Vista ou Windows Server 2008 ? Pourrai-je également les exécuter ?
R Non, malheureusement cela ne fonctionnera pas. Les outils de gestion de toute version d'Exchange Server antérieure à Exchange Server 2007 SP1 ne seront pas pris en charge par Windows Vista ou Windows Server 2008. En d'autres termes, même après la commercialisation de Windows Server 2008, l'installation du Gestionnaire système Exchange d'Exchange Server 2003 sur ce logiciel ne sera pas prise en charge. La gestion des serveurs Exchange Server 2003 doit s'effectuer à partir de stations de travail Windows Server 2003 ou de postes de travail de Windows XP. Sinon, vous pouvez également utiliser la connexion Bureau à distance de n'importe quel système d'exploitation.

Q J'exécute plusieurs serveurs Exchange Server 2003 dans mon domaine. Pourrai-je mettre à niveau mes contrôleurs de domaine vers des contrôleurs de domaine Windows Server 2008 ?
R Oui, tout à fait. L'exécution d'Exchange Server 2003 SP2 dans un domaine possédant des contrôleurs de domaine Windows Server 2008 est prise en charge. Veuillez noter qu'Exchange Server ne peut pas utiliser les contrôleurs de domaine en lecture seule (RODC) ou les serveurs de catalogue global en lecture seule (ROGC) de Windows Server 2008. Si vous spécifiez manuellement (par codage en dur) à Exchange Server d'utiliser les RODC/ROGC de Windows Server 2008, vous risquez d'être confronté à un comportement imprévu.

Nino Bilic, responsable du programme de capacité de prise en charge pour Exchange Server, consacre ses loisirs à la découverte de la beauté de la communication de serveur à serveur en lisant une tonne d'analyses Netmon le soir avant de s'endormir.
Scott Landrytechnicien de support de gestion pour Exchange Server, ne se déplace jamais sans sa serviette, un exemplaire du Guide et son fidèle téléphone mobile Windows


 Coup de projecteur sur les utilitaires: Applets de commande SMS pour Windows&#160;PowerShell
Coup de projecteur sur les utilitaires
Applets de commande SMS pour Windows PowerShell
Don Brown
Télécharger le code de cet article: Utility2007_11.exe (1211KB)

Auparavant, il n'existait aucun moyen de gérer vos clients Microsoft System Management Server (SMS) 2003 à partir de la ligne de commande. Heureusement, parmi les nombreuses technologies d'exception qui ont récemment émergé pour aider les administrateurs à gérer la complexité, les modifications et la configuration, Windows PowerShell est arrivé pour résoudre ce problème.
Pour l'exploiter, j'ai écrit un petit « utilitaire », SMS2003PowerShellSnapinSample (que vous pouvez trouver dans le téléchargement de code qui accompagne cet article, disponible en ligne à l'adresse technetmagazine.com/code07.aspx). L'utilitaire se limite, en fait, à une collection de six applets de commande assemblées en un seul composant logiciel enfichable Windows PowerShellTM. À l'aide de ces applets de commande, vous pouvez configurer la stratégie locale du client SMS à partir de Windows PowerShell pour l'ordinateur local ou les groupes d'ordinateurs distants.
Plus je joue avec la stratégie locale du client SMS, plus je la trouve logique. Avantage collatéral, cela m'a permis d'en découvrir davantage sur le fonctionnement de SMS. J'ai appris qu'en appliquant soigneusement la stratégie locale du client SMS, il était possible de le contrôler d'une toute nouvelle façon : il n'est pas nécessaire de configurer de la même façon tous les ordinateurs sous l'autorité du même site. Des nouvelles idées ont commencé à germer dans mon esprit : configuration de certains ordinateurs pour qu'ils puissent être contrôlés à distance sans qu'aucune autorisation ne soit exigée, modification de la fréquence de contrôle de la nouvelle stratégie de la part du client, désactivation de composants spécifiques à diverses heures du jour, et bien d'autre. L'utilisation de la stratégie locale du client SMS n'est limitée qu'à la mesure de vos idées. Examinons cela de plus près.

À propos de la stratégie locale du client avancé SMS
Programmation de ressources
  • Présentation de Windows PowerShell Notions fondamentales indispensables pour toute personne souhaitant commencer à utiliser Windows PowerShell
  • Forum Technet sur la personnalisation de SMS à l'aide des stratégies locales Application MOF de la stratégie locale du client avancé SMS
  • Création de votre première applet de commande
  • Comment créer un composant logiciel enfichable Windows PowerShell
  • Client de protection d'accès réseau (NAP) pour Windows Server 2008
  • Guide du programmeur Windows PowerShell Pour ceux qui souhaitent plus d'informations sur l'écriture des applets de commande, des composants logiciels enfichables, des hôtes et d'autres aides à la programmation de Windows PowerShell
  • Guides pas-à-pas de Windows Server 2008 Bêta 3

Tous les clients avancés SMS 2003 fonctionnels ont une stratégie de configuration, laquelle se résume à une liste de paramètres pilotant leurs divers composants. Tous les paramètres du client, du regroupement Inventaire et de la distribution logicielle (entre autres) sont inclus dans ces stratégies de configuration. Les stratégies elles-mêmes sont créées sur le serveur du site et fournies au Client avancé via le point de gestion SMS.
Le véritable corps d'une stratégie SMS est similaire à un fichier MOF (Managed Object Format) en ce sens qu'il contient une série d'instances qui seront compilées dans les espaces de noms\\.\root\CCM WMI (Windows® Management Instrumentation) sur le client avancé. Les divers autres agents liront ensuite ces paramètres, qui se trouvent dans l'espace de noms \\.\root\ccm\policy\machine\requestedconfig. En appliquant la stratégie locale via MOF, cependant, vous ne pouvez compiler qu'un seul MOF sur un seul ordinateur et il doit être exécuté localement (ou plutôt, lorsque vous avez ouvert une session directement sur l'ordinateur). Mais WMI, du fait de sa nature distribuée, est accessible à la fois localement et à distance, ce qui engendre un plus large éventail d'options destinées à aider les administrateurs SMS. En d'autres termes, vous pouvez vous connecter à WMI sur un ordinateur distant aussi facilement que vous pouvez vous connecter à WMI sur votre ordinateur local, sous réserve que vous disposiez des droits administratifs appropriés.
La stratégie du client SMS se compose de paramètres de configuration pour les divers composants clients, mais elle peut également inclure des instructions permettant d'exécuter le contenu du package logiciel. À l'instar de la stratégie de groupe Active Directory®, la stratégie du client avancé SMS 2003 obtenue à parti d'un point de gestion SMS peut être remplacée par la stratégie locale du client SMS. Vous ne pouvez pas remplacer toutes les parties d'une stratégie, mais certaines propriétés vraiment intéressantes peuvent être remplacées. Cela donne aux administrateurs SMS un plus haut niveau de contrôle sur la configuration et sur les opérations du client SMS car cela autorise des exceptions à la configuration standard appliquée au site SMS.
Prenons l'exemple d'un environnement sécurisé et consolidé, où les administrateurs SMS gèrent des serveurs et des postes de travail en tant que clients d'un site principal SMS unique. Dans cet environnement imaginaire, une stratégie de sécurité peut déterminer qu'une autorisation doit être demandée à un utilisateur avant que les techniciens du support technique puissent prendre le contrôle à distance de son ordinateur. Cela pose évidemment un problème si les techniciens de support technique veulent utiliser le contrôle à distance pour se connecter aux serveurs : en principe, aucun utilisateur n'est connecté aux serveurs, donc personne n'accorde d'autorisation pour le contrôle à distance. En appliquant soigneusement la stratégie locale, cependant, l'exigence d'autorisation de l'utilisateur peut être supprimée sur des clients spécifiques. Vous pouvez probablement imaginer des douzaines d'autres circonstances dans lesquelles la stratégie locale SMS peut être utile pour l'octroi d'une exception à la configuration d'un agent de client SMS particulier.

Au cœur du composant logiciel enfichable Windows PowerShell
Une fois vous connaissez les principes fondamentaux de Windows PowerShell, vous pouvez ajouter des éléments à l'exemple de code source fourni dans cet article afin de compléter la stratégie locale du client SMS à partir de la ligne de commande. Certains attributs spécifiques doivent être appliqués à une classe avant d'être exposés à Windows PowerShell. Vous devez décider de la fonction de l'applet de commande et de l'action à exécuter. C'est ce que l'on appelle l'association « Verbe-Nom ». Add, Get et Set sont quelques verbes courants utilisés dans Windows PowerShell. La partie Nom décrit l'objet sur lequel vous voulez agir. En principe, les applets de commande intègrent des paramètres qui sont déclarés dans une classe Cmdlet en tant que propriétés publiques de divers types. Enfin, la fonction ProcessRecord est l'endroit principal dans lequel vous effectuez la plupart de votre travail. La figure 1 illustre un modèle générique que vous pouvez utiliser pour vos propres applets de commande.
Figure 1 Modèle d'applet de commande (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
Lorsque vous avez compilé votre composant logiciel enfichable, vous l'inscrivez auprès de Windows PowerShell en incluant dans votre projet une classe possédant le jeu d'attribut RunInstaller et quelques propriétés spécifiques définies. Pour plus de détails, consultez le code source accompagnant cet article. Pour inscrire votre composant logiciel enfichable, vous devez utiliser l'outil InstallUtil.exe inclus avec Microsoft® .NET Framework. La figure 2 illustre la syntaxe que vous devez utiliser pour inscrire votre composant logiciel enfichable. Notez que dans Windows Vista®, cette opération nécessite l'élévation des privilèges. Vous devez donc ouvrir Windows PowerShell avec l'option « Ouvrir en tant qu'administrateur » ou utiliser les PowerToys d'élévation de script pour Windows Vista (que vous pouvez télécharger à l'adresse technetmagazine.com/issues/2007/06/UtilitySpotlight).
Figure 2 Installation du composant logiciel enfichable Windows PowerShell (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
La prochaine étape consiste à vérifier que votre composant logiciel enfichable est reconnu par Windows PowerShell. Utilisez l'applet de commande Get-PSsnapin avec le paramètre Registered, et Windows PowerShell résume les composants logiciel enfichables actuellement chargés, suivis d'une liste des composants logiciels enfichables inscrits à ajouter. Votre composant logiciel enfichable doit se trouver dans cette liste :
PS> Get-PSsnapin -registered
Vous pouvez maintenant ajouter le composant logiciel enfichable Windows PowerShell au noyau à l'aide de l'applet de commande Add-PSsnapin, comme suit :
PS> add-pssnapin SMS2003PowerShellSnapinSample
Si l'opération est réussie, vous pouvez exécuter les applets de commande dans votre composant logiciel enfichable Windows PowerShell.
Pour afficher toutes les applets de commande mises à disposition par les composants logiciels enfichables Windows PowerShell, il vous suffit de spécifier le composant logiciel enfichable particulier avec l'applet de commande Get-Command, en transmettant le nom de votre composant logiciel comme valeur du paramètre PSsnapin. L'exemple de composant logiciel enfichable décrit dans l'article affiche six applets de commande, parmi lesquelles le modèle d'Applet de commande Verb-Noun, comme décrit à la figure 3.
Figure 3 Affichage des applets de commande dans un composant logiciel enfichable
Figure 3 Affichage des applets de commande dans un composant logiciel enfichable
Dans l'exemple de code source, je n'ai écrit l'aide pour l'applet de commande Get-SMSServerConnection que pour vous en expliquer la construction. Si vous voulez développer l'aide, vous aurez un exemple dont vous pouvez vous inspirer dans le fichier XML. La figure 4 illustre le résultat de l'aide.
Figure 4 Sortie de l'exemple Get-Help (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Maintenant que vous avez compris comment installer le composant logiciel enfichable Windows PowerShell, comment connaître les commandes présentes dans le composant logiciel enfichable et comment obtenir de l'aide sur une applet de commande type, nous pouvons commencer à utiliser les applets de commande. Pour afficher une liste de toutes les collections sur un serveur de site principal SMS, vous pouvez utiliser la commande suivante :
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
Remarquez le pipeline. Il s'agit d'un élément fondamental du fonctionnement de Windows PowerShell et d'un outil très puissant. Il est possible de faire à peu près n'importe quoi dans Windows PowerShell sur une seule ligne. L'applet de commande Get-SMSServerConnection établit une connexion avec le serveur SMS. Puisque l'applet de commande Get-Collections ne comporte qu'un seul paramètre d'entrée du type qui est retourné par Get-SMSServerConnection, il vous suffit de transmettre la sortie de l'applet de commande Get-SMSServerConnection à l'applet de commande Get-Collections. C'est ainsi que fonctionne le pipeline et c'est un bon exemple de la façon dont vous pouvez faire passer des objets complexes d'une applet de commande à l'autre. Vous pouvez également stocker des objets dans des variables et si vous le faites dans un script Windows PowerShell, cela peut ressemble à quelque chose comme ceci :
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
Il se peut que la sortie soit un peu difficile à lire sans mise en forme agréable, car Get-Collections renvoie un objet de type SMSCollections (qui est en gros un ensemble d'objets de type SMSCollection). En résumé, l'affichage n'est pas très joli. Vous devez donc filtrer les collections que vous ne souhaitez pas afficher ou formater l'affichage dans une table comprenant uniquement les propriétés qui vous intéressent. Pour ce faire, transmettez la sortie de l'applet de commande Get-Collections via le pipeline à l'applet de commande Format-Table, qui peut n'afficher que les propriétés que vous spécifiez. Par exemple, vous pouvez ajouter | Format-Table Name, Members.
Mais il existe un moyen encore plus efficace d'afficher tous les membres d'une collection particulière et dans cet exemple, il s'agit de Get-CollectionMembers. Cette applet de commande renvoie un ensemble de chaînes représentant le nom de chaque membre de la collection. Comme vous l'avez sûrement deviné, c'est un excellent candidat à transmettre à la prochaine applet de commande via le pipeline.
Jusqu'à présent, nous n'avons pas parlé de la stratégie locale du client avancé SMS, mais seulement des connexions au serveur du site principal SMS et de l'énumération des collections et des membres des collections. Cet exemple de composant logiciel enfichable Windows PowerShell comprend deux dernières applets de commande appelées respectivement Enable-SoftwareDistribution et Disable-SoftwareDistribution. C'est ici qu'intervient la stratégie locale du client SMS. Ces deux dernières applets de commande manipulent la stratégie locale du client SMS pour le composant Agent client de distribution logicielle sur le client avancé SMS. Comme vous l'avez deviné avec la partie verbe de l'applet de commande, Disable place un remplacement de la stratégie locale du client qui spécifie que l'agent client de distribution logicielle doit également être désactivé. De même, le verbe Enable supprime tous les remplacements de la stratégie locale du client, en ramenant l'agent client de distribution logicielle à son état normal, qui est défini par la stratégie SMS transmise par le point de gestion SMS. La figure 5 montre à quoi peut ressembler un exemple de code uniligne Windows PowerShell qui place un remplacement de la stratégie locale du client SMS sur l'agent client de distribution logicielle en le forçant à se désactiver pour tous les membres de la collection personnalisée des systèmes Windows Server 2003. Le code uniligne permettant de supprimer tous les remplacements de la stratégie locale du client SMS pour l'agent client de distribution logicielle sur cette même collection est également répertorié. Les applets de commande Disable-SoftwareDistribution et Enable-SoftwareDistribution peuvent également être utilisées seules si vous souhaitez manipuler la stratégie locale du client SMS sur quelques ordinateurs seulement.
Figure 5 Assemblage des applets de commande - exemples (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

Étapes suivantes
L'exemple de code source proposé dans cet article peut vous fournir un excellent point de départ pour appliquer des remplacements de la stratégie locale du client SMS à des groupes d'ordinateurs. Cet exemple concerne uniquement l'agent client de distribution logicielle, et uniquement la propriété Enabled. Les autres agents client possèdent un nombre bien supérieur de propriétés sur lesquelles vous pouvez appliquer des remplacements de la même façon. Maintenant que vous avez un point de départ commun, la prochaine étape logique consiste à examiner les autres parties de la stratégie locale du client SMS. Réfléchissez aux groupes de systèmes gérés auxquels les remplacements de la stratégie locale du client SMS pourraient s'appliquer et aux remplacements de la stratégie locale qu'il serait intéressant d'utiliser. Une dernière remarque : il est important de savoir à l'avance où vous allez. Vous devez donc toujours tout tester de façon approfondie dans un environnement de laboratoire.

Don Brown est technicien principal senior chez Microsoft. Il travaille sur SMS (ahem, SCCM) depuis des lustres. Vous pouvez le contacter à l'adresse donbrown@microsoft.com.


 Le petit c&#226;bleur: Authentification unique sans fil
Le petit câbleur
Authentification unique sans fil
Joseph Davies

Les connexions sans fil qui sont établies puis doivent s'authentifier avec un réseau privé peuvent accroître les difficultés tant pour l'utilisateur que pour l'administrateur. Un client sans fil sous Windows qui est membre d'un domaine Active Directory doit exécuter une authentification IEEE 802.1X pour obtenir une
connexion sans fil protégée et une ouverture de session de domaine. Dans la mesure où l'authentification peut impliquer des informations d'identification de l'utilisateur ou de l'ordinateur et où les ouvertures de session de domaine dépendent de la connectivité réseau, les problèmes surviennent lorsque vous configurez l'ordre dans lequel les authentifications sont exécutées et que vous spécifiez les informations d'identification à utiliser. Tout ceci peut influer sur les ouvertures de session de domaine et conduire à ce qu'un utilisateur soit invité plusieurs fois à saisir ses informations d'identification.
Heureusement, l'authentification unique sans fil de Windows Vista® vous permet de spécifier que l'authentification IEEE 802.1X pour Wi-Fi Protected Access 2 (WPA2)-Enterprise, WPA-Enterprise et l'authentification 802.1X avec Wireless Equivalency Privacy (WEP) survient avant le processus d'ouverture de session d'un utilisateur. Ceci vous permet de résoudre les problèmes liés à l'ouverture de session de domaine dans des configurations spécifiques. L'authentification unique sans fil intègre également de façon transparente l'authentification sans fil avec l'expérience d'ouverture de session Windows®, ce qui est globalement plus intéressant pour les utilisateurs. Pour toutes ces raisons, j'ai consacré ce mois-ci cet article aux fonctionnalités de l'authentification unique sans fil, à leur configuration et à leur fonctionnement pendant le processus d'ouverture de session d'un utilisateur.

Principes fondamentaux de l'authentification unique
Un client sans fil Windows peut exécuter une authentification sur un réseau sans fil, en utilisant uniquement les informations d'identification de l'utilisateur ou de l'ordinateur, ou une combinaison des deux. S'il n'utilise que les informations d'identification de l'ordinateur, Windows exécute une authentification 802.1X avant d'afficher l'écran d'ouverture de session Windows. L'ordinateur client sans fil peut ainsi accéder rapidement aux ressources du réseau telles les contrôleurs de domaine Active Directory®.
Lorsqu'il utilise uniquement les informations d'identification de l'utilisateur, Windows sans l'authentification unique exécute l'authentification 802.1X dès que le processus d'ouverture de session de l'utilisateur est terminé. La figure 1 illustre la chronologie de démarrage et d'ouverture de session pour ce scénario.
Figure 1 Chronologie lorsque seules les informations d'identification de l'utilisateur sont utilisées pour l'authentification sans fil
Figure 1 Chronologie lorsque seules les informations d'identification de l'utilisateur sont utilisées pour l'authentification sans fil
L'utilisation exclusive des informations d'identification de l'utilisateur pour l'authentification sans fil entraîne qu'un utilisateur ne peut pas ouvrir une session de domaine initiale sur un ordinateur parce qu'il n'existe aucune information d'identification dans le cache local pour son compte utilisateur et aucune connexion au contrôleur de domaine pour authentifier les nouvelles informations d'identification. De plus, certaines opérations d'ouverture de session de domaine échouent parce qu'il n'existe pas de connexion aux contrôleurs de domaine du domaine Active Directory à ce moment-là. Les scripts d'ouverture de session, les mises à jour des stratégies de groupe et les mises à jour des profils utilisateurs échouent, ce qui génère des erreurs dans le journal des événements de Windows.
Dans une combinaison des informations d'identification de l'utilisateur et de l'ordinateur, Windows exécute une authentification 802.1X avec les informations d'identification de l'ordinateur avant d'afficher l'écran d'ouverture de session Windows. Une fois l'utilisateur connecté, Windows exécute une autre authentification 802.1X avec les informations d'identification de l'utilisateur. Certaines infrastructures de réseau utilisent des réseaux locaux virtuels (VLAN) différents pour les ordinateurs authentifiés avec les informations d'identification de l'ordinateur et ceux qui ont utilisé les informations d'identification de l'utilisateur. Si l'authentification au réseau sans fil à l'aide des informations d'identification de l'utilisateur et du commutateur vers le VLAN authentifié par l'utilisateur survient après le processus d'ouverture de session de l'utilisateur, le client Windows sans fil n'a pas accès aux ressources réseau, telles que les contrôleurs de domaine Active Directory, sur le VLAN authentifié par l'utilisateur pendant le processus d'ouverture de session de l'utilisateur. Une fois encore, cette situation provoque l'échec des opérations d'ouverture de session de domaine.
Un autre problème survient lorsque l'authentification sans fil avec les informations d'identification de l'utilisateur utilise autre jeu d'informations d'identification de sécurité que les informations d'authentification de l'utilisateur. Pour de telles configurations, Windows invite l'utilisateur à saisir des informations d'identification supplémentaires lorsque l'authentification sans fil commence, ce qui peut prêter à confusion.
La fonctionnalité d'authentification unique de Windows Vista a été développée pour résoudre les problèmes d'ouverture de session de domaine, de séparation des VLAN authentifiés par l'ordinateur et par l'utilisateur et de la requête d'informations d'identification différentes à des moments différents. Avec l'authentification unique, les administrateurs de réseau peuvent spécifier que l'authentification sans fil avec les informations d'identification de l'utilisateur survient avant le processus d'ouverture de session de l'utilisateur. Lorsque les informations d'identification de l'utilisateur nécessaires pour l'ouverture de session de l'utilisateur et pour l'authentification sans fil sont différentes, toutes les informations d'identification requises sont demandées et recueillies sur l'écran d'ouverture de session Windows.
Avec l'authentification unique, un client Windows Vista sans fil peut être configuré pour exécuter une authentification de réseau sans fil avec les informations d'authentification de l'utilisateur avant le processus d'ouverture de session de l'utilisateur. La figure 2 illustre la nouvelle chronologie de démarrage et d'ouverture de session.
Figure 2 Chronologie lors d'une authentification de réseau sans fil avec les informations d'authentification de l'utilisateur avant l'ouverture de session d'utilisateur
Figure 2 Chronologie lors d'une authentification de réseau sans fil avec les informations d'authentification de l'utilisateur avant l'ouverture de session d'utilisateur
Ceci permet les configurations qui n'utilisent que les informations d'identification de l'utilisateur ou une combinaison des informations d'identification de l'utilisateur et de l'ordinateur avec des VLAN séparés sans perte de fonctionnalité. Dans la mesure où le client sans fil dispose d'une connexion réseau ou d'une connexion au VLAN authentifiée par l'utilisateur avant le démarrage du processus d'ouverture de session de l'utilisateur, les opérations d'ouverture de session de domaine peuvent se dérouler sans heurt. Pour un exemple, reportez-vous à l'article « Connexion d'un client sans fil Windows Vista à un domaine » à l'adresse microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.
Reposant sur la configuration du profil sans fil, l'authentification unique consolide les champs d'entrée des informations d'identification de l'utilisateur pour l'authentification sans fil et les ajoute à l'écran d'ouverture de session Windows. Toutes les informations d'identification de l'utilisateur pour l'ouverture de session de l'utilisateur et l'authentification sans fil utilisant l'identification de l'utilisateur sont donc fournies simultanément par l'utilisateur.
Les méthodes EAP (Extensible Authentication Protocol) écrites pour la nouvelle architecture EAPHost dans Windows Vista peuvent utiliser l'API de prise en charge EAP Pre-Logon Authentication Provider (PLAP) pour inclure les champs d'entrée nécessaires à l'authentification sur l'écran d'ouverture de session Windows. Pour plus d'informations, consultez la documentation sur l'authentification unique (SSO) et l'API PLAP à l'adresse msdn2.microsoft.com/bb530584.
À titre d'exemple d'une session à authentification unique, imaginons un client sans fil Windows Vista configuré pour exécuter l'authentification en n'utilisant que les informations d'identification de l'utilisateur, et un nom d'utilisateur et un mot de passe pour l'ouverture de session de domaine et pour l'authentification 802.1X. Lorsque l'utilisateur appuie sur Ctrl + Alt + Suppr dans l'écran initial de Windows Vista, l'authentification unique détermine que l'authentification 802.1X doit survenir avant l'ouverture de session de l'utilisateur. Lorsque l'utilisateur saisit son nom d'utilisateur et son mot de passe, l'authentification unique exécute d'abord l'authentification de réseau sans fil basée sur l'utilisateur et affiche un message indiquant qu'il se connecte au réseau sans fil par son nom. Après l'authentification sans fil, Windows Vista exécute l'ouverture de session de l'utilisateur et affiche le Bureau de l'utilisateur.

Configuration de l'authentification unique
Dans les coulisses
Pour que vous compreniez parfaitement le processus d'authentification sans fil, nous allons examiner dans le détail ce qui se passe lorsque l'utilisateur essaie activement d'ouvrir une session. Lorsqu'un utilisateur appuie sur Ctrl + Alt + Suppr pour ouvrir une session sur un client sans fil exécutant Windows Vista, les étapes suivantes sont exécutées :
  1. La configuration automatique sans fil détermine le profil du réseau sans fil à utiliser. Si le client sans fil a déjà exécuté avec succès l'authentification avec les informations d'identification de l'ordinateur, le profil du réseau sans fil actuellement connecté est utilisé. Si le profil sans fil déterminé est configuré pour exécuter l'authentification avec uniquement les informations d'identification de l'ordinateur, aucune authentification sans fil supplémentaire avec les informations d'identification de l'utilisateur n'est nécessaire. Les étapes 2 à 6 supposent que le profil sans fil sélectionné est configuré pour exécuter l'authentification avec les informations d'identification de l'utilisateur, que l'authentification unique activée et que le paramètre Immédiatement avant l’ouverture de session de l’utilisateur est sélectionné.
  2. L'utilisateur saisit ses informations d'identification pour l'ouverture de sa session et l'authentification sans fil (si nécessaire) et lance l'ouverture de sa session.
  3. Windows affiche un message indiquant à l'utilisateur qu'il tente de se connecter au nom du réseau sans fil.
  4. Windows tente d'exécuter une authentification de réseau sans fil avec les informations d'identification de l'utilisateur. Si le paramètre Autoriser l’affichage de boîtes de dialogue supplémentaires pendant l’authentification unique est activé et que le type EAP a besoin d'afficher des boîtes de dialogue supplémentaires pour l'utilisateur, Windows affiche les boîtes de dialogue. Si l'authentification sans fil ne réussit pas dans le délai maximal de connexion (exprimé en secondes), l'authentification sans fil est abandonnée. Si le paramètre Ce réseau utilise un réseau local virtuel (VLAN) différent pour l’authentification avec l’ordinateur et les informations d’identification de l’utilisateur est sélectionné, Windows exécute un renouvellement DHCP de la configuration de l'adresse IP de la carte réseau sans fil dès que l'authentification sans fil réussit.
  5. Windows lance le processus d'ouverture de session de l'utilisateur.
  6. Windows affiche le Bureau.
Si le paramètre Immédiatement après l’ouverture de session de l’utilisateur est sélectionné, Windows exécute les étapes dans l'ordre suivant : 1, 2, 5, 3, 4, 6.

Pour activer et configurer l'authentification unique, vous pouvez utiliser l'extension Stratégie de groupe des stratégies de réseau sans fil (IEEE 802.11) et configurer les paramètres de sécurité avancés pour un profil sans fil d'une stratégie Windows Vista. Pour plus d'informations, consultez l'article « Paramètres de stratégies de groupe sans fil pour Windows Vista » à l'adresse technetmagazine.com/issues/2007/04/CableGuy.
Dans la boîte de dialogue Paramètres de sécurité avancés, sélectionnez Activer l’authentification unique pour ce réseau et configurez les options d'authentification unique selon les besoins. La figure 3 illustre un exemple d'authentification unique activée avec les paramètres par défaut.
Figure 3 Paramètres par défaut d'authentification unique
Figure 3 Paramètres par défaut d'authentification unique
Il existe des paramètres d'authentification unique pour exécuter l'authentification sans fil 802.1X immédiatement avant ou après le processus d'ouverture de session de l'utilisateur et pour indiquer le délai d'exécution de l'authentification 802.1X avant le démarrage du processus d'ouverture de session de l'utilisateur. Vous pouvez également indiquer si les boîtes de dialogue au-delà de la consolidation des champs d'entrée doivent être affichées sur l'écran d'ouverture de session Windows. Par exemple, si un type d'EAP veut que l'utilisateur confirme le certificat envoyé par le serveur RADIUS (Remote Authentication Dial-in User Service) pendant l'authentification, le type d'EAP peut afficher la boîte de dialogue.
Vous pouvez également spécifier que le client sans fil doit lancer un renouvellement DHCP (Dynamic Host Configuration Protocol) de la configuration TCP/IP de la carte d'accès sans fil après avoir exécuté l'authentification basée sur l'utilisateur. Sélectionnez cette option s'il existe des VLAN différents pour les clients sans fil authentifiés par l'utilisateur et ceux authentifiés par l'ordinateur, et si ces VLAN sont des sous-réseaux IPv4 ou IPv6 différents.
Dès que vous avez créé le profil sans fil contenant les paramètres d'authentification unique au sein de la stratégie, vous pouvez également configurer les clients sans fil Windows Vista en exportant le profil sous forme de fichier XML, puis en important le profil XML sur les clients sans fil Windows Vista.
Pour créer un profil sans fil à authentification unique, créez un profil sans fil avec les paramètres d'authentification unique appropriés. Dans l'onglet Général de la stratégie sans fil de Windows Vista, cliquez sur le profil sans fil avec les paramètres d'authentification unique, puis sur Exporter. Lorsque vous y êtes invité, précisez le nom du fichier XML du profil et son emplacement.
Pour utiliser le profil d'authentification unique afin de configurer un autre client sans fil Windows Vista, importez le profil XML avec la commande :
netsh wlan add profile filename=
    "[FileName].xml"
Pour déterminer si l'authentification unique est activée dans un profil sans fil, utilisez :
netsh wlan show profile=[ProfileName]
Les paramètres d'authentification unique sont répertoriés dans la section « Paramètres de sécurité » de l'affichage de la commande netsh wlan show profile et dans le texte des événements de connexion sans fil du journal des événements Windows. Vous pouvez également utiliser le composant logiciel enfichable Observateur d'événements pour afficher les événements dans le dossier Microsoft\Windows\WLAN-AutoConfig des journaux des applications et des services avec la source « WLAN-AutoConfig » et les ID d'événement 13001, 13002, 13003 et 13004.
Vous trouverez plus d'informations sur la page Web consacrée à la mise en réseau sans fil à l'adresse microsoft. com/wifi. Pour plus de détails sur le processus d'authentification unique, lisez l'encadré « Dans les coulisses ».

Joseph Daviesest rédacteur technique chez Microsoft et enseigne et écrit sur la mise en réseau Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et est l'auteur de la rubrique mensuelle Le petit câbleur de Technet Magazine.


 Notes de recherche: Utilisation de l'informatique hautes performances dans la lutte contre le VIH
Notes de recherche
Utilisation de l'informatique hautes performances dans la lutte contre le VIH
Kristin Firth et Mia Matusow

Lorsque vous pensez à des personnes réalisant des recherches médicales, imaginez-vous des hommes et des femmes en blouses blanches manipulant des éprouvettes et des microscopes ? Peut-être imaginez-vous une équipe de chimistes dans une université ou une entreprise pharmaceutique ? Ce sont là des images courantes et certes réelles de la recherche médicale, mais elles n'en représentent
qu'un aspect. En réalité, certaines recherches médicales sont réalisées dans des endroits très différents.
Vous serez peut-être étonné d'apprendre que Microsoft Research joue un rôle essentiel dans les efforts de développement d'un vaccin contre le virus d'immunodéficience humain (VIH). Qui plus est, sans un seul bec Bunsen, dans des bureaux classiques équipés de nombreux ordinateurs.
Quel rôle joue donc Microsoft dans toute cette recherche ? Ces gens en blouse blanche (les chercheurs des divers centres de recherche et universités, tels que Mass General à Boston, la University of British Columbia, la University of Washington, le Fred Hutchinson Cancer Research Center et la Murdoch University en Australie) réunissent d'énormes quantités de données au cours de leurs projets. Le groupe eScience de Microsoft Research, composé d'une demi-douzaine de personnes environ, basées pour la plupart à Redmond, dans l'État de Washington (plus une personne au Nouveau Mexique), aide ces chercheurs à traiter et analyser d'énormes quantités de données. La participation de Microsoft Research à ce projet remonte à en 2003 et aujourd'hui, le groupe eScience collabore avec des scientifiques sur toute une variété de projets traitant de problèmes affectant la société. L'équipe travaille en étroite collaboration avec des scientifiques externes, créant des solutions personnalisées pour les projets, effectuant de nombreux calculs et analysant les résultats.
Dans un projet haute priorité, Microsoft aide à analyser des données relatives aux modèles de mutation du VIH. David Heckerman, MD, PhD, chercheur senior pour Microsoft, explique que le VIH se transforme rapidement lorsqu'il est attaqué par le système immunitaire d'une personne infectée. « Nous travaillons sur une étude qui tente de déterminer comment le VIH se transforme pour répondre au système immunitaire de l'hôte. Pour ce faire, nous recherchons des corrélations entre le type de système immunitaire d'un individu et les séquences de protéine du VIH qui l'infectent ».
Les scientifiques utilisent des échantillons provenant de personnes infectées par le VIH pour déterminer les types de système immunitaire et les séquences de VIH. C'est là qu'interviennent les calculs. L'étude recherche des corrélations entre 3 000 acides aminés du VIH et des centaines de types de système immunitaire sur plusieurs centaines d'individus. « Nous avons conçu des tests statistiques qui produisent des corrélations plus fiables, avec moins de faux positifs et négatifs » commente Carl Kadie, PhD, ingénieur de développement de logiciel de recherche principal pour Microsoft. « Cependant, ces tests exigent une énorme puissance de calcul et plus le nombre de sujets inclus sera élevé, mieux ce sera. L'idée est de réaliser des millions de simulations pour révéler les corrélations les plus fiables ».

Utilisation de l'informatique hautes performances dans la lutte contre le VIH
Il y a encore quelques années, des restrictions de traitement entravaient les efforts de recherche. Armés de seulement une demi-douzaine d'ordinateurs, les chercheurs Microsoft impliqués dans ce projet ne disposaient pas d'une puissance de traitement suffisante pour réaliser les analyses dans un délai approprié. Il aurait fallu une année entière pour examiner chaque position le long du génome du vaccin et les types immunologiques différents pour 200 sujets seulement. Même s'ils disposaient de 20 ordinateurs consacrés à cette analyse, les chercheurs auraient été forcés d'exécuter les tests manuellement sur 20 ordinateurs séparés, auraient reçu 20 séries individuelles de résultats et auraient eu besoin d'un autre programme (et de plus de temps) pour tabuler les séries de résultats séparées. La gestion de tâches multiples, le rassemblement de résultats partiels et toutes les autres tâches individuelles impliquées auraient pris trop de temps. Ils se sont donc adressés au groupe High-Performance Computing (HPC) de Microsoft.
En 2006, les chercheurs ont implémenté Windows® Compute Cluster Server 2003. Cette solution HPC leur offrait un moyen simple d'exploiter la puissance de plusieurs ordinateurs travaillant en collaboration. Windows Compute Cluster Server permet en fait la répartition du travail sur des nœuds de serveur exécutés en parallèle. L'ensemble de la tâche de distribution des données sur les nœuds, de gestion des données et de combinaison des résultats est automatisé. La solution inclut des procédures d'installation, une suite d'outils de gestion et un planificateur de tâches intégré.
Enfin, avec cette solution, les principaux obstacles techniques ont été surmontés : la puissance de calcul n'était plus restreinte et le processus de distribution du travail et de gestion des données était entièrement automatisé.

Installation
Pour Microsoft Research, l'approche du cluster de calcul était idéale. Windows Compute Cluster Server 2003 est adapté aux projets qui impliquent des applications réalisant continuellement les mêmes opérations (par exemple, lorsque la résolution et l'analyse des problèmes peut être accélérée en exécutant des tâches en parallèle). Cependant, le déploiement de cette solution ne doit pas être envisagé à la légère, puisque l'informatique hautes performances peut coûter cher en capital, surtout en termes d'alimentation et de refroidissement. Il nécessite plusieurs serveurs qui sont souvent exécutés à 100 % d'utilisation du processeur pendant des semaines.
Les étapes suivantes consistent à déterminer quelle taille de cluster l'organisation peut se permettre et où le stocker. Si un environnement est déjà basé sur Windows avec Active Directory® en place, les administrateurs ont l'infrastructure nécessaire pour installer, déployer et prendre en charge un cluster. Dans les environnements où Active Directory n'est pas encore utilisé, certaines étapes de configuration supplémentaires sont nécessaires.
Vous devez également décider comment configurer les nœuds dans le cluster de calcul, c.-à-.d. choisir d'utiliser les outils fournis avec Windows Compute Cluster Server 2003 ou vos propres techniques de déploiement internes. Vous devez déployer Windows Compute Cluster Server 2003 avec les applications logicielles que vous souhaitez exécuter sur le cluster. L'accès des utilisateurs au cluster doit également être établi de sorte que les utilisateurs puissent se connecter au cluster et transmettre des tâches, ce qui peut être réalisé grâce à l'interface utilisateur incluse ou par le biais d'interfaces de ligne de commande.
Windows Compute Cluster Server 2003 est un système d'exploitation 64 bits. (L'architecture typique d'un environnement Windows Compute Cluster Server 2003 est illustrée à la figure 1.) À la date de rédaction de cet article (juin 2007), Microsoft Research exécutait toute une variété d'applications différentes sur un cluster reposant sur 25 serveurs IBM eServer 326. Chacun de ces serveurs comporte deux processeurs AMD Opteron à 2,6 GHz.
Figure 1 Exploitation de la puissance avec Windows Compute Cluster Server 2003
Figure 1 Exploitation de la puissance avec Windows Compute Cluster Server 2003
Après avoir déployé Windows Compute Cluster Server, le groupe a mis à jour l'application dont il se sert pour réaliser les corrélations génétiques afin de l'utiliser sur le cluster. La complexité du déploiement d'applications pour des clusters de calcul peut varier. Les applications elles-mêmes influencent la part de programmation nécessaire.
Au début, le groupe a utilisé les outils intégrés dans Windows Compute Cluster Server pour établir rapidement une interface utilisateur générique. Il s'agissait cependant là simplement d'une solution temporaire en attendant que le groupe ait créé sa propre application Web personnalisée, qui fournit une plus grande flexibilité et permet de mettre certains nœuds de cluster à la disposition de scientifiques extérieurs à Microsoft. En fait, Microsoft fait partie de l'Open Grid Forum et certains des clusters de Microsoft Research sont mis à la disposition d'utilisateurs d'autres universités à travers le monde, ce qui permet aux chercheurs de collaborer et de se partager le travail.
Outre ses interfaces utilisateur graphiques, Windows Compute Cluster Server prend également en charge les opérations de ligne de commande, ce qui permet aux utilisateurs d'écrire des scripts. Et il fournit des API riches pouvant être utilisées pour écrire des programmes qui interagissent directement avec le Planificateur de tâches de Windows Compute Cluster, technique que Microsoft Research a choisi d'utiliser.

Les résultats
Grâce à son utilisation de l'informatique hautes performances, le groupe eScience de Microsoft Research a fait des progrès énormes dans la course au vaccin contre le VIH. « Avec l'informatique hautes performances, nous avons pu accélérer notre temps d'analyse » explique David Heckerman. « Plusieurs des groupes externes avec lesquels nous collaborons utilisent maintenant nos techniques statistiques et partagent leurs résultats. Et par conséquent, les scientifiques nous proposent déjà de nouvelles hypothèses. Avant, l'obtention de résultats aurait pris une année pour chaque étape du processus. Á l'heure actuelle, il suffit d'une journée. »
Avant Windows Compute Cluster Server, les méthodes utilisées par Microsoft Research n'auraient pas été pratiques en raison du temps requis pour réaliser l'analyse. « Avec Windows Compute Cluster Server », explique Carl Kadie, « nous pouvons exécuter 50 tâches de 200 000 éléments de travail chacune dans le temps qu'il nous fallait auparavant pour exécuter 1 tâche ».
Maintenant que le groupe eScience dispose de capacités de calcul énormes, il peut mener des tests plusieurs fois sur des données simulées. Les tests sur données simulées sont cruciaux pour déterminer quels résultats sur données réelles sont intéressants. Plus le nombre de simulations exécutées est important, plus les résultats sont fiables.

Les leçons apprises
Microsoft Research a évidemment bénéficié de l'utilisation de Windows Compute Cluster Server, mais la relation est de nature symbiotique. Les développeurs du groupe High-Performance Computing, qui travaille actuellement sur une seconde version de Windows Compute Cluster Server, continuent de tirer des leçons des commentaires que leur fournit le groupe eScience.
Le groupe HPC en a notamment appris beaucoup sur l'allocation des ressources en surveillant et en analysant le comportement du cluster Microsoft Research pour déterminer la meilleure façon d'équilibrer les ressources du cluster pour des utilisateurs multiples. Par exemple, sur ce projet, un utilisateur crée généralement un travail à la fois avec une moyenne de 50 tâches associées à chaque travail. L'utilisateur soumet le travail et Windows Compute Cluster Job Manager alloue suffisamment de ressources pour la gestion des 50 tâches. Pour ce faire, il revendique immédiatement tous les nœuds disponibles sur le cluster pour traiter les tâches. Ce scénario ne poserait pas de problème dans un environnement à utilisateur unique, mais les choses se gâtent dans un cadre multi-utilisateurs où il très important que les projets progressent simultanément.
Actuellement, lorsque 10 des 50 tâches du travail sont terminées, 10 serveurs ne sont pas libérés. Le Job Manager attend que les 50 tâches du travail soient terminées pour libérer les serveurs et s'attaquer à un autre travail. Les développeurs HPC travaillent maintenant sur une façon de réattribuer des ressources à la fin de chaque tâche et non de l'ensemble du travail.
Microsoft Research a également fait appel au groupe HPC pour résoudre des problèmes spécifiques concernant la façon dont les chercheurs souhaitaient utiliser Windows Compute Cluster Server. Les chercheurs souhaitaient notamment configurer la sécurité de sorte que les informations d'identification se propageraient automatiquement depuis le serveur Web frontal vers le cluster de calcul. La solution a été de travailler dans Microsoft® .NET Framework et d'étendre l'authentification des formulaires ASP.NET de sorte que l'application Web puisse fournir les informations d'authentification complètes de l'utilisateur à chaque fois qu'un utilisateur soumet un travail.
À présent, les membres de l'équipe eScience de Microsoft Research et leurs collègues du monde entier peuvent se consacrer à des aspects plus importants de leur travail et laisser toutes les tâches impliquées dans le traitement et la gestion des données aux ordinateurs. « Nous pouvons ainsi aller plus loin en tant qu'équipe » commente David Heckerman. « Nous repoussons les limites des connaissances sur le VIH et progressons dans la lutte contre la maladie ».

Kristin Firth et Mia Matusowde Blue Line Writing & Editing, ont consacré ces dix dernières années à la création de contenus stratégiques pour des entreprises des secteurs public et privé de trois continents


 Windows&#160;PowerShell: &#201;criture d'expressions r&#233;guli&#232;res
Windows PowerShell
Écriture d'expressions régulières
Don Jones

192.168.4.5. \\Server57\Share. johnd@contoso.com. Vous reconnaissez sans doute ces trois éléments comme étant une adresse IP, un chemin UNC (Universal Naming Convention) et une adresse e-mail. Votre cerveau reconnaît leur format. Quatre groupes de chiffres, des barres obliques inverses, le symbole @ et d'autres indices indiquent quels types de données ces chaînes de
caractères représentent. Sans avoir à réfléchir beaucoup, vous pouvez reconnaître rapidement que 192.168 seul n'est pas une adresse IP valide, que 7\\Server2\\Share n'est pas une UNC valide et que joe@contoso n'est pas une adresse e-mail valide.
Malheureusement, les ordinateurs ont plus de mal à « comprendre » des formats compliqués comme ceux-ci. C'est là qu'entrent en jeu les expressions régulières. Une expression régulière est une chaîne, écrite à partir d'un langage d'expression régulière spécial, qui aide un ordinateur à identifier des chaînes qui présentent un format particulier (par exemple, une adresse IP, une UNC ou une adresse e-mail). Une expression régulière bien écrite peut permettre à un script Windows PowerShellTM d'accepter ou de rejeter des données selon qu'elles sont conformes ou non au format que vous avez spécifié.

Correspondance simple
L'opérateur de correspondances -match Windows PowerShell compare une chaîne à une expression régulière (regex), puis renvoie une réponse True (Vrai) ou False (Faux) selon que la chaîne correspond ou non à l'expression régulière. Une expression régulière très simple n'a même pas besoin de contenir une syntaxe spéciale : des caractères littéraux suffiront. Par exemple :
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
Lorsqu'elles sont exécutées dans Windows PowerShell, les deux premières expressions renvoient True (Vrai) tandis que la troisième renvoie False (Faux). Dans chaque expression, une chaîne est suivie par l'opérateur –match, lui-même suivi par une expression régulière. Par défaut, une expression régulière flottera sur une chaîne pour trouver une correspondance. Les caractères « soft » se retrouvent dans Software (Logiciel) et Microsoft, mais dans des positions différentes. Notez également que, par défaut, une expression régulière n'est pas sensible à la casse : « soft » se trouve dans « Software » malgré son S majuscule.
Mais si nécessaire, un opérateur différent, –cmatch, offre une comparaison d'expressions régulières sensible à la casse, comme ceci :
"Software" –cmatch "soft"
Cette expression renvoie la réponse False (Faux) puisque la chaîne « soft » ne correspond pas à « Software » dans une comparaison sensible à la casse. Notez que l'opérateur -imatch est également disponible comme option insensible à la casse explicite, bien qu'il s'agisse du comportement par défaut de –match.

Caractères génériques et répéteurs
Une expression régulière peut contenir plusieurs caractères génériques. Un point, par exemple, correspond à une instance de n'importe quel caractère. Un point d'interrogation correspond à zéro ou une instance de n'importe quel caractère. Voici quelques exemples à titre d'illustration :
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
Dans la première expression, le point correspond à un caractère exactement, donc la correspondance est True (Vrai). Dans la seconde expression, le point ne trouve pas le caractère dont il a besoin, donc la correspondance est False (Faux). Le point d'interrogation, présent dans les troisième et quatrième expressions, peut correspondre à un seul caractère inconnu ou aucun caractère. Enfin, dans le quatrième exemple, la correspondance est True (Vrai) parce que « D » et « n » n'ont pas de caractère entre eux. Ainsi, le point d'interrogation peut être considéré comme représentant un caractère facultatif, donc la correspondance reste True (Vrai) même si aucun caractère n'apparaît à cet endroit.
Une expression régulière reconnaît également les symboles * et + comme des répéteurs. Ceux-ci doivent suivre un ou des caractère(s) spécifique(s). Le symbole * correspond à zéro ou plusieurs des caractères spécifiés, tandis que le + correspond à un ou plusieurs des caractères spécifiés. Voici quelques exemples :
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
Notez que * et + correspondent à « Do », et pas seulement au « o ». C'est parce que ces répéteurs sont conçus pour correspondre à une série de caractères, et non un seul caractère.
Qu'en est-il si vous devez établir une correspondance avec les symboles ., *, ? ou + à proprement parler ? Il vous suffit de les précéder d'une barre oblique inverse, qui est le caractère d'échappement des expressions régulières :
"D.n" -match "D\.n" (True)
Notez qu'il est différent du caractère d'échappement de Windows PowerShell (l'apostrophe ascendante), mais qu'il suit la syntaxe des expressions régulières normalisée.

Classes de caractères
Une classe de caractères est une forme plus large de caractères génériques, représentant un groupe entier de caractères. Windows PowerShell reconnaît plusieurs classes de caractères. Par exemple :
  • \w correspond à n'importe quel caractère de mot, c'est-à-dire les lettres et chiffres.
  • \s correspond à n'importe quel caractère d'espace blanc, par exemple les tabulations, les espaces, et ainsi de suite.
  • \d correspond à n'importe quel chiffre.
On distingue également des classes de caractères négatifs : \W correspond à un caractère de non mot, \S correspond à un caractère de non espace blanc et \D correspond à un non chiffre. Ces classes peuvent être suivies par * ou + pour indiquer que plusieurs correspondances sont acceptables. Voici quelques exemples :
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
Applet de commande du mois
L'applet de commande Write-Debug est très pratique pour l'écriture d'objets (tels que les chaînes de texte) dans le pipeline Debug. Toutefois, il peut être décevant d'essayer cette applet de commande dans l'environnement de ligne de commande, parce qu'on a l'impression que l'applet de commande ne sert à rien.
En fait, le pipeline Debug est bloqué par défaut : la variable $DebugPreference est réglée sur « SilentlyContinue ». Si vous la réglez sur « Continue », tout ce que vous envoyez avec Write-Debug apparaîtra en jaune dans la console. C'est une façon idéale d'ajouter un code de suivi à vos scripts, ce qui vous permet de suivre l'exécution d'un script complexe. La couleur jaune vous aide à distinguer le suivi de la sortie normale du script et vous pouvez bloquer les messages de débogage à tout moment sans avoir à supprimer toutes les instructions Write-Debug. Il vous suffit de régler $DebugPreference sur « SilentlyContinue » à nouveau et le texte de débogage sera éliminé.

Bien que les deux expressions renvoient le résultat True (Vrai), elles correspondent à des choses fort différentes. Heureusement, il y existe un moyen de décrypter l'opérateur -match : à chaque fois qu'une correspondance est établie, une variable spéciale appelée $matches est peuplée avec les résultats de la correspondance, c.-à-d. les caractères de la chaîne pour lesquels l'opérateur a établi une correspondance avec votre expression régulière. La variable $matches retient ses résultats jusqu'à ce qu'une autre correspondance positive soit établie avec l'opérateur -match. La figure 1 illustre la différence entre les deux expressions que je viens de vous montrer. Comme vous pouvez le voir, \w correspondait au « S » de « Shell », tandis que le \w* répété correspondait au mot entier.
Figure 1 Différence engendrée par le symbole *
Figure 1 Différence engendrée par le symbole *

Groupes, plages et tailles de caractères
Une expression régulière peut également contenir des groupes ou plages de caractères placés entre crochets. Par exemple, [aeiou] signifie que n'importe lequel des caractères inclus (a, e, i, o, ou u) est une correspondance acceptable. [a-zA-Z] indique que n'importe quelle lettre de la plage a-z ou A-Z est acceptable (toutefois, si vous utilisez l'opérateur –match non sensible à la casse, a-z ou A-Z seul suffirait). Voici un exemple :
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
Vous pouvez également spécifier un nombre minimal et maximal de caractères à l'aide d'accolades. {3} Indique que vous voulez exactement trois exemplaires du caractère spécifié, {3,} signifie que vous voulez au moins trois exemplaires ou plus et {3,4} indique que vous voulez au moins trois exemplaires, mais pas plus de quatre. C'est une façon idéale de créer une expression régulière pour les adresses IP :
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Cette expression régulière veut quatre groupes de chiffres contenant chacun un à trois chiffres, tous séparés par un point. Mais regardez cet exemple :
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Il montre les limites des expressions régulières. Bien que le formatage de cette chaîne corresponde à celui d'une adresse IP, il ne s'agit évidemment pas d'une adresse IP valide. Une expression régulière ne peut pas déterminer si des données sont valides ; elle peut seulement déterminer si le formatage des données est correct.

Arrêt du flottement
Le dépannage d'une expression régulière n'est pas toujours évident. Voici par exemple une expression régulière qui teste un chemin UNC dans le format \\Server2\Share :
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Ici, l'expression régulière elle-même est difficile à lire parce que chaque barre oblique inverse que je veux tester doit être échappée avec une deuxième barre oblique inverse. Bien que cela ait l'air de marcher, ce n'est vraiment pas le cas :
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Ce second exemple n'est clairement (au moins pour vous et moi) pas un chemin UNC valide, mais l'expression régulière l'a validé. Pourquoi ? Souvenez-vous que les expressions régulières flottent par défaut. Cette expression régulière recherche simplement deux barres obliques inverses, une lettre et un chiffre ou plus, une autre barre oblique inverse, et d'autres lettres et chiffres. Ce modèle existe dans la chaîne, ainsi que les chiffres supplémentaires au début, qui en font un chemin UNC non valide. En fait, il faut dire à l'expression régulière de commencer à effectuer la correspondance au début de la chaîne, sans flotter. Je peux procéder de la façon suivante :
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
Le caractère ^ indique l'endroit où commence la chaîne. Avec cet ajout, le chemin UNC non valide échoue parce que l'expression régulière recherche deux barres obliques inverses comme premiers caractères et ce n'est pas le cas ici.
De même, le symbole $ peut être utilisé pour indiquer la fin d'une chaîne. Ceci ne serait pas très utile dans le cas d'un chemin UNC puisqu'un chemin UNC peut contenir des segments de chemin supplémentaires, tels que \\Server2\Share\Folder\File, par exemple. Cependant, je suis sûr qu'il y a de nombreux cas où vous souhaiteriez spécifier la fin d'une chaîne.

Aide pour les expressions régulières
Dans Windows PowerShell, la rubrique d'aide about_regular_expressions fournit une aide à la syntaxe fondamentale pour le langage des expressions régulières, mais les ressources en ligne vous fourniront encore plus d'informations. Ainsi, l'un de mes sites Web préférés, www.RegExLib.com, propose une bibliothèque gratuite d'expressions régulières qui ont été écrites dans des buts divers par le public. Vous pouvez effectuer des recherches par mots-clés, tels que « e-mail » ou « UNC » pour trouver rapidement une expression régulière adaptée à vos besoins, ou au moins pour démarrer. Si vous parvenez à créer une bonne expression régulière, vous pouvez la proposer à la bibliothèque pour que d'autres puissent l'utiliser.
J'aime également RegexBuddy (www.RegexBuddy.com). Il s'agit d'un outil bon marché qui fournit un éditeur graphique d'expressions régulières. RegexBuddy facilite non seulement l'assemblage d'une expression régulière complexe, mais également les tests d'expressions régulières pour s'assurer qu'elles acceptent les chaînes valides et rejettent les chaînes non valides correctement. Plusieurs autres développeurs de logiciels ont également créé des éditeurs et testeurs d'expressions régulières, gratuits, contributifs ou commerciaux que les utilisateurs trouveront certainement utiles.

Utilisation des expressions régulières
Vous vous demandez peut-être dans quelles circonstances vous utiliseriez une expression régulière dans la vie de tous les jours. Imaginez que vous lisez des informations dans un fichier CSV et que vous utilisez ces informations pour créer de nouveaux utilisateurs dans Active Directory®. Si le fichier CSV est généré par quelqu'un d'autre, vous souhaiterez être sûr que les données contenues dans le fichier présentent un formatage correct. Une expression régulière peut s'en charger. Une expression régulière simple telle que \w+, par exemple, peut confirmer que le prénom et le nom ne contiennent pas de caractères spéciaux ou de symboles, et une expression régulière plus complexe peut confirmer que les adresses e-mail sont conformes à la norme de votre entreprise. Vous pourriez par exemple utiliser ceci :
"^[a-z]+\.[a-z]+@contoso.com$"
Cette expression régulière nécessite une adresse e-mail sous la forme don.jones@contoso.com, où le prénom et le nom peuvent contenir uniquement des lettres et où ils doivent être séparés par un point. Á ce propos, les adresses e-mail sont les chaînes les plus difficiles pour l'écriture d'expressions régulières. Si vous pouvez restreindre votre objectif à une norme d'entreprise spécifique, ce sera plus facile.
N'oubliez pas ces points d'ancrage de début et de fin (^ et $), qui garantissent que rien ne suit contoso.com et que rien ne précède les caractères composant le prénom de l'utilisateur.
En fait l'utilisation de cette expression régulière dans Windows PowerShell est relativement simple. Si l'on suppose que la variable $email contient l'adresse e-mail que vous lisez dans le fichier CSV, une expression régulière du type suivant vérifiera sa validité :
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
Et dans cet exemple, vous avez appris un nouvel opérateur. -notmatch renvoie la réponse True (Vrai) si la chaîne ne correspond pas à l'expression régulière fournie. (Il existe aussi –cnotmatch pour les comparaisons sensibles à la casse.)
Il y a encore beaucoup à dire sur les expressions régulières : d'autres classes de caractères, des opérations plus avancées et même l'un ou l'autre opérateur. Il y a aussi le type d'objet [regex] pris en charge par Windows PowerShell. Toutefois, ce dont j'ai parlé dans cet aperçu rapide de la syntaxe des expressions régulières devrait vous suffire pour démarrer. N'hésitez pas à me rendre visite sur www.ScriptingAnswers.com si vous avez besoin d'aide pour une expression régulière particulièrement difficile.

Don Jones contribue à l'élaboration de TechNet Magazine et est le coauteur de Windows PowerShell: TFM (SAPIEN Press). Il enseigne Windows PowerShell (www.ScriptingTraining.com) et peut être contacté par le biais du site Web ScriptingAnswers.com.


 H&#233;, vous le scripteur&#160;!: Secrets de gestion des ordinateurs de bureau d'outre-tombe
Hé, vous le scripteur !
Secrets de gestion des ordinateurs de bureau d'outre-tombe
Les scripteurs Microsoft
Télécharger le code de cet article: HeyScriptingGuy2007_11.exe (151KB)

À la demande générale, nous avons voulu ce mois-ci faire quelque chose d'un peu différent : au lieu de commencer par parler de scripts d'administration système, nous allons commencer par (envoyez la musique sinistre) vous raconter une histoire de fantômes !
Remarque : Techniquement parlant, si nous voulions vraiment faire quelque chose de vraiment différent ce mois-ci, nous commencerions par parler des scripts d'administration système. Mais faites-nous confiance. Vous allez bientôt comprendre.
Il y a plusieurs années de cela, l'une des arrière-arrière-arrière-grands-mères Script mourut. Peu de temps après que Grand-mère eut été enterrée dans son cercueil en bois, Grand-père commença à faire des cauchemars terribles dans lesquels sa femme bien-aimée essayait désespérément de sortir de sa tombe à la force des ongles. Après bon nombre de cauchemars et de supplications incessantes, Grand-père réussit à convaincre les autorités locales d'exhumer le corps de sa femme. Lorsque le cercueil fut ouvert, tout le monde fut horrifié de voir que les ongles de Grand-mère étaient tordus et que l'intérieur du cercueil était couvert d'égratignures !
D'accord, cette histoire n'est peut-être pas être tout à fait vraie. En fait, à bien y réfléchir, elle n'est absolument pas vraie. Néanmoins, elle nous enseigne une leçon importante. Qu'est-ce que c'était déjà...
Ah, nous nous en souvenons maintenant ! Les cercueils étaient initialement conçus pour protéger le défunt des éléments et pour empêcher le corps de se décomposer. Malheureusement, ils avaient également une conséquence inattendue : ils permettaient, en théorie du moins, d'enterrer une personne vivante et de faire en sorte qu'elle n'en sorte jamais. Comme le montre l'histoire de l'arrière-arrière-arrière-grand-mère Script, même les projets les mieux planifiés peuvent avoir des résultats désastreux, voire entraîner l'enterrement de personnes vivantes ! (Envoyez à nouveau la musique sinistre).
Remarque : à moins, bien sûr, que vous n'optiez pour le cercueil de sécurité inventé par Franz Vester dans les années 1860. Ce cercueil incluait une ficelle reliée à une cloche placée à la surface ; dans le cas d'un enterrement prématuré, le « défunt » pouvait simplement sonner la cloche pour appeler à l'aide. Le cercueil de sécurité incluait également une échelle pliante, bien que nous ne sachions pas très bien comment une échelle pliante peut aider quelqu'un à s'échapper d'un cercueil enterré six pieds sous terre. Bien sûr, si vous êtes enterré au-dessus d'un garage, une échelle pliante peut s'avérer utile. Autrement...
La même chose (c'est-à-dire le fait que même les meilleurs plans peuvent conduire au désastre) est vraie pour les pare-feu Internet. Enfin, presque. Les pare-feu ont été initialement conçus pour empêcher l'accès aux personnes non autorisées : ils bloquent le trafic réseau entrant, empêchant ainsi les pirates informatiques et les intrus d'accéder à votre ordinateur. Tout ceci est très bien, mais, comme dans le cas de l'enterrement vivant, ils ont également une conséquence imprévue : ils peuvent également empêcher les personnes autorisées de rentrer. C'est surtout vrai dans le cas de Windows® Management Instrumentation (WMI), qui repose sur DCOM pour exécuter des tâches administratives sur les ordinateurs distants. Les pare-feu ont tendance à bloquer tout le trafic DCOM entrant, si bien qu'il est très difficile (si ce n'est carrément impossible) de gérer des ordinateurs par programmation sur Internet. En fait, sans ouvrir de ports supplémentaires sur le pare-feu et vous rendre ainsi plus vulnérable aux pirates informatiques, c'est franchement impossible. À moins que, bien sûr, que vous n'optiez pour WinRM : la Gestion à distance de Windows (échelle pliante non incluse).

Qu'est-ce que la Gestion à distance de Windows ?
D'après le kit de développement WinRM (msdn2.microsoft.com/aa384426), la Gestion à distance de Windows est « la mise en œuvre par Microsoft du protocole WS-Management, protocole standard SOAP compatible avec les pare-feu qui permet au matériel et aux systèmes d'exploitation de différents fournisseurs d'interfonctionner ». Impressionnant, n'est-ce pas ? Nous n'aborderons pas les détails du protocole WS-Management dans l'article de ce mois, mais nous vous recommandons de lire le kit de développement WinRM pour plus d'informations. Pour le moment, il vous suffit de savoir que WinRM est disponible sur Windows Server® 2003 R2, Windows Vista® et Windows Server 2008, et qu'il vous permet de gérer des ordinateurs sur Internet. WinRM utilise pour cela le port 80, un port de services Internet standard que la plupart des pare-feu laissent ouvert (cependant, le port utilisé par WinRM et le mécanisme de transport par défaut, HTTP, peuvent être modifiés si besoin est).
Nous ne nous attarderons pas non plus dans cet article sur l'installation et la configuration de WinRM. Il y a déjà toute une foule d'informations disponibles à ce propos (msdn2.microsoft.com/aa384372). Cependant, j'aimerais tout de même souligner un point important : si vous voulez utiliser WinRM pour récupérer des informations depuis un ordinateur distant (ce qui est la raison principale de l'utilisation de WinRM), votre ordinateur local et l'ordinateur distant doivent tous deux exécuter WinRM.
Qu’est-ce que cela signifie ? Cela signifie que si vous n'avez pas mis à niveau vos ordinateurs clients vers Windows Vista (j'espère que ce n'est pas le cas), ou si vous n'avez pas mis à niveau vos serveurs vers Windows Server 2003 R2 ou Windows Server 2008, vous ne trouverez pas WinRM particulièrement utile, du moins pas pour l'instant. Il va de soi, cependant, que cela ne sera probablement pas le cas à l'avenir. De plus, en supposant bien entendu que votre pare-feu l'autorise, vous toujours pouvez utiliser WMI et DCOM pour gérer des ordinateurs distants.

Renvoi de toutes les propriétés et instances d'une classe
Mais pourquoi se soucier des avertissements et des avis de non-responsabilité ? Au lieu de tout ce jargon obscur, voyons si nous pouvons écrire un script qui tire parti de WinRM. Justement, il se trouve que nous disposons d'un petit script simple qui utilise le protocole HTTP et le port 80 pour se connecter à un ordinateur nommé atl-fs-01.fabrikam.com, puis renvoie des informations complètes sur tous les services installés sur cet ordinateur. Reportez-vous à la figure 1 pour voir le script dans toute sa splendeur.
Figure 1 Composants d'un projet Silverlight (Close Figure 1)

Fichier | Description
CreateSilverlight.js | Il s'agit d'un script JScript (dans sa version initiale, Silverlight ne prend en charge que les scripts JScript) servant à spécifier les paramètres initiaux de démarrage de Silverlight, y compris le fichier XAML utilisé pour configurer l'interface utilisateur et les objets graphiques.
SampleProject.js | Il s'agit simplement d'un fichier blanc où vous pouvez mettre des fonctions JScript.
Silverlight.js | Ce fichier sert à initialiser la commande Silverlight.
SampleProject.html | C'est le fichier le plus excitant. SampleProject.html est simplement un fichier HTML qui inclut le code de lecture des trois fichiers .js. Il inclut également le code permettant d'instancier la commande Silverlight.
SampleProject.xaml | À quoi est-ce que cela sert ? Pour le découvrir, il faut que vous reveniez à la partie principale de cette rubrique.
Figure 1 Affichage d'une liste de services sur un ordinateur distant (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Comme vous pouvez le voir, nous commençons par attribuer le nom DNS de l'ordinateur (atl-fs-01.fabrikam.com) à une variable appelée strComputer. Nous pourrions éventuellement effectuer la connexion en utilisant l'adresse IP de l'ordinateur (ou même son adresse IPv6). Par exemple :
strComputer = "192.168.1.1"
Après avoir attribué une valeur à strComputer, nous créons une instance de l'objet WSMan.Automation, puis nous appelons la méthode CreateSession pour nous connecter à l'ordinateur distant, en utilisant dans ce cas le protocole HTTP (exactement comme nous l'avions prévu) :
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
Comme nous l'avons dit, nous voulons renvoyer les informations sur les services installés sur l'ordinateur distant. De plus, et au moins pour ce premier exemple, nous voulons des informations sur toutes les propriétés de tous les services. Qu’est-ce que ça signifie ? Cela signifie que nous devons spécifier une ressource URI qui nous lie à la classe Win32_Service sur l'ordinateur distant :
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
D'accord, ce n'est pas la ressource URI la plus avenante qu'on ait jamais vue (mais à bien y réfléchir, nous ne nous souvenons pas avoir jamais rencontre une URI avenante). Heureusement, l'essentiel de l'URI est passe-partout ; tout ce dont vous devez vous soucier est le chemin de WMI tout à la fin :
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Cela devrait être assez simple. Que se passe-t-il si vous voulez vous connecter à la classe root/cimv2/Win32_Process ? Et bien, il suffit de modifier le chemin de l'URI en conséquence :
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
Vous voulez utiliser la classe root/default/SystemRestore ? Encore une fois, il suffit de modifier la classe URI, en prenant soin de spécifier l'espace de noms par défaut (au lieu de l'espace de noms cimv2) :
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
Et ainsi de suite. Dommage qu'il faille inclure la partie http://schemas.microsoft.com/wbem/wsman/1/wmi de l'URI...
À ce stade nous sommes prêts à recevoir certaines données en retour. Pour cela, il nous suffit d'appeler la méthode Enumerate, en utilisant la variable strResource comme unique paramètre de méthode :
Set objResponse = _
  objSession.Enumerate(strResource)
Cette ligne de code peut-elle vraiment remplir objResponse avec des informations sur les services installés sur l'ordinateur atl-fs-01 ? Absolument. Cependant, contrairement aux scripts WMI standard, vous ne recevez pas une série d'objets, chacun avec ses propres propriétés et méthodes de propriété. Au lieu de cela, vous recevez un seul blob XML qui ressemble un peu à ce que vous pouvez voir à la figure 2.
Figure 2 Jolies couleurs (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

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

</Canvas>
Figure 2 Blob XML (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
Si vous êtes un as du XML, cela n'est pas un problème ; quiconque connaissant bien XML devrait pouvoir analyser et traiter ces informations sans trop de difficultés (bien que, d'après le kit de développement WinRM, ces informations ne soient pas dans « format lisible »). Mais qu'en est-il si vous n'êtes pas un as du XML ? Dans ce cas, vous avez deux choix. Soit vous attendez jusqu' au mois prochain, lorsque nous vous montrerons quelques astuces pour travailler avec le XML de WinRM, soit vous faites ce que nous avons fait dans notre exemple de script : vous utilisez la transformation XSL qui est installée avec WinRM.

La transformation quoi ?
Une transformation XSL n'est rien de plus qu'un modèle qui décrit comment un fichier XML doit être affiché. Une explication, même superficielle, sur les fichiers XSL dépasserait le cadre de l'article de ce mois. Par conséquent, nous n'essaierons pas d'expliquer comment WsmTxt.xsl (nom de la transformation intégrée) fonctionne. Nous allons plutôt vous montrer comment vous pouvez utiliser cette transformation dans votre script.
Lorsque vous appelez la méthode Enumerate, WinRM renvoie un flux de données XML. La façon la plus facile de travailler avec ces données est de configurer une boucle Do Until qui continue à s'exécuter jusqu'à ce que vous atteigniez la fin du flux de données. C'est ce que nous faisons ici :
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
Comme vous pouvez le voir, dans notre boucle, nous appelons une sous-routine appelée DisplayOutput. Lorsque nous appelons cette sous-routine, nous transmettons la valeur de la méthode ReadItem du flux comme paramètre de la sous-routine (comme l'implique cette approche, le flux XML est renvoyé sous forme d'éléments séparés au lieu d'un seul blob de données. Notre script lit également les données XML un élément à la fois).
La sous-routine DisplayOutput a l'aspect suivant :
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
En bref, nous commençons par créer deux instances de l'objet MSXml2.DOMDocument.3.0. Nous chargeons le flux de données XML (strWinRMXML) dans un objet, puis nous chargeons le fichier XSL (WsmTxt.xsl) dans l'autre objet. À ce stade, nous appelons la méthode TransformNode pour utiliser les informations du fichier XSL afin de formater et d'afficher les données reçues du flux XML.
Oui, c'est un peu compliqué. Mais au moins la sortie (bien que loin d'être parfaite) est un peu plus facile à lire (voir figure 3).
Figure 3 Peindre un texte (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

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

</TextBlock>
Figure 3 Une version plus propre du fichier XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
Comme nous l'avons déjà dit, c'est bien, mais ce n'est pas parfait, ce qui constitue une raison de plus pour lire l'article du mois prochain, où nous vous montrerons des façons de manipuler vous-même la sortie XML.

Renvoi d'instances et de propriétés sélectionnées d'une classe
Tout cela est très bien, à l'exception d'une chose : il se peut que cela ne reflète pas entièrement votre façon de travailler. Parfois, vous aurez besoin de renvoyer toutes les propriétés de toutes les instances d'une classe, et à d'autres moments vous aurez besoin de renvoyer uniquement certaines propriétés ou instances données d'une classe. Par exemple, vous pourriez vouloir renvoyer uniquement les informations sur les services en cours d'exécution, chose que vous faites dans un script WMI normal en utilisant un code du type :
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
Bon d'accord. Mais comment allez-vous modifier votre chaîne de ressource pour qu'elle soit équivalente à ce code ?
Et bien, pour être parfaitement honnête, vous ne pouvez pas modifier votre chaîne de ressource pour la rendre équivalente à l'instruction ExecQuery. Vous devrez absolument modifier la chaîne de ressource, mais vous devrez également effectuer d'autres actions.
Observons la figure 4 tout en gardant cela à l'esprit. Il s'agit d'un script WinRM qui renvoie des informations sur les services en cours d'exécution sur un ordinateur (par opposition à tous les services installés sur cet ordinateur).
Figure 4 Astuces pour TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 Recherche des services en cours d'exécution (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
À première vue, ce script peut paraître identique au premier script WinRM que nous vous avons montré. Cependant, il y a quelques différences très importantes. Tout d'abord, examinez la valeur que nous attribuons à la chaîne de ressource :
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
Notez que dans la requête filtrée, nous ne spécifions pas le nom réel de la classe (Win32_Service) que nous voulons utiliser ; au lieu de cela, nous nous connectons simplement à l'espace de noms (root/cimv2) où cette classe réside. N'oubliez pas de placer l'astérisque (*) à la fin. Si vous ne le faites pas, le script échoue avec le message «... the class name must be '*' (star) » (... le nom de classe doit être * (étoile)), qui signifie simplement que vous devez définir le nom de classe sur *.
Nous devons en outre également définir un filtre et un dialecte :
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
Le filtre devrait être assez facile à déterminer ; c'est là que se trouve la requête Windows Management Instrumentation Query Language ou WQL ("Select * From Win32_Service Where State = 'Running'"). Le dialecte, lui, est le langage de requête utilisé lors de la création du filtre. Pour l'instant, un seul langage de requête est autorisé : WQL. Néanmoins, le dialecte doit être spécifié, sinon le script échoue avec un message indiquant que « filter dialect ... is not supported. » (le dialecte de filtre... n'est pas pris en charge.).
Remarque : il est intéressant de noter que le message d'erreur suggère de supprimer le dialecte lorsque vous appelez la méthode Enumerate. C'est une recommandation à ne pas suivre. Lors de la création d'une requête filtrée, le dialecte doit être spécifié et doit être WQL. Il n'y a pas d'exception.
Le seul autre changement que nous devons apporter intervient au moment de l'appel de la méthode Enumerate. À ce stade, nous devons transmettre les variables représentant le filtre (strFilter) et le dialecte (strDialect), ainsi que la variable représentant la ressource (strResource) :
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
Faites un essai et voyez ce que vous obtenez.
Maintenant, comment faire pour renvoyer uniquement certaines propriétés données d'une classe ? Par exemple, supposons que vous vouliez renvoyer uniquement les propriétés Name et DisplayName de tous les services exécutés sur un ordinateur. Que se passe-t-il alors ?
Dans un cas comme celui-ci, vous pouvez essayer de manipuler le fichier XML pour que seules les propriétés Name et DisplayName s'affichent. Bien que cela soit faisable, c'est un peu compliqué. Une méthode plus facile consiste à spécifier uniquement ces propriétés lors de l'attribution du filtre :
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
Vous recevez ainsi les propriétés Name et DisplayName de chaque service, comme indiqué ci-dessous :
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Certes, le formatage semble un peu bizarre (qu'est-ce que cette histoire de XmlFragment ?). Voilà une nouvelle raison de lire notre article du mois prochain.

Vous verrez !
Avec un peu de chance, vous pourrez commencer à faire des merveilles avec WinRM. Nous ne pouvons cependant pas terminer un article sur WinRM sans mentionner les « morgues temporaires » autrefois courantes à travers l'Allemagne. Dans les villes qui avaient des morgues temporaires, les cadavres n'étaient pas été enterrés tout de suite. Ils étaient placés dans des pièces chauffées avec un certain nombre de ficelles et de fils attachés à leurs doigts et orteils. L'idée, bien sûr, était que le moindre mouvement déclenchait une alarme pour appeler à l'aide. Les corps étaient conservés dans ces morgues jusqu'à ce que leur état ne fasse plus de doute.
A bien y songer, une morgue temporaire est un peu comme être assigné à l'équipe de scripteurs, non ? La seule différence est que personne n'est jamais revenu à la vie dans les morgues, alors que les personnes assignées à l'équipe des scripteurs...

Les scripts embrouillés du Dr. Scripto
En juin 2007, les scripteurs ont assisté à la conférence Tech•Ed 2007 à Orlando, en Floride. Non contents d'assister simplement à la conférence, nous avons décidé de nous amuser un peu. Non seulement cela, mais nous avons en plus pensé que tout le monde avait besoin de se divertir un peu. C'est dans cet esprit que nous avons inventé Dr. Scripto's Fun Book, un petit livre d'énigmes ayant trait aux scripts et divers autres éléments d'information. Nous nous sommes associés à TechNet Magazine (où plutôt nous les avons persuadés de nous laisser utiliser une partie de leur stand dans le hall d'exposition) et nous avons distribué des copies de ce livre aux gens qui passaient.
Il se trouve qu'il a eu beaucoup de succès (peut-être pas autant que la figurine à tête branlante du Dr. Scripto, mais presque). Les gentils opportunistes de TechNet Magazine, décelant une nouvelle occasion d'exploiter le succès des scripteurs (qui eux ne semblent jamais pouvoir exploiter leur propre succès), nous ont alors demandé de créer des énigmes pour eux. Sitôt que la scripteuse Jean Ross a eu le dos tourné, le scripteur Greg Stemp a répondu « Pas de problème » ! Voici donc : Les scripts embrouillés du Dr. Scripto. Bonne chance !

Script dans le désordre
Dans cette énigme, vous devez remettre toutes les lettres de la première section dans le bon ordre pour reconstituer un script (en code VBScript). Ne vous inquiétez pas, vous ne devez pas tout déchiffrer ; il suffit simplement de déchiffrer une colonne à la fois. Les lettres de chaque colonne de la section du haut doivent être placées dans les espaces vides de la même colonne de la section inférieure. Voici un exemple :
Comme vous pouvez le voir, la colonne 1 contient les lettres S, C et T. Ces trois lettres doivent être placées dans un autre ordre dans la grille du bas. Lorsque toutes les lettres sont remises dans le bon ordre, la grille inférieure (qui doit être lue de gauche à droite) devient logique. Regardez la solution :
Vous pouvez voir que les lettres S, C et T de la colonne 1 deviennent T, S et C. Cela correspond à la première lettre de chaque mot de la phrase « The Script Center ». La vraie énigme est un peu plus difficile car elle est plus longue et que le résultat final est un script complet.
Petite astuce : le script final commence par un chemin de fichier complet, puis une analyse et affiche seulement le nom du fichier.
Bonne chance !

Les scripts embrouillés du Dr. Scripto
Réponse : Script dans le désordre, novembre 2007
Dans cette énigme, vous deviez placer les caractères de chaque colonne dans les cases correctes de la grille du dessous pour que les lignes forment un script. Voici le script :
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
Voici comment il apparaît dans la grille de l'énigme :

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;: Acc&#232;s &#224; distance s&#233;curis&#233;
Vigilance sécurité
Accès à distance sécurisé
John Morello

L'une des tendances indéniables du paysage technologique actuel est que le personnel des entreprises est de plus en plus mobile et connecté. Dans de nombreuses organisations, un grand nombre de membres du personnel travaillent depuis des bureaux dispersés, pratiquent le télétravail ou se déplacent fréquemment chez les clients. Le fait de fournir à ces utilisateurs un accès facile aux applications et aux données, quel que soit leur emplacement, ne peut qu'augmenter leur
productivité. Cependant, jusqu'à il y a peu, l'accès à distance sécurisé impliquait souvent d'installer un logiciel client, de taper des commandes complexes, ainsi que des temps de connexion longs.
Au cours des dernières années, plusieurs approches ont contribué à rendre l'accès à distance plus simple et plus accessible. Par exemple, Outlook® Web Access (OWA) fournit aux utilisateurs un outil simple basé sur un navigateur pour accéder à leur messagerie électronique, leur calendrier et leurs contacts sans les complexités d'un réseau privé virtuel (VPN) de couche 3 complet. Bien que les technologies telles qu'OWA puissent offrir un élément important d'une solution d'accès à distance, la plupart des organisations disposent de nombreuses applications clés qui ne permettent pas le même genre d'expérience intégrée basée sur un navigateur. Dans ce type de cas, les solutions telles que les services Terminal Server offrent une méthode efficace pour donner aux utilisateurs un accès à leurs applications quel que soit l'endroit où ils se trouvent.
Avec Windows Server® 2008, Microsoft a considérablement amélioré l'ensemble des fonctionnalités intégrées des services Terminal Server. Les services Terminal Server incluent désormais une fenêtre transparente, une fonctionnalité de publication pour chaque application, une fonctionnalité de pilote d'impression universel dans EasyPrint et un portail basé sur navigateur appelé TS Web Access. De plus (et c'est là la clé du scénario d'accès à distance), Windows Server 2008 inclut également le composant Passerelle TS qui fournit l'encapsulation SSL pour le protocole RDP (Remote Desktop Protocol), lui permettant ainsi de traverser de façon simple et sécurisée les pare-feu et les périphériques de traduction d'adresses réseau (NAT). La fonctionnalité de passerelle TS s'intègre également avec une autre nouvelle technologie de Windows Server 2008, la protection de l’accès réseau (NAP), pour assurer une vérification de l'intégrité du client de point de terminaison. Lorsque tous ces composants sont associés, les organisations ont la possibilité de générer des solutions qui permettent aux utilisateurs d'accéder facilement et de façon sécurisée à leurs applications et données depuis n'importe quel site.
Cet article se concentre sur les aspects relatifs à la sécurité et au réseau de la conception d'une solution d'accès à distance plutôt que sur la gestion des composants Terminal Server. Je décrirai les méthodes et les meilleures pratiques pour la création d'une telle solution basée sur les technologies incluses dans Windows Server 2008.

Pourquoi les réseaux privés virtuels de couche 3 posent-ils un problème ?
Lorsque vous envisagez d'utiliser une nouvelle technologie, il est important de comprendre ses avantages par rapport aux approches actuelles de sorte à pouvoir évaluer de façon précise la valeur du nouveau modèle. Dans le cas d'un VPN de couche 3 classique, deux problèmes majeurs se posent généralement : sécurité et simplicité d'utilisation.
Il peut sembler paradoxal d'énumérer la sécurité comme l'un des problèmes de nombreux VPN de couche 3 existants. Le but d'un VPN n'est-il pas de fournir un tunnel sécurisé sur Internet ? Pour mieux comprendre, examinons à un plus haut niveau ce qui est généralement considéré comme des menaces pour le réseau VPN. Je ne dis pas que les données transitant par ces VPN courent un risque d'interception ou de falsification ; la plupart des VPN modernes de couche 3 fournissent un excellent chiffrement du flux de données. Pensez plutôt aux menaces posées par les ordinateurs distants qui bénéficient d'un accès complet « tous ports, tous protocoles » au réseau de votre organisation. Le problème ne réside pas dans le flux de données chiffré et transporté sur le réseau par les VPN de couche 3, mais plutôt dans les clients distants se connectant via ces tunnels, qui représentent un risque plus grand pour votre réseau interne. Rappelons que la plupart des organisations ayant subi les conséquences de logiciels malveillants tels que Slammer ou Blaster n'ont pas été infectées par des ordinateurs sur leur réseau interne ou par des pirates informatiques traversant leurs pare-feu. L'infection provenait d'employés distants se connectant à leurs réseaux via des VPN depuis des ordinateurs infectés. Lorsque ces VPN créent des connexions de couche 3 entièrement routées, l'ordinateur distant a souvent autant accès (ce qui est à la fois une bonne et mauvaise chose) aux ressources internes qu'un ordinateur situé au centre de données.
De plus, les VPN de couche 3 sont souvent coûteux parce qu'ils nécessitent l'installation et la configuration de logiciels sur des ordinateurs qui ne sont pas gérés par l'équipe informatique de l'organisation. Par exemple, l'installation d'un client VPN sur l'ordinateur personnel d'un utilisateur peut impliquer la création de packages d'installation personnalisés, la rédaction d'instructions d'installation détaillées pour l'utilisateur et des conflits de dépannage avec des applications existantes sur l'ordinateur de l'utilisateur. En outre, les coûts de gestion peuvent être élevés si de nouvelles versions du client doivent être déployées ou si les données de configuration sont modifiées (par exemple lors de l'ajout d'un nouveau point de terminaison VPN). Pour l'utilisateur, l'utilisation de ce type de VPN se traduit souvent par une expérience non intuitive. Puisque le VPN fournit uniquement la connexion de couche 3, les applications et les données d'entreprise de l'utilisateur ne sont pas facilement accessibles et visibles.

Résolution des problèmes liés aux services Terminal Server
Les services Terminal Server, ainsi que d'autres technologies VPN de couche 7 ou de couche d'application, résolvent ces deux problèmes en fournissant un contrôle beaucoup plus approfondi sur les ressources et protocoles auxquels les utilisateurs peuvent accéder, et en rendant l'expérience utilisateur beaucoup plus simple et intuitive qu'auparavant.
Du point de vue de la sécurité, la différence la plus importante entre l'approche de VPN de couche 3 et celle qui utilise les services Terminal Server et la passerelle TS réside dans le fait que la connexion au réseau interne n'est pas totalement ouverte. En particulier, alors qu'une approche de couche 3 crée une interface virtuelle sur l'ordinateur local avec une fonctionnalité de routage complète vers le réseau interne, l'approche de passerelle TS autorise seulement aux paquets RDP à atteindre le réseau interne. Ainsi, la surface d'attaque générale est fortement réduite et des contrôles plus granulaires peuvent être appliqués dans RDP. Par exemple, alors que RDP fournit une prise en charge native pour le réacheminement de lecteur, les organisations peuvent configurer leurs passerelles TS de sorte qu'elles s'intègrent à NAP et qu'elles n'autorisent pas cette fonctionnalité à moins que l'ordinateur distant puisse prouver que son logiciel antivirus est à jour.
Pour les utilisateurs finaux, la différence la plus évidente entre une approche VPN de couche 3 et une approche Terminal Server réside dans la simplicité d'installation (souvent, il n'y a pas d'installation du tout) et un accès beaucoup plus facile et intuitif aux applications et données. Dans la mesure où le client Connexion Bureau à distance est intégré à Windows (et maintenu à jour à l'aide de technologies de maintenance standard telles que Windows® Update), il n'y a généralement pas de logiciel client à installer. De plus, en utilisant TS Web Access, les utilisateurs peuvent utiliser une URL unique pour rechercher toutes leurs applications et données. Il suffit de cliquer sur l'application appropriée pour lancer la passerelle TS qui tunnelise la connexion sur Internet de façon sécurisée, et l'application est envoyée de façon transparente au bureau de l'utilisateur. En d'autres termes, l'application se comporte comme si elle était installée localement, offrant notamment la possibilité de copier et coller et de la réduire dans la barre de tâches. En rendant facilitant la détection et l'installation des applications et des données, l'approche Terminal Server d'accès à distance améliore la satisfaction des utilisateurs et réduit les coûts de support.

Choix d'architecture réseau
Il existe deux approches fondamentales de conception de réseau pouvant être utilisées pour rendre un serveur de passerelle TS accessible sur Internet. La première place la passerelle TS dans le réseau de périmètre, entre deux pare-feu de couches 3 et 4. La seconde laisse la passerelle TS sur le réseau interne et utilise un pare-feu de couche d'application (tel que Microsoft® ISA Server, Microsoft Intelligent Application Gateway ou toute une série de solutions de tiers) pour résider sur le réseau de périmètre et inspecter les trames HTTPS entrantes. Une fois ces sessions entrantes analysées, les paquets sont transférés au serveur de passerelle TS interne.
Si une organisation dispose uniquement de pare-feu de couches 3 et 4 avec une vérification de paquets avec état de base, le périphérique de passerelle TS peut être directement placé dans le réseau de périmètre, comme illustré à la figure 1. Dans cette conception, le pare-feu ouvert sur Internet limite la connectivité à la passerelle TS pour autoriser uniquement le trafic HTTPS Internet à l'atteindre. Cependant, le pare-feu n'effectue pas de vérification sur la couche d'application de ce trafic ; il transfère simplement le trafic à la passerelle TS. Le serveur de passerelle TS extrait ensuite les trames RDP des paquets HTTPS et les transfère au serveur principal approprié. Ces serveurs principaux sont souvent séparés du réseau de périmètre par un deuxième pare-feu configuré pour autoriser les trames RDP de la passerelle TS à atteindre les serveurs internes appropriés.
Figure 1 Avec un pare-feu de couches 3 et 4, la passerelle TS est placée dans le réseau de périmètre
Figure 1 Avec un pare-feu de couches 3 et 4, la passerelle TS est placée dans le réseau de périmètre
Bien qu'il s'agisse d'un scénario entièrement pris en charge et qui peut être utile à de nombreuses organisations, il présente deux inconvénients essentiels. Tout d'abord, dans la mesure où la passerelle TS reçoit le trafic directement d'Internet, elle est exposée à un niveau de risques provenant de tiers malveillants externes relativement plus élevé. Ces tiers malveillants pourraient tenter d'attaquer la passerelle via la session SSL et, comme le pare-feu frontal vérifie uniquement les en-têtes et pas les charges utiles, ces sessions atteindraient la passerelle. Cela ne veut pas dire que la passerelle TS est un composant vulnérable ; elle a été soumise aux mêmes conception et tests de sécurité rigoureux que le reste du produit Windows Server 2008. Cependant, son risque relatif est plus élevé dans ce scénario, simplement parce qu'elle contrôle un trafic non filtré provenant directement d'Internet. Le deuxième inconvénient majeur réside dans la quantité accrue de trafic devant être autorisé entre la passerelle et le pare-feu principal. Pour authentifier les utilisateurs, la passerelle TS doit communiquer avec Active Directory®. Pour autoriser cette communication, le pare-feu principal doit avoir des exceptions pour un nombre de ports et de protocoles beaucoup plus important que HTTPS. Ce niveau accru de communications autorisées représente également une augmentation du risque relatif de cette conception.
Une meilleure approche d'exposition d'une passerelle TS à Internet consiste à utiliser un pare-feu de couche d'application (couche 7) pour traiter les sessions HTTPS entrantes avant qu'elles n'atteignent la passerelle (voir figure 2). Dans cette conception, des pare-feu de couches 3/4 traditionnels peuvent toujours former un réseau de périmètre. Cependant, au lieu de la passerelle TS, c'est le pare-feu de couche 7 qui se situe dans le réseau de périmètre. Lorsque le trafic atteint le pare-feu externe, ce pare-feu filtre tout sauf les trames HTTPS, puis transfère ces trames vers le pare-feu de couche 7. Le pare-feu de couche 7 met fin à la session SSL, vérifie les contenus du flux non chiffrés, bloque le trafic malveillant, puis envoie les trames RDP vers la passerelle TS via le pare-feu principal. Notez que, si nécessaire, le pare-feu de couche 7 peut également rechiffrer les trames avant de les envoyer à la passerelle TS. Cette approche peut ne pas être nécessaire sur le réseau privé d'une organisation, mais elle peut être très utile dans des centres de données hébergés ou des réseaux partagés.
Figure 2 Utilisation d'un pare-feu de couche d'application avec un périphérique de passerelle TS
Figure 2 Utilisation d'un pare-feu de couche d'application avec un périphérique de passerelle TS
Cette conception évite les deux inconvénients de la solution précédente. Dans la mesure où le serveur de passerelle TS reçoit uniquement le trafic qui a été inspecté par le pare-feu de couche 7, le risque de transmission d'attaques véhiculées par Internet est moins élevé. Le pare-feu de couche 7 devrait filtrer ces attaques et ne renvoyer que le trafic propre et inspecté à la passerelle.
Le deuxième avantage majeur de cette solution réside dans la position de la passerelle par rapport au réseau interne. Comme le trafic provenant d'Internet est inspecté par le pare-feu de couche 7 avant d'atteindre la passerelle, il peut rester sur le réseau interne et avoir directement accès aux contrôleurs de domaine pour les hôtes d'authentification et RDP pour les sessions utilisateur. De plus, le pare-feu principal peut avoir une stratégie beaucoup plus restrictive. Au lieu d'autoriser le trafic RDP et le trafic d'authentification d'annuaire, il doit simplement autoriser les sessions RDP entre du pare-feu de couche 7 et la passerelle TS. L'utilisation d'un pare-feu de couche 7 frontal dans votre déploiement de passerelle TS offre une solution plus sécurisée, qui est plus facile à gérer sans qu'il soit nécessaire de revoir la conception de votre réseau de périmètre existant.

Intégration NAP
Ressources pour les services Terminal Server
  • Services Terminal Server dans Windows Server 2008
  • Windows Server 2008 Terminal Services TechNet Forum
  • Blog de l'équipe des services Terminal Server
  • Microsoft Intelligent Application Gateway 2007
  • Network Access Protection (NAP) pour Windows Server 2008
  • Blog sur la protection de l’accès réseau (NAP, Network Access Protection)
  • Guides pas à pas de Windows Server 2008 Bêta 3

Bien qu'une bonne conception de périmètre soit un élément clé de votre solution d'accès à distance, il est également important de garantir la conformité et la sécurité de vos périphériques de point de terminaison. RDP étant un protocole riche qui autorise un grand nombre de types de réacheminement de périphérique, tels que les sessions RDP et les imprimantes, il est essentiel que les clients se connectant à votre solution se conforment aux stratégies de sécurité de votre organisation. Par exemple, même avec une topologie de réseau sécurisée basée sur les meilleures pratiques comme celles décrites précédemment, un utilisateur final se connectant à un serveur Terminal Server à partir d'un ordinateur non sécurisé peut finir par perdre des données confidentielles ou placer des fichiers malveillants sur le serveur Terminal Server. Bien que la quantité de connectivité et les dommages potentiels soient considérablement moindres que si cet utilisateur se connecte via un VPN de couche 3, il reste important de gérer le risque de perte de données et de garantir la conformité à vos stratégies informatiques.
La protection d'accès réseau (NAP) est une nouvelle technologie de Windows Server 2008 qui vous permet de contrôler non seulement qui peut se connecter à votre réseau, mais aussi à partir de quels genres de systèmes les utilisateurs autorisés peuvent se connecter. Par exemple, vous pouvez utiliser NAP pour garantir que seuls les ordinateurs ayant un pare-feu en cours d'exécution et un logiciel antivirus à jour puissent se connecter au réseau. NAP est une solution extensible qui ne couvre pas seulement le réseau interne de l'organisation, mais également les utilisateurs à distance, y compris ceux qui se connectent via des VPN de couche 3 et ceux qui se connectent via la passerelle TS. En intégrant NAP à votre conception de passerelle TS, vous pouvez vous assurer que seuls les systèmes conformes à vos stratégies de sécurité peuvent se connecter. Pour plus de détails sur NAP, consultez mon article Vigilance sécurité du numéro de mai 2007 de TechNet Magazine, disponible en ligne à l'adresse technetmagazine.com/issues/2007/05/SecurityWatch.
L'intégration de NAP à un déploiement de passerelle TS est un processus simple qui implique l'ajout d'un seul service supplémentaire à la conception. Ce service, appelé Network Policy Server (NPS), peut être installé soit sur le serveur de passerelle TS lui-même, soit sur une instance distincte du système d'exploitation. La console MMC de la passerelle TS est ensuite utilisée pour créer les stratégies d'autorisation des connexions (CAP) qui définissent quelles fonctionnalités RDP sont autorisées pour un état d'intégrité donné. Le serveur de passerelle TS est configuré pour vérifier auprès du service NPS chaque fois qu'une nouvelle connexion est tentée et pour transférer la déclaration d'intégrité (SoH) de cette connexion à NPS. Le service NPS compare ensuite la SoH à ses stratégies et indique à la passerelle TS si la connexion doit être autorisée en fonction de l'intégrité du client.
Comme l'illustre la figure 3, si un système non conforme n'est pas configuré pour utiliser Windows Update, mais que la stratégie de sécurité de l'organisation requiert que les mises à jour automatiques soient activées, lorsqu'un utilisateur tente de se connecter à la passerelle TS, son ordinateur génère et transfère une SoH. Cette SoH comprend des informations du type, « Mon pare-feu est activé et mon antivirus est à jour, mais les mises à jour automatiques sont désactivées ». La passerelle TS transfère alors cette SoH au service NPS (la passerelle TS n'a pas de logique lui permettant de décoder seule la SoH), et le service NPS compare la déclaration SoH aux stratégies définies par son administrateur. Dans la mesure où les mises à jour automatiques ont été désactivées, le service NPS détermine que la connexion est conforme à la stratégie de « non conformité » et indique à la passerelle TS de ne pas autoriser la connexion. La passerelle TS arrête la connexion et notifie l'utilisateur que l'ordinateur n'est pas conforme aux stratégies de sécurité de l'organisation. L'utilisateur peut alors prendre les mesures de correction nécessaires (dans ce cas, en activant les mises à jour automatiques) avant de faire une nouvelle tentative de connexion. Une nouvelle SoH est alors générée, le serveur NPS détermine la conformité et la passerelle TS autorise la connexion.
Figure 3 Seuls les systèmes conformes peuvent se connecter
Figure 3 Seuls les systèmes conformes peuvent se connecter

Conclusion
Windows Server 2008 inclut les composants clés d'une solution d'accès à distance sécurisée. La passerelle TS fournit une méthode sécurisée pour la tunnelisation des sessions de bureau à distance sur Internet et offre aux organisations une grande liberté de choix dans la façon dont ces sessions sont intégrées à leurs réseaux existants. Les options consistent soit à placer la passerelle TS directement sur le réseau de périmètre, soit à utiliser devant elle un pare-feu de couche 7, comme ISA Server ou Intelligent Application Gateway. NAP peut être associé à la passerelle TS pour ajouter des fonctionnalités d'inspection de l'intégrité des points de terminaison à la solution. Les vérifications de point de terminaison permettent aux organisations de s'assurer non seulement que les connexions à distance proviennent d'utilisateurs valides, mais également qu'elles proviennent d'ordinateurs qui sont conformes à leurs stratégies de sécurité informatique. Lorsqu'elles sont utilisées ensemble, ces technologies fournissent aux organisations des fonctionnalités d'accès à distance plus sécurisées et plus efficaces qui offrent une meilleure expérience aux utilisateurs finaux. Vous trouverez de nombreuses informations complémentaires sur les sites indiqués dans l'encadré « Ressources pour les services Terminal Server ».

John Morello est chez Microsoft depuis 2000. En tant que consultant senior, il a conçu des solutions de sécurité pour des entreprises figurant dans le classement Fortune 100 ainsi que des clients civils et militaires de l'administration fédérale. Il est actuellement responsable de programme senior au sein du groupe Windows Server qui se consacre aux technologies de sécurité et d’accès à distance. Vous pouvez lire le blog de son équipe à l'adresse blogs.technet.com/WinCAT.


 Histoires de Bureau: La v&#233;rit&#233; sur la d&#233;fragmentation
Histoires de Bureau
La vérité sur la défragmentation
Wes Miller

La fragmentation de disque est aussi ancienne que les disques durs. Si vous êtes soucieux de vos systèmes, vous les défragmentez certainement régulièrement. Ceci vous rappelle probablement ce monologue que vous sert chaque année votre dentiste sur l'importance de l'utilisation du fil dentaire ; vous vouez certainement de quoi je veux parler. Eh bien, la défragmentation est tout aussi importante.
À moins que votre ordinateur ne soit relégué dans un coin, toujours éteint, il est de plus en plus fragmenté. Je vous montrerai d'ici peu comment cela se produit, mais penchons-nous pour l'instant sur un petit historique de la défragmentation.

Défragmentation et Windows NT
Windows NT® ne possédait pas d'utilitaire de défragmentation intégré et les idées reçues de l'époque voulaient que vous n'en ayez pas besoin. Après tout, le système de fichiers NTFS avait été créé avec l'optimisation à l'esprit, et il ne souffrait pas de la fragmentation de manière aussi spectaculaire qu'un volume FAT similaire. Mais au fil du temps, même les performances NTFS peuvent pâtir d'un placement de fichier moins qu'optimal. Ceci a permis la naissance d'un marché des outils de défragmentation tiers très prospère. L'un des produits les plus populaires parmi les professionnels de l'informatique était le logiciel Diskeeper d'Executive Software (maintenant Diskeeper Corporation). Lorsque Windows 2000 a intégré la fonctionnalité de défragmentation, Microsoft a acquis la licence de la technologie d'Executive Software. La fonctionnalité de défragmentation de Windows® 2000 était disponible dans son propre composant enfichable MMC (Microsoft ® Management Console), dfrg.msc. Celui-ci pouvait être invoqué en cliquant sur un volume ou en exécutant manuellement defrag.exe à partir de la ligne de commande. Bien que cet utilitaire ne permît pas la planification et disposât uniquement ligne de commande uniquement, de nombreux professionnels de l'informatique créèrent néanmoins des scripts fonctionnels pour automatiser la défragmentation en utilisant cette version intégrée. Defrag.exe dans Windows XP et Windows Server® 2003 constituait une légère amélioration par rapport à la version précédente, mais offrait une automatisation limitée. Il était toujours nécessaire d'écrire des scripts pour celle-ci.
Plusieurs fournisseurs, dont Winternals Software (mon ancien employeur), ont alors créé des logiciels pour le segment de la défragmentation d'entreprise. La plupart de ces produits fonctionnent de façon identique, avec une console centralisée, un agent d'un certain type hébergé sur les systèmes clients (parfois de manière permanente et parfois seulement sur demande) et une structure permettant d'indiquer quand et comment la tâche de défragmentation s'exécute.
Windows Vista® perpétue principalement la tendance de défragmentation de système unique, tout en optimisant le defragmenteur et en incluant des options telles que la défragmentation de petits fragments de fichiers (64 Mo ou moins), ce qui accélère la défragmentation mais conserve les plus grands fragments de fichiers sur le disque. Le moteur de défragmentation à proprement parler est plus puissant dans Windows Vista et Windows Server 2008 que dans les versions précédentes de Windows. Il s'exécute en outre automatiquement et ne nécessite aucune planification manuelle. Mais si vous êtes en charge d'une grande organisation ou devez optimiser vos systèmes avec des méthodes non fournies par défaut par la défragmentation, il est possible que vous deviez toujours avoir recours à des logiciels tiers. Et, tout comme dans les versions précédentes, vous risquez de rencontrer des difficultés pour la défragmentation d'un volume sur lequel la compression NTFS est activée et utilisée de façon intensive. Un outil tiers peut également être utile dans un tel scénario.

Comment la fragmentation survient-elle ?
La fragmentation survient car les fichiers changent avec le temps. Dans l'idéal, les fichiers Windows ne changent pas. Ou, tout du moins, ils ne changent pas très souvent, à vrai dire seulement avec les installations de Service Packs et de mises à jour logicielles. Autrement, les fichiers système demeurent relativement constants. Après l'exécution d'une mise à jour importante telle que l'installation d'un Service Pack, une fragmentation surviendra naturellement puisque les fichiers mis à jour ne peuvent habituellement pas être écrasés à leur emplacement sur le disque (et peuvent nécessiter un redémarrage pour être mis à jour) ce qui se traduit par une nouvelle fragmentation.
Les fichiers et données des utilisateurs (et le Registre Windows), en revanche, font l'objet de modifications constantes. La lecture, l'écriture, la modification, la copie et la suppression continuelles de fichiers provoquent une fragmentation intensive, en particulier lorsque la capacité du lecteur est atteinte.
Pour représenter ceci, imaginons un disque parfaitement ordonné, dans lequel les fichiers occupent un espace contigu sans aucun espace entre eux. Supposons que vous ouvrez un fichier et le modifiez, puis essayez de l'enregistrer. Si le fichier a grandi, Windows doit enregistrer le fichier dans son intégralité à un autre emplacement sur le disque (par exemple après le fichier N) ou enregistrer les nouvelles données après le fichier N. Cela signifie que le fichier 2 est maintenant fragmenté. Si vous modifiez maintenant le fichier 1, vous aurez deux fichiers fragmentés. Répétez ceci au fil du temps et vous obtiendrez un système considérablement fragmenté dans lequel le lecteur doit examiner un grand nombre d'emplacements pour accéder à un fichier individuel. Avec des fichiers de base de données de grande taille, des fichiers de disque dur volumineux pour les technologies d'informatique virtuelle et une multitude de vidéos et de fichiers audio enregistrés sur les disques standard, la fragmentation est chose commune. Bien sûr, la taille toujours plus importante des disques durs atténue le problème représenté par la fragmentation, mais celui-ci ne disparaît pas pour autant. Les anciens portables avec des disques durs plus réduits réagiront de moins en moins bien, seront plus lents à démarrer et nécessiteront une durée plus longue pour ouvrir et enregistrer des fichiers.
Le principal souci ne réside pas dans le degré de fragmentation du disque, mais celui des fichiers individuels. Depuis l'arrivée des premiers défragmenteurs de disque avec indications visuelles multicolores, les utilisateurs les observent en se disant « je voudrais une barre de couleur pleine ». Cela ne serait en fait absolument pas souhaitable. Certains produits tentent de faire en sorte que leurs disques apparaissent comme deux blocs : un bloc coloré (les données de fichiers) et un bloc généralement blanc (l'espace libre). Il s'agit malheureusement de l'une des pires choses à souhaiter pour votre disque si votre objectif est de réduire la fréquence et le coût de la défragmentation. Si vous avez compressé de manière agressive toutes les données de fichiers dans la première partie du disque et supprimé une bonne partie de l'espace libre lorsque vous avez apporté des modifications supplémentaires à un fichier, toutes ces modifications devront être écrites à la fin des données de fichier et, en effectuant la défragmentation de la sorte, vous avez en fait provoqué une fragmentation, qui commencera avec le prochain fichier modifié. Au lieu de deux blocs de données de fichiers soigneusement organisés, une bonne défragmentation se traduit par une image qui n'est pas nécessairement parfaite. Observez par exemple la figure 1 pour mon système de test avant défragmentation. Observez ensuite la figure 2 pour voir le même système une fois la fragmentation exécutée par Windows.
Figure 1 Mon lecteur avant défragmentation
Figure 1 Mon lecteur avant défragmentation
Figure 2 Mon lecteur après défragmentation
Figure 2 Mon lecteur après défragmentation
Notez que Windows ne se concentre pas sur la fragmentation des fichiers sur l'ensemble du disque, mais plutôt sur la fragmentation de chaque fichier individuel (voir la figure 3 pour la section du rapport de défragmentation sur les fichiers les plus fragmentés avant la défragmentation du système).
Figure 3 Rapport de défragmentation
Figure 3 Rapport de défragmentation
Par conséquent, même après la défragmentation, Windows n'affichera pas un bloc de données de fichiers compacté dans la première partie du disque. Notez également la grande section de données vertes des deux figures 1 et 2. Il s'agit du fichier d'échange Windows, que j'aborderai sous peu. Si la mise en veille prolongée est activée dans votre système Windows, elle affichera une défragmentation similaire.

Une défragmentation régulière est essentielle
Tout comme avec le fil dentaire, l'important est de se souvenir de défragmenter régulièrement. Il est encore plus important de défragmenter fréquemment sur les systèmes à haut degré d'utilisation tels que les serveurs, car si vous attendez trop longtemps, ce processus peut prendre trop longtemps et rendre votre serveur indisponible ou peu réceptif (car la défragmentation peut prendre un temps considérable et certaines phases de défragmentation peuvent en outre être exigeantes en termes de processeur).
Même les meilleurs outils de défragmentation en ligne ne peuvent pas tout défragmenter. Par exemple, ils ne peuvent pas toujours défragmenter les fichiers ouverts ou verrouillés (tels que le fichier d'échange ou du Registre) et doivent également trouver une solution pour le fichier de mise en veille prolongée, le cas échéant (qui possède une taille aussi importante que la mémoire vive utilisée sur votre système). Pour optimiser les fichiers verrouillés, consultez la section suivante sur les astuces de défragmentation.
Je pense qu'il est important de comprendre les mythes et les réalités associés à la défragmentation. La figure 4 et la figure 5 répertorient certains sujets courants évoqués au cours de discussions concernant la défragmentation et les possibilités réelles d'apparition de ces problèmes.
Figure 5 Mythes entourant la défragmentation (Close Figure 5)

Mythe | Probabilité
Les systèmes tomberont en panne. | Peu probable : les pannes sont habituellement dues à des problèmes de pilote ou de matériel (corruption de la mémoire, problèmes thermiques provoquant des redémarrages ou défaillance de disques en raison d'abus thermiques de disque).
Les applications tomberont en panne. | Peu probable : comme avec l'ensemble du système, une application convenablement conçue ne devrait pas tomber en panne en raison de la fragmentation. Par conséquent, à moins qu'il ne soit prouvé qu'elle en soit la cause, il n'existe aucune raison de croire que la fragmentation est à l'origine du problème.
Le Registre sera endommagé. | Peu probable (voir ci-dessus) : la fragmentation ne provoque pas et ne mène pas à des dégâts sur le Registre.
La défragmentation doit se traduire par une barre pleine dans la représentation visuelle du disque. | Peu probable : tous les fichiers du système ne doivent pas être compressés ensemble, sauf dans le cas très spécifique où vous prévoyez de créer une image du système avec un outil de création d'image basé sur les secteurs qui n'exclut pas l'espace libre et ne permet pas la réduction ou le fractionnement des partitions. Vous devez faire en sorte que les fichiers soient au premier plan du disque. Dans le cas contraire, une consolidation de fichiers agressive n'entraînera qu'une fragmentation accrue.
Figure 4 Inquiétudes courantes concernant la défragmentation (Close Figure 4)

Inquiétude | Probabilité
Les performances du système seront affectées. | Élevée : en particulier en fonction de l'utilisation du système.
La récupération de fichiers accidentellement supprimés peut devenir difficile ou impossible. | Élevée : la plupart des outils de récupération de fichiers dépendent de l'heuristique (pour déterminer le type de données) et de la proximité des groupes de fichiers. La dispersion des fichiers se traduit par une opération de récupération plus complexe ou impossible.
Il sera coûteux de défragmenter le système. | Moyenne : il existe une corrélation directe entre la fréquence d'utilisation du système et la quantité de modification des fichiers sur le système au fil du temps. Si les utilisateurs modifient des fichiers de façon intensive mais les enregistrent uniquement sur des partages de serveur, par exemple, vous ne constaterez pas beaucoup de dégradation au fil du temps.
Les disques subiront des dommages. | Faible : peu probable. Ici encore, plus vous exploiterez un système (en le conservant allumé avec les disques constamment sous tension, en éditant, modifiant et supprimant des fichiers), plus cette probabilité sera grande. Mais avec le matériel actuel, ceci ne se produira pas en raison de la modification de fichiers seule.

Défragmentation dans le cadre de votre infrastructure
Il est fortement conseillé de procéder régulièrement à la défragmentation de tous vos systèmes. Vous pouvez soit utiliser la défragmentation intégrée à Windows, soit examiner les options proposées par des fournisseurs tiers. En gros, cela se résume à la quantité d'ingénierie que vous êtes prêt à mettre en œuvre. Windows XP et ses versions ultérieures vous permettent d'ajouter defrag.exe en tant que tâche planifiée (l'article de la base de connaissances support.microsoft.com/kb/555098 vous indique comment faire). Notez que la défragmentation d'ordinateur portable s'accompagne de considérations particulières. Il est souhaitable de défragmenter le système d'un utilisateur lorsqu'il est alimenté (de préférence par le secteur), mais il est également préférable de ne pas monopoliser les cycles de processeur ou de disque lorsqu'un utilisateur mobile essaie de travailler. Malheureusement, lorsqu'un utilisateur mobile ne travaille pas sur son système, il est probable qu'il soit déconnecté du secteur et soit en veille, soit en veille prolongée (ce qui, du point de vue de la gestion de l'alimentation et des tâches planifiées, revient à être hors tension). Chez Winternals (comme probablement partout ailleurs), nous avons passé beaucoup de temps à essayer de concevoir un scénario idéal pour les utilisateurs mobiles. Si vous utilisez Windows Vista, une solution utilisant la défragmentation intégrée et les tâches planifiées, beaucoup plus consciente de l'alimentation que les versions précédentes, peut fournir une solution suffisante. Si ce n'est pas le cas, une solution de fournisseur tiers pour systèmes mobiles peut être nécessaire. Certaines peuvent en fait déclencher une tâche de défragmentation et vous indiquer qu'elle s'est exécutée, à quel moment elle s'est exécutée (et avec quelle fréquence), ainsi que le temps qu'elle a pris.
Outre les scénarios mobiles, il est souhaitable de réfléchir à la fragmentation au-delà du système de fichiers. Il ne s'agit pas d'une chose dont vous devrez généralement vous préoccuper avec les systèmes de bureau ou mobiles, mais les serveurs, Microsoft Exchange, SQL ServerTM ou les autres magasins de données peuvent nécessiter leur propre défragmentation. Dans de tels cas, vous devrez décider si cette tâche doit être effectuée avant ou après l'exécution d'une défragmentation du système de fichiers.
Si vous utilisez un produit de défragmentation de fournisseur tiers, il est souhaitable de s'assurer qu'il utilise l'API de défragmentation de Windows. Depuis Windows NT 4.0, Windows possède sa propre API de défragmentation pour empêcher les pertes de données imprévues. Par exemple, si vous êtes en train de déplacer un fichier et que l'alimentation de votre système est interrompue, la dernière chose que vous voulez est un déplacement de fragment incomplet, qui pourrait se traduire par une perte de données, voire un système ne pouvant pas être démarré.
Enfin, si vous utilisez la technologie d'informatique virtuelle, il est également conseillé de réfléchir à la façon dont la défragmentation doit être gérée sur les disques virtuels. Ils sont tout aussi susceptibles de faire l'objet d'une fragmentation que les disques physiques et celle-ci peut en toute probabilité s'avérer pire en raison des contraintes de taille. De plus, si votre solution de virtualisation vous permet de réduire des disques ou des partitions, il est préférable de les défragmenter au préalable afin de libérer de l'espace (ou tout du moins de réduire le temps nécessaire à l'opération de réduction).

Outils supplémentaires
Vous êtes maintenant certainement convaincu de l'importance et de la valeur de la défragmentation. Même si vous n'utilisez pas un outil tiers pour la défragmentation, vous devriez peut-être envisager l'outil PageDefrag de Mark Russinovich, que vous trouverez sur le site des outils de Microsoft Sysinternals (voir microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx). Comme je l'ai mentionné précédemment, le fichier d'échange de Windows ne peut pas être défragmenté pendant que Windows est actif. En fait, ceci s'applique également aux fichiers du Registre de Windows et des journaux d'événements. Grâce à un petit pilote, PageDefrag vous permet de défragmenter ces fichiers verrouillés avant que Windows ait terminé de démarrer et ait verrouillé ces fichiers. Pour l'utiliser, exécutez simplement PageDefrag et configurez-le pour s'exécuter au redémarrage suivant ou à chaque redémarrage. Lorsque le système redémarre (au stade du processus de démarrage où vous pouvez avoir vu précédemment qu'une vérification de disque est exécutée), il défragmente les fichiers spécifiés dans la liste (voir la figure 6).
Figure 6 Fichiers à défragmenter dans PageDefrag
Figure 6 Fichiers à défragmenter dans PageDefrag
Lorsque PageDefrag a accompli sa tâche, le système termine de démarrer normalement. Si vous recherchez plus d'informations sur PageDefrag, Lance Whitney l'a évoqué dans la chronique Coup de projecteur sur les utilitaires du numéro de septembre (voir technetmagazine.com/issues/2007/09/UtilitySpotlight). Notez que PageDefrag est uniquement pris en charge par Windows NT 4.0, Windows 2000, Windows XP et Windows Server 2003. Il n'est actuellement pas pris en charge par Windows Vista.
Outre PageDefrag, il existe un autre outil disponible auprès de Sysinternals portant le nom de Contig, qui vous permet de défragmenter un fichier spécifique manuellement (voir microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). Celui-ci peut être utile si un fichier spécifique n'a pas pu être défragmenté à l'aide d'une tâche de défragmentation normale ou s'il a été fragmenté depuis (mais que le reste du volume n'a pas été aussi fragmenté).
Contig permet également de défragmenter un répertoire ou des sous-répertoires entiers en utilisant les caractères génériques. La commande suivante défragmentera tous les fichiers de l'arborescence du répertoire Windows, indépendamment de leur emplacement.
Contig –s c:\Windows\*.*
Appliquez le commutateur -v pour afficher le détail de l'opération et –q pour qu'elle s'exécute sans affichage d'informations.

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


 Sur le terrain: Le Cod de conduite
Sur le terrain
Le Cod de conduite
Betsy Aoki

Parfois, ce qu'il vous faut, ce n'est pas un serveur plus grand, ou une base d'utilisateurs mieux élevés qui s'abstiennent de vous appeler quand vous êtes sur le point de quitter le bureau en avance pour le week-end. Parfois le problème ne réside pas dans la gestion du code ; ce qu'il vous faut, c'est un gros poisson.
Il y a un an, je travaillais sur les rapports d'abus pour le site Live QnA (qna.live.com). Nous étions aux commandes des boutons de suppression et protégions le site face aux attaques idiotes et aux mauvais comportements. Nous disposions d'outils internes. Nous disposions de stratégies externes. Nous étions confrontés à deux vrais cinglés tentant de saboter nos questions avec du contenu absolument ignoble.
Pendant ce temps, je m'usais. Après tout, l'intégrité communautaire du site était ma raison d'être. C'est moi qui avais aidé à l'élaboration du code de conduite qui déterminait le ton du site. J'étais la Gardienne du temple et tout le monde avait intérêt à se tenir à carreau.
Mais ce n'était pas le cas. Les gens sont faibles, capables des plus grandes perfidies et de la sainteté la plus sauvage. Et mes souhaits de calme et d'harmonie n'empêchaient absolument pas certains utilisateurs de traiter les autres de demeurés.
Donc, ce samedi-là, j'étais assise dans ma cuisine et je réfléchissais au code de conduite que je défendais. Alors que je gribouillais avec mon stylo, j'ai eu une révélation. Et s'il n'y avait pas un code de conduite, mais un Cod de conduite ? Et si c'était le cas, comment se présenterait et agirait-il ? J'ai grandi en Nouvelle-Angleterre, où l'on mange du cabillaud. Ou plutôt du cod, comme nous les anglophones l'appelons. Du cabillaud blanc, farineux, fade. Je voulais pouvoir gronder et cajoler mes membres QnA avec le ton narquois et détaché d'un cabillaud. Pas simplement appuyer sur le bouton de suppression, que j'utilisais trop fréquemment depuis quelque temps, mais avec l'humour cinglant qui ferait rire les coupables alors même qu'ils jureraient ne pas recommencer. C'est ainsi qu'est né Norbert, le Cod de conduite. J'ai envisagé de lui donner une pipe, mais le nœud pap' m'a paru suffisant.
Le Cod de conduite
Le Cod de conduite
J'ai téléchargé le dessin de mon poisson sur un nouveau LiveID, lui ai donné un nom d'utilisateur QnA et Norbert, le Cod de conduite QnA, était prêt à l'action. Je n'étais pas toujours derrière lui, ceci dit. Parfois un autre membre de l'équipe prenait le rôle de Norbert et réprimandait les scélérats. Qui est le Cod de conduite ? Voir go.microsoft.com/fwlink/?LinkId=99044. Le Cod de conduite blesse-t-il les gens ? Voir go.microsoft.com/fwlink/?LinkId=99045.
Les membres de la communauté QnA ont mordu au jeu comme... euh... comme un poisson mord à l'hameçon. Ils plaisantaient avec lui, l'appelaient, se fâchaient avec lui. Il formait les nouveaux, grondait ceux que nous pensions pouvoir remettre sur la bonne voie et proposait une façon plus légère de rappeler les règles, bien différente du ton sentencieux d'une page Web de conditions d'utilisation.
Les règles, qu'il s'agisse de politique d'entreprise, de loi tribale ou de l'ordre hiérarchique dans une cour de récréation, dépendent toutes de la bonne volonté des gens qui ressentent les effets de leur exécution. En tant que professionnel de l'informatique ou développeur de site Web communautaire, vous pouvez créer des outils qui aident à appliquer les règles, mais parfois le meilleur outil sera quelque chose qui provient de votre propre personnalité ou du sens humanitaire collectif. Un peu d'huile de coude peut être plus efficace que l'ingénierie technique. Ou peut-être, dans notre cas, de l'huile de coude et un poisson.

Betsy Aoki est responsable de programme communautaire pour Microsoft au sein de l'équipe Xbox. Ses gentilles névroses sont exprimées avec avidité dans ses messages électroniques, sur son blog et, espérons-le, sur XNA Framework.


 La vie secr&#232;te de Windows: Le paradoxe du syst&#232;me de fichiers
La vie secrète de Windows
Le paradoxe du système de fichiers
Raymond Chen

Si vous examinez votre disque dur, vous remarquerez probablement qu'un grand nombre de fichiers du système d'exploitation sont stockés dans le répertoire racine du lecteur de démarrage. Si vous regardez de plus près ces fichiers, vous verrez peut-être un thème : boot.ini, NTLDR et NTDETECT.COM sont des fichiers de démarrage critique et hiberfil.sys est le fichier de mise en veille prolongée. Ce sont tous des fichiers qui sont utilisés lors des premières étapes cruciales de démarrage du système d'exploitation ou, dans le cas de hiberfil.sys, de la reprise après une mise en veille prolongée, et qui doivent être placés à la racine du lecteur de démarrage. Pourquoi ne peut-on pas les placer ailleurs ?
Mon collègue Adrian Oney a fourni l'explication suivante : Pour pouvoir lire les fichiers de démarrage du disque, il vous faut un pilote du système de fichiers ; toutefois, celui-ci se trouve sur le disque, que vous ne pouvez pas lire tant que vous n'avez pas chargé le pilote du système de fichiers. Situation inextricable si l'en est !
C'est pour rompre ce cercle vicieux qu'un pilote du système de fichiers miniature est intégré aux fichiers de démarrage importants. Ce pilote miniature en sait juste assez pour localiser les fichiers dans le répertoire racine et les charger dans la mémoire. Ces fichiers font alors démarrer le système d'exploitation, et le vrai pilote du système de fichiers peut prendre le relais et rechercher des fichiers dans des endroits beaucoup plus sophistiqués tels que les sous-répertoires.
La mise en veille prolongée suit un schéma similaire. La mise en veille prolongée du système d'exploitation consiste à vider le contenu entier de la mémoire dans le fichier de mise en veille prolongée ; sa restauration nécessite de remettre ce fichier en mémoire et de faire comme si rien ne s'était passé. Encore une fois, c'est le problème de l'œuf ou la poule : Pour charger le fichier de mise en veille prolongée, vous avez besoin du pilote du système de fichiers, qui se situe dans le fichier de mise en veille prolongée. Si vous laissez le fichier de mise en veille prolongée dans le répertoire racine du lecteur de démarrage, le pilote du système de fichiers miniature peut être utilisé.
Si vous utilisiez les premières versions de MS-DOS®, vous devez connaître cette contrainte sur l'emplacement des fichiers de démarrage du système d'exploitation. L'ancienne commande SYS permettait de transformer une bête disquette en disquette de démarrage. Cependant, si vous l'exécutiez sur une disquette qui contenait déjà des données, il était probable que la conversion échouait car les premières versions de MS-DOS nécessitaient que les fichiers de démarrage se situent à des emplacements spécifiques sur la disquette pour que le secteur d'amorçage puisse les trouver. Les versions ultérieures de MS-DOS ont assoupli ces exigences en améliorant le chargeur de démarrage. Cependant, même avec la version améliorée, les fichiers système doivent toujours résider dans le répertoire racine.
Un jour, un client nous a demandé, « Puis-je placer le fichier de mise en veille prolongée dans un sous-répertoire » ? Après tout, pourquoi l'emplacement du fichier a-t-il tant d'importance ? Les ACL sur le fichier sont les mêmes, quel que soit son emplacement. Cet utilisateur voulait le placer sur un lecteur autre que le lecteur de démarrage et on lui avait indiqué que c'était impossible. Il ne voyait pas vraiment la raison de cette restriction et a donc tenté le tout pour le tout : si je peux au moins le déplacer vers un sous-répertoire, je pourrai ensuite créer un répertoire et en faire une jonction qui pointera vers l'emplacement où je souhaite placer le fichier de mise en veille prolongée. Ça y est : j'ai réussi à déplacer le fichier de mise en veille prolongée !
Bien sûr, le pilote du système de fichiers miniature ne comprend pas les points de montage, car les points de montage nécessitent de communiquer avec le service de gestion de disque, et au moment où le système démarre, l'ordinateur n'a même pas chargé le système d'exploitation, sans parler d'un service avancé qui sait mapper les lettres de lecteur sur les chemins ARC ! Et même si vous réussissiez à mettre ce service en exécution, vous devriez rechercher les pilotes des autres disques durs et charger les pilotes de système de fichiers correspondants.
Ce n'est qu'une question de temps avant qu'un utilisateur demande comment mettre le fichier de mise en veille prolongée sur une jonction DFS.

Raymond Chen, The Old New Thing, et son livre du même titre (Addison-Wesley, 2007) traitent de l’historique de Windows et de la programmation Win32. Son nom Web 2.0 est Raymond ou bien Chester.