 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

Vous vous préparez à adopter Exchange 2007 ? Vous êtes au bon endroit. Ce mois-ci, nous vous montrerons comment préparer la mise à niveau, comment écrire des scripts pour gérer Exchange à l'aide de l'environnement de ligne de commande Exchange Management Shell et comment obtenir le meilleur accès possible et une messagerie unifiée en combinant Outlook Web Access et Exchange 2007.

De plus, vous trouverez toutes les dernières améliorations dans Exchange Server 2007 et dans le client Outlook 2007, vous apprendrez comment combattre le courrier indésirable plus efficacement avec l'environnement Sender ID et à explorer la journalisation dans Exchange 2007 pour un meilleur contrôle et une meilleure conformité.

FONCTIONNALITÉS
Exchange Server 2007 Mise à niveau de votre infrastructure vers Exchange 2007

Que votre organisation soit petite ou grande, une transition en douceur vers Echange Server 2007 nécessitera une planification préalable. En adoptant la bonne stratégie, vous pouvez éviter toute interruption de service. Nous allons étudier les étapes que vous devrez suivre pour la réalisation de la mise à niveau.

Kate Follis Prendre le commandement de l'environnement de ligne de commande Exchange Management Shell

L'environnement de ligne de commande Exchange Management Shell offre aux administrateurs une interface puissance pour gérer tous les aspects d'Exchange Server 2007. Découvrez comment commencer à écrire des scripts, à intégrer des applications et à effectuer d'autres tâches de gestion puissantes à partir de la ligne de commande.

David Strome Exchange & Outlook : Plus efficaces ensemble

Ensemble, Exchange Server 2007 et Microsoft Office Outlook 2007 représentent un pas de géant dans la communication et la collaboration. Découvrez comment nous progressons au fur et à mesure vers une configuration simplifiée, des capacités de recherches améliorées, une messagerie unifiée et plus encore.

Michael Khalili Toujours joignable grâce à Exchange 2007

La communication est devenue plus puissante que jamais. Découvrez comment les capacités de la messagerie unifiée et de Outlook Web Access intégrées à Exchange Server 2007 vous permettent d'accéder à tous vos messages en un seul et même endroit depuis n'importe où.

Joshua Trupin Une journalisation plus puissante dans Exchange 2007

Exchange Server 2007 offre des capacités de journalisation beaucoup plus flexibles, en facilitant la surveillance des comptes d'utilisateurs spécifiques et en répondant aux exigences dans une grande organisation.

David Strome Lutter contre le courrier indésirable et le phishing grâce au Sender ID

L'authentification du courrier électronique construit sur SIDF (Sender ID Framework) est en train d'être largement adoptée, entraînant une avancée majeure dans la lutte contre les courriers indésirables et phishing. En fait, plus d'un tiers du volume mondial de courrier électronique est déjà authentifié et compatible avec SIDF. Voilà comment il fonctionne

Craig Spiezle et Alexander Nikolayev
COLONNES
De la part de l'éditeur

Pour un public plus large

Joshua Trupin Boîte à outils

De nouveaux produits pour les professionnels de l'informatique

Greg Steen Windows PowerShell

Des commandes simples Une administration puissante

Don Jones Post mortem

Migration à partir d'Exchange 5.5

Whitney Roberts 		Forum aux questions sur SQL

Éviter les redémarrages, installer plusieurs mises à jour et plus encore

Par Nancy Michell Hé, vous le Scripteur !

Où sont les porte-gobelets ?

Les scripteurs de Microsoft Surveillance de la sécurité

Déployer une PKI globalement fiable

John Morello Les fichiers du bureau

Les coulisses du format Windows Imaging

Wes Miller Windows Confidential

En attendant RunOnce

Raymond Chen


 Exchange Server&#160;2007: Mise &#224; niveau de votre infrastructure vers Exchange&#160;2007
Exchange Server 2007 Kate Follis

Mise à niveau de votre infrastructure vers Exchange 2007
Vue d'ensemble:
  • Nouveautés Exchange 2007
  • Préparation pour la mise à niveau
  • Déploiement basé sur les rôles
  • Topologie de routage des messages

J'ai par le passé donné un cours traitant de la migration d'Exchange Server version 5.5 vers Exchange 2000 Server. Le cours commençait à 8 h 30 le matin et finissait aux environs de 18 h 00 l'après-midi. Lorsque je quittais la salle de classe,
je n'avais plus d'énergie. Il y avait un gros travail de préparation rien que pour déplacer les ressources du répertoire et beaucoup de confusion sur NTDSNoMatch et sur la fiabilité de Windows NT® 4.0 qui de temps à autre refusait d'être fiable. En raison de contraintes de temps, nous nous sommes contentés d'effleurer l'administration d'Exchange 2000 Server, cependant il y avait toujours quelques étudiants impatients qui projetaient de quitter la salle de classe le vendredi soir et d'effectuer la migration le week-end. J'émettais des réserves face à cette pratique, en préconisant un temps de planification plus long, mais je doute qu'ils aient tenu compte de l'avertissement.
La transition entre Exchange 2000 Server ou Exchange Server 2003 et Exchange Server 2007 nécessite le même type de précaution - il vous faut consacrer du temps à la planification. Le processus de transition lui-même variera en fonction de l'organisation et de la complexité du déploiement existant, mais le processus de transition nécessitera cependant plusieurs phases. Une petite organisation peut gérer ces phases comme un seul projet, alors qu'une grande organisation peut décider d'introduire des rôles de serveur et de prendre en charge Exchange de façon progressive suivant un schéma de cohabitation pendant un certain temps. Le processus de bout en bout est conçu pour maintenir la fonctionnalité de la messagerie et sa stabilité tout au long de la période de transition. Dans cet article, je me concentrerai sur les étapes essentielles requises pour maintenir les flux de messages au sein de votre organisation lors de la mise à niveau vers Exchange Server 2007.

Remarques
La première exigence à prendre en compte est qu'Exchange Server 2007 doit être déployé sur du matériel 64 bits et ne prend pas en charge la mise à niveau in situ à partir d'une version antérieure d'Exchange. Vous devez utiliser la méthode de mise à niveau « swing » pour faire migrer vos services de messagerie existants vers Exchange 2007. L'organisation Exchange doit ensuite fonctionner en mode natif pour prendre en charge l'ajout des serveurs Exchange 2007 ; aussi, si votre organisation utilise actuellement Exchange 5.5, vous devrez effectuer une mise à niveau intermédiaire vers Exchange Server 2003 avant de passer à Exchange 2007.
Il existe quelques modifications importantes dans Exchange 2007 que vous devez prendre en considération lors de la planification de votre transition. Par exemple, Exchange 2007 introduit le déploiement basé sur les rôles, qui vous laisse choisir les services de messagerie que vous souhaitez fournir et déployer les rôles de serveur spécifiques à ces services. Vous pouvez déployer les rôles de serveur de façon individuelle sur du matériel dédié ou installer plusieurs rôles sur le même serveur physique, administrés comme des entités distinctes. Pour des explications concernant chacun de ces rôles, reportez-vous à la barre latérale « Rôles Exchange 2007 Server ».
Rôles du serveur Exchange Server 2007
Serveur de boîtes aux lettres Le rôle serveur de boîtes aux lettres permet de stocker les messages d'une organisation. Exchange 2007 peut prendre en charge jusqu'à 50 enregistrements par serveur. Ces enregistrements peuvent être déployés comme 50 groupes de stockage individuels ; vous pouvez aussi créer jusqu'à 50 enregistrements dans un seul groupe de stockage. Le rôle serveur de boîtes aux lettres est le seul rôle qui puisse être déployé sous la forme d'un cluster ; aussi, si vous comptez utiliser le clustering (la mise en grappes), vous devrez installer le serveur de boîtes aux lettres sur du matériel dédié.
Serveur d'accès au client Le rôle serveur d'accès au client Exchange remplace la fonctionnalité fournie par un serveur frontal. Il fournit un accès aux boîtes aux lettres pour les clients ayant accès à Exchange à l'aide de POP3, IMAP4, Outlook® Web Access (OWA), RPC sur HTTPS (connu désormais sous le nom d'Outlook Anywhere) et Exchange ActiveSync®.
Serveur de transport Hub Ce rôle fournit les services de transport de messages SMTP et MAPI pour l'organisation Exchange. Chaque message envoyé ou reçu par les utilisateurs de votre organisation est traité par un serveur de transport Hub. C'est ce qu'il vous faut, parce que cela garantit qu'aucun message ne peut contourner les règles basées sur les serveurs ou les stratégies de journalisation qui sont fournies par des agents qui se déclenchent en divers points du pipeline de transport.
Serveur de messagerie unifiée Ce rôle fournit un accès vocal à votre boîte aux lettres. Il s'intègre à votre passerelle IP/VoIP ou à votre IP-PBX pour permettre l'accès aux messages et aux éléments du calendrier par téléphone et vous permet de transcrire une réponse. Ce rôle est une nouveauté sur Exchange et ne peut interagir avec une version antérieure d'Exchange.
Serveur de transport Edge Le serveur de transport Edge est généralement déployé sur votre réseau de périmètre. Il permet le transport des messages SMTP entre l'organisation Exchange et Internet et offre un traitement anti-spam et antivirus grâce à des agents de transport. Vous pouvez désormais utiliser une seule technologie standardisée pour vos serveurs réseau organisationnel et de périmètre. Ce modèle d'interaction transparent simplifie l'administration et facilite l'intégration des serveurs de périmètre.

Examinez votre topologie
Par où allez-vous commencer ? Il est en fait difficile de savoir quelle direction prendre à moins que vous ne sachiez où vous vous trouvez. Prenez le temps d'évaluer votre environnement et de renseigner la topologie - non seulement votre environnement Exchange mais aussi votre environnement Active Directory®. Vous serez probablement content d'apprendre qu'Exchange 2007 s'est débarrassé du routage de l'état de liaison et de la topologie basée sur les groupes et les connecteurs de routage. Au lieu de cela, Exchange 2007 tire parti de l'investissement que votre organisation a déjà fait en concevant la topologie Active Directory. Par conséquent, toutes les données destinataire et de configuration Exchange sont stockées dans Active Directory, la topologie de routage est dérivée de la configuration du site Active Directory et tous les rôles de serveur utiliseront la notoriété du site pour découvrir les services exécutés sur d'autres rôles de serveur.
Assurez-vous que la topologie du site Active Directory actuelle tire véritablement parti du réseau matériel sous-jacent et que tous les sites Active Directory présentent des sous-réseaux associés, puis renseignez les sites Active Directory existants et les liaisons entre les sites IP. Renseignez également l'emplacement où tous vos serveurs Exchange 2003 résident physiquement et la structure du groupe de routage et du connecteur de groupe de routage.
L'étape la plus délicate du processus de transition est la suivante : passer d'une infrastructure de routage Exchange basée sur les groupes de routage à une infrastructure de routage basée sur les sites Active Directory. Pour une petite organisation, il s'agit généralement d'un processus simple. Mais une grande organisation avec plusieurs groupes de routage aura besoin de planifier correctement une période de transition pendant qu'Exchange 2003 et Exchange 2007 cohabitent. Ce que vous ne voulez surtout pas, c'est recevoir un message envoyé à votre boîte aux lettres Exchange 2003 par l'utilisateur d'Exchange 2007 via le hall acheminé par un groupe de routage à distance sur une connexion à bande passante basse.
Commençons par émettre quelques hypothèses concernant votre topologie actuelle :
  • L'organisation Exchange 2003 est exécutée en mode natif.
  • Vous disposez de plus d'un groupe de routage.
  • Vous disposez de plus d'un site Active Directory.
La figure 1 illustre une topologie Exchange et Active Directory. Rappelez-vous que plus vous apportez de détails à vos plans préliminaires, meilleure sera votre conception.
Figure 1 Une topologie Exchange et Active Directory
Figure 1 Une topologie Exchange et Active Directory (Cliquer sur l'image pour la réduire)
Figure 1 Une topologie Exchange et Active Directory
Figure 1 Une topologie Exchange et Active Directory (Cliquer sur l'image pour l'agrandir)

Comment Exchange 2007 utilise Active Directory
Lorsqu'un serveur Exchange 2007 démarre, il est marqué d'un attribut site qui aide d'autres serveurs Exchange 2007 à localiser les services fournis par ce serveur. Seul le serveur de transport Hub peut utiliser SMTP pour transporter un message au sein de l'organisation. Chaque site Active Directory contenant un serveur de boîtes aux lettres doit aussi contenir un serveur de transport Hub et, si les utilisateurs de boîtes aux lettres accèdent à leur boîte aux lettres à l'aide d'une quelconque méthode non-MAPI, chaque site doit aussi contenir un serveur d'accès client. À chaque fois qu'un message doit être traité pour distribution, il va passer par un serveur de transport Hub qui prendra une décision sur la façon dont le message doit être acheminé. Si le message est destiné à un serveur de boîtes aux lettres dans le même site Active Directory que le serveur de transport Hub, le serveur de transport Hub distribuera le message à la boîte aux lettres. Si le message est destiné à un serveur de boîtes aux lettres situé dans un site différent, le serveur de transport Hub relaiera directement le message à un serveur de transport Hub dans le site à distance.
Le serveur de transport Hub utilise les informations de coût de liaison entre les sites IP Active Directory pour calculer l'itinéraire le plus économique vers le site Active Directory sur lequel se situe la boîte aux lettres du destinataire. L'algorithme de sélection du chemin est très semblable à Exchange 2003, mais il est basé sur les coûts de liaison entre les sites IP plutôt que sur les coûts de connecteur de groupe de routage. En outre, le message ne s'arrête pas à chaque serveur de transport Hub le long du chemin. Il va directement de la source à la cible. Alors pourquoi s'embête t-il à calculer l'itinéraire le plus économique s'il compte sur le réseau IP pour transporter le message ? Il y a deux raisons à cela. L'une consiste à retarder la bifurcation des messages. Un message qui est envoyé à plus d'un destinataire peut avoir à être distribué à des serveurs de boîtes aux lettres dans plus d'un site Active Directory. Plutôt que de bifurquer ou de fractionner le message au niveau du premier serveur de transport Hub, Exchange 2007 ne fractionnera pas le message jusqu'à ce qu'il atteigne un embranchement sur le chemin de routage. Par conséquent, le message sera directement relayé à un serveur de transport Hub dans le site Active Directory qui représente le point de bifurcation. Ce comportement est connu sous le nom de sortance retardée.
L'itinéraire le plus économique est également utilisé pour déterminer l'endroit où le message doit être mis en file d'attente dans le cas où la cible ne peut être atteinte. Si un serveur de transport Hub du site Active Directory cible ne peut être atteint, le serveur de transport Hub expéditeur tentera alors d'effectuer la distribution vers un serveur de transport Hub du site Active Directory suivant le plus proche en fonction du chemin de routage. La distribution du message se poursuivra en suivant l'itinéraire le plus économique jusqu'à ce qu'il atteigne un site Active Directory sur lequel un serveur de transport Hub est disponible. Enfin, si aucun serveur de transport Hub n'est disponible le long du chemin qui mène au site Active Directory destinataire, le message est mis en file d'attente en local. Cette méthode met en file d'attente le message aussi près que possible du point de distribution, ce qui aide à rendre le diagnostic de pannes réseau plus déterministe. Ce comportement est connu sous le nom de mise en file d'attente au point de rupture.
Exchange 2003 fonctionne de façon complètement différente. Il calcule l'itinéraire le plus économique d'un groupe de routage à un autre en fonction des coûts affectés aux connecteurs de groupe de routage. Un serveur tête de pont dans chaque groupe de routage le long du chemin de routage recevra et relaiera le message. Si le connecteur suivant sur le chemin n'est pas disponible, une tentative est faite pour calculer un chemin alternatif. Les messages de mise à jour de l'état de liaison sont également communiqués à toute l'organisation Exchange pour avertir les autres serveurs Exchange que la connexion n'est pas disponible. Les serveurs pont tenteront de contourner le connecteur indisponible jusqu'à réception d'une notification d'état de liaison indiquant que la connexion fonctionne.
Le défi lorsqu'une grande organisation effectue sa transition consiste à maintenir le flux des messages pendant la période de cohabitation. Pour maintenir cette continuité lorsque Exchange 2007 est introduit dans l'environnement, tous les serveurs Exchange 2007 deviennent les membres d'un groupe de routage unique. Cela signifie que quel que soit le site Active Directory dans lequel le serveur Exchange 2007 se trouve, Exchange 2003 le verra comme appartenant à ce groupe de routage unique. Ceci vous permet d'établir un connecteur de groupe de routage entre ce groupe de routage et les groupes de routage d'Exchange 2003 de sorte qu'Exchange 2003 puisse savoir comment acheminer les messages vers Exchange 2007. Exchange 2007 utilisera également le connecteur de groupe de routage pour déterminer comment faire parvenir les messages à Exchange 2003. Cependant, Exchange 2007 préférera toujours acheminer un message via un autre serveur Exchange 2007 et ne s'appuiera jamais sur un groupe de routage Exchange 2003 pour atteindre un autre serveur Exchange 2007.

Introduction du premier serveur Exchange 2007 Server
Lorsque vous installerez le premier serveur Exchange 2007 dans l'organisation Exchange 2003, vous aurez besoin de sélectionner un serveur tête de pont Exchange 2003 avec lequel établir le premier connecteur de groupe de routage.
La figure 2 présente la façon dont le premier serveur Exchange 2007 affecte la topologie de l'organisation.
Figure 2 Installation du premier serveur Exchange 2007 Server
Figure 2 Installation du premier serveur Exchange 2007 Server (Cliquer sur l'image pour la réduire)
Figure 2 Installation du premier serveur Exchange 2007 Server
Figure 2 Installation du premier serveur Exchange 2007 Server (Cliquer sur l'image pour l'agrandir)
Jusque-là, tout va bien. Remarquez que le coût par défaut du connecteur de groupe de routage créé par Exchange 2007 est seulement de 1. Le courrier continue de circuler de façon habituelle via les serveurs Exchange 2003 et si un message est envoyé à un utilisateur sur le serveur Exchange 2007 à partir de tout serveur Exchange 2003, il circulera via le groupe de routage Acapulco. Lorsque le connecteur de groupe de routage a été créé, le serveur tête de pont Exchange 2003 que vous avez sélectionné est automatiquement devenu membre du groupe universel de sécurité ExchangeLegacyInterop et a reçu les autorisations adéquates pour envoyer et recevoir des messages électroniques en direction et à partir d'Exchange 2007. Vous devez également toujours utiliser New-RoutingGroupConnector dans l'environnement de ligne de commande Exchange Management Shell pour créer un connecteur de groupe de routage à chaque fois qu'un serveur Exchange 2007 est défini comme serveur source ou cible pour le connecteur. Vous pouvez également utiliser la cmdlet Set-RoutingGroupConnector pour modifier la configuration d'un connecteur de groupe de routage. Par exemple, il se peut que vous souhaitiez ajouter des serveurs source et cible au connecteur de groupe de routage initial à des fins de redondance. (Pour plus d'informations, reportez-vous à l'article de David Strome sur l'environnement de ligne de commande Exchange Management Shell dans le présent numéro de TechNet Magazine.)

Préparez-vous à déplacer quelques boîtes aux lettres
La prochaine étape consiste à déplacer quelques boîtes aux lettres des serveurs Exchange 2003 vers les serveurs Exchange 2007. Pour ce faire, utilisez la cmdlet Move-Mailbox. Cependant, avant de pouvoir mettre hors service les serveurs Exchange 2003, vous souhaiterez créer des connecteurs d'envoi et de réception sur le serveur Exchange 2007 afin de remplacer tout connecteur SMTP qui a été défini sur le serveur Exchange 2003 pour gérer le routage vers des espaces d'adressage SMTP externes.
Dans le diagramme qui suit, les ressources provenant du groupe de routage Acapulco ont été déplacées vers Exchange 2007. Le groupe de routage Acapulco peut être mis hors service, mais cela signifie que vous devez établir maintenant un connecteur de groupe de routage vers un groupe de routage différent. Dans la figure 3, j'ai configuré le connecteur de groupe de routage pour un serveur tête de pont du groupe de routage Miami North.
Figure 3 Configuration du connecteur de groupe de routage
Figure 3 Configuration du connecteur de groupe de routage (Cliquer sur l'image pour la réduire)
Figure 3 Configuration du connecteur de groupe de routage
Figure 3 Configuration du connecteur de groupe de routage (Cliquer sur l'image pour l'agrandir)
Passons maintenant à la transition du groupe de routage LA East vers Exchange 2007. C'est le type de situation où le maintien du routage se complique quelque peu. Dans la figure 4, Exchange 2007 a été installé sur le site de Los Angeles et un second groupe de routage a été mis hors service, mais aucun connecteur de groupe de routage n'a été créé.
Figure 4 Exchange 2007 installé sur le site de Los Angeles
Figure 4 Exchange 2007 installé sur le site de Los Angeles (Cliquer sur l'image pour la réduire)
Figure 4 Exchange 2007 installé sur le site de Los Angeles
Figure 4 Exchange 2007 installé sur le site de Los Angeles (Cliquer sur l'image pour l'agrandir)
À partir de maintenant, si un message est envoyé du serveur Exchange 2007 du site de Los Angeles au groupe de routage LA West du serveur Exchange 2003, il sera d'abord relayé à Acapulco, puis à Miami North, à Miami South et enfin à LA West. Si un message est envoyé à partir du groupe de routage LA West du serveur Exchange 2003 au serveur Exchange 2007 du site de Los Angeles, il sera d'abord transmis à Miami South, puis à Miami North, Acapulco et reviendra enfin à Los Angeles. Aïe !
Afin d'éviter cela, nous devrons ajouter un second connecteur de groupe de routage. La figure 5 montre l'ajout d'un connecteur de groupe de routage de LA West au serveur Exchange 2007 sur le site de Los Angeles. Remarque : Si vous souhaitez éviter un trop grand nombre de connecteurs de groupe de routage, assurez-vous que votre premier connecteur de groupe de routage est configuré dans un site hub Active Directory correctement connecté.
Figure 5 Routage plus efficace
Figure 5 Routage plus efficace (Cliquer sur l'image pour la réduire)
Figure 5 Routage plus efficace
Figure 5 Routage plus efficace (Cliquer sur l'image pour l'agrandir)
Ceci introduit un problème qui peut ne pas apparaître immédiatement. Il existe à présent plusieurs moyens dans et hors du groupe de routage Exchange 2007. Le groupe de routage Exchange 2007 n'utilisant pas l'état de liaison, il y a à présent une boucle de routage potentielle. Le serveur Exchange 2003 peut sélectionner un chemin alternatif pour contourner un connecteur indisponible, tandis qu'Exchange 2007 sélectionnera toujours l'itinéraire le plus économique.. Le moyen de contourner ce problème consiste à supprimer les messages mineurs de mise à jour de l'état de liaison, ce qui bloquera les messages d'état de liaison qui communiquent l'état d'un connecteur indisponible mais ne bloquera pas les messages d'état de liaison qui communiquent les changements de configuration. C'est important, car nous voulons que les serveurs Exchange 2003 connaissent les nouveaux connecteurs de groupe de routage, mais nous ne voulons pas qu'ils essaient de calculer un chemin alternatif. Au final, les serveurs Exchange 2003 présenteront le même comportement de mise en file d'attente au point de rupture que les serveurs Exchange 2007.
Dans la figure 6, nous avons fait passer davantage de ressources Exchange 2003 vers Exchange 2007. Les mises à jour de l'état de liaison ont été supprimées et nous avons pris soin d'établir des connecteurs de groupe de routage qui maintiennent un chemin de routage logique.
Figure 6 Déplacer davantage de ressources Exchange 2003 vers Exchange 2007
Figure 6 Déplacer davantage de ressources Exchange 2003 vers Exchange 2007 (Cliquer sur l'image pour la réduire)
Figure 6 Déplacer davantage de ressources Exchange 2003 vers Exchange 2007
Figure 6 Déplacer davantage de ressources Exchange 2003 vers Exchange 2007 (Cliquer sur l'image pour l'agrandir)
Cependant, un autre problème se pose. Nous avons créé des îlots d'état de liaison à Redmond et à Vancouver. Le courrier peut circuler correctement, même s'il passe par Miami, mais il n'existe pas de solution pour que Redmond et Miami communiquent les changements de configuration de l'état de liaison. Pour maintenir une table de routage en fonctionnement, vous devrez configurer un autre connecteur de groupe de routage entre Redmond et Vancouver. Vous pouvez ajuster le coût de ce connecteur de groupe de routage de sorte qu'il soit assez élevé pour empêcher Exchange 2003 d'acheminer via la connexion, tout en permettant toujours la communication des changements de configuration de l'état de liaison.
Avec une planification sérieuse, vous pouvez contourner les problèmes qui peuvent résulter du maintien de deux topologies de routage Exchange distinctes. Vous obtiendrez les résultats les plus satisfaisants en procédant à la transition d'un seul groupe de routage à la fois, puis en passant au suivant, jusqu'à ce que vous n'exécutiez plus que des serveurs Exchange 2007.
Jusqu'ici, je me suis concentrée sur les changements de routage dans Exchange 2007 et sur la façon dont ces changements affecteront votre transition. Vous devez garder d'autres éléments à l'esprit lorsque vous prévoyez de passer à Exchange 2007.
Les serveurs frontaux Exchange 2003 n'ont pas accès aux boîtes aux lettres Exchange 2007. Cependant, un serveur d'accès client Exchange 2007 n'a pas de problème pour vous connecter à votre boîte aux lettres Exchange 2003. Lorsque vous utiliserez le serveur d'accès client Exchange 2007, vous verrez simplement s'afficher la même version d'OWA que celle utilisée par le serveur de boîtes aux lettres sur lequel votre boîte aux lettres est stockée. Si vous déployez Exchange 2007 sur un matériel distinct, le serveur d'accès client devra être le premier rôle que vous introduirez sur un site Active Directory. Tout serveur frontal Exchange 2003 qui permet un accès Internet public à des boîtes aux lettres devra être remplacé par un serveur d'accès client Exchange 2007 avant de déplacer les boîtes aux lettres sur Exchange 2007.
J'ai indiqué précédemment que chaque site qui contient le rôle serveur de boîtes aux lettres requiert aussi le rôle serveur d'accès au client Exchange (si vous disposez de clients non-MAPI - et qui pourrait se passer d'OWA de nos jours ?) et un serveur de transport Hub. Ainsi, si vos rôles de serveur doivent se partager le matériel, veillez à inclure le serveur d'accès client à la sélection des rôles. Une installation type comprendra le rôle serveur de transport Hub, le rôle serveur d'accès client et le rôle serveur de boîtes aux lettres - tout ce dont vous avez besoin pour disposer d'un environnement Exchange totalement fonctionnel.
Un autre élément à prendre en considération pour le processus de transition est le moment où vous devez mettre à niveau votre application cliente (Outlook). Vous n'aurez pas la possibilité de tirer pleinement parti de toutes les fonctionnalités du serveur Exchange 2007 tant que vos clients n'auront pas été mis à niveau vers Outlook 2007. Ceci inclut des fonctionnalités améliorées de paramètres de message d'absence du bureau et de dossiers de boîtes aux lettres gérés.
Vous devrez également décider quand déployer le rôle serveur de transport Edge. Techniquement, vous pouvez remplacer le relais SMTP et l'hôte intelligent de votre réseau de périmètre courant par le serveur de transport Edge avant ou après avoir introduit d'autres rôles de serveur Exchange 2007. Cependant, si vous déployez le serveur de transport Edge en premier, l'ensemble des fonctionnalités sera limité car Exchange 2003 n'a pas la possibilité de répliquer les données destinataire et de configuration dont le serveur de transport Edge a besoin d'Active Directory vers ADAM (Active Directory en mode application).
Une fois que vous avez installé au moins un serveur de transport Hub, vous pouvez déployer le serveur de transport Edge dans le réseau de périmètre et abonner ensuite le serveur de transport Edge au site Active Directory sur lequel le serveur de transport Hub est installé. Le service EdgeSync sur le serveur de transport Hub répliquera un sous-ensemble des données destinataire d'Active Directory vers ADAM.
Ces données permettent au serveur de transport Edge de consulter les destinataires et de consolider la liste d'adresses électroniques sécurisées pour vous permettre de tirer pleinement parti des agents anti-spam exécutés sur le serveur de transport Edge. En outre, EdgeSync va créer les connecteurs d'envoi nécessaires au flux de messages de bout en bout en direction et en provenance de l'organisation Exchange et d'Internet. Ceci peut simplifier le processus de remplacement des connecteurs SMTP Exchange 2003 qui assure le routage vers des espaces d'adressages externes.
Aussi, si vous prenez un peu de temps pour planifier votre transition vers Exchange 2007, le cheminement vous semblera simple et sans difficulté.

Kate Follis est l'éditrice de contenu senior de l'équipe de rédaction Exchange 2007. Son groupe est spécialisé dans les rôles serveur de transport Edge et serveur de transport Hub. Avant de rejoindre Microsoft, Kate a travaillé comme formatrice certifiée Microsoft pendant plusieurs années ; elle enseignait les fonctionnalités d'Exchange et d'Active Directory.
© 2007 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.


 Exchange Server&#160;2007: Prendre le commandement avec Exchange Management Shell
Exchange Server 2007 David Strome

Prendre le commandement avec Exchange Management Shell
Vue d'ensemble:
  • Fonctionnement d'Exchange Management Shell
  • Utilisation des cmdlets
  • Cmdlets vs. commandes

Si vous administrez un environnement Exchange, je suis sûre que vous savez maintenant que le nouveau Exchange Server 2007 inclut une nouvelle interface à ligne de commande appelée Exchange Management Shell. Construite sur la technologie Microsoft Windows PowerShell, Exchange
Management Shell est une interface de gestion puissante que vous pouvez utiliser pour gérer tous les aspects d'Exchange Server 2007 depuis la ligne de commande. À partir de là, vous pouvez interagir directement avec Exchange Management Shell, écrire des scripts pour l'automatisation ou intégrer vos applications avec le moteur sous-jacent. La Figure 1 montre l'interpréteur de commandes en action.
Figure 1 Exchange Management Shell
Figure 1 Exchange Management Shell (Cliquer sur l'image pour la réduire)
Figure 1 Exchange Management Shell
Figure 1 Exchange Management Shell (Cliquer sur l'image pour l'agrandir)
La console de gestion Exchange ne se contente pas d'utiliser Exchange Management Shell pour effectuer des opérations, les assistants vous montrent quelles sont les commandes qu'ils effectuent. Copiez les commandes que les assistants créent et collez-les directement dans la ligne de commande ou dans un script. Après avoir modifié les paramètres à votre convenance, testez vos scripts ou vos commandes en utilisant le paramètre WhatIf, ce qui vous permet de voir les résultats avant d'effectuer des modifications de votre environnement.
Exchange Management Shell vous fournit une plate-forme de script solide et souple pour intégrer vos solutions de script courantes et vous permet de communiquer en mode natif avec des sources de données telles que COM et Windows Management Instrumentation (WMI). Basée sur .NET Framework, Exchange Management Shell utilise des cmdlets - la plus petite unité de fonctionnalité dans Exchange Management Shell - pour accepter et renvoyer des données structurées au lieu du texte brut. Nous allons nous intéresser de plus près aux cmdlets d'ici peu.

Composant logiciel enfichable Windows PowerShell
La première étape pour comprendre Exchange Management Shell est d'observer la relation qui la lie à Windows PowerShell™, une interface à ligne de commande toute nouvelle, puissante et souple basée sur .NET Framework. Elle associe les meilleures fonctionnalités de plusieurs autres interpréteurs de commandes et en ajoute également un grand nombre de nouvelles. Windows PowerShell est conçu pour héberger d'autres applications, un peu comme Microsoft Management Console (MMC) agit en tant qu'hôte pour les divers composants logiciels enfichables fournis avec les applications. Exchange Management Shell est le premier composant logiciel enfichable Windows PowerShell a être publié.
Les composants logiciels enfichables sont des collections de cmdlets utilisées pour administrer une application ou un composant majeur. Si vous ne les chargez pas en premier, vous ne pouvez pas les utiliser. Heureusement, il est très facile de démarrer le composant logiciel enfichable Exchange Management Shell. Mais avant d'en arriver là, il faut que je vous explique quelques concepts essentiels que vous aurez besoin de comprendre lors de la lecture de cet article et de l'utilisation d'Exchange Management Shell.
Cmdlets Les cmdlets ressemblent aux commandes intégrées d'autres interpréteurs de commandes, comme par exemple la commande dir que l'on trouve dans cmd.exe. Comme ces commandes d'usage courant, les cmdlets peuvent être appelées directement depuis la ligne de commande dans Exchange Management Shell et s'exécuter dans le contexte de l'interpréteur de commandes et non pas en tant que processus séparé. Contrairement aux commandes d'autres interpréteurs, les cmdlets ont des appellations verbe-nom descriptives. Le verbe décrit l'action que fait la cmdlet et le nom décrit le composant ou la fonction sur lequel ou laquelle on agit.
Vous n'avez pas à deviner que ce fait la cmdlet. Lorsque vous voyez la cmdlet Move-Mailbox, vous savez exactement ce pourquoi elle est utilisée.
Pour voir la différence entre les cmdlets et les commandes ordinaires, veuillez vous reporter à la barre latérale « Cmdlets vs. Commandes » extraite de la section .NET Framework 3.0 de Windows® SDK, qui se trouve sur windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx.
Paramètre Identité (Paramètre de Positionnement) Le paramètre Identité peut être utilisé avec la plupart des cmdlets associées à Exchange. Il vous permet d'accéder aux identificateurs uniques qui se réfèrent à un objet particulier dans Exchange Server 2007 afin que vous puissiez effectuer des actions sur un objet Exchange spécifique en utilisant la valeur unique la plus significative pour vous.
Le paramètre Identité est une collection de valeurs d'autres paramètres. Le caractère unique de ces valeurs est garanti dans cet ensemble d'objets. Vous pouvez spécifier les valeurs de ces autres paramètres, telles que Nom et DistinguishedName, qui peuvent également être générées par le système, tel qu'un GUID. Les paramètres supplémentaires utilisés, s'il y en a et la manière dont ils sont alimentés, dépendent de l'objet auquel vous vous référez.
Le paramètre Identité est également considéré comme un paramètre de positionnement - c'est-à-dire un paramètre qui vous permet de spécifier sa valeur sans spécifier son nom. Un paramètre est dit de positionnement si l'attribut Paramètre de positionnement est un nombre entier. Ce nombre entier indique la position de la ligne de commande où la cmdlet peut trouver la valeur du paramètre. Parce qu'Identité est un paramètre de positionnement qui réside à la position 0 qui est la première position, n'importe quelle valeur entrée à cette position sans un nom de paramètre est considérée comme étant une valeur de paramètre Identity. Cela réduit le nombre de frappes de touche lorsque vous tapez des commandes. Par exemple :
Get-Mailbox –Identity "Kim Akers"
effectue la même action que :
Get-Mailbox "Kim Akers"
Traitement « pipeline » Le traitement « pipeline » dans Exchange Management Shell correspond à l'action d'une cmdlet utilisant la sortie d'une autre cmdlet lorsqu'elle effectue une opération. Le traitement « pipeline » s'effectue en utilisant le symbole « | ». Tous les verbes dans le même ensemble nom-cmdlet peuvent utiliser des informations transmises en provenance d'une autre commande. Certains ensembles nom-cmdlet vous permettent également de transmettre des données par le pipeline à un autre ensemble nom-cmdlet.
L'utilisation du traitement par pipeline pour chaîner ensemble les actions de deux cmdlets ou plus vous permet de choisir des composants plus petits et de les convertir en éléments plus puissants. Par exemple, vous pouvez utiliser une cmdlet pour rassembler des données, transmettre ces données à une deuxième cmdlet pour filtrer les données vers un sous-ensemble, puis transmettre ces données à une troisième cmdlet pour agir sur le sous-ensemble seulement.

Démarrer Exchange Management Shell
La manière la plus simple de charger un interpréteur de commandes est de cliquer sur Démarrer, de cliquer sur Programmes, puis sur Microsoft Exchange Server 2007 et enfin de cliquer sur Exchange Management Shell.
La deuxième manière de charger le composant logiciel enfichable Exchange Management Shell est de le faire manuellement depuis une session Windows PowerShell. Cliquez sur Démarrer, puis sur Programmes et enfin sur Windows PowerShell. Après le démarrage, exécutez la commande suivante pour charger Exchange Management Shell:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Il existe quelques différences entre le chargement du composant logiciel enfichable Exchange Management Shell à l'aide de l'entrée de menu Programmes et son démarrage manuel à l'aide de la tcmdlet Add-PSSnapin. Lorsque vous utilisez l'entrée de menu Programmes, cela charge non seulement le composant logiciel enfichable Exchange Management Shell mais exécute également un script Windows PowerShell pour configurer un environnement d'administration Exchange personnalisé. Si vous voulez configurer un environnement administratif similaire après avoir chargé Exchange Management Shell manuellement, allez dans votre répertoire \bin Exchange de votre installation - par exemple, C:\Program Files\Microsoft\Exchange Server\Bin. Puis exécutez la commande suivante :
.\Exchange.ps1
Examinez le script Exchange.ps1 pour voir comment personnaliser l'environnement Windows PowerShell et l'adapter à vos besoins. Lorsque vous chargerez Exchange Management Shell, vous verrez quelque chose qui ressemble à la Figure 2.
Figure 2 Bannière de Bienvenue d'Exchange Management Shell
Figure 2 Bannière de Bienvenue d'Exchange Management Shell (Cliquer sur l'image pour la réduire)
Figure 2 Bannière de Bienvenue d'Exchange Management Shell
Figure 2 Bannière de Bienvenue d'Exchange Management Shell (Cliquer sur l'image pour l'agrandir)

Par où dois-je commencer ?
Le tableau de cmdlets de l'interpréteur de commandes étant si étendu, la cmdlet Get-Help et le fichier d'aide Exchange Server 2007 seront des aides précieuses. La section Opérations dans le fichier d'aide Exchange Server 2007 vous procure des dizaines de modes opératoires pour effectuer la plupart des tâches administratives.
Le fait de taper Get-Help seul affiche des informations d'aide générale sur la manière d'obtenir de l'aide. Pour obtenir de l'aide sur une cmdlet spécifique, tapez Get-Help suivi de la cmdlet sur laquelle vous voulez des informations. Vous pouvez contrôler quelles sont les informations exposées en utilisant les paramètres Détail, Tout et Exemple. Il vous suffit de les ajouter à la fin de la commande. Par exemple, le nom de cmdlet Get-Help (– Tout) renvoie la totalité des sections d'aide disponibles pour une cmdlet.
Si vous voulez récupérer des informations concernant un ou plusieurs paramètres spécifiques sur une cmdlet, vous pouvez utiliser le paramètre Paramètres avec Get-Help. Ainsi, si vous voulez visualiser tous les paramètres et leur description sur la cmdlet Set-Mailbox qui contient le mot « quota », utilisez la commande :
Get-Help Set-Mailbox –Parameter *quota*
Il se peut que vous vouliez visualiser une liste de cmdlets qui gère un rôle de serveur spécifique ou une fonctionnalité de composant ou qui affecte les objets sur un certaine gamme de fonctionnalités. La cmdlet Get-Help vous permet de faire ça avec trois paramètres. Rôle, Composant et Fonctionnalité. Lorsque vous utilisez la cmdlet Get-Help avec ces paramètres, vous devez inclure les valeurs que vous spécifiez avec ces trois paramètres dans des caractères génériques « * ». Ci-dessous des exemples qui montrent comment appeler Get-Help avec chaque paramètre.
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Pour plus d'informations, le sujet « Getting Help » dans le fichier d'aide Exchange Server 2007 répertorie toutes les valeurs de rôle, de composant et de fonctionnalité qui peuvent être utilisées.

Formater la sortie de commande
Par défaut, lorsque la sortie est affichée à l'écran, Exchange Management Shell affiche uniquement un sous-ensemble des propriétés disponibles pour chaque objet. Cependant, vous pouvez facilement accéder à toutes les propriétés en transférant la sortie d'une commande aux trois cmdlets de formatage suivantes : Format-List, Format-Table et Format-Wide. Vous utiliserez probablement Format-List et Format-Table de manière régulière, je vais donc vous en parler plus en détail.
La cmdlet Format-List accepte une entrée du pipeline et génère en sortie une liste en colonnes verticales de toutes les propriétés spécifiées de chaque objet. Vous pouvez spécifier les propriétés que vous voulez afficher en utilisant le paramètre Propriété (bien que le paramètre Propriété soit un paramètre de positionnement, ce qui signifie que vous n'avez à spécifier que les valeurs et non le nom du paramètre). Si la cmdlet Format-List est appelée sans aucun paramètre spécifié, toutes les propriétés sont générées en sortie. Cette cmdlet encapsule les lignes au lieu de les tronquer. L'une des meilleures utilisations de Format-List est de remplacer la sortie par défaut d'une cmdlet afin de pouvoir récupérer des informations supplémentaires ou mieux ciblées. Par exemple :
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
La figure 3 illustre la sortie de cette commande.
Figure 3 Exemple de sortie Format-List
Figure 3 Exemple de sortie Format-List (Cliquer sur l'image pour la réduire)
Figure 3 Exemple de sortie Format-List
Figure 3 Exemple de sortie Format-List (Cliquer sur l'image pour l'agrandir)
La cmdlet Format-Table vous permet d'afficher des éléments dans un format de tableau avec des en-têtes et des colonnes de données de propriété. Par défaut, de nombreuses cmdlets, telles que Get-Mailbox et Get-JournalRule, utilisent le format de tableau en sortie. Les paramètres de la cmdlet Format-Table incluent les paramètres Propriétés et Grouper par. Ceux-ci fonctionnent exactement comme avec la cmdlet Format-List. Pour que de longues lignes d'informations de propriétés s'affichent complètement au lieu d'être tronquées en fin de ligne, utilisez le paramètre Encapsuler, comme suit :
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
Voir la Figure 4 pour visualiser la sortie
Figure 4 Exemple de sortie Format-Table
Figure 4 Exemple de sortie Format-Table (Cliquer sur l'image pour la réduire)
Figure 4 Exemple de sortie Format-Table
Figure 4 Exemple de sortie Format-Table (Cliquer sur l'image pour l'agrandir)
Si vous incluez un caractère générique, vous pouvez faire correspondre plusieurs propriétés sans avoir à taper chaque nom de propriété individuellement. Par exemple, cela renvoie toutes les propriétés qui commencent par une adresse électronique.
Get-Mailbox | Format-List Email*

Mise en pratique
Maintenant que vous avez acquis quelques commandes de base, pourquoi ne pas mettre en pratique les exemples suivants. Ils illustreront la puissance et la souplesse d'Exchange Management Shell et vous feront mettre la main à la pâte.
La première commande que vous allez essayer, crée 10 utilisateurs, appelés Utilisateur1 jusqu'à Utilisateur10 :
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Examinons ses différentes parties. La commande 1.0 génère les nombres entiers de 1 à 10 et les transmet par le pipeline à chaque cmdlet ForEach. La cmdlet ForEach agit sur chaque objet à sa réception et exécute les commandes entre accolades { } pour chaque objet. La commande Net User crée un nouvel utilisateur de domaine et la cmdlet Enable-Mailbox crée une nouvelle boîte aux lettres dans la « Base de données de boîte aux lettres » sur le serveur local. Le point-virgule sépare les deux commandes afin qu'elles puissent être placées sur la même ligne de commande. La variable $_ est une variable spéciale qui contient la valeur de l'objet qui se trouve dans le pipeline. Dans cet exemple, la variable $_ contient le nombre entier qui se trouve dans le pipeline.
L'exemple suivant vous permettra de visualiser les boîtes aux lettres qui résident sur le serveur MBX et de renvoyer le Nom, la base de données de boîte aux lettres et les propriétés de quota de chaque boîte aux lettres.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
La cmdlet Get-Mailbox renvoie chaque boîte aux lettres spécifiée avec le paramètre Serveur, puis transfère la sortie de chaque objet de boîte aux lettres à la cmdlet Format-Table. Par défaut, la cmdlet Format-Table affiche toutes les propriétés renvoyées par une cmdlet à moins que vous ne spécifiiez les propriétés à afficher. Ici seules les propriétés Nom et Base de données, comme toutes les propriétés qui contiennent la chaîne « quota » sont requises. La Figure 5 montre à quoi pourrait ressembler cette sortie.
Figure 5 Sortie de commande Get-Mailbox
Figure 5 Sortie de commande Get-Mailbox (Cliquer sur l'image pour la réduire)
Figure 5 Sortie de commande Get-Mailbox
Figure 5 Sortie de commande Get-Mailbox (Cliquer sur l'image pour l'agrandir)
Dans cet exemple, vous définirez la limite de quota d'envoi à 600 Mo pour tous les utilisateurs pouvant utiliser la messagerie dans l'organisation, qui ont le terme de « Manager » (Responsable) dans leur titre.
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Auto-exécutée, la cmdlet Get-User renvoie tous les objets utilisateurs de Active Directory, y compris les utilisateurs non autorisés à utiliser la messagerie électronique. Afin de récupérer un ensemble d'objets utilisateurs que la cmdlet Set-Mailbox peut utiliser, il vous faut donner l'instruction à la cmdlet Get-User de ne renvoyer que les objets utilisateurs Active Directory qui sont des utilisateurs autorisés à utiliser la messagerie. Le paramètre RecipientTypeDetails vous permet de spécifier le type de destinataire Active Directory, UserMailbox dans le cas présent. Ensuite, il vous faut récupérer un ensemble d'utilisateurs autorisés à utiliser la messagerie qui sont des managers. Dans le présent exemple, la propriété Title de chaque objet utilisateur Active Directory est renseignée. Vous pouvez utiliser cette valeur pour déterminer les utilisateurs qui sont des managers à l'aide du paramètre Filter qui donne l'instruction au serveur de ne renvoyer que les objets Active Directory correspondant à vos critères. Cette opération s'appelle le filtrage côté serveur. Une fois que vous avez défini un ensemble d'objets, celui-ci est transmis à la cmdlet Set-Mailbox, qui définit alors la propriété ProhibitSendQuota de chaque boîte aux lettres à 600 Mo.
Nous testerons ensuite le résultat d'une commande de suppression de toutes les boîtes aux lettres qui sont membres d'un groupe de distribution. Voici la commande :
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
La première cmdlet récupère les objets destinataires qui sont membres du groupe de distribution « Fourth Year Students ». Puis seuls les objets destinataires correspondant au RecipientType de « UserMailbox » sont transmis à la cmdlet Remove-Mailbox. Au lieu de supprimer les boîtes aux lettres, la cmdlet Remove-Mailbox affichera l'action qu'elle aurait effectuée et les objets sur lesquels elle aurait agi. La cmdlet Get-DistributionGroupMember récupère une liste de tous les objets destinataires qui sont membres du groupe de distribution « Fourth Year Students ». Cependant, comme la cmdlet peut uniquement fonctionner avec des utilisateurs autorisés à utiliser la messagerie, il vous faut exclure tous les types de destinataires sauf « UserMailbox ». Contrairement à d'autres cmdlets, la cmdlet Get-DistributionGroupMember n'a pas la cmdlet Filter, ce qui signifie qu'elle ne peut pas effectuer le filtrage côté serveur. Pour les cmdlets qui ne peuvent pas effectuer un filtrage côté serveur (parce qu'elles n'y voient aucun avantage en termes de performance), vous pouvez utiliser la cmdlet Where pour effectuer le filtrage côté client, ce qui récupère tous les objets et effectue le filtrage sur la machine cliente locale. La cmdlet Where ne transmet que les objets qui répondent aux critères que vous spécifiez. Les objets qui ont un RecipientType de « UserMailbox » sont envoyés à la cmdlet Remove-Mailbox. Cette cmdlet supprime l'objet utilisateur Active Directory et marque la boîte aux lettres pour élimination.. Lorsque le paramètre WhatIf est utilisé, la cmdlet Remove-Mailbox affiche un texte similaire à ce qui suit :
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
Si vous êtes persuadé que la commande va effectuer les actions que vous voulez, exécutez la commande à nouveau sans WhatIf. Pour certaines cmdlets, telles que celles qui comportent le verbe Remove, l'interpréteur de commandes demandera automatiquement confirmation avant toute modification. Vous avez le choix d'examiner chaque modification, d'indiquer à l'interpréteur de commandes de ne pas demander confirmation une nouvelle fois ou d'annuler tout traitement ultérieur. Pour les cmdlets qui n'implémentent pas de confirmation automatiquement, vous pouvez forcer la confirmation en utilisant le paramètre Confirm.

Conclusion
Maintenant que vous avez eu un avant-goût de la cmdlet, vous êtes prêt à faire vos expériences par vous-même et à constater à quel point Exchange Management Shell et Microsoft Windows PowerShell vous seront utiles pour vos futures tâches de gestion systèmes. Pour plus d'informations sur ces deux sujets, consultez les ressources suivantes. Concernant Management Shell, veuillez vous reporter au fichier d'aide d'Exchange Server 2007 sur go.microsoft.com/fwlink/?LinkId=69434, au centre de script Windows Powershell sur go.microsoft.com/fwlink/?LinkId=71134 et au blog de l'équipe Exchange sur msexchangeteam.com.

David Strome est rédacteur technique auprès du groupe Exchange User Education chez Microsoft depuis à peine plus d'un an. Avant de rejoindre Microsoft à Redmond dans l'État de Washington, David a passé une dizaine d'années à concevoir, implémenter et administrer des installations Exchange Server dans diverses entreprises basées en Colombie britannique, au Canada.. Vous pouvez le contacter à l'adresse suivante : technet@getwired.com.


 Exchange Server&#160;2007: Exchange &amp; Outlook&#160;: Plus efficaces ensemble
Exchange Server 2007 Michael Khalili

Exchange & Outlook : Plus efficaces ensemble
Vue d'ensemble:
  • Installation simplifiée
  • Intégrer la voix, le fax et le courrier électronique
  • Dossiers gérés pour conformité

Pendant un certain nombre d'années, Microsoft Exchange Server et Outlook ont envoyé des courriers électroniques fiables par millions, aidé des gens à collaborer et à gérer leurs calendriers et facilité l'organisation des contacts. Certains pourraient se demander ce que ces deux outils associés pourraient faire de mieux. En fait, Exchange Server 2007
et Microsoft Office Outlook 2007 sont à la veille d'être mis à la disposition du public et constituent à eux deux un saut quantique dans le domaine de la communication et de la collaboration.
Les améliorations proposées par Exchange Server 2007 et Office Outlook® 2007 sont visibles dès lors que vous démarrez le client Outlook. Dans les versions précédentes, Outlook s'attendait à ce que vous sachiez le nom de votre serveur de boîtes aux lettres Exchange, ce qui bloquait un grand nombre d'utilisateurs. Il en résultait des appels fréquents au support technique ou des scripts d'initialisation compliqués, lesquels augmentaient le coût et la complexité d'exécution d'un environnement de messagerie efficace. Aujourd'hui, avec le service Web Exchange Autodiscover, Outlook peut configurer automatiquement le compte si le client est joint au domaine. Si le client n'est pas joint au domaine, l'utilisateur n'aura à entrer qu'un nom, une adresse électronique et un mot de passe. Outlook et Exchange se chargeront du reste (voir Figure 1).
Figure 1 Installation de comptes
Figure 1 Installation de comptes (Cliquer sur l'image pour la réduire)
Figure 1 Installation de comptes
Figure 1 Installation de comptes (Cliquer sur l'image pour l'agrandir)
De même, au bon vieux temps (pas si vieux que ça), les utilisateurs n'installaient pas seulement Outlook pour l'utilisation initiale mais étaient également responsables de la reconfiguration d'Outlook à chaque fois qu'on les déplaçait vers un serveur de courrier électronique différent. Même si un courrier avertissait les utilisateurs d'une migration de boîte aux lettres imminente, les bêtes de travail ne prêtaient que peu d'attention à tout ce qui avait à voir avec la migration en question - jusqu'à ce qu'ils se retrouvent un matin devant l'impossibilité d'accéder à Outlook. À ce stade, s'ensuivait un autre appel au support technique. Les services Web Autodiscover peuvent aussi résoudre cela. Lorsqu'un utilisateur est déplacé d'un serveur de boîtes aux lettres vers un autre, Outlook reconnaît que l'ancienne configuration n'est plus valide, questionne le service Web Autodiscover une nouvelle fois, puis reconfigure le client pour la nouvelle boîte aux lettres. Ce processus est transparent pour l'utilisateur final.

Réinventer le calendrier
Par le passé, la plus grande partie de la logique calendaire résidait dans Outlook. Chaque mise à jour de réunion était considérée comme une invitation à une réunion séparée, ce qui signifiait que les notifications pouvaient être acceptées dans le mauvais ordre. Si deux mises à jour de réunion étaient envoyées rapidement l'une après l'autre et qu'un destinataire acceptait la seconde avant la première, il pouvait avoir des informations obsolètes sur son agenda. De plus, accéder aux informations Outlook depuis un Smartphone ou un PDA pouvait entraîner des informations de disponibilité différées suivant la méthode utilisée par les utilisateurs pour afficher les données.
La solution était de déplacer toute la logique calendaire depuis le client Outlook vers Exchange Server 2007. Lorsqu'une demande de réunion est reçue par le serveur, la réunion est automatiquement placée sur le calendrier comme provisoire jusqu'à ce que l'utilisateur choisisse d'accepter ou de refuser le rendez-vous. Si une modification de l'heure ou du lieu de la réunion est reçue, la réunion sera automatiquement mise à jour et l'ancienne invitation marquée comme obsolète afin que les utilisateurs ne l'acceptent pas par erreur. Cette logique est uniforme pour tous les clients - Office Outlook, Outlook Web Access, Outlook Mobile ou tout autre client tiers - de sorte que seules les réunions valides et à la dernière mise à jour sont visibles.
Grâce à la fiabilité et à la précision du calendrier, il devient possible de proposer un nouvel ensemble d'outils qui peut rendre les utilisateurs plus productifs. Par le passé, il n'était pas aisé de mettre en place des réunions auxquelles de nombreux employés à l'emploi du temps chargé pouvaient participer. Les utilisateurs devaient trouver manuellement des plages horaires vides pour les réunions, parcourant les informations de journées entières pour trouver un horaire adapté à tous les participants. Désormais, l'Assistant Planification Outlook 2007 (voir Figure 2) trouvera le meilleur horaire pour chacun. Après avoir entré le nom des participants obligatoires et facultatifs ainsi que les salles ou ressources souhaitées, l'Assistant Planification affiche une vue des jours les plus adaptés pour une réunion, codés par couleur. Une fois qu'un jour a été sélectionné, la même méthode est utilisée pour trouver le meilleur horaire du jour en question.
Figure 2 Assistant Planification
Figure 2 Assistant Planification (Cliquer sur l'image pour la réduire)
Figure 2 Assistant Planification
Figure 2 Assistant Planification (Cliquer sur l'image pour l'agrandir)
L'Assistant Planification accorde d'abord la priorité aux participants obligatoires, puis aux participants facultatifs et enfin aux salles et aux ressources pour déterminer l'heure optimale de la réunion. L'Assistant Planification facilite également la gestion des problèmes tels que la flexibilité des heures de travail et les différents fuseaux horaires. Les utilisateurs peuvent fixer leurs propres heures de travail, en définissant leur heure d'arrivée chaque matin et leur heure de départ chaque soir. Donc, un « lève-tard » qui n'arrive pas avant 9 ou 10 heures du matin peut définir que son travail démarre à cette heure-là. Lorsque d'autres personnes ont besoin de programmer une réunion, un horaire plus matinal (8 heures par exemple) ne sera pas proposé. Si deux groupes appartenant à deux fuseaux horaires différents - l'un à Londres et l'autre à Los Angeles par exemple - doivent se rencontrer, seuls les horaires qui se chevauchent sur leurs jours de travail seront proposés. Les Londoniens se réuniront en fin d'après-midi tandis que les « Angelinos » se réuniront à la première heure de la matinée, afin d'éviter une réunion à 2 heures du matin, qu'il s'agisse des uns ou des autres.

Trouver l'aiguille dans la botte de foin
Au fil des années, le nombre de courriers électroniques arrivant en moyenne dans la boîte aux lettres de l'utilisateur n'a cessé de croître à un rythme alarmant. Alors qu'une boîte aux lettres professionnelle de base ne peut contenir que quelques centaines de messages environ, certaines personnes en reçoivent désormais autant en un seul jour. Être enseveli sous cette avalanche de messages représente une multitude d'informations critique pour les opérations de n'importe quelle entreprise. Trouver les bonnes informations au moment où vous en avez besoin peut s'avérer être un gros problème.
Les possibilités de recherche d'Office Outlook 2007 et d'Exchange Server 2007 ont été nettement améliorées comparées aux versions précédentes. Que l'utilisateur soit en mode mis en cache ou en ligne, les mêmes algorithmes de recherche sont appliqués au message. En mode en ligne, la demande de recherche est envoyée au serveur Exchange, où la recherche est exécutée. L'Indexeur de contenu Exchange, 35 fois plus rapide que celui d'Exchange Server 2003, est utilisé pour s'assurer que les messages peuvent être trouvés et récupérés rapidement. En mode mis en cache, Outlook utilise la Recherche instantanée, basée sur Windows® Desktop Search 3.0, consolidant les moteurs d'indexation et réduisant le temps processeur. La recherche peut être effectuée pour du texte trouvé dans l'objet, dans le corps du texte, vers et depuis des champs ou même dans les pièces jointes, comme illustré dans la Figure 3.
Figure 3 Nouvelles techniques de recherche pour ce type de message électronique important
Figure 3 Nouvelles techniques de recherche pour ce type de message électronique important (Cliquer sur l'image pour la réduire)
Figure 3 Nouvelles techniques de recherche pour ce type de message électronique important
Figure 3 Nouvelles techniques de recherche pour ce type de message électronique important (Cliquer sur l'image pour l'agrandir)

Accès depuis n'importe où avec la messagerie unifiée
La messagerie unifiée Exchange, qui est un composant intégré d'Exchange Server 2007, met tous les types de communications professionnelles dans une seule boîte aux lettres, y compris les courriers électroniques, les messages vocaux et les fax. Dans les systèmes traditionnels, les messages vocaux sont accessibles par téléphone, les courriers électroniques via l'ordinateur et les fax via un télécopieur dédié à cet usage. La messagerie unifiée Exchange permet à l'utilisateur de choisir le client le mieux adapté à ses besoins à un moment et à un endroit donnés. Dans Outlook, les messages vocaux et les fax apparaissent dans la boîte de réception juste à côté des messages électroniques. Le message vocal, lorsqu'il est sélectionné, contient un lecteur intégré pour pouvoir écouter directement le message à partir du volet de lecture (voir Figure 4).
Figure 4 Lecture de messages de la messagerie vocale via Outlook
Figure 4 Lecture de messages de la messagerie vocale via Outlook (Cliquer sur l'image pour la réduire)
Figure 4 Lecture de messages de la messagerie vocale via Outlook
Figure 4 Lecture de messages de la messagerie vocale via Outlook (Cliquer sur l'image pour l'agrandir)
Outlook permet également aux messages d'être traités en contexte. En général, lorsque vous écoutez un message vocal, vous prenez quelques notes sur une feuille de papier. Ces notes ne sont pas associées au message et peuvent se perdre - ce qui est loin d'être un modèle de communication efficace. Grâce à la messagerie unifiée Exchange, les notes peuvent être directement prises dans Outlook. Elles sont conservées avec le message et seront indexées en tant que texte pouvant faire l'objet d'une recherche, ce qui garantit que les notes s'afficheront toujours dans le contexte de ce message vocal. Ainsi, elles peuvent être rapidement retrouvées à l'aide du système de recherche amélioré d'Exchange Server 2007 et d'Office Outlook 2007.
Outlook peut également gérer de nombreuses options de messagerie vocale (voir Figure 5), y compris celle de permettre aux utilisateurs de modifier leur numéro d'identification personnel (PIN) à partir du client. (La réinitialisation du code PIN est une source majeure d'appels au support technique pour les systèmes de messagerie vocale.) À partir de leurs options Outlook, les utilisateurs peuvent obtenir un nouveau code PIN qu'ils génèrent et reçoivent sur leur adresse électronique. Ce code PIN leur donne un accès à usage unique à Outlook Voice Access, l'interface téléphonique de messagerie unifiée Exchange, il leur est ensuite demandé de modifier leur code PIN.
Figure 5 La messagerie unifiée contient une option Pin Reset (réinitialisation du code PIN)
Figure 5 La messagerie unifiée contient une option Pin Reset (réinitialisation du code PIN) (Cliquer sur l'image pour la réduire)
Figure 5 La messagerie unifiée contient une option Pin Reset (réinitialisation du code PIN)
Figure 5 La messagerie unifiée contient une option Pin Reset (réinitialisation du code PIN) (Cliquer sur l'image pour l'agrandir)

Sécuriser et protéger
Aujourd'hui, les organisations doivent faire face à de nombreuses menaces sur leur environnement de messagerie. Outlook et Exchange collaborent pour lutter contre ces menaces. Le courrier indésirable ne constitue que l'une de ces menaces et Office Outlook 2007 introduit la prise en charge des cachets électroniques Outlook, une nouvelle façon de lutter contre le spam. Outlook applique une petite « moulinette » de calcul sur le message sortant et ajoute la réponse de ce calcul au message. Exchange vérifie alors les résultats. Alors que ces « moulinettes » de calcul consomment un temps processeur relativement faible lorsqu'elles sont effectuées une seule fois, comme c'est typiquement le cas avec le courrier légitime, si la machine d'un expéditeur de courriers indésirables devait créer ces « moulinettes » pour du courrier électronique de masse, la contrainte sur leur machine serait extrême. Par conséquent, un message comportant un cachet électronique Outlook a bien plus de chances d'être légitime qu'un message qui n'en comporte pas et Exchange prend ceci en considération lorsqu'il détermine la validité de chaque message électronique.
En plus des menaces déjà anciennes comme le courrier indésirable, de nouveaux systèmes de réglementation sont en train de changer les exigences applicables aux systèmes de messagerie. Les réglementations telles que Sarbanes-Oxley, HIPPA et Basel II édictent des règles strictes pour la rétention ou la destruction des enregistrements. Afin de répondre à ce besoin naissant, Exchange et Outlook introduisent les Dossiers gérés. Ces dossiers sont configurés par un administrateur pour les messages d'un type particulier. Dans Outlook, l'utilisateur final voit ces dossiers avec une description de ce qui devrait être stocké dans le dossier (voir Figure 6). Les messages peuvent également être envoyés automatiquement dans un dossier en particulier en se servant des règles de transport Exchange. Une fois inclus dans un Dossier géré donné, les messages conservent les stratégies d'archivage, de rétention et d'expiration de ce dossier et seront automatiquement traités de manière à être en cohérence avec la stratégie de l'organisation.
Figure 6 Les Dossiers gérés renforcent les règles de conformité pour le courrier électronique
Figure 6 Les Dossiers gérés renforcent les règles de conformité pour le courrier électronique (Cliquer sur l'image pour la réduire)
Figure 6 Les Dossiers gérés renforcent les règles de conformité pour le courrier électronique
Figure 6 Les Dossiers gérés renforcent les règles de conformité pour le courrier électronique (Cliquer sur l'image pour l'agrandir)
Malgré tous les efforts déployés, des violations de conformité se produisent. Dans ces cas, il est impératif de procéder à une identification et à une réparation rapides. Le mode de recherche rapide proposé par Exchange devient un élément clé pour que les responsables de la conformité trouvent les messages susceptibles de constituer des indices d'identification de violation de conformité. Les recherches peuvent être effectuées sur plusieurs boîtes aux lettres afin de repérer et de remédier à ces violations.

Un environnement plus gérable
Ensemble, Exchange Server 2007 et Office Outlook 2007 offrent un système de messagerie très nettement amélioré par rapport aux versions précédentes. Ils placent toutes vos communications professionnelles vitales en un seul emplacement, ce qui permet de les retrouver et de les configurer facilement et les rend compatibles et conformes dès qu'ils arrivent. Ensemble, ils ont fait passer la collaboration et la communication au niveau supérieur.

Michael Khalili est chef de produit d'Exchange Server, responsable de l'Accès client et de la Messagerie unifiée. Il est, entre autres, responsable de l'intégration d'Outlook et d'Exchange.


 Exchange Server&#160;2007: Toujours joignable gr&#226;ce &#224; Exchange&#160;2007
Exchange Server 2007 Joshua Trupin

Toujours joignable grâce à Exchange 2007
Vue d'ensemble:
  • Améliorations de Outlook Web Access
  • Messagerie unifiée dans Exchange Server 2007
  • Sécurité avec ISA Server 2006

Il y a des années de cela, la communication en ligne était rudimentaire. Le courrier électronique était envoyé via POP3 et SMTP. C'était assez simple. Évidemment, le changement s'impose. Aujourd’hui, les organisations doivent permettre aux employés
de travailler quand et comme ils le souhaitent avec toute la souplesse nécessaire et ils doivent pouvoir le faire en toute sécurité. Microsoft® Exchange Server 2007 comporte plusieurs fonctionnalités intégrées, notamment Microsoft Office Outlook® Web Access (OWA) et la messagerie unifiée. Examinons ces deux composants clés d'Exchange Server 2007 et voyons dans quelle mesure ils devancent les versions précédentes pour créer une plate-forme de communication plus puissante pour les entreprises d'aujourd'hui.
OWA est partie intégrante d'Exchange depuis la version 5.5. À vrai dire, les premières versions étaient un peu maladroites. Elles constituaient une réponse au problème d'accès à une boîte aux lettres Exchange via un navigateur Web, mais sans trop recourir à la fonctionnalité proposée par Outlook.
Avec l'OWA amélioré introduit dans Exchange Server 2003, les choses ont commencé à s'arranger pour les utilisateurs finaux. L'utilisation d'un navigateur est devenue plus naturelle, presque comme si vous étiez en train de travailler dans un programme client. OWA pour Exchange Server 2007 va même encore plus loin avec une réécriture complète des versions précédentes permettant d'adopter d'autres innovations techniques récentes telles que RPC sur HTTP et ASP.NET 2.0.
Par exemple, regardez comment OWA est restitué. Les versions précédentes d'OWA étaient restituées par le serveur de boîtes aux lettres, pendant le processus de stockage. Cela ajoutait une charge supplémentaire au serveur de boîtes aux lettres, pouvant ainsi provoquer des lenteurs dans le système. Outlook Web Access 2007, à l'inverse, restitue les données via ASP.NET, sur des serveurs d'accès client (CAS). Le traitement des pages est ainsi déplacé du serveur de boîtes aux lettres, ce qui améliore les performances.
Le travail réalisé sur le serveur frontal a également été modifié. Dans les versions précédentes d'Exchange, les requêtes OWA HTTP étaient transmises via un proxy au serveur de boîtes aux lettres approprié. Exchange Server 2007 réduit le trafic associé à OWA en allant directement chercher les données dans le serveur de boîtes aux lettres approprié via RPC. C'est le même processus, à peu de choses près, qui vous permet d'utiliser Outlook sur un client qui n'est pas sur une connexion de réseau privé virtuel (VPN) dans votre entreprise. Les informations de boîtes aux lettres sont alors restituées par OWA. Exchange Server 2007 peut également transmettre par proxy des requêtes OWA, mais au lieu de les envoyer directement aux serveurs de boîtes aux lettres, il les fait suivre vers d'autres serveurs CAS.
La figure 1 illustre l'architecture d'OWA sur Exchange Server 2007.
Figure 1 Procédure d'accès d'OWA aux ressources Exchange Server
Figure 1 Procédure d'accès d'OWA aux ressources Exchange Server (Cliquer sur l'image pour la réduire)
Figure 1 Procédure d'accès d'OWA aux ressources Exchange Server
Figure 1 Procédure d'accès d'OWA aux ressources Exchange Server (Cliquer sur l'image pour l'agrandir)

Administration
L'architecture d'Exchange Server 2007 revisitée comporte des options développées pour la gestion d'OWA. Vous pouvez utiliser la console de gestion Exchange ou l'environnement de ligne de commande Exchange Management Shell. Les paramètres de configuration sont stockés à différents emplacements.
La console de gestion Exchange vous permet d'accéder à la plupart des paramètres de configuration, tels que l'activation ou la désactivation des fonctionnalités en utilisant la segmentation, le blocage des pièces jointes, l'authentification et l'accès aux fonctionnalités telles que le calendrier, la liste des tâches et la vérification orthographique. Tout ce qui est possible avec la console de gestion Exchange peut également être effectué à l'aide de l'environnement de ligne de commande Exchange Management Shell.
De plus, l'environnement de ligne de commande Exchange Management Shell vous permet de créer et de supprimer de nouveaux répertoires virtuels pour OWA. Vous pouvez également avoir un contrôle plus fin sur les paramètres de segmentation par utilisateur et modifier, entre autres, le paramètre de langue par défaut.
Le registre Windows est la banque par défaut pour les délais d'expiration d'authentification basée sur les formulaires. (Ces paramètres ne sont pas disponibles via la console de gestion Exchange ou l'environnement de ligne de commande Exchange Management Shell.) Active Directory® vous permet d'accéder à des paramètres spécifiques d'OWA tels que le blocage des pièces jointes et la segmentation. La métabase IIS contient tous les paramètres (authentification, compression GZIP) qui influencent le comportement d'IIS. Par ailleurs, web.config comporte des paramètres ASP.NET tels que « maxuploadsize », qui contrôle le téléchargement des pièces jointes OWA.

Authentification
OWA propose plusieurs choix pour l'authentification au niveau du serveur. Après l'installation, la sécurité prend par défaut l'authentification basée sur les formulaires. Cependant, celle-ci peut être améliorée de plusieurs manières si nécessaire, afin de s'adapter aux exigences de votre organisation. IIS effectuera l'authentification par rapport à Active Directory pour s'assurer que l'utilisateur qui se connecte possède les droits de domaine correspondants. Vous pouvez aussi utiliser un compte de connexion basé sur l'authentification de base, l'authentification Digest (l'authentification par résumé), le RSA SecurID ou encore la carte à puce pour accéder au courrier électronique.
Le niveau de sécurité le plus élevé pour OWA est intégré à Windows et combine Kerberos et NTLM. En fait, le niveau de sécurité intégré à Windows est requis pour l'accès à Outlook Web Access 2007 Web Part et pour la transmission par proxy des CAS entre les sites Active Directory. Les utilisateurs qui accèdent à OWA sur un intranet profitent également d'un avantage supplémentaire£ ils ont accès à une authentification unique avec l'authentification client Windows, ainsi vous n'avez pas à ouvrir de session sur OWA si vous êtes déjà un utilisateur de confiance.
Si vous utilisez l'authentification basée sur les formulaires, l'option par défaut, OWA expirera automatiquement après une période d'inactivité. Selon que l'utilisateur a choisi une machine publique ou privée (au moment de l'ouverture de session), le délai peut être de 15 minutes (pour les machines publiques) ou jusqu'à 8 heures (pour un ordinateur privé). Choisir une machine publique ou privée est important pour les utilisateurs, car d'autres paramètres de sécurité peuvent aussi être configurés différemment en fonction de cette option. Vous pouvez, par exemple, bloquer des pièces jointes sur les machines publiques ou modifier les délais d'authentification. L'authentification basée sur les formulaires est, à la base, un processus en quatre étapes comme illustré par la figure 2.
Figure 2 Processus d'authentification
  1. Les clients envoient une demande au serveur, non-cryptée.
  2. Les serveurs renvoient un cookie crypté au client.
  3. Les serveurs continuent de supprimer et de créer de nouvelles clés de cryptage, en gardant en mémoire les trois clés les plus récentes.
  4. Les clients qui envoient des requêtes avec une clé de cryptage périmée qui se trouve encore en mémoire obtiennent un nouveau cookie crypté avec la clé la plus récente.
    £ou£
    Les clients qui envoient des requêtes avec une clé de cryptage périmée qui a été supprimée et dont le délai a expiré doivent ouvrir une nouvelle session.

msExchQueryBaseDN est le mécanisme utilisé pour restreindre certains utilisateurs et ne leur permettre de voir qu'une partie du carnet d'adresses dans OWA. msExchQueryBaseDN est inscrit sur les objets des utilisateurs et il pointe vers une liste d'adresses (LA) ou une unité d'organisation (OU). Cette LA sera utilisée en tant que liste d'adresses globale (LAG) pour l'utilisateur et celui-ci verra une LAG qui n'inclut que des comptes utilisateurs dans cette OU. Vous pouvez définir msExchQueryBaseDN à l'aide de LDAP.

Compatibilité descendante
Le cœur d'Outlook Web Access dans Exchange Server 2007 est le CAS et le modèle CAS a été construit pour offrir la meilleure interopérabilité possible avec les serveurs qui exécutent des versions plus anciennes d'Exchange. Pour être sûr que cela fonctionne, vous devez toujours déployer ou mettre à niveau vos serveurs CAS avant de mettre à niveau les serveurs de boîte aux lettres qui leur sont associés.
Un serveur Exchange 2007 avec le rôle CAS peut être utilisé pour se connecter aux boîtes aux lettres sur les serveurs Exchange 2000 et Exchange 2003. RPC sur HTTP et Exchange ActiveSync® continueront tous les deux à fonctionner avec une mise à niveau du site partielle. OWA et WebDAV fonctionneront aussi si vous y accédez via des répertoires virtuels /exchange, /public ou /exchweb. Vous pouvez créer des répertoires virtuels OWA personnalisés pour ces versions plus anciennes sur Exchange Server 2007 également.

ISA Server 2006 est votre ami
Outlook Web Access a été largement amélioré dans Exchange Server 2007, mais il est possible de le faire évoluer encore plus en le couplant avec Internet Security and Acceleration (ISA) Server 2006.
ISA Server 2006 est une passerelle de sécurité intégrée. De plus, ISA Server contribue à la protection de votre site contre les menaces en provenance d'Internet et il permet un accès à distance sécurisé aux applications et aux données. Dans la mesure où l'objectif d'OWA est le même, le couplage des deux vous offre le plus merveilleux des concepts informatiques, la synergie. (Pour plus d'informations sur ISA Server, visitez la page Web microsoft.com/isaserver/2006.)
ISA Server 2006 offre divers avantages à l'administrateur Exchange surmené. Par exemple, la fonctionnalité Web Publishing Load Balancing (WPLB) vous permet d'équilibrer les charges à l'aide des cookies HTTP. Vous pouvez garantir l'affinité client/serveur même lorsque l'IP du client change. ISA Server 2006 fournit également la compression et la décompression GZIP, vous permettant d'analyser la compression du trafic ou du déchargement à partir des serveurs Web. Avec ISA Server 2004, il vous fallait faire un choix : vous pouviez utiliser la compression HTTP avec OWA ou vous pouviez utiliser l'authentification basée sur les formulaires avec ISA Server. ISA Server 2006 a la bonne idée de prendre en charge les deux de manière simultanée.
De plus, vous pouvez effectuer la conversion de liaison via ISA Server. Si quelqu'un met un lien intranet dans un message électronique OWA, ISA Server peut le convertir en un véritable lien Internet. Ceci peut s'avérer assez utile, mais vous devez vous souvenir de publier les liens intranet dans le même groupe ISA qui publie OWA.
La fonctionnalité probablement la plus importante d'ISA Server 2006 est la pré-authentification qui contribue à la protection de votre réseau au niveau du périmètre. La pré-authentification a pour but de garantir qu'aucun trafic HTTP non autorisé ne parvient jusqu'aux serveurs. Si le trafic dirigé vers votre CAS est bien valide, ISA Server l'expédiera depuis le périmètre jusqu'au domaine. (Les serveurs de périmètre se trouvent à l'extérieur du domaine intranet et bloquent le trafic qui n'en fait pas partie. Votre CAS ne doit pas être déployé dans le domaine de périmètre ; il doit être sur le domaine intranet afin de pouvoir accéder aux comptes utilisateurs Active Directory.)

Dépannage d'Outlook Web Access
Outlook Web Access 2007 comporte de nouveaux outils qui améliorent la surveillance et la résolution de problèmes. Une tâche de surveillance s'exécute automatiquement sur le serveur CAS. Cette tâche teste la connectivité de chaque serveur de boîtes aux lettres, ainsi que les ouvertures de session OWA. Exchange Server 2007 contient également des messages du journal des événements beaucoup plus précis et des compteurs de performances.
Exchange Server Best Practices Analyzer (voir notre couverture microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange) a été amélioré pour attirer l'attention des administrateurs sur les avertissements importants et les erreurs si OWA n'est pas configuré convenablement. Vous pouvez également établir des rapports d'utilisation OWA à partir des journaux IIS via l'outil Logparser (couvert dans l'édition d'octobre 2006 sur microsoft.com/technet/technetmag/issues/2006/10/LogParser).

Messagerie unifiée
Alors qu'OWA répond aux besoins de la téléphonie mobile, la messagerie unifiée consolide les différentes formes de messagerie en un emplacement unifié (d'où le nom astucieux). Désormais, le courrier électronique se trouve sur Exchange Server. La voix (appels téléphoniques, messagerie vocale) est disponible sur un serveur de téléphonie. Le courrier électronique est accessible sur votre bureau et vous récupérez les messages vocaux via votre téléphone. Et sans parler de la télécopie !
La messagerie unifiée Exchange Server 2007 permet à une organisation de distribuer le courrier électronique, les messages vocaux et les informations transmises par télécopie dans une boîte de réception unique, à laquelle les utilisateurs peuvent accéder via Outlook et OWA. La messagerie utilise aussi un autre canal : les utilisateurs peuvent accéder à la messagerie vocale, au courrier électronique, aux contacts et aux calendriers par le téléphone avec Outlook Voice Access.
Pour l'administration des systèmes, la messagerie unifiée simplifie la communication de messages en combinant votre infrastructure Exchange et votre infrastructure de téléphonie pour vous offrir une seule solution de stockage, un seul répertoire et un seul transport. Le niveau global de complexité est réduit lorsque chaque personne dispose d'une boîte aux lettres unique.
Le meilleur dans tout ça ? Ceci peut être effectué à l'aide de vos serveurs existants et si vous connaissez Exchange Server 2007 ainsi que la téléphonie, vous aurez peu à apprendre. Les fonctionnalités de la messagerie unifiée sont intégrées à Exchange£vous utilisez le même modèle de sécurité et les mêmes boîtes de réception. Vous pouvez accéder à la messagerie vocale et à la télécopie via OWA.
La figure 3 illustre l'architecture de la messagerie unifiée Exchange Server 2007 avec le rôle serveur de messagerie unifiée installé. Regardez cette figure (il y aura peut-être une série de questions plus tard) puis observez de manière plus approfondie l'architecture de la messagerie unifiée.
Figure 3 La messagerie unifiée réunit communication vocale, télécopie et courrier électronique
Figure 3 La messagerie unifiée réunit communication vocale, télécopie et courrier électronique (Cliquer sur l'image pour la réduire)
Figure 3 La messagerie unifiée réunit communication vocale, télécopie et courrier électronique
Figure 3 La messagerie unifiée réunit communication vocale, télécopie et courrier électronique (Cliquer sur l'image pour l'agrandir)
Lorsque vous installez la messagerie unifiée dans une entreprise, de nombreux éléments sont à prendre en compte. Exchange Server contient des objets qui représentent le matériel de téléphonie. Les relations entre ces objets peuvent être définies au sein de l'environnement Exchange. Le système de messagerie unifiée Exchange Server comprend le serveur MU, le plan de numérotation de messagerie unifiée, la passerelle IP de messagerie unifiée et le groupe de recherche de messagerie unifiée, ainsi que la stratégie de boîte aux lettres de messagerie unifiée et le standard automatique de messagerie unifiée. Examinons la manière dont ces objets justifient leur existence.
L'objet serveur de messagerie unifiée est créé dans Active Directory à l'endroit où le rôle serveur de messagerie unifiée est installé. Il permet à un administrateur de contrôler l'installation et les propriétés d'un déploiement de messagerie unifiée Exchange Server 2007. Le plan de numérotation de messagerie unifiée est l'unité administrative de base dans la messagerie unifiée ; il représente la manière dont les numéros de poste sont utilisés en interne. Tous les utilisateurs dans un plan de numérotation de messagerie unifiée peuvent en contacter d'autres simplement en appelant leur numéro de poste. Si vous reliez d'autres emplacements, chacun d'entre eux disposera de son propre plan de numérotation.
L'objet passerelle IP de messagerie unifiée représente une passerelle VoIP (protocole voix sur IP) physique ou un autocommutateur privé (PBX) IP activé pour une SIP (Session Initiation Protocol). Un serveur de messagerie unifiée peut recevoir des appels provenant d'un système de passerelle IP/VoIP. Un groupe de recherche de messagerie unifiée relie une passerelle IP avec un plan de numérotation de messagerie unifiée. Une fois que le groupe de recherche est configuré au niveau du PBX, un groupe de recherche de messagerie unifiée est créé dans Active Directory pour représenter cela. Vous pouvez configurer le groupe de recherche pour fournir l'équilibrage de la charge sur l'ensemble des passerelles IP. Ces passerelles, à tour de rôle, peuvent fournir l'équilibrage de la charge en associant un groupe de recherche de messagerie unifiée unique à plusieurs passerelles. Les stratégies de boîte aux lettres de messagerie unifiée sont analogues aux classes de service de messagerie vocale. Elles comprennent un plan de numérotation et des propriétés qui définissent des stratégies de fonctionnement pour les utilisateurs et les groupes.
Le standard automatique de messagerie unifiée peut être associé à un plan de numérotation de messagerie unifiée unique. Il peut être personnalisé pour effectuer plusieurs tâches, comme par exemple enregistrer des invites personnalisées et définir des tâches à effectuer certains jours et à certaines heures. Le standard automatique peut être configuré à l'aide de listes d'adresses.
La figure 4 montre comment six objets messagerie unifiée fonctionnent ensemble.
Figure 4 Interaction des objets téléphonie de messagerie unifiée
Figure 4 Interaction des objets téléphonie de messagerie unifiée (Cliquer sur l'image pour la réduire)
Figure 4 Interaction des objets téléphonie de messagerie unifiée
Figure 4 Interaction des objets téléphonie de messagerie unifiée (Cliquer sur l'image pour l'agrandir)

Configuration
Une fois que l'utilisateur dispose d'une boîte aux lettres Exchange Server 2007, l'administrateur doit l'activer pour la messagerie unifiée. Pour ce faire, l'administrateur doit associer la boîte aux lettres à une stratégie de boîte aux lettres de messagerie unifiée et à un numéro de poste, tous les deux inclus dans le plan de numérotation. Le PBX doit aussi être configuré pour acheminer l'appel vers la messagerie unifiée sur un RNA (appel, pas de réponse). Le PBX acheminera d'abord l'appel vers le numéro de l'utilisateur. Puis, en cas de RNA, l'appel est acheminé vers la passerelle VoIP puis sur le serveur de messagerie unifiée.
La messagerie unifiée est évolutive. Vous pouvez ajouter autant de chaînes PBX commutées et de serveurs de messagerie unifiée que nécessaires. Lorsque vous utilisez des passerelles VoIP, les appels IP seront remis à la messagerie unifiée Exchange. Dans la mesure où cette fonctionnalité est une nouveauté pour de nombreuses entreprises, il vous est recommandé d'effectuer une analyse complète du réseau pour vous assurer que votre réseau IP dispose de la bande passante adéquate pour gérer à la fois les données et la voix.
Un serveur de messagerie unifiée Exchange Server 2007 peut gérer entre 50 et 200 appels IP simultanés et jusqu'à 200 appels vocaux et appels de télécopie entrants (définis à la valeur 100 par défaut). Vous pouvez construire des serveurs de messagerie unifiée supplémentaires si vous avez besoin de davantage de capacité ou si vous souhaitez augmenter votre tolérance aux pannes.

Conclusion
Et voilà ! Exchange Server 2007 offre deux fonctionnalités, Outlook Web Access et la messagerie unifiée, qui, ensemble, procurent d'immenses avantages à une organisation. Outlook Web Access vous permet d'accéder au courrier électronique en toute sécurité depuis n'importe où et la messagerie unifiée permet aux utilisateurs d'accéder à leur courrier électronique, aux messages de télécopie et aux autres données de boîte aux lettres qui peuvent arriver dans leur boîte aux lettres Exchange 2007.

Joshua Trupin est le rédacteur en chef technique de MSDN Magazine et TechNet Magazine. Il a écrit de nombreux articles pour MSJ, MIND, MSDN Magazine et TechNet Magazine, ainsi qu'un livre intitulé Hoop Stats: The Basketball Abstract.


 Exchange Server&#160;2007: Une journalisation plus puissante dans Exchange&#160;2007
Exchange Server 2007 David Strome

Une journalisation plus puissante dans Exchange 2007
Vue d'ensemble:
  • Règles du journal Exchange Server 2007
  • Le nouvel Assistant Journal
  • Que contient un rapport de journal ?

Vous est-il déjà arrivé de devoir journaliser des messages électroniques envoyés à un utilisateur spécifique ou reçus de cet utilisateur, mais vous avez finalement obtenu les messages recherchés ainsi que des messages des 300 autres boîtes aux lettres
appartenant à cette banque de boîtes aux lettres ? Microsoft Exchange Server 2007 permet de résoudre ce problème et vous apporte la finesse de contrôle dont vous avez besoin.
La journalisation par destinataire, disponible avec les licences d'accès client (CAL) d'entreprise, vous permet de cibler qui vous souhaitez journaliser. En utilisant les règles de journal, vous pouvez maintenant cibler uniquement les destinataires et les expéditeurs que vous souhaitez journaliser. Vous pouvez choisir de prendre en compte une seule boîte aux lettres ou d'inclure également, par exemple, l'ensemble du personnel d'un service des ventes. De plus, il n'est pas nécessaire que leur boîte aux lettres fasse partie du même serveur, du même site Active Directory®, ni même d'une organisation Exchange. Grâce à la réplication d'Active Directory, vos modifications s'appliquent automatiquement à tous les ordinateurs qui utilisent le rôle de serveur de transport Hub dans votre organisation.

Fonctionnement de la journalisation
Avec Exchange Server 2003, la journalisation était implémentée sur des banques de boîtes aux lettres distinctes pour chaque serveur physique. Si vous souhaitiez journaliser toutes les boîtes aux lettres de votre organisation, vous deviez configurer la journalisation sur chaque banque de boîtes aux lettres. En outre, si vous souhaitiez journaliser les messages d'un destinataire particulier, vous deviez soit journaliser tous les membres de la banque de boîtes aux lettres de cet utilisateur, soit créer une nouvelle banque de boîtes aux lettres spécifiquement pour cet utilisateur.
La journalisation dans Exchange Server 2007 utilise la nouvelle topologie basée sur les rôles, dans Exchange. Comme le montre la Figure 1, tous les messages sont traités par des serveurs de transport Hub lorsqu'ils sont à destination ou en provenance de serveurs de boîtes aux lettres et de messagerie unifiée, d'autres systèmes Exchange, d'applications tierces et d'Internet. Tous les serveurs de transport Hub contiennent un agent de transport appelé agent de journalisation. Ce dernier est responsable de l'application des règles de journal à tous les messages. Comme l'agent de journalisation se trouve sur les serveurs de transport Hub, il intercepte et évalue chaque message avant qu'il atteigne son destinataire. L'agent de journalisation traite les messages après la catégorisation£cela garantit l'accès à tous les attributs du destinataire et de l'expéditeur d'un message, d'une part, et, d'autre part, cela permet à l'agent de déterminer si le message a été envoyé directement à un destinataire ou s'il a été reçu via l'expansion d'un groupe de distribution. L'agent peut également savoir si le destinataire se trouvait sur la ligne À, Cc ou Cci d'un message en provenance de l'organisation Exchange Server 2007.
Figure 1 Flux de messages du serveur de transport Hub
Figure 1 Flux de messages du serveur de transport Hub (Cliquer sur l'image pour la réduire)
Figure 1 Flux de messages du serveur de transport Hub
Figure 1 Flux de messages du serveur de transport Hub (Cliquer sur l'image pour l'agrandir)
L'agent de journalisation applique les règles de journal configurées par l'administrateur aux messages, lorsqu'ils circulent dans le serveur de transport Hub. Ces règles déterminent si l'agent devra collecter les informations relatives à un message et les transférer avec le message original à une boîte aux lettres de journal. Ces données sont envoyées dans un message appelé rapport de journal.
Avec les versions antérieures d'Exchange, vous deviez appliquer les configurations à plusieurs serveurs. En revanche, lorsque vous créez une règle de journal dans Exchange Server 2007, cette modification s'applique à tous les serveurs de transport Hub de votre organisation, via Active Directory. Tous les serveurs de transport Hub et de ce fait tous les agents de journalisation lisent la même configuration à partir d'Active Directory. Cette couverture complète garantit donc que tous les agents de journalisation appliquent la même configuration de journalisation.
Lorsque vous créez ou modifiez les règles de journal, souvenez-vous que la réplication d'Active Directory nécessite un certain temps, car un changement de configuration doit être répliqué dans l'ensemble de votre organisation et lu par les serveurs de transport Hub. Ainsi, la réplication prend parfois plusieurs heures. Pour vous aider à identifier à quel moment la configuration de journalisation est mise à jour, Exchange produit un événement dans le journal d'événements de sécurité de chaque serveur.
Exchange Server 2007 garantit qu'aucun rapport de journal ne sera perdu à cause d'une boîte aux lettres de journal non disponible, qu'elle soit pleine, mal configurée ou hors ligne. (Cette fonction s'avère très utile pour vous aider à satisfaire aux différentes exigences juridiques et réglementaires, puisque les messages perdus peuvent être à l'origine d'un non-respect de ces exigences.) Si la livraison d'un rapport de journal à une boîte aux lettres de journal est impossible, le rapport reste dans la file d'attente du serveur de transport Hub jusqu'à ce que cette boîte aux lettres soit disponible. Puisque cela peut entraîner rapidement de longues files d'attente, il est recommandé que vous surveilliez la disponibilité de votre boîte aux lettres de journal, afin de vérifier son bon fonctionnement. Si une boîte aux lettres de journal reste non disponible pendant une période conséquente, vous pouvez en configurer une autre afin qu'elle réceptionne les rapports conservés dans la file d'attente.

Quelles données journaliser ?
Avant de commencer la création de règles de journal, vous devez savoir clairement qui vous souhaitez cibler et quels types de données vous souhaitez journaliser. En spécifiant un utilisateur dans une règle de journal, vous pouvez sélectionner des utilisateurs spécifiques pour la journalisation. Ces utilisateurs peuvent, par exemple, être soumis à des exigences réglementaires ou être impliqués dans des procédures juridiques qui nécessitent l'enregistrement de messages électroniques et d'autres communications pour démontrer certains éléments.
Outre la spécification des destinataires à journaliser, vous pouvez également déterminer la portée des messages à journaliser, en sélectionnant les options Interne, Externe et Global. Interne cible uniquement les messages envoyés au sein de votre organisation ; Externe cible les messages dont l'expéditeur ou le destinataire se trouve à l'extérieur ; Global cible à la fois les messages internes et externes. (Notez que l'option Global journalise tous les messages passant par un serveur de transport Hub, même ceux qui ont éventuellement déjà été traités par les règles, via les portées Interne et Externe.)
Exchange Server 2007 prend en charge la messagerie unifiée. Vous pouvez donc configurer Exchange pour qu'il collecte les courriers électroniques, la boîte vocale ainsi que les fax d'un utilisateur dans sa boîte de réception. Cela vous permet également de journaliser l'ensemble de ces données, ou bien de choisir d'en exclure certaines.
Si vous utilisez Exchange Server 2007 avec des CAL standard, vous pouvez toujours choisir la journalisation par banque de boîtes aux lettres. Toutefois, si vous souhaitez utiliser les nouvelles fonctionnalités de journalisation par destinataire, vous devez effectuer une mise à niveau pour obtenir les CAL d'entreprise d'Exchange Server 2007.

Où placer la boîte aux lettres de journal ?
Après avoir décidé quelles données vous souhaitez journaliser, vous devez décider où envoyer les rapports de journal. Si vous disposez de plusieurs sites, vous devez tenir compte de la topologie actuelle ou prévue du réseau pour décider où placer vos boîtes aux lettres de journal. Selon la taille de votre organisation et le nombre de boîtes aux lettres, la journalisation peut entraîner la production d'un nombre important de rapports répétitifs.
Les boîtes aux lettres ne sont toutefois pas indispensables avec Exchange. Vous pouvez envoyer des rapports de journal vers toute adresse SMTP valide. Cette adresse peut mener à des services hébergés sur Exchange, à une autre solution d'archivage ou aux deux, par l'intermédiaire d'un groupe de distribution. Cependant, veillez à ce que les emplacements où les rapports de journal sont envoyés appliquent certaines règles de sécurité.
Vous devez toujours créer un objet destinataire dans Active Directory, peu importe où vous avez décidé de placer votre boîte aux lettres de journal. Il peut s'agir d'une boîte aux lettres Exchange Server 2007, d'un contact autorisé à utiliser la messagerie qui redirige le courrier vers les services hébergés par Exchange ou vers une autre solution d'archivage, ou encore d'une liste de distribution qui contient à la fois des boîtes aux lettres et des contacts.

Que contient un rapport de journal ?
Lorsque l'agent de journalisation journalise un message, il essaie d'inclure dans un rapport de journal le plus de détails possibles sur le message d'origine. Ce rapport est ensuite envoyé à la boîte aux lettres de journal. Ces informations sont très utiles pour vous aider à déterminer l'objet du message, ses destinataires et ses expéditeurs. Par exemple, en identifiant si le destinataire figure directement dans le champ À, s'il est inclus dans le champ Cc ou s'il appartient simplement à une liste de distribution, vous pouvez déterminer le degré d'implication du destinataire dans le sujet du message. Le message d'origine est inclus en pièce jointe. Les captures d'écran de la figure 2 présentent un rapport de journal indiquant qu'un message envoyé à david@contoso.com a été transféré à christine@contoso.com, ainsi qu'un autre rapport de journal indiquant qu'un message envoyé au groupe de distribution Sales_Group@contoso.com a été étendu et que le destinataire lukas@contoso.com, qui est membre du groupe de distribution Sales Group, a reçu le message. Les deux rapports contiennent le message d'origine en pièce jointe, indiquent que l'expéditeur d'origine est brian@contoso.com et ont pour sujet « Sales forecast ».
Figure 2 Rapports de journal indiquant un destinataire en transfert et un destinataire d'un groupe de distribution étendu
Figure 2 Rapports de journal indiquant un destinataire en transfert et un destinataire d'un groupe de distribution étendu (Cliquer sur l'image pour la réduire)
Figure 2 Rapports de journal indiquant un destinataire en transfert et un destinataire d'un groupe de distribution étendu
Figure 2 Rapports de journal indiquant un destinataire en transfert et un destinataire d'un groupe de distribution étendu (Cliquer sur l'image pour l'agrandir)
Exchange classe uniquement les informations dont il est sûr de l'exactitude. Les informations qu'il est impossible de déterminer automatiquement sont placées dans les champs appropriés du rapport de journal. La figure 2 présente les champs inclus dans le corps du rapport de journal.

Tout sur la sécurité
Toutes les communications entre les ordinateurs utilisant Exchange Server 2007 dans la même organisation Exchange sont cryptées par défaut. Ce cryptage inclut les rapports de journal. Afin de réduire le risque d'utilisation non autorisée des rapports de journal, Exchange Server a recours aux mesures suivantes :
  • Des liens sécurisés sont utilisés entre les serveurs de transport Hub et les serveurs de boîte aux lettres dans l'organisation Exchange 2007.
  • Des rapports de journal sont envoyés en tant que « Microsoft Exchange », pour le compte de l'expéditeur du message d'origine.
  • Des sessions entre le serveur de transport Hub et le serveur de boîtes aux lettres sont authentifiées.
  • Seules les connexions authentifiées sont acceptées lorsque des rapports de journal sont transmis entre les serveurs de transport Hub et les serveurs de boîte aux lettres, dans la même organisation Exchange 2007.
Lorsque vous créez une boîte aux lettres de journal, vous devez la sécuriser, car elle contient des messages envoyés et reçus par des destinataires de votre organisation. Il est possible que certains messages fassent partie de procédures juridiques ou qu'ils soient soumis à des exigences réglementaires. En outre, plusieurs lois exigent que les messages soient infalsifiables avant leur soumission à une commission d'enquête. Afin d'améliorer la sécurité de la boîte aux lettres de journal, il est recommandé de configurer la boîte aux lettres de sorte qu'elle accepte uniquement les messages des expéditeurs de Microsoft Exchange et de sorte que tous les messages envoyés à la boîte aux lettres de journal proviennent d'expéditeurs authentifiés. La figure 3 illustre les restrictions de livraison des messages configurées sur une boîte aux lettres de journal. Vous pouvez également utiliser la commande Exchange Management Shell suivante pour configurer les restrictions de livraison de ces messages :
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Figure 3 Restrictions de livraison des messages
Figure 3 Restrictions de livraison des messages (Cliquer sur l'image pour la réduire)
Figure 3 Restrictions de livraison des messages
Figure 3 Restrictions de livraison des messages (Cliquer sur l'image pour l'agrandir)
Si vous envoyez des rapports de journal à une boîte aux lettres de journal située à l'extérieur de votre organisation Exchange Server 2007, vous devez crypter et sécuriser manuellement la connexion entre vos ordinateurs Exchange Server 2007 et le serveur destinataire. Pour ce faire, vous pouvez exiger l'utilisation de Transport Layer Security (TLS) entre les deux systèmes, exiger l'authentification au niveau du système destinataire, accepter, au niveau du système destinataire, uniquement les messages en provenance de l'adresse SMTP du destinataire Microsoft Exchange (cette adresse SMTP sera de type Exchange_UMUnique GUID@contoso.com) et configurer le contact Active Directory utilisé pour transférer les messages afin qu'il accepte les messages en provenance du destinataire Microsoft Exchange uniquement.

Implémentation des règles du journal
Assez discuté maintenant. Il est temps d'implémenter des règles ! Pour configurer les règles du journal dans l'agent de journalisation, il est possible d'utiliser soit Exchange Management Shell soit la console de gestion Exchange. Tous deux peuvent vous permettre de configurer le destinataire, la portée et les paramètres de la boîte aux lettres de journal. Les règles de journal sont activées par défaut au moment de leur création. La valeur spécifiée pour l'adresse électronique de journal doit être un objet destinataire existant dans l'organisation Exchange Server 2007. Cet objet destinataire peut être une boîte aux lettres, un groupe de distribution, un groupe de distribution dynamique ou un contact qui envoie du courrier à une adresse SMTP.
Pendant l'utilisation de la console de gestion Exchange, l'Assistant Nouvelle règle de journal vous guide lors de la création de nouvelles règles de journal. Dans la section Configuration d'organisation, sélectionnez le rôle de serveur de transport Hub. Ensuite, dans le volet Action, cliquez sur Nouvelle règle de journal. Vous devez alors attribuer des valeurs au nom, à l'adresse électronique de journal et à la portée de la règle. Il n'est pas nécessaire de spécifier une valeur pour le champ Destinataire si vous souhaitez que la règle journalise les messages de tous les destinataires de votre organisation. Vous pouvez également choisir de désactiver la règle de journal au moment de sa création. La figure 4 présente un exemple de configuration qui doit journaliser tous les messages envoyés et reçus par brian@contoso.com. Les messages journalisés sont envoyés à une boîte aux lettres de journal appelée Boîte aux lettres de conformité.
Figure 4 Assistant Nouvelle règle de journal
Figure 4 Assistant Nouvelle règle de journal (Cliquer sur l'image pour la réduire)
Figure 4 Assistant Nouvelle règle de journal
Figure 4 Assistant Nouvelle règle de journal (Cliquer sur l'image pour l'agrandir)
Dans Exchange Management Shell, vous pouvez utiliser ces six cmdlets pour administrer l'agent de journalisation :
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
La cmdlet New-JournalRule vous permet de créer une nouvelle règle de journal. Avec cette cmdlet, les critères de base pour la création d'une nouvelle règle de journal sont les mêmes qu'avec l'assistant. Vous devez spécifier des valeurs pour les paramètres Nom, Portée et JournalEmailAddress. Là encore, il n'est pas nécessaire de spécifier une valeur pour le paramètre Destinataire si vous souhaitez que la règle journalise les messages de tous les destinataires de votre organisation. En outre, si vous souhaitez que la règle de journal soit désactivée au moment de sa création, vous devez spécifier une valeur $False pour le paramètre Activé. Pour la création d'une règle de journal dotée de la même configuration que dans l'illustration de la figure4, il convient d'utiliser la commande suivante :
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Utilisez la cmdlet Get-JournalRule pour obtenir une liste de toutes les règles de journal que vous avez créées. L'utilisation de cette cmdlet seule affiche une liste récapitulative de toutes les règles de journal configurées dans votre organisation, ainsi que tous leurs paramètres de configuration. Si vous souhaitez consulter l'ensemble des informations disponibles sur une règle de journal, vous pouvez transférer la cmdlet Get-JournalRule vers la cmdlet Format-List. Ce transfert envoie la sortie d'une cmdlet vers la cmdlet suivante. Ainsi, la deuxième cmdlet peut effectuer des opérations de traitement supplémentaires au niveau de la sortie. Par exemple, la cmdlet Format-List affiche la totalité de la sortie qu'elle reçoit. Pour consulter l'ensemble des informations disponibles sur une règle de journal créée précédemment, vous pouvez utiliser la commande suivante :
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Utilisez les cmdlets Enable-JournalRule et Disable-JournalRule pour activer ou désactiver une règle de journal. Lorsque vous utilisez ces cmdlets, vous devez spécifier le nom de la règle de journal dans le paramètre Identité. Par exemple, pour désactiver la règle de journal qui vient d'être créée, utilisez la commande suivante :
Disable-JournalRule -Identity "Brian Smith Journal Rule"
La cmdlet Set-JournalRule vous permet de modifier une règle de journal existante. Le nom de la règle de journal est utilisé avec le paramètre Identité pour indiquer à l'agent de journalisation la règle qui est modifiée. Spécifiez ensuite le Destinataire, la JournalEmailAddress, la Portée ou toute combinaison de ces paramètres, ainsi que leur valeur. Par exemple, si vous souhaitez modifier la valeur enregistrée dans le paramètre JournalEmailAddress pour la règle créée, utilisez la commande suivante :
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
Enfin, vous pouvez utiliser la cmdlet Remove-JournalRule pour supprimer une règle de journal existante. Spécifiez le nom de la règle de journal en utilisant le paramètre Identité. Pour supprimer l'exemple de règle de journal, utilisez la commande suivante :
Remove-JournalRule "Brian Smith Journal Rule"
Exchange Management Shell vous demandera alors si vous êtes sûr de vouloir supprimer la règle de journal. Encore un dernier conseil : pour pratiquement toutes les cmdlets, vous pouvez vous contenter de spécifier la valeur du paramètre Identité, sans lui donner de nom.

David Strome est rédacteur technique auprès du groupe Exchange User Education chez Microsoft depuis à peine plus d'un an. Avant de rejoindre Microsoft à Redmond dans l'état de Washington, David a passé une dizaine d'années à concevoir, implémenter et administrer des installations Exchange Server dans diverses entreprises basées en Colombie britannique, au Canada. Vous pouvez le contacter à l'adresse suivante : dstrome@microsoft.com.


 Exchange Server&#160;2007: Lutter contre le courrier ind&#233;sirable et le phishing &#224; l'aide de Sender ID
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

Lutter contre le courrier indésirable et le phishing à l'aide de Sender ID
Vue d'ensemble:
  • Notions fondamentales sur Sender ID
  • Configurer Sender ID sur Exchange Server
  • Avantages de l'authentification

De nombreuses technologies d'identification et de filtrage ont été développées suite à la menace grandissante du courrier indésirable. Leur efficacité repose sur le questionnement de chaque message électronique, concernant
l'expéditeur du message par exemple. Malheureusement, la réponse à la question fondamentale de l'identité de l'expéditeur n'est pas toujours facile à donner. Le courrier électronique est généralement envoyé sur Internet sans que l'expéditeur soit authentifié ou sans que les ordinateurs agissent au nom de l'expéditeur. En réalité, il est facile d'envoyer un message électronique tout en prétendant être quelqu'un d'autre et il n'existe aucune méthode automatisée pour détecter ces messages usurpés.
Le SMPT (Simple Mail Transfer Protocol), utilisé pour envoyer et recevoir des courriers électroniques, n'a pas été conçu pour vérifier l'identité de l'expéditeur d'un message électronique. Cette faille technologique rend possible l'insertion de n'importe quel nom et n'importe quelle adresse au titre d'expéditeur. Par conséquent, des mesures de filtrage de contenu ou anti-spam ne peuvent se baser uniquement sur les informations d'en-tête pour garantir que les messages proviennent vraiment de l'expéditeur déclaré.
L'authentification du courrier électronique répond de manière spécifique à cette faille. Grâce à l'authentification, les systèmes d'envoi et de réception de courrier électronique attestent que les messages proviennent des domaines d'où ils déclarent venir. Les organisations peuvent ainsi filtrer le courrier électronique indésirable facilement et de manière efficace, mais peuvent également s'assurer que le courrier électronique légitime arrive aux destinataires prévus.
Il existe aujourd'hui deux méthodes, libres de droits, permettant l'authentification du courrier électronique : SIDF (Sender ID Framework) et DKIM (DomainKeys Identified Mail). SIDF est une solution basée sur IP (Internet Protocol) créée à partir de la fusion de SPF (Sender Policy Framework) et de l'ID de l'appelant Microsoft pour le courrier électronique. En avril 2006, IETF (Internet Engineering Task Force) a publié les spécifications RFC 4405-4408 de Sender ID. Une coalition des parties prenantes de l'industrie et des entreprises, y compris Microsoft, recommande le déploiement de SIDF basé sur des facteurs tels que sa valeur technique et commerciale, sa stabilité, sa maturité, sa facilité de déploiement, son impact réduit sur les performances sortantes ou entrantes ainsi que son interopérabilité avec l'écosystème du courrier électronique pour les fournisseurs de services Internet et les environnements d'entreprise.
DKIM est la fusion de Yahoo! Spécifications des IIM (Identified Internet Mail) de DomainKeys et de Cisco Systems Inc. En janvier 2006, IETF a approuvé la création d'un groupe de travail DKIM et la spécification est actuellement revue par IETF.
Comme il n'existe aucune solution parfaite pour lutter contre le courrier indésirable, SIDF constitue une initiative industrielle d'importance non négligeable pour lutter contre les domaines usurpés. Par conséquent, il s'agit d'un élément clé pour réduire les attaques de courrier indésirable et de phishing et pour augmenter la confiance en général et la fiabilité des opérations en ligne. Partout dans le monde, le SIDF est de plus en plus adopté par les organisations. De nos jours, plus de 5,5 millions d'entreprises et de détenteurs de domaines ont publié des enregistrements SPF et plus de 600 millions d'utilisateurs sont protégés par SIDF. À ce jour, plus d'un tiers du volume du courrier électronique journalier mondial est désormais authentifié et compatible avec SIDF.
Le développement et l'adoption mondiale de SIDF seraient impossibles sans la contribution et le soutien de nombreuses organisations et entreprises, dont AOL, AOTA (Authentication and Online Trust Alliance), Bell Canada, ESPC (E-Mail Senders Provider Coalition), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, entre autres.

Comprendre Sender ID
Certaines enquêtes industrielles indiquent que plus de 95 % des schémas de phishing proviennent de domaines usurpés et possèdent des adresses d'expéditeur de courrier électronique usurpées. C'est là que SIDF fait toute la différence pour ce qui est du traitement anti-spam. SIDF ne résoudra pas à lui seul ce problème de courrier indésirable, mais il contribue fortement à minimiser les conséquences des attaques de courrier indésirable et de phishing. SIDF n'empêche pas l'envoi des courriers électroniques indésirables. Il facilite cependant leur détection. Cet environnement permet aux expéditeurs de courrier électronique de protéger leur nom de domaine, leur réputation et leur marque. Il fournit une base solide pour prendre des décisions de filtrage basées sur la réputation et le comportement de l'expéditeur, en termes de courrier électronique.
Sender ID cherche à vérifier que chaque message électronique provient du domaine Internet duquel il déclare avoir été envoyé. Ceci se fait par la vérification de l'adresse du serveur qui envoie le courrier électronique par rapport à une liste enregistrée de serveurs autorisés par le propriétaire de domaine à envoyer des courriers électroniques. La vérification est exécutée par le fournisseur de services Internet ou par le serveur de courrier du destinataire avant que le message ne soit délivré à la boîte de réception de l'utilisateur.
Remarquez que le Sender ID ou tout autre mécanisme d'authentification ne remplacent pas les systèmes de filtrage du contenu. Ni SIDF ni DKIM ne vérifient le contenu réel du message. Au lieu de cela, l'authentification indique au système de courrier électronique d'entrée si le message peut être validé comme provenant de l'expéditeur revendiqué. Parce que la plupart des tentatives de spam et de phishing ne proviennent pas, en fait, du domaine affiché, cette approche permet d'identifier automatiquement ces messages et de les séparer du flux de courrier électronique entrant.
Au sein du SIDF, l'enregistrement SPF fournit un simple enregistrement de texte de tous les serveurs de messagerie de sortie associés à un domaine, en même temps que leurs adresses IP respectives. Une organisation publie l'enregistrement SPF sur son fichier de zone de serveur, qui est alors vérifié par les serveurs de messagerie du destinataire. Configurer un enregistrement SPF : c'est rapide, facile et gratuit. L'assistant d'enregistrement SPF de l'environnement Sender ID fournit un processus pas à pas pour examiner les serveurs de messagerie d'un domaine et créer des enregistrements personnalisés prêts pour la publication. (Les informations concernant la publication d'un enregistrement SPF sont disponibles sur microsoft.com/senderid. Vous pouvez accéder directement à l'assistant sur microsoft.com/senderid/wizard.)
Le serveur de courrier électronique SMPT de réception exécute le fichier de zone du domaine dans le DNS pour détecter la présence d'un enregistrement SPF. Une fois détectée, l'adresse IP du serveur expéditeur est vérifiée par rapport aux adresses IP répertoriées. S'il y a correspondance, l'authenticité du message est validée. En revanche, si l'enregistrement SPF sur le domaine de l'expéditeur ne correspond pas à l'adresse IP d'où provient le message, il échoue, est évalué négativement et risque d'être placé dans le dossier de courrier indésirable. La figure 1 présente ce processus.
Figure 1 Vérification des enregistrements SPF pour les messages entrants
Figure 1 Vérification des enregistrements SPF pour les messages entrants (Cliquer sur l'image pour la réduire)
Figure 1 Vérification des enregistrements SPF pour les messages entrants
Figure 1 Vérification des enregistrements SPF pour les messages entrants (Cliquer sur l'image pour l'agrandir)
Une fois le message balisé, le SIDF permet au serveur de courrier destinataire d'analyser le message sur la base des comportements précédents, sur la réputation de l'expéditeur, le contenu et sur d'autres critères qui peuvent être définis s'il y a lieu. Cette possibilité assure une meilleure sécurité. Par exemple, les expéditeurs de courrier indésirable peuvent enregistrer des domaines d'aspect semblable et des enregistrements SPF publiés pour tromper l'utilisateur et le réseau de réception et les amener à penser que le courrier électronique émane d'un expéditeur légitime. Et même si le message électronique passe la barrière de la vérification de l'authentification, la réputation d'expéditeur de courrier indésirable de l'expéditeur est suffisante pour bloquer, rendre indésirable ou supprimer le message.

Options de déploiement de Sender ID
L'authentification du courrier sortant via SIDF ne nécessite pas d'évolution de l'infrastructure ou de mise à jour logicielle et n'est pas spécifique au logiciel client ou serveur. Cependant, les organisations qui désirent incorporer l'authentification à l'arrivée des messages pour protéger leur entreprise et leurs employés, devront mettre à jour leurs systèmes d'entrée et leurs MTA (Message Transfer Agent) et déployer un logiciel ou un système qui prend en charge SIDF. La majorité des principaux MTA commerciaux et Open Source et des fournisseurs anti-spam, dont Microsoft® Exchange Server et Exchange Hosted Filtering, propose des solutions intégrées.
Microsoft a intégré SIDF à tous ses produits de messagerie, y compris à Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering (filtrage Microsoft Exchange), Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express ainsi qu'à la messagerie Outlook Office et aux clients de collaboration.
Et pourtant, même Microsoft reçoit des courriers indésirables. Environ 15 millions de messages arrivent chaque jour chez Microsoft et lors des dernières attaques de courrier indésirable, nous avons constaté que ce volume pouvait doubler à quadrupler. Dans un tel environnement, le moyen le plus efficace pour se protéger du courrier indésirable consiste à être vigilant et à implémenter les technologies disponibles.
Microsoft utilise une solution anti-spam Exchange Server interne basée sur le filtre Sender ID dans Exchange Server 2003 et sur l'agent Sender ID dans Exchange Server 2007. Dans ces deux versions d'Exchange Server, l'état du Sender ID est basé sur l'évaluation de l'enregistrement du Sender ID situé sur les serveurs DNS correspondants. Le domaine réel est déterminé par l'examen des en-têtes du message RFC 2822 dans l'ordre de priorité suivant :
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
Le domaine de l'expéditeur (ou l'entité responsable de l'injection d'un message dans le flux de messagerie et qui est la plus récente car les systèmes de messagerie peuvent transférer des courriers électroniques de manière légitime, au nom d'autres serveurs de messagerie) est déterminé par la localisation de la première définition des en-têtes qui viennent d'être mentionnés dans l'ordre défini. Si aucun de ces en-têtes n'est trouvé, SIDF utilisera la valeur MAIL FROM de SMTP RFC 2821.

Configurer Sender ID
Dans Exchange Server 2007, l'agent Sender ID peut être activé sur les serveurs sur lesquels est installé le rôle de transport Edge. Si l'agent Sender ID est activé, il filtrera les messages passant par les connecteurs de réception - tout le trafic entrant non authentifié (provenant de sources externes) sera soumis à un traitement par le Sender ID. Dans Exchange Server 2003, l'état du Sender ID persiste d'un serveur à l'autre dans le blob EXCH50. Dans Exchange Server 2007, il a également été ajouté aux métadonnées du message. Au niveau de leur destination finale, tous deux sont convertis en une propriété MAPI pour une consommation client future.
La configuration de filtrage du Sender ID dans Exchange Server 2003, disponible dans les propriétés de remise des messages, consiste uniquement à spécifier comment Exchange Server gère l'échec de la validation.
Pour activer Sender ID dans Exchange Server 2007, il suffit d'ouvrir Exchange Management Console pour un serveur sur lequel est configuré le rôle de transport Edge, de sélectionner l'onglet Anti-spam, puis le Sender ID et dans le volet Actions, de cliquer sur Activer ou Désactiver pour agir sur l'agent Sender ID comme illustré dans la figure 2. De plus, vous pouvez utiliser Exchange Management Shell pour activer ou désactiver Sender ID comme illustré dans la figure 3.
Figure 2 Contrôles de la console de gestion Exchange pour l'agent Sender ID dans Exchange Server 2007
Figure 2 Contrôles de la console de gestion Exchange pour l'agent Sender ID dans Exchange Server 2007 (Cliquer sur l'image pour la réduire)
Figure 2 Contrôles de la console de gestion Exchange pour l'agent Sender ID dans Exchange Server 2007
Figure 2 Contrôles de la console de gestion Exchange pour l'agent Sender ID dans Exchange Server 2007 (Cliquer sur l'image pour l'agrandir)
Figure 3 Activer Sender ID en utilisant l'environnement de ligne de commande Exchange Management Shell
Figure 3 Activer Sender ID en utilisant l'environnement de ligne de commande Exchange Management Shell (Cliquer sur l'image pour la réduire)
Figure 3 Activer Sender ID en utilisant l'environnement de ligne de commande Exchange Management Shell
Figure 3 Activer Sender ID en utilisant l'environnement de ligne de commande Exchange Management Shell (Cliquer sur l'image pour l'agrandir)
La boîte de dialogue des propriétés du Sender ID ne reflète pas l'état (activé ou désactivé) de l'agent. L'onglet Action fournit des options très similaires à celles disponibles dans Exchange Server 2003 (voir Figure 4).
Figure 4 Propriétés Action de l'agent Sender ID dans Exchange Server 2007
Figure 4 Propriétés Action de l'agent Sender ID dans Exchange Server 2007 (Cliquer sur l'image pour la réduire)
Figure 4 Propriétés Action de l'agent Sender ID dans Exchange Server 2007
Figure 4 Propriétés Action de l'agent Sender ID dans Exchange Server 2007 (Cliquer sur l'image pour l'agrandir)
En termes d'implémentation et de fonctionnalité du Sender ID, il n'existe pas de différence majeure entre Exchange Server 2003 et Exchange Server 2007. Le filtre Sender ID (dans Exchange Server 2003) et l'agent Sender ID (dans Exchange Server 2007) utilisent le même algorithme sous-jacent pour l'extraction et la vérification. L'éventail des actions possibles est également le même : Supprimer le message (suppression silencieuse), Rejeter le message (réponse de protocole SMPT niveau 500) et Marquer le message avec le résultat du Sender ID et continuez le traitement. La dernière option est l'action par défaut dans les deux versions d'Exchange Server.
Dans Exchange Server 2007, les codes d'état FAIL et TempError peuvent déclencher une action Rejeter le message (dans Exchange Server 2003, seul un code d'état FAIL peut déclencher cette action). L'agent Sender ID doit être configuré de manière explicite pour déclencher l'action Rejeter le message sur des messages comportant un code d'état TempError car, par défaut, ces messages seront acceptés dans le système, marqués avec le résultat du Sender ID puis traités.
L'option de configuration par cela n'est pas disponible dans l'interface utilisateur graphique, vous devez donc utiliser Exchange Management Shell pour configurer les actions de Sender ID pour le code d'erreur TempError. Par exemple, pour forcer l'agent Sender ID à rejeter les messages avec un code d'état TempError, exécutez la cmdlet de l'agent Sender ID suivante :
Set-SenderIDConfig -TempErrorAction Reject
L'éventail des résultats d'état et des actions possibles de Sender ID dans Exchange Server 2007 est semblable à celui du filtre Sender ID Exchange Server 2003 ; il est illustré dans la figure 5.
Figure 5 État et actions de Sender ID dans Exchange Server 2007 (Close Figure 5)

État de Sender ID | Description | Actions
Neutre | Les données publiées de Sender ID sont de toute évidence peu concluantes. | StampStatus
Pass | L'adresse IP se trouve dans la définition autorisée | StampStatus
Fail | L'adresse IP se trouve dans la définition non autorisée | StampStatus, Supprimer ou Rejeter
SoftFail | L'adresse IP se trouve peut-être dans la définition non autorisée | StampStatus
Aucun | Aucune donnée publiée | StampStatus
TempError | Erreur temporaire telle que serveur DNS indisponible | StampStatus ou Rejeter
PermError | Erreur irrécupérable telle qu'une erreur dans le format d'enregistrement | StampStatus
Exchange (s'il est configuré pour ça) supprimera seulement les messages qui ont échoué à la vérification du Sender ID. Aucun autre résultat ne déclenchera une suppression de message. Les messages entrants affichant une attribution d'état Neutre, Aucun, SoftFail, TempError ou PermError seront marqués de manière appropriée et transmis pour une vérification anti-spam approfondie. Dans certains cas, lorsque le message est vraiment mal fait et que l'adresse IP FROM fait défaut, l'état Sender ID ne peut être marqué sur le message. Dans une telle situation, le message n'est ni ignoré ni rejeté. Au lieu de cela, il sera transmis pour un traitement approfondi sans que l'état Sender ID soit défini et un événement approprié sera journalisé pour renforcer la vigilance.
Dans Exchange Server 2007, il est facile de définir les domaines d'expédition et les destinataires d'Exchange Server qui doivent être exclus de la vérification Sender ID. Là aussi, cette option de configuration n'est disponible que via l'environnement de ligne de commande Exchange Management Shell. Par exemple, pour exclure le domaine contoso.com du filtrage Sender ID, exécutez la commande suivante :
Set-SenderIDConfig -BypassedSenderDomains contoso.com
De la même façon, pour exclure les messages envoyés à des destinataires d'Exchange Server spécifiés à partir du filtrage Sender ID, exécutez la commande suivante :
Set-SenderIDConfig -BypassedRecipients user@contoso.com
Dans Exchange Server 2007, les valeurs de configuration du Sender ID définies via les cmdlets de l'environnement de ligne de commande Exchange Management Shell mais non disponibles dans l'interface utilisateur graphique, peuvent être facilement obtenues en exécutant la commande Get-SenderIDConfig dans l'environnement de ligne de commande Exchange Management Shell comme illustré dans la figure 6.
Figure 6 Cmdlets de configuration Sender ID
Figure 6 Cmdlets de configuration Sender ID (Cliquer sur l'image pour la réduire)
Figure 6 Cmdlets de configuration Sender ID
Figure 6 Cmdlets de configuration Sender ID (Cliquer sur l'image pour l'agrandir)
L'environnement de ligne de commande Exchange Management Shell peut être utilisé pour effectuer une vérification manuelle rapide de l'adresse IP et du nom de domaine correspondant. Pour vérifier l'état Sender ID, exécutez la commande suivante :
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Si le domaine n'existe pas, vous verrez un résultat similaire à celui de la figure 7.
Figure 7 Vérifier l'état Sender ID d'une adresse
Figure 7 Vérifier l'état Sender ID d'une adresse (Cliquer sur l'image pour la réduire)
Figure 7 Vérifier l'état Sender ID d'une adresse
Figure 7 Vérifier l'état Sender ID d'une adresse (Cliquer sur l'image pour l'agrandir)

Avantages de Sender ID
Outre l'intérêt évident de l'authentification des messages électroniques et de la réduction de la quantité de courrier indésirable reçue par les utilisateurs, SIDF en tant que protocole présente d'autres avantages. Lors de son développement, Microsoft s'est concentré sur plusieurs objectifs clés, dont la performance, le coût, le déploiement, l'évolutivité et l'interopérabilité.
SIDF authentifie d'abord un expéditeur de message électronique et permet l'évaluation de la réputation de l'expéditeur. Par conséquent, il peut potentiellement réduire de manière significative les messages de courrier indésirable et les messages usurpés et améliorer la remise du courrier électronique légitime provenant d'expéditeurs connus et de confiance. La création d'un enregistrement SPF est gratuite, toute organisation qui désire donc être compatible avec SIDF peut faire ça facilement. Les organisations qui désirent être compatibles avec les paramètres d'un nouveau standard doivent pouvoir le faire. Avec SIDF, la compatibilité est aussi facile que la publication d'un enregistrement SPF.
SIDF a été développé pour fonctionner sur les logiciels existants partout où c'est possible. Il peut être utilisé avec un large éventail d'architectures de courrier électronique et de logiciels client et serveur. Pour être efficace, tout service d'authentification doit pouvoir satisfaire les besoins des fournisseurs de services Internet les plus importants aussi facilement que ceux du plus petit serveur de courrier électronique personnel. SIDF peut prendre en charge de un à plusieurs milliers de serveurs de courrier électronique, plus ceux qui externalisent leurs serveurs de courrier électronique vers une autre organisation.
Les 18 et 19 avril 2007, Microsoft et un consortium d'entreprises de plus de 30 organisations et partenaires vont accueillir le Sommet Authentification et Identification en ligne & à Boston, Massachussets. Ce programme de deux jours passera en revue des études de cas et proposera une étude technique du Sender ID, en détaillant la valeur commerciale de l'authentification du courrier électronique. Pour plus d'informations, consultez le site www.aotalliance.org/summit2007. Pour plus d'informations concernant les outils et les ressources, visitez les sites www.microsoft.com/senderid et microsoft.com/exchange.

Craig Spiezle est responsable de la stratégie technologique et de la planification pour Windows Live Safety chez Microsoft. En tant que chef de produit de l'authentification du courrier électronique, Craig a été un élément moteur dans l'avènement de Sender ID dans ce secteur. Depuis ses débuts chez Microsoft en 1992, Craig a occupé plusieurs postes de direction, y compris dans le secteur du marketing international, des stratégies de support technique, des OEM et du développement des marchés émergents.
Alexander Nikolayev est responsable de programme chez Microsoft, en charge des protocoles côté serveur, de Transport Core et des composants anti-spam pour Exchange Server et Windows Server. Il possède un MBA (Master of Business Administration) obtenu à l'université de Mary, Washington. Lisez les commentaires d'Alexander sur le blog de l'équipe Exchange sur blogs.technet.com/exchange.


 De la part de l'&#233;diteur: Pour un public plus large
De la part de l'éditeur
Pour un public plus large

TECHNET MAGAZINE NE SE RESUME PAS seulement à cette merveilleuse publication que vous tenez aujourd'hui dans les mains. Notre équipe a travaillé d'arrache-pied pour créer un nouveau site Web innovant qui rendra notre contenu accessible à plus d'un milliard de personnes dans le monde. À commencer par le numéro du mois de novembre, chaque article sera disponible en ligne dans sept langues : l'anglais, l'espagnol, le français, l'allemand, le russe, le chinois simplifié et le portugais brésilien. En ajoutant ces six langues supplémentaires (le contenu était déjà disponible en ligne en anglais !), le nombre des personnes pouvant utiliser notre contenu dans leur langue natale augmente de plus de 1,6 milliard. C'est incroyable !
Comme si cela ne suffisait pas, nous avons ajouté une ribambelle de fonctionnalités afin de rendre le site plus facile à utiliser. Grâce à nos nouveaux flux RSS personnalisables, vous pouvez sélectionner notre contenu en fonction d'une date, d'une rubrique, d'un auteur ou d'un sujet. Vous pouvez même associer et assortir les critères de sélection. Consultez la page technetmagazine.com/rss pour commencer dès aujourd'hui à créer vos propres flux.
Nous introduisons également des pages sur de nouveaux sujets. Si vous souhaitez tout savoir sur ce que les professionnels de l'informatique doivent faire pour se préparer à Windows Vista, il vous suffit de vous rendre sur la page technetmagazine.com/vista (en anglais). Si vous êtes administrateur, vous devez absolument consulter la page technetmagazine.com/exchange (en anglais) La page technetmagazine.com/topics comporte 32 sujets d'intérêt et d'autres viendront par la suite. (Au mois de novembre, nous avions 43 articles sur la sécurité attendant patiemment que vous leur accordiez votre attention.)
Et ce n'est pas tout. Vous pouvez désormais avoir un aperçu plus détaillé du magazine et du monde des professionnels de l'informatique. Joshua Hoffman, l'éditeur technique et des acquisitions de TechNet Magazine, gère le blog du magazine sur blogs.technet.com/tnmag. Quant à moi, j'anime un podcast mensuel sur notre site, à l'adresse www.technetmagazine.com/podcasts (en anglais). A chaque fois, je parlerai aux auteurs des articles que vous lisez, pour au-delà des mots expliquer de quoi il retourne. Vous adorerez entendre nos auteurs préférés parler de leurs articles et de leur travail.
Nous allons tout mettre en œuvre pour faire de TechNet Magazine la ressource la plus utile au monde pour les professionnels de l'informatique. L'année 2006 a été bonne, mais nous aimerions savoir ce que nous pourrions encore faire d'autre pour vous. Si vous avez des commentaires, envoyez-nous un message ! La hotline de la rédaction est la suivante tnmag@microsoft.com. Vos suggestions sont toujours les bienvenues.
£JOSHUA TRUPIN

Merci aux experts techniques Microsoft suivants : Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher et Scot Vidican.


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

Test de stress de vos applications Web
Outil de stress des applications Web WAPT
www.loadtestingtool.com
La connaissance du fonctionnement de la dernière version de votre application Web est essentielle pour dimensionner correctement votre infrastructure et éviter ces moments de pression où le PDG vous demande pourquoi elle obtient la réponse « Serveur encombré » lorsqu'elle contrôle le site. Et si vous êtes à la recherche d'un outil de test de stress et de performances de l'application Web relativement bon marché et simple d'utilisation, WAPT 4.0 de SoftLogica LLC pourrait répondre à vos besoins.
L'application s'exécute sur la plupart des versions Windows®, mais vous allez vouloir utiliser Windows 2000, Windows XP ou Windows Server® 2003 pour être le plus productif possible du fait des limitations de sockets sur les versions précédentes. Comme pour la plupart des applications de test de performances qui utilisent des utilisateurs virtuels, plus vous avez une mémoire importante, un processeur rapide et une connexion réseau importante et plus vous pourrez simuler d'utilisateurs virtuels avec WAPT.
La documentation annonce une limite d'environ 2000 utilisateurs virtuels pour un PIV 2.4 avec 512 Mo de RAL et une interface gig-e, mais ceci est fonction du type d'application que vous êtes en train de tester et de la manière dont vous configurez votre profil de test. Un autre facteur qui fera varier vos tests est le délai entre les requêtes, que WAPT vous laisse définir comme étant le temps de réflexion de l'utilisateur dans un profil d'utilisateur virtuel.
Une fois que vous avez défini un profil d'utilisateur virtuel (vous pouvez avoir différents scénarios par test), vous pouvez créer le plan de test pour ce profil. WAPT divise la séquence de test en trois parties : Actions initiales, principales et finales. Ce sont des séparations logiques plutôt que fonctionnelles, mais elles invitent à une division de votre fonction de connexion ou d'enregistrement, par exemple, dans la section initiale et à une division de l'action de déconnexion dans la section finale. WAPT vous permet de saisir les requêtes manuellement ou d'utiliser l'enregistreur de navigation intégré pour déterminer la manière dont vous souhaitez que les utilisateurs de ce profil surfent sur votre site. Ensuite, vous pouvez passer aux paramètres généraux pour déterminer qu'elle doit être la charge pour ce test et si vous souhaitez qu'elle soit fixe ou qu'elle augmente progressivement jusqu'au niveau souhaité sur une période de temps spécifiée. Pendant le test, WAPT peut vous proposer une vue en temps réel des statistiques de performances de votre scénario de test. Et lorsque vous avez terminé, vous pouvez enregistrer les résultats au format HTML ou CSV pour les réexaminer ultérieurement.
Prix : 350 dollars par machine.
La connaissance du fonctionnement de la dernière version de votre application Web est essentielle pour dimensionner correctement votre infrastructure et éviter ces moments de grosse pression lorsque le PDG vous demande pourquoi elle obtient la réponse « Serveur encombré » lorsqu'elle contrôle le site. Et si vous êtes à la recherche d'un outil de test de stress et de performance de l'application Web relativement bon marché et simple d'utilisation, WAPT 4.0 de SoftLogica LLC pourrait répondre à vos besoins.
L'application s'exécute sur la plupart des versions Windows®, mais vous allez vouloir utiliser Windows 2000, Windows XP ou Windows Server® 2003 pour être le plus productif possible du fait des limitations de sockets sur les versions précédentes. Comme pour la plupart des applications de test de performances qui utilisent des utilisateurs virtuels, plus vous avez une mémoire importante, un processeur rapide et une connexion réseau importante et plus vous pourrez simuler d'utilisateurs virtuels avec WAPT.
Outil de stress des applications Web WAPT
Outil de stress des applications Web WAPT (Cliquer sur l'image pour la réduire)
Outil de stress des applications Web WAPT
Outil de stress des applications Web WAPT (Cliquer sur l'image pour l'agrandir)
La documentation annonce une limite d'environ 2000 utilisateurs virtuels pour un PIV 2.4 avec 512 Mo de RAL et une interface gig-e, mais ceci est fonction du type d'application que vous êtes en train de tester et de la manière dont vous configurez votre profil de test. Un autre facteur qui fera varier vos tests est le délai entre les requêtes, que WAPT vous laisse définir comme étant le temps de réflexion de l'utilisateur dans un profil d'utilisateur virtuel.
Une fois que vous avez défini un profil d'utilisateur virtuel (vous pouvez avoir différents scénarios par test), vous pouvez créer le plan de test pour ce profil. WAPT divise la séquence de test en trois parties : Actions initiales, principales et finales. Ce sont des séparations logiques plutôt que fonctionnelles, mais elles invitent à une division de votre fonction de connexion ou d'enregistrement, par exemple, dans la section initiale et à une division de l'action de déconnexion dans la section finale. WAPT vous permet de saisir les requêtes manuellement ou d'utiliser l'enregistreur de navigation intégré pour déterminer la manière dont vous souhaitez que les utilisateurs de ce profil surfent sur votre site. Ensuite, vous pouvez accéder aux paramètres généraux pour déterminer quelle sera la charge pour ce test et si vous souhaitez qu'elle soit fixe ou qu'elle augmente progressivement jusqu'au niveau souhaité sur une période de temps spécifiée. Pendant le test, WAPT peut vous proposer une vue en temps réel des statistiques de performances de votre scénario de test. Et lorsque vous avez terminé, vous pouvez enregistrer les résultats au format HTML ou CSV pour une révision future.
Prix : 350 dollars par machine.

Critique
Content Networking Fundamentals
www.ciscopress.com
Le contenu est roi et Content Networking Fundamentals (Cisco Press, 2006) par Silvano Da Ros vous aide à améliorer rapidement votre infrastructure de distribution de contenu. Le livre se présente comme « une introduction générale à la théorie et aux applications pratiques de la mise en réseau de contenu » et il s'agit bien de cela. Même si, de toute évidence, le livre évoque largement l'équipement de mise en réseau de Cisco, il donne une bonne idée des différents éléments de mise en réseau de contenu ainsi que des instructions pratiques pour la mise en œuvre des principes sous-jacents à la mise en réseau de contenu et qui sont applicables quels que soient les types de produits de mise en réseau de contenu de votre infrastructure.
Le livre commence par une présentation détaillée des différents éléments de la mise en réseau du contenu (ce qui améliore véritablement la performance et la distribution de la couche 4 via la communication 7 du modèle OSI). Ensuite, le livre décrit de manière plus approfondie les principaux formats de présentation du contenu tels que XML, HTML, WAP ainsi que la transformation du contenu via XSLT à la frontière du réseau et comporte une section sur la distribution du média de diffusion. Enfin, l'évolutivité et la disponibilité sont abordées à travers des discussions sur l'équilibrage de la charge du serveur (à la fois au plan global et local), l'équilibrage de la charge du pare-feu et l'utilisation des périphériques de mise en cache de contenu tels que les commutateurs des services de contenu de Cisco.
Si vous utilisez des commutateurs de services de contenu dans votre infrastructure, vous serez intéressé par le chapitre sur la commutation de contenu sécurisé. Celui-ci vous décrira les détails de la configuration du module des services de contenu pour SSL (Secure Sockets Layer) ainsi que la configuration des URL et la réécriture des en-têtes. Généralement, les professionnels de la mise en réseau, quelle que soit la marque à laquelle ils sont fidèles, trouveront le chapitre sur QoS utile pour la compréhension des différents mécanismes de file d'attente et la gestion de l'encombrement.
En résumé, bien qu'il insiste beaucoup sur les implémentations matérielles Cisco (après tout, il est publié par Cisco Press), ce livre vous aidera à transformer l'expression « distribution de contenu » qu'on entend partout en méthodologies pratiques et applicables à votre infrastructure de distribution de contenu.
Prix : $55.00.

Surveiller vos services
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
La capacité à détecter (et si possible à résoudre) les problèmes au sein de l'organisation avant les utilisateurs finals est une qualité qui assure la réputation du bon professionnel en informatique. De ce fait, l'un des outils les plus importants dont peut disposer un professionnel de l'informatique est un système de surveillance efficace capable d'approfondir les différents services que vous fournissez afin de vérifier qu'ils fonctionnent convenablement. ExclamationSoft's WebWatchBot peut vous aider à parvenir à cela.
Cette application peut surveiller tous les services courants imaginables. Au lieu de se contenter de vérifier qu'un service est en cours d'exécution, WebWatchBot améliore le processus. En fait, il teste les services pour s'assurer qu'ils fonctionnent correctement. Par exemple, la vérification FTP peut effectivement télécharger un fichier en aval ou en amont, la surveillance DNS peut exécuter l'une quelconque des 40 commandes de requête différentes et rechercher une chaîne dans la réponse et les tests de POP3 et SMTP peuvent effectuer la journalisation et évaluer la performance de la messagerie.
WebWatchBot
WebWatchBot (Cliquer sur l'image pour la réduire)
WebWatchBot
WebWatchBot (Cliquer sur l'image pour l'agrandir)
De plus, WebWatchBot vous permet de chaîner une suite d'étapes dans une transaction et il signalera toute erreur ou toute latence inacceptable (selon les seuils que vous définissez) pour la transaction dans son ensemble. L'application surveillera également les URL HTTP et HTTPS et vérifiera le contenu spécifié. Vous pouvez même paramétrer des moniteurs de base de données qui exécuteront des requêtes et vérifieront les données par rapport à un modèle de réponse.
Prix : 495,95 dollars la licence utilisateur unique.

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


 Windows PowerShell: Des commandes simples Une administration puissante
Windows PowerShell
Des commandes simples Une administration puissante
Don Jones
Cette rubrique est basée sur une version préliminaire de Windows PowerShell. Toutes les informations contenues dans cette rubrique peuvent être amenées à évoluer.

Cela a pris du temps, mais aujourd'hui nous y sommes : Windows PowerShell est quasiment prêt à démarrer. Cela signifie que c'est désormais aux administrateurs Windows d'entrer dans le mouvement. Windows PowerShell propose sans doute la solution la plus facile et la plus souple pour automatiser une multitude de tâches administratives et ainsi améliorer l'efficacité de votre travail.
Mais, ce qui est encore plus important, Microsoft crée les consoles administratives graphiques de produits tels que Exchange Server 2007 et System Center 2007, intégrées à Windows PowerShell™. Ainsi, vous pourrez effectuer presque n'importe quelle tâche administrative à partir de Windows PowerShell. Microsoft prévoit à terme de poursuivre l'intégration des fonctionnalités d'administration de davantage de produits. Windows PowerShell pourrait donc finalement devenir le premier outil d'administration universel pour pratiquement tous les produits Microsoft server. Pour vous aider à démarrer, je traiterai régulièrement de Windows PowerShell dans cette nouvelle rubrique. Veillez à télécharger une copie du logiciel.

Puissance et simplicité
Comme son nom l'indique, Windows PowerShell est un environnement semblable à l'invite de commande (Cmd.exe) utilisée depuis Windows NT® 3.1. Cmd.exe ne va pas disparaître, mais depuis l'arrivée de Windows PowerShell, il y a peu de raisons de continuer à utiliser Cmd.exe.
L'utilisation de Windows PowerShell n'est pas si éloignée de celle de Cmd.exe, mis à part que Windows PowerShell est plus puissant. Comme Cmd.exe, Windows PowerShell dispose d'un langage de script intégré, mais celui-ci offre beaucoup plus de souplesse que le langage de commande Cmd.exe d'origine. Plus souple, dans quelle mesure ? Grâce à Windows PowerShell, vous pouvez automatiser des tâches extrêmement complexes à l'aide d'un langage qui contient seulement une demi-douzaine de mots-clés intégrés.
Maintenant que j'ai mentionné le script, je pense qu'il me faut à présent aborder la question de la sécurité. Windows PowerShell profite des connaissances acquises en matière de sécurité par Microsoft depuis plus d'une décennie. Par défaut, Windows PowerShell n'exécutera aucun script ; il peut seulement être utilisé de manière interactive pour exécuter des commandes individuelles. Si vous activez le script, vous pouvez demander à Windows PowerShell d'exécuter uniquement des scripts signés numériquement. Tout ceci dans le but de garantir que Windows PowerShell ne sera pas le prochain VBScript, un langage formidable dont l'usage a souvent été détourné pour créer des scripts malveillants. VBScript ne va pas disparaître non plus, mais vous allez très probablement trouver que Windows PowerShell est plus facile à utiliser pour accomplir de nombreuses tâches différentes.
Windows PowerShell vous permet d'effectuer presque toutes les opérations que vous auriez pu réaliser avec Cmd.exe. Par exemple, vous pouvez exécuter ipconfig et vous obtiendrez le résultat habituel. Cependant, Windows PowerShell propose un tout nouvel ensemble de commandes qui ne sont pas constituées de fichiers exécutables externes. Ces cmdlets (prononcer « command-lètes ») sont directement intégrées à Windows PowerShell. (Pour accéder aux cmdlets les plus utiles qui vous initieront à l'utilisation de Windows PowerShell, reportez-vous à la barre latérale « Top 10 des Cmdlets à utiliser immédiatement ».)
Top 10 des Cmdlets à utiliser immédiatement
  • La commande Get-Command permet d'afficher la liste de toutes les cmdlets disponibles.
  • La commande Get-Help permet d'afficher des informations d'aide sur les cmdlets et les concepts.
  • La commande Get-WMIObject permet d'afficher des informations de gestion en utilisant WMI.
  • La commande Get-EventLog permet d'afficher les journaux d'événements Windows.
  • La commande Get-Process permet d'afficher un ou plusieurs processus actifs sous forme de liste.
  • La commande Get-Service permet d'afficher un service Windows.
  • La commande Get-Content lit les données des fichiers texte, traitant chaque ligne comme un objet enfant.
  • La commande Add-Content permet d'ajouter du contenu dans un fichier texte.
  • La commande Copy-Item permet de copier des fichiers, des dossiers et d'autres objets.
  • La commande Get-Acl permet d'afficher des listes de contrôles d'accès (ACL).
Pour obtenir la liste complète des cmdlets fournies avec Windows PowerShell, visitez la page windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx.
Les noms des cmdlets ayant tous le format standard verbe/nom, ils se retiennent facilement. Par exemple, si vous exécutez la cmdlet Get-Command, vous obtiendrez la liste de toutes les cmdlets disponibles. Get-WMIObject est sans doute la cmdlet la plus utile pour un administrateur. Imaginons que vous voulez savoir quel Service Pack est exécuté sur le Serveur2. Il vous suffit d'exécuter la cmdlet :
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Pour obtenir la même information avec VBScript, il vous faudrait écrire plusieurs lignes de code. D'autres cmdlets vous permettent de traiter, parmi tant d'autres, des services (Start-Service, Stop-Service, etc), des processus (Stop-Process et autres), des fichiers (Rename-Item, Copy-Item, Remove-Item, Move-Item, par exemple), etc. La plupart de ces cmdlets ont même des noms de raccourcis, qu'on appelle des alias. Pour exécuter la commande Get-WMIObject, il vous suffit de saisir « gwmi ». Exécutez Get-Alias pour obtenir la liste de ces noms de raccourcis.

Pourquoi l'approche orientée objet est décisive
Basé sur le Microsoft® .NET Framework, Windows PowerShell est entièrement orienté objet. D'habitude, seul un développeur de logiciel serait enthousiasmé par cette idée, mais dans ce cas, l'approche orientée objet permet aux administrateurs de gagner un temps considérable. En effet, ces derniers peuvent désormais traiter des objets étendus dans un environnement texte. Examinez cet exemple :
Get-Process | Sort-Object pm –desc | Select-Object –first 10
Il s'agit d'une ligne unique comportant trois cmdlets différentes, séparées par des canaux (sur lesquels nous reviendrons dans un instant). La première cmdlet récupère tous les processus en cours d'exécution, puis transfère ces objets vers la commande Sort-Object. Cette deuxième cmdlet trie par ordre décroisant les objets de processus en fonction de leur consommation de mémoire physique. L'ensemble d'objets de processus triés est ensuite transféré vers Select-Object, qui extraie et affiche les 10 premiers objets. Résultat ? Cette simple ligne affiche les 10 objets qui consomment le plus de mémoire physique sur la machine, comme l'illustre la figure 1. Ceci est extrêmement efficace pour obtenir un aperçu rapide lors d'un dépannage.
Figure 1 Utilisation d'une Cmdlet simple pour effectuer un dépannage
Figure 1 Utilisation d'une Cmdlet simple pour effectuer un dépannage (Cliquer sur l'image pour la réduire)
Figure 1 Utilisation d'une Cmdlet simple pour effectuer un dépannage
Figure 1 Utilisation d'une Cmdlet simple pour effectuer un dépannage (Cliquer sur l'image pour l'agrandir)
L'utilisation de canaux (caractères en forme de ligne verticale généralement situés sur la touche de barre oblique inverse sur les claviers américains) constitue un élément essentiel dans l'étendue des capacités de Windows PowerShell. Utilisez ce caractère pour transférer les objets d'une cmdlet à l'autre, pour affiner les résultats, les formater, etc. Ce mécanisme fonctionne car chaque cmdlet retourne un ou plusieurs objets au lieu du texte pur et fournit aux cmdlets suivantes l'intégralité de l'objet en vue de son traitement.
L'utilisation d'objets dans Windows PowerShell est prépondérante, jusque dans ses variables. Par ailleurs, vous n'avez pas à déclarer les variables en amont ; vous pouvez commencer simplement à les utiliser en faisant précéder le nom d'une variable par le caractère dollar ($). Même si cela n'est pas obligatoire, vous pouvez également indiquer à Windows PowerShell le type de données que vous voulez insérer dans la variable. Windows PowerShell met en correspondance la variable et l'un des types extrêmement puissants de .NET Framework, ce qui vous permet d'obtenir de nombreuses fonctionnalités intégrées supplémentaires. Par exemple, supposez que vous voulez demander un nom d'ordinateur et récupérer la version de Service Pack de cet ordinateur, mais vous ne savez pas si la personne qui saisit le nom de l'ordinateur entrera deux barres obliques inverses (comme \\Serveur2). Comme vous savez que la cmdlet Get-WMIObject ne nécessite pas les barres obliques inverses, vous pouvez sauvegarder le nom de l'ordinateur dans une variable de chaîne et utiliser la méthode Replace pour remplacer les barres obliques inverses par des chaînes vides, comme suit :
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
La valeur du paramètre –Computer est fournie dans la variable $c. Cette variable a été initialement créée comme une chaîne. Ainsi, elle a sélectionné toute la fonctionnalité du type de chaîne .NET Framework, y compris la méthode Replace. Bien sûr, il vous faudra du temps pour découvrir toutes ces fonctionnalités, mais vous les dénicherez facilement dans les exemples. Windows PowerShell lui-même simplifie l'apprentissage. Par exemple, si vous saisissez $c = $c. (n'oubliez pas le point) et que vous appuyez sur la touche de tabulation, Windows PowerShell affiche Clone(), la première méthode du type chaîne. Si vous maintenez la touche de tabulation appuyée, Windows PowerShell passera en revue toutes les méthodes disponibles. Fondamentalement, lorsque vous procédez ainsi, Windows PowerShell vous démontre ce qu'il sait faire avec une chaîne !
À présent, voici une tâche plus ardue. lire une liste de noms d'ordinateurs depuis un fichier, avec un nom par ligne, et afficher le numéro de Service Pack de chaque ordinateur. Dans VBScript, l'exécution de cette tâche nécessiterait au mois une douzaine de lignes de code. Dans Cmd.exe, il vous faudrait utiliser un fichier batch compliqué. Dans Windows PowerShell, il suffit de saisir une seule ligne pour exécuter cette tâche :
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
La cmdlet Get-Content lit le contenu du fichier C:\Ordinateurs.txt. Chaque ligne du fichier devient un objet en tant que tel. Ce groupe d'objets (c.-à-d. les noms d'ordinateur) est transféré à la commande Foreach qui constitue tout simplement un alias pour la cmdlet ForEach-Object. Les commandes comprises dans les accolades sont répétées une fois par objet transféré. Dans cet exemple, cela signifie qu'elles sont exécutées une fois pour chaque nom d'ordinateur. La variable spéciale $_ contiendra l'objet courant (c.-à-d., le nom d'ordinateur courant).
Les accolades contiennent effectivement deux commandes : La première affiche simplement le nom d'ordinateur courant en éditant le contenu de $_. La deuxième correspond à la désignation « gwmi » que vous connaissez bien maintenant. Une liste des versions de Service Pack s'affiche pour chaque ordinateur répertorié dans ce fichier. Tout ceci a été effectué à l'aide d'une ligne de commande relativement simple.
Notez que les noms de paramètre –Property et –Computer ont été abrégés. Windows PowerShell n'a besoin que du stricte nécessaire pour distinguer de façon univoque les noms de paramètre.

Lisibilité et réutilisation
L'écriture d'une seule ligne de commandes et de paramètres ne contribue toutefois pas à la lisibilité. Windows PowerShell vous permet d'améliorer la lisibilité des commandes que vous pouvez saisir directement dans l'application sans avoir écrire de script. Voici comment cela peut se présenter :
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
Cette fois-ci, le contenu du fichier est stocké dans la variable $names. Cet exemple utilise toujours Foreach, mais la commande n'est pas entrée via un canal, de sorte que vous devez lui indiquer les ensembles d'objets à passer en revue et la variable dans laquelle sera stocké chaque objet. Il s'agit de la partie qui contient : ($name in $names). Tout le reste est à peu près similaire. Dès que vous appuyez sur Entrée, le code est exécuté et les résultats s'affichent.
Si vous souhaitez répéter le même code, il vous suffit d'en faire une fonction. Entrez de nouveau le code directement dans l'environnement :
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Comme vous pouvez le voir, rien n'a vraiment changé. L'exemple précédant est tout simplement repris dans une fonction appelée Get-ServicePacks (qui conserve la convention de nom verbe/nom de Windows PowerShell). La fonction a maintenant le paramètre d'entrée "$file" qui a été substitué dans la cmdlet Get-Content, de sorte qu'un fichier différent peut être spécifié lorsque la fonction est exécutée. À présent que la fonction est définie, exécutez-la tout simplement en appelant son nom, pratiquement comme une cmdlet, puis en transférant le paramètre d'entrée :
PS C:\> Get-ServicePacks c:\computers.txt
La figure 2 illustre les résultats.
L'inconvénient est que cette fonction n'existera que le temps pendant lequel cette instance de Windows PowerShell est exécutée. Une fois que vous fermez l'application, la fonction est supprimée. Vous pouvez copier la fonction dans votre profil Windows PowerShell, qui est une sorte de script qui s'exécute automatique à chaque démarrage de Windows PowerShell. En procédant ainsi, la fonction sera disponible dans chaque fenêtre Windows PowerShell que vous ouvrez. Ou, si vous le souhaitez, vous pouvez définir la fonction dans un script autonome, que vous pouvez ensuite exécuter simplement en entrant le chemin du script et le nom de fichier.
Figure 2 Résultats de l'exécution de la fonction Get-ServicePacks
Figure 2 Résultats de l'exécution de la fonction Get-ServicePacks

Le monde est un fichier (ou un dossier)
Windows PowerShell, c'est bien plus que des fonctions et des cmdlets. Attardons-nous sur la gestion de fichiers pour illustrer rapidement les autres fonctionnalités offertes par Windows PowerShell . La navigation dans les dossiers et les lecteurs dans Cmd.exe n'a sans doute plus aucun secret pour vous : vous tapez « C » pour accéder au lecteur C et "cd \test" pour passer dans le dossier C:\Test. Windows PowerShell fonctionne exactement de la même manière, bien que cd est simplement un alias de la cmdlet Set-Location.
Essayez d'exécuter Get-PSDrive, la cmdlet qui répertorie tous les lecteurs disponibles. Outre les lecteurs C:, D: et éventuellement A:, vous en trouverez également un nommé « Cert », un autre nommé « Env » et enfin deux autres nommés « HKCU » et « HKLM ». Windows PowerShell fait réellement preuve de nombreux types de ressources de stockage sous forme de « lecteurs », semblables à des magasins de certificats, à des variables d'environnement et à un registre, tous disponibles dans un environnement comparable à une interface de navigation par fichiers habituelle.
Passez à la ruche de registre HKEY_LOCAL_MACHINE en saisissant Set-Location HKLM : (ou cd hklm : si vous préférez le raccourci), puis appuyez sur Entrée. Exécutez ensuite cd software\microsoft pour passer dans la clé SOFTWARE\Microsoft. Vous pouvez utiliser dir (un alias de la cmdlet Get-ChildItem) pour répertorier les sous-clés dans cette portion du registre. Si vous souhaitez supprimer une clé, utilisez del pour la supprimer comme s'il s'agissait d'un fichier ou d'un dossier. (Soyez très prudent, de graves problèmes peuvent se produire si vous supprimez les clés requises ou si vous modifiez le registre de façon incorrecte.)
Toute cette souplesse provient des fournisseurs qui mettent en correspondance les ressources (comme le registre et le magasin de certificats) dans un format qui ressemble à un système de fichiers. Microsoft prévoit d'étendre Windows PowerShell en ajoutant des fournisseurs, pour vous permettre, par exemple, de naviguer dans un magasin Exchange Server comme dans un système de fichiers. Il s'agit d'une technique très importante. Elle utilise la grande variété de référentiels utilisés par Windows et les fait tous apparaître de façon identique. Par ailleurs, elle permet de les gérer via un système de commandes et des procédés que vous connaissez déjà bien.

Conçu pour la sécurité
J'ai déjà mentionné le fait que la conception de Windows PowerShell tient compte des aspects liés à la sécurité. La première caractéristique de sécurité de Windows PowerShell est constituée par sa politique d'exécution. Par défaut, cette politique est définie sur Restreint, ce que vous pouvez vérifier en exécutant la cmdlet Get-ExecutionPolicy. En mode Restreint, les scripts ne sont pas exécutés. Point. Comme il s'agit du mode par défaut, Windows PowerShell ne peut pas être utilisé pour exécuter des scripts prêts à l'emploi.
Vous pouvez spécifier d'autres modes en utilisant la cmdlet Set-ExecutionPolicy. Personnellement, je préfère le mode RemoteSigned. Ce mode permet d'utiliser les scripts locaux (mais pas les scripts distants) sans qu'il soit nécessaire d'appliquer une signature numérique, ce qui permet de développer et tester des scripts avec beaucoup de facilité. Le mode AllSigned exécute uniquement les scripts dotés d'une signature numérique, au moyen d'un certificat délivré par un éditeur de confiance. Enfin, la stratégie Non restreinte exécute tout. Je la déconseille fortement, car elle laisse Windows PowerShell exécuter des scripts malveillants qui ont pu accéder à votre ordinateur. Notez que la stratégie d'exécution peut également être commandée par la stratégie de groupe, qui remplace tout paramètre local. (Set-ExecutionPolicy vous préviendra si les paramètres d'une stratégie de groupe remplacent vos paramètres locaux.)
En outre, Windows PowerShell n'exécutera pas les scripts de votre répertoire actuel, sauf si vous spécifiez le chemin. Cela doit permettre d'éviter tout piratage de commande. Imaginez que quelqu'un crée un script appelé IPConfig.ps1 (PS1 est l'extension des fichiers script Windows PowerShell). S'il était possible d'exécuter des fichiers en dehors du dossier actuel, vous risqueriez de taper ipconfig et d'exécuter le script créé par cet utilisateur, alors que vous aviez en fait l'intention d'exécuter le programme Windows Ipconfig.exe. Comme Windows PowerShell n'exécute pas les scripts en dehors du dossier actuel, cette erreur est impossible. Mais si vous souhaitez exécuter un script en dehors du dossier actuel, il suffit de spécifier le chemin : .\myscript, par exemple. Grâce à cette référence explicite au dossier actuel, vous êtes sûr d'exécuter un script et non une commande shell.
Windows PowerShell inclut également des fonctionnalités permettant d'améliorer la sécurité des tests. Par exemple, envisagez (mais s'il vous plaît, sans essayer) cet inquiétant cas de figure :
Get-Process | Stop-Process
La cmdlet Get-Process crée un ensemble d'objets de processus et les transfère vers la cmdlet Stop-Process, qui va vraiment les interrompre ! Cette action entraîne l'affichage, au bout d'environ cinq secondes, d'un écran bleu d'erreur STOP, car des processus Windows essentiels sont supprimés. Mais il est possible de voir ce qui se produira sans que cela se produise vraiment, en ajoutant le paramètre très pratique Whatif :
Get-process | Stop-Process -Whatif
L'exécution de ce paramètre dans Windows PowerShell entraîne la production d'un flot de déclarations, indiquant quelles auraient été les conséquences de l'utilisation de ces cmdlets, sans que vous les ayez vraiment activées. Le système d'aide en ligne de Windows PowerShell (accessible grâce à l'alias d'aide) ne décrit pas encore le paramètre Whatif, mais pensez-y. Il s'agit d'un outil précieux pour tester les scripts et les cmdlets, sans pour autant risquer des dommages ou perturbations potentielles.

Conclusion
Parmi les caractéristiques non incluses dans cette version de Windows PowerShell, la plus importante est peut-être le support de Active Directory® Services Interface (ADSI). Tandis que Windows PowerShell peut utiliser les classes .NET très robustes qui fonctionnent avec Active Directory et d'autres services d'annuaire, elle ne dispose pas encore d'une cmdlet Get-ADSIObject appropriée. En conséquence, il est un peu difficile de travailler avec des objets d'annuaire.
De même, Windows PowerShell propose souvent de nombreuses méthodes différentes pour exécuter la même tâche. C'est avantageux, mais cela peut compliquer l'apprentissage de Windows PowerShell car pour une tâche donnée, vous pouvez voir s'afficher une demi-douzaine d'exemples de méthodes.
Cela sera corrigé à terme et l'équipe Windows PowerShell continuera d'ajouter des fonctionnalités au produit. Pour rester dans la boucle, visitez le blog de l'équipe.

Don Jones est le fondateur de ScriptingAnswers.com et le co-auteur de Windows PowerShell : TFM (SAPIEN Press, 2006). Vous pouvez le contacter à l'adresse suivante :don@scriptinganswers.com.


 Post mortem: Migration &#224; partir d'Exchange&#160;5.5
Post mortem
Migration à partir d'Exchange 5.5
Whitney Roberts

LE PROJET
Le département de l'éducation du Kentucky avait besoin de migrer de son implémentation existante Microsoft® Exchange Server 5.5 vers Exchange Server 2003. Le système prend en charge environ 600 000 professeurs, étudiants et autre personnel au cours d'une année scolaire.
LES INTERVENANTS
Le projet a été géré par l'OET (Office of Education Technology) du ministère de l'éducation du Kentucky assisté des consultants de KiZAN Technologies. Le personnel de l'OET a fourni une vue d'ensemble de l'implémentation Exchange 5.5. L'exécution au jour le jour des serveurs Exchange était de la responsabilité du personnel local des circonscriptions scolaires.
LES DÉFIS
Le ministère de l'éducation assure la direction technique des 178 circonscriptions scolaires de l'État du Kentucky (Commonwealth of Kentucky). Ces circonscriptions scolaires sont reliées les unes aux autres via un WAN mais chacune héberge son propre serveur Exchange 5.5 géré en local, qui nécessitait d'être mis à niveau de façon individuelle. Cette mise à niveau devait permettre une prise en charge pour les clients en mode mis en cache Outlook® 2003, une pratique d'Outlook Web Access (OWA) améliorée, un schéma d'adressage électronique standardisé et bien d'autres choses.
Outre la mise en œuvre d'une nouvelle infrastructure cliente et de serveur de messagerie, plusieurs des circonscriptions scolaires ajoutaient la prise en charge du courrier électronique pour les étudiants. La police fédérale et gouvernementale ont toutes deux exigé que les informations des étudiants soient protégées et ne soient pas visibles hors de leur circonscription respective.
LE PROGRAMME
Étant donné qu'un ADC (connecteur Active Directory®) ne pouvait pas être utilisé, nous avons créé une nouvelle organisation Exchange et avons migré vers elle. Utiliser des adresses électroniques standardisées signifiait créer de nouveaux sous-domaines d'identification pour chaque circonscription scolaire et près de 400 nouvelles stratégies de destinataire. La protection des adresses des étudiants a nécessité la construction d'un système de listes d'adresses globales (LAG) et de listes d'adresses personnalisées pour chaque circonscription scolaire.
La migration effective impliquait d'activer du nouveau matériel, de créer et de configurer des boîtes aux lettres basées sur l'appartenance à la circonscription et le type d'utilisateur et de configurer des attributs d'extension basés sur l'appartenance à la circonscription et le type d'utilisateur de façon à ce que l'utilisateur s'affiche dans les listes d'adresses appropriées.
Nous avons créé une application basée sur Visual Basic® pour détecter et corriger les attributs de comptes ou les appartenances aux groupes mal configurés et pour attribuer correctement de nouvelles boîtes aux lettres et garantir que les exigences en matière de visibilité étaient conservées. L'application a été déployée dans les 178 circonscriptions et fonctionne de façon temporisée à partir des serveurs des circonscriptions scolaires.

Contexte
À première vue, ce travail peut ne pas sembler une tâche délicate ou techniquement difficile. Pourtant, comme on me l'a fait remarquer, les exigences de fonctionnement sont prioritaires et les exigences de fonctionnement de ce projet nous ont ouvert les yeux.
Au fil des années, la décentralisation de la gestion et un méli-mélo au niveau des normes ont créé de nombreux « silos » de prise en charge qui la plupart du temps devaient être gérés par l'OET. En outre, l'OET devait également s'assurer que l'implémentation Exchange 5.5 était conforme aux exigences des circonscriptions scolaires et à celles du ministère de l'éducation. Ceci signifiait que pour les circonscriptions qui utilisaient le courrier électronique des étudiants, les informations de ces derniers devaient être protégées et ne pas être visibles hors de la circonscription concernée, comme défini par les normes fédérales et gouvernementales (voir la page ed.gov/policy/gen/guid/fpco/ferpa/index.html, en anglais).
Dans Exchange 5.5, ces normes signifiaient que les données des étudiants au sein de la circonscription ne pouvaient pas être répliquées vers les autres circonscriptions scolaires ou les autres agences gouvernementales qui partageaient les données LAG. Cela nécessitait en particulier de passer par un processus d'exportation/importation manuel pour chacun des 178 sites Exchange 5.5 : masquer les étudiants, répliquer la liste, ne plus masquer les étudiants et enfin réimporter la liste d'adresses. De cette façon, les autres circonscriptions ne pouvaient visualiser que les données du personnel et la circonscription scolaire propriétaire des informations pouvait visualiser toutes les données la concernant mais seulement les données du personnel des autres circonscriptions scolaires.
Compte tenu des forces et des faiblesses du système existant, la mise à niveau de l'infrastructure de messagerie devait remplir certains critères spécifiques. Tout d'abord, le département de l'éducation du Kentucky souhaitait utiliser un schéma d'affectation de nom SMTP lisible commun qui soit généralisé à toute l'organisation. Le schéma devait fournir des espaces d'adressage SMTP différents pour les professeurs et les étudiants.
Le nouveau système devait également fournir un service géré de manière centralisée qui enlèverait à la circonscription la gestion et la responsabilité de la mise à disposition de la messagerie. Ceci comprenait la centralisation de la gestion de la récupération des données après sinistre, du flux de messages et de la résolution des appels au support technique. Par conséquent, le nouveau système devait fournir une méthode centralisée pour généraliser la configuration utilisateur dans toutes les circonscriptions, quelle que soit la situation géographique ou l'affiliation à une circonscription d'un utilisateur donné.
Le nouveau système devait ensuite fournir un accès Web et via des appareils mobiles sécurisé au courrier électronique en passant par un espace de noms unifié commun à toutes les circonscriptions.
Compte tenu de ces exigences (dont beaucoup n'étaient pas encore implémentées dans le système Exchange 5.5 existant) la mise à niveau vers Exchange 2003 semblait assez impressionnante.

Blocs de génération de la solution
Pour satisfaire aux exigences de fonctionnement, plusieurs options propres à Exchange ont été choisies pour le déploiement.
Étant donné le manque de standardisation et l'importance particulière de l'environnement Exchange 5.5, un ADC ne pouvait pas être utilisé. Au lieu de cela, nous avons créé une nouvelle organisation Exchange et avons migré dans celle-ci.
Le nettoyage et la standardisation des adresses électroniques pour le personnel et les étudiants de chaque circonscription ont engendré la création de plus de 400 nouvelles stratégies de destinataire. Les exigences imposaient qu'il y ait un sous-domaine d'identification unique pour chaque circonscription, comprenant une désignation d'identification de la circonscription pour les étudiants. Par exemple, dans le cas du comté de Shelby, le sous-domaine primaire devait être shelby.kyschools.us. Les étudiants de chaque circonscription ont reçu une désignation de sous-domaine stu., afin que les étudiants du comté de Shelby aient des adresses stu.shelby.kyschools.us.
Une autre contrainte était que les adresses des étudiants ne devaient être visibles que dans la circonscription de ces étudiants, alors que les adresses du personnel devaient être visibles dans toutes les circonscriptions. Cela supposait la construction d'un système élaboré de LAG et de listes d'adresses personnalisées, comme présenté dans la figure 1 et la figure 2. L'un des avantages de passer à Exchange 2003 était que les listes d'adresses pouvaient être sécurisées par des autorisations et que l'accès à chaque liste d'adresses individuelle pouvait être contrôlé en fonction de l'appartenance à un groupe. Nous avons fait bon usage de cette fonctionnalité et avons créé deux groupes de sécurité au niveau de la circonscription (l'un pour le personnel et l'autre pour les étudiants), puis nous avons sécurisé les LAG et les listes d'adresses des étudiants et du personnel correspondantes de sorte que seul les comptes utilisateur d'une circonscription spécifique aient accès à certaines listes d'adresses. En supprimant la LAG et les listes d'adresses par défaut puis en s'assurant que les groupes Tous les utilisateurs et Utilisateurs authentifiés n'étaient pas répertoriés sur la liste de contrôle d'accès (ACL) pour chaque liste d'adresses, nous pouvions présélectionner la liste d'adresses qu'un type d'utilisateurs spécifique d'une circonscription spécifique pourrait voir.
Figure 1 Listes d'adresses personnalisées basées sur les rôles
Figure 1 Listes d'adresses personnalisées basées sur les rôles (Cliquer sur l'image pour la réduire)
Figure 1 Listes d'adresses personnalisées basées sur les rôles
Figure 1 Listes d'adresses personnalisées basées sur les rôles (Cliquer sur l'image pour l'agrandir)
Cependant, les autorisations ne résolvaient qu'une partie du problème de la visibilité. Il nous fallait trouver un moyen de contrôler ce qui était visible et dans quelle liste d'adresses. Une requête LDAP (Lightweight Direct Access Protocol) de base a été créée pour nous permettre d'effectuer la demande de la visibilité des étudiants et du personnel ; la requête a alors été légèrement adaptée à chaque liste d'adresses et LAG. Par exemple, la requête LDAP pour la LAG du personnel de Shelby ne devait montrer que les étudiants et le personnel concernés de Shelby et tout le personnel (mais pas les étudiants) de toutes les autres circonscriptions de l'état. La LAG des étudiants de Shelby ne devait montrer que le personnel et les étudiants de Shelby et pas le personnel ou les étudiants des autres circonscriptions dans l'état. Nous avons répété cette requête pour toutes les autres circonscriptions de l'organisation. La figure 3 présente les exemples de quelques requêtes LDAP utilisées dans cette migration complexe.
Figure 3 Requête LDAP de liste d'adresses (Close Figure 3)

Requête LDAP de LAG du personnel
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Requête LDAP de liste d'adresses de la circonscription
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Requête LDAP de liste d'adresses des étudiants de la circonscription
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Requête LDAP de liste d'adresses hors connexion de la circonscription
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Figure 2 Listes d'adresses globales différenciant le personnel des étudiants
Figure 2 Listes d'adresses globales différenciant le personnel des étudiants (Cliquer sur l'image pour la réduire)
Figure 2 Listes d'adresses globales différenciant le personnel des étudiants
Figure 2 Listes d'adresses globales différenciant le personnel des étudiants (Cliquer sur l'image pour l'agrandir)
Les valeurs personnalisées pour les propriétés de l'utilisateur Exchange extensionAttribute14 (attribut personnalisé 14) et extensionAttribute15 (attribut personnalisé 15) constituaient le mécanisme de différenciation sous-jacent aux requêtes LDAP. Tout le personnel et les étudiants d'un bout à l'autre de l'État utilisaient une valeur spécifique pour extensionAttribute14 pour désigner le type d'utilisateur et une valeur unique dans extensionAttribute15 pour afficher l'appartenance à la circonscription. En utilisant des valeurs uniques pour chaque circonscription et les mêmes valeurs pour chaque type d'utilisateur, les listes d'adresses pouvaient afficher avec exactitude les informations requises pour chaque type d'utilisateur dans chaque circonscription.
Ces listes d'adresses fonctionnaient plutôt bien en ce qui concerne l'accès des utilisateurs au courrier électronique via Outlook en mode hors cache ou via OWA. (Nous dirigions chaque utilisateur vers la liste d'adresses correcte dans OWA à l'aide de l'attribut msExchQueryBaseDN.) Mais pour les utilisateurs exécutant Outlook en mode mis en cache, cela présentait un autre problème. Outlook ne considèrera pas une LAG personnalisée comme étant le carnet d'adresses en mode hors connexion désigné ; aussi avons-nous donc dû créer des listes d'adresses supplémentaires qui étaient des copies des LAG. Chaque banque de boîtes aux lettres de la circonscription a alors été configurée avec la liste d'adresses du carnet d'adresses en mode hors connexion appropriée pour ses utilisateurs en mode mis en cache. En tout, cette solution plafonnait à plus de 1 500 listes d'adresses pour offrir des fonctions complètes aux différents types d'utilisateurs dans les 178 circonscriptions.

Garantie de la conformité
Pour s'assurer que la structure qui était mise en place fonctionnerait correctement, l'adhésion aux normes nouvellement établies était d'une importance capitale. Plusieurs tâches de haut niveau devaient se produire pour chaque utilisateur autorisé Exchange dans l'organisation. Cela s'explique par le fait que chaque utilisateur doit être correctement localisé sur tous les serveurs Exchange de la circonscription et doit également être visible sur les bonnes listes d'adresses.
L'utilisateur devait être membre du groupe de sécurité approprié au sein du domaine de la circonscription car le groupe de sécurité fournit les autorisations pour ouvrir la liste d'adresses appropriée. L'utilisateur avait également besoin que l'attribut msExchQuerybaseDN soit correctement défini en fonction de l'appartenance à la circonscription et à l'unité d'organisation. L'unité d'organisation de l'utilisateur déterminait le type d'utilisateur.
L'étape suivante consistait à créer la boîte aux lettres de l'utilisateur sur la bonne banque et sur le serveur approprié en fonction de l'appartenance à la circonscription et du type d'utilisateur. Ceci avait un impact sur les niveaux de service, les limites de taille de boîtes aux lettres et les listes d'adresses des carnets d'adresses en mode hors connexion de telle manière que le mode mis en cache d'Outlook puisse fonctionner correctement. Les attributs d'extension étaient définis en fonction de l'appartenance à la circonscription et du type d'utilisateur de sorte que l'utilisateur puisse apparaître dans les listes d'adresses appropriées et ne soit pas visible dans les autres.
Enfin, nous devions fournir un moyen de corriger automatiquement tout attribut de compte ou toute appartenance aux groupes dans le cas où ces éléments auraient été mal définis par erreur sur des valeurs inappropriées ou modifiés. Si un utilisateur passe d'une unité d'organisation à une autre au sein du domaine de la circonscription, cela signifie que la classification d'un utilisateur est modifiée et que l'emplacement de la boîte aux lettres, le choix de la LAG et la visibilité de la liste d'adresses doivent être mis à jour.
Nous avions besoin d'un système d'attribution de privilèges qui accomplirait ces tâches et assurerait la cohérence du système et l'exactitude des données d'Active Directory. Nous avons créé une application Visual Basic basée sur une console qui s'exécute de façon temporisée à partir des serveurs Exchange 2003 des circonscriptions scolaires. L'application, qui certifie le respect des normes et de la stratégie et gère également la création de nouveaux objets et l'attribution de privilèges d'accès, a été déployée sur les 178 circonscriptions.
Nous avons pensé que les tâches en cours étaient trop complexes pour qu'une série de scripts puisse fonctionner rapidement et de façon fiable. Par conséquent, l'application Visual Basic a été considérée comme la solution appropriée parce qu'elle était efficace, prenait en charge la gestion des exceptions et des erreurs de façon structurée et que son code interne pourrait être facilement adapté au code d'extension Microsoft Identity Integration Server (MIIS) à l'avenir avec une réécriture minimale.
Puisque nous devions migrer vers une nouvelle organisation, il nous fallait créer une méthode de cohabitation. Il y avait plus de 178 domaines SMTP hérités à prendre en charge dans le nouvel environnement £ certaines circonscriptions avaient des domaines de courrier électronique préexistants pour les étudiants et d'autres non £ mais nous avions la chance de pouvoir faire migrer les circonscriptions une par une et d'amener les messages et les adresses hérités sur le nouveau système sans que cela n'affecte les autres circonscriptions. Il nous fallait cependant éviter d'interrompre le flux de messages lors de la migration d'une circonscription d'Exchange 5.5 à Exchange 2003. Cela supposait d'implémenter un certain type de synchronisation des répertoires entre Active Directory d'Exchange 2003 et le répertoire Exchange 5.5 hérité. Microsoft accordait aux services de l'éducation du Kentucky une utilisation limitée de MIIS pour le temps de la migration uniquement et du code d'extension personnalisé a donc été développé et utilisé pour synchroniser les deux organisations Exchange via MIIS avant, pendant et après la migration.
Le transfert vers une nouvelle organisation Exchange affecte naturellement la configuration du client MAPI. Les services de l'éducation ont été confrontés au fait qu'il y avait littéralement des dizaines de milliers de profils MAPI au niveau de la circonscription qui devaient être reconfigurés pendant la migration. Heureusement, Microsoft a sorti Exchange Profile Tool (l'outil de profil Exchange, ExProfRe.exe), qui a été utilisé pour la migration de profil dans les circonscriptions. Nous avons créé un installateur empaqueté qui exécutait ExProfRe.exe avec des valeurs préchargées de sorte que les migrations de profil au niveau de la circonscription puissent être effectuées de façon automatique. Le programme était appelé via la stratégie de groupe. Nous avons obtenu un taux de réussite de près de 100 pour cent sur les migrations de profil automatisées entre organisations.

Mises à niveau matérielles
Les nouveaux serveurs Exchange 2003 allaient remplacer les serveurs Exchange 5.5 qui étaient dispersés géographiquement ; du point de vue matériel, cette solution devait donc prendre en charge le même nombre d'utilisateurs que le déploiement Exchange 5.5, plus le chargement des comptes étudiants supplémentaires. Les serveurs devaient être hébergés en local au sein des circonscriptions car la topologie WAN était conçue de telle façon que la totalité du trafic inter-circonscription (Internet et interne) puisse circuler sur une ligne T1 privée (Pour certaines circonscriptions, sur plusieurs lignes T1).
En raison de contraintes budgétaires, de gestion et d'hébergement de l'équipement, les serveurs Exchange ne disposeraient pas du stockage connecté au réseau SAN (storage area network), tout stockage devait donc être interne ou à connexion directe. La plupart des circonscriptions ne disposant pas de centres de données avec stockage en rack et refroidissement centralisé, les serveurs devaient être aussi autonomes que possible. Par chance, la plupart des circonscriptions comptaient moins de 5 000 utilisateurs ; des déploiements sur un seul serveur étaient donc possibles. Pour les circonscriptions comptant davantage d'utilisateurs, des serveurs plus puissants (voire plusieurs serveurs) et des espaces de stockage supplémentaires ont été utilisés, parfois avec des serveurs frontaux séparés pour pouvoir trier ultérieurement le trafic étudiant du trafic personnel.
Dans la plupart des circonscriptions, nous avons pu déployer des serveurs à deux processeurs bien équipés dont la configuration comprenait le nombre maximal de 15 000 disques RPM Ultra320 SCSI, plusieurs contrôleurs RAID et 4 Go de RAM. Les circonscriptions plus importantes se sont vu dotées d'un serveur à quatre processeurs ou plus, utilisant des serveurs frontaux plus petits si nécessaire. Les tests d'évaluation et de performances avant déploiement n'ont indiqué aucun problème d'utilisation ou de chargement. Cependant, à des degrés divers, les modèles d'utilisation locale constitueraient le véritable facteur déterminant la performance globale du serveur.

Test de validation technique
Même si l'environnement de production contient une forêt Active Directory de 178 domaines, le laboratoire de validation technique (VT) a été réduit à 13 domaines de circonscription et à un domaine racine vide. Tous les domaines de test ont été renseignés avec des exportations provenant des domaines de production. Des serveurs Exchange 5.5 virtuels ont été générés et configurés avec des copies des bases de données de la circonscription sélectionnée afin que nous puissions tester le processus et la création de la migration de l'environnement programmé. Le laboratoire de test de validation technique entier a été construit avec des ordinateurs virtuels de sorte que l'environnement puisse être référencé, figé et redéployé par la suite lorsque nécessaire.
De multiples scripts (à l'aide de VBScript), de packages d'installation Systems Management Server (SMS) et d'applications de console ont été créés, codés, testés et finalisés. Au final, nous avions des scripts qui effectuaient l'installation et la configuration initiales d'Exchange 2003, y compris les stratégies de destinataire, les LAG et les listes d'adresses personnalisées et les autorisations. Les scripts géraient également la configuration du groupe administratif, la configuration du domaine de circonscription (création du groupe de sécurité et délégation des autorisations) et la configuration après déploiement pour la migration.
L'activation des serveurs Exchange 2003 représentait quelques défis importants. Il nous fallait installer correctement tous les serveurs Exchange sur les 178 domaines et le faire de manière à ne pas compromettre le reste de la migration. Exchange 2003 diffère d'Exchange 2000 du fait que le groupe Serveurs de domaine Exchange spécifique aux domaines n'est pas ajouté à l'ACL de l'organisation avant que le premier serveur Exchange 2003 du domaine ne soit installé. (Dans Exchange 2000, le groupe est ajouté lors de l'exécution du processus DomainPrep.) Afin de nous assurer que nous disposions de tous les groupes de sécurité nécessaires répertoriés sur l'objet d'organisation dans Active Directory, il nous fallait effectuer l'installation, dans un domaine donné, copier manuellement Active Directory à partir du domaine vers le site hub de réplication Active Directory, puis tirer cette réplication vers la prochaine circonscription devant être installée. L'installation de la circonscription suivante ne pouvait commencer en toute sécurité qu'une fois que l'on avait confirmé que l'ACL sur l'objet d'organisation avait le groupe Serveurs de domaine Exchange de la circonscription précédente. Si ce processus avait été effectué dans le mauvais ordre ne serait-ce que pour un domaine, cette circonscription aurait dû au minimum être réinstallée ou bien la communication entre d'autres circonscriptions n'aurait pas été possible à cause d'un objet d'organisation ACL ne répertoriant pas toutes les autres circonscriptions correctement.
Nous avons testé la totalité du déploiement, la configuration, l'activation des serveurs et la migration plusieurs fois jusqu'à ce que nous soyons sûrs du bon fonctionnement du processus au sein de l'environnement de VT.

Migration et difficultés grandissantes
Une fois les procédures de VT et les résultats approuvés par l'équipe du projet, la migration pouvait commencer. Les OET avaient choisi d'effectuer leurs propres migrations dans un premier temps afin qu'ils puissent personnellement expérimenter le processus et ses répercussions. Au moment de la migration, tous les serveurs avaient déjà été activés et l'environnement initial avait été vérifié. Tous les serveurs de protocole frontaux étaient en place et prêts à être utilisés.
L'exécution du plan de migration s'est bien passé et, après 21 heures de transfert du contenu d'un serveur à un autre, l'OET était fin prêt et opérationnel sur Exchange 2003. Heureusement, il n'y avait eu aucun problème majeur concernant le passage des profils Outlook d'Exchange 5.5 à Exchange 2003. Nous avons empaqueté un fichier de commande appelant ExProfRe.exe dans différentes configurations sur la base d'une logique simple. Nous avons alors distribué le fichier de commande et ExProfRe.exe au partage Accès réseau d'un contrôleur de domaine dans chaque circonscription et utilisé la stratégie de groupe pour exécuter la commande pour tous les clients à la fin de la migration. Ceci à bien fonctionné pour l'OET et nous étions confiants pour la suite du processus.
À ce niveau, le plan de migration a été revu et réapprouvé en fonction de notre expérience de déploiement avec l'OET. Pour la suite de la migration, nous avons choisi six circonscriptions comme premiers sites de production. Avant la migration de chaque circonscription, le MIIS devait lire les dernières informations concernant les boîtes aux lettres de la circonscription d'Exchange 5.5 et mettre à jour les utilisateurs correspondants dans le domaine de la circonscription. Nous avons utilisé l'Assistant Migration Microsoft Exchange (Mailmig.exe) afin de procéder au déplacement effectif des données de boîte aux lettres entre organisations. Lorsque l'assistant a déplacé les données de boîte aux lettres, toutes les adresses proxy ont été amenées et mises à jour à partir de ce que MIIS avait à l'origine exporté sur Active Directory. Au cours de la migration, la messagerie serait mise en file d'attente dans les serveurs SMTP frontaux, puis distribuée à la circonscription une fois la migration, la configuration des serveurs après migration et les tests utilisateur effectués ; la circonscription était prête à effectuer la migration client à grande échelle avec ExProfRe.exe.

Batailler avec le RUS
Pour que les clients Outlook fonctionnent correctement, nous avions besoin de nous assurer que la solution d'attribution de privilèges constituait l'autorité ultime au niveau de la définition des valeurs d'attributs. Nous avions également besoin que le service de mise à jour des destinataires (RUS) ait fait, pour ainsi dire, son travail d'installation des comptes, mais le RUS ne devait se lancer qu'une fois l'attribution de privilèges d'accès effectuée. Pour ce faire, les instances du RUS pour les 178 circonscriptions étaient définies sur Never (Jamais) et la solution d'attribution de privilèges d'accès utilisait du code qui déclenchait le lancement du RUS une fois l'attribution de privilèges effectuée.
La plupart des circonscriptions comptaient quotidiennement moins de 5 000 utilisateurs et encore moins de mises à jour ; le RUS s'exécutait donc rapidement puisque le système d'attribution de privilèges lançait une mise à jour au lieu d'une reconstruction à la fin de son exécution quotidienne. Cependant, il y avait plusieurs circonscriptions qui comptaient plus de 10 000 utilisateurs. Les mises à jour dans ces environnements prenaient beaucoup plus de temps et lorsqu'une reconstruction complète d'un RUS était nécessaire pour les grands domaines, le service pouvait s'exécuter pendant une semaine ou plus. Le RUS évaluant tous les types d'objet lorsqu'il s'exécute, le fait d'effectuer une reconstruction dans un domaine aussi grand était affaiblissant.
Bien que nous n'ayons pas pu arriver à une stratégie d'atténuation (et que nous ayons travaillé avec des membres du groupe produit Exchange pour tenter de trouver une solution), nous avons amélioré le code d'attribution de privilèges pour gérer une grande partie des éléments que gère normalement le RUS. Les attributs proxyAddresses et showInAddressBook ont été renseignés pour les utilisateurs après l'attribution de privilèges initiale de sorte qu'ils puissent se connecter immédiatement plutôt que de devoir attendre que le RUS ait achevé sa tâche. Nous avons également créé une tâche manuelle qui s'exécute sur l'un des serveurs de protocole frontaux Exchange 2003. Elle effectue une importation LDIFDE temporisée et efface l'adresse gatewayProxy du RUS de sorte que si une stratégie de destinataire est appliquée par accident dans l'environnement, elle n'est pas placée sur la liste des tâches à effectuer de chaque RUS dans l'organisation.

Problèmes de catégoriseur
L'un des aspects intéressants dans le fait d'empêcher les données des étudiants de sortir de la circonscription scolaire était l'implémentation de contrôles qui empêche les étudiants d'envoyer des messages à des utilisateurs situés en dehors de leur propre circonscription ou vers des adresses Internet situées hors du système. Plutôt que de travailler via un système sophistiqué de connecteurs et d'éléments annexes, nous avons décidé d'implémenter une fonctionnalité moins connue d'Exchange 2003 et d'utiliser des restrictions de connecteur sur le connecteur de groupe de routage existant entre la circonscription et le concentrateur central où se trouvent les serveurs de protocole frontaux. Deux groupes de sécurité ont été créés dans chaque domaine - l'un pour le personnel et l'autre pour les étudiants - et ces groupes ont été ajoutés aux restrictions du connecteur.
Une fois la vérification des restrictions de connecteur activées dans le Registre, nous avons commencé à remarquer quelques problèmes d'affaiblissement des performances. Des messages allaient être bloqués dans le catégoriseur et dans les files d'attentes de distribution locales pendant des heures £ y compris les messages destinés à des destinataires sur le même serveur. Ces problèmes ont empiré au fur et à mesure de la migration de circonscriptions supplémentaires. Nous avons établi une solution à court terme en désactivant la vérification des restrictions de connecteur, avec pour résultat l'amélioration des performances de distribution du courrier. Un contrôle plus approfondi révéla que le catégoriseur vérifiait non seulement les appartenances aux groupes des deux groupes de son propre domaine lorsque les messages étaient soumis, mais également les appartenances aux groupes des deux mêmes groupes dans les 177 autres domaines. Cette opération était effectuée pour chaque message entrant ou sortant du serveur.
Suite à cela, nous avons contacté Microsoft pour une prise en charge du problème. Après évaluation, Microsoft est actuellement en train de générer un correctif pour atténuer ce problème en permettant au catégoriseur de travailler selon un mode de complexité de topologie réduit. À la date de publication, nous n'avons pas plus d'informations concernant le correctif, mais l'objectif est de fournir un paramètre qui permette au catégoriseur de formuler certaines hypothèses sur la topologie de routage et de ne pas vérifier l'appartenance aux groupes sur tous les connecteurs.

Retour d'expérience
S'il y a bien une chose que j'ai apprise tout au long de ce projet, c'est que les exigences de fonctionnement régissent tout ce que nous faisons en tant que consultants. À plusieurs reprises, la faisabilité de l'exigence de fonctionnement a dû être mise en balance avec la complexité de la solution. Les décisions et les options que j'ai décrites dans cette rubrique sont celles que nous avons estimé être les plus appropriées compte tenu de notre environnement (qui comprend des éléments dont je n'ai pas eu le temps de parler ici), de nos ressources et de nos exigences de fonctionnement. Vos décisions peuvent s'avérer différentes mais espérons que cette rubrique vous aura apporté quelques éléments de réflexion. Heureusement pour nous, Exchange 2003 et Active Directory nous ont apporté une grande souplesse pour répondre à toutes les exigences de cette migration complexe. Une fois passé le choc du gigantisme du déploiement des services de l'éducation du Kentucky, la solution elle-même est assez simple et est générée à partir des fonctionnalités Active Directory et Exchange 2003 qui pour moi sont sous-exploitées.
La seconde leçon importante à retenir, c'est qu'il faut mettre en pratique une approche équilibrée en ce qui concerne la gestion des pannes et des problèmes ou des risques. Il est parfois approprié de résoudre les pannes en local et parfois nécessaire de faire appel aux ressources avancées des services de support technique de Microsoft.

Perspectives
L'environnement du ministère de l'éducation du Kentucky est certainement unique. Au cours de ce déploiement, presque toutes les fonctionnalités d'Exchange ont été utilisées ou personnalisées pour satisfaire aux exigences des services. Maintenant que l'environnement dans son intégralité a été déployé et a migré correctement, le temps d'implémenter des fonctionnalités supplémentaires est venu. Le ministère de l'éducation a déjà vu l'intérêt des circonscriptions scolaires pour la plate-forme Windows Mobile® et espère que cette tendance pour les outils mobiles va continuer.
La consolidation des serveurs permet une amélioration considérable. Le ministère de l'éducation du Kentucky cherche actuellement à virtualiser certains aspects de l'environnement Active Directory. Et avec la perspective d'Exchange 2007, le ministère a commencé à s'intéresser aux exigences pour la mise à niveau de ses systèmes de messagerie.
Les services de l'éducation du Kentucky étudient également d'autres propositions supplémentaires de collaborations dans Live Communication Server, Live Meeting Server, etc. De plus, Microsoft Operations Manager 2005 est actuellement en cours de déploiement pour la gestion et le contrôle des serveurs Exchange et Active Directory.

Résultats
Chaque enfant scolarisé dans le système scolaire public du Kentucky va pouvoir profiter de la qualité et de la généralisation de cette implémentation £ y compris mes propres enfants et les enfants des gens avec lesquels j'ai travaillé sur ce projet. Cette implémentation a plus que jamais positionné les services de l'éducation du Kentucky pour aller plus loin et plus vite en matière de technologie, d'une manière plus sécurisée et standardisée que jamais. Je suis fier d'avoir participé à une telle entreprise.

Whitney Robertsest consultant principal de KiZAN Technologies (www.kizan.com) et travaille avec Exchange depuis la sortie d'Exchange 4.0.


 Forum aux questions sur SQL: &#201;viter les red&#233;marrages, installer plusieurs mises &#224; jour et plus encore
Forum aux questions sur SQL
Éviter les redémarrages, installer plusieurs mises à jour et plus encore
Par Nancy Michell

Éviter les redémarrages

Q Comment puis-je limiter le nombre de redémarrages pendant l'application de correctifs de sécurité ou autres sur le SQL Server et même sur le système d'exploitation en général ?

R Tout d'abord, cela vous intéressera certainement de savoir que la plupart des redémarrages post-installation ne sont pas codés en dur dans l'installateur. Ils sont généralement le résultat de fichiers verrouillés. Cela signifie que l'installateur essaie de mettre à jour les fichiers qui sont en cours d'utilisation (verrouillés) par d'autres applications ou par le système d'exploitation. Il existe une approche simple pour éliminer ces redémarrages, qui consiste à s'assurer qu'aucun processus n'utilise les fichiers en question. Comment est-ce que l'on fait ça ?
La première étape consiste à déterminer les fichiers spécifiques qui étaient utilisés et ont été verrouillés pendant l'installation. La manière la plus simple est de les rechercher dans le registre à HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Vérifier cette clé de registre est utile pour deux raisons : cela confirme que la demande de redémarrage a bien été causée par des fichiers verrouillés et cela vous indique quels fichiers étaient verrouillés. Si vous les recherchez après l'installation, mais avant le redémarrage, vous serez peut-être en mesure de découvrir ce qui a causé la demande de redémarrage puis de prendre des mesures pour l'éliminer lors d'installations futures.
Vous pouvez rencontrer deux types d'entrées. Si un fichier a été verrouillé en lecture, vous verrez une entrée du type une- ligne-par-fichier qui signifie que le fichier mis à jour est déjà présent sur le disque mais que vous devez nettoyer la copie temporaire qui est encore en cours d'utilisation. Si un fichier a été verrouillé en écriture, vous verrez une entrée du type deux- lignes-par-fichier qui signifie que la mise à jour n'a pas encore été effectuée, que l'application est dans un état inconnu et ne doit pas être utilisée. Tout ça revient pratiquement à s'arrêter au beau milieu de l'installation Dans ce cas, une ligne indique le fichier réel et l'autre pointe vers un fichier temporaire (qui deviendra le fichier réel au redémarrage).
L'étape suivante dépend de plusieurs facteurs, mais le principe est d'identifier quel logiciel utilise les fichiers verrouillés. Utilisez des vérificateurs de dépendance si vous le pouvez ou la base de données DLL HELP sur MSDN® (consultez support.microsoft.com/kb/815065).
Si le logiciel que vous identifiez a un service, arrêtez ce service manuellement puis faites le test à nouveau. Si c'est une application, fermez-la et réessayez. Parfois, plusieurs applications utilisent un fichier unique et vous devez toutes les arrêter.
Le résultat de ces tests (dans votre environnement de test) est une liste d'applications et de services à arrêter dans l'environnement de production avant l'installation. Ainsi, l'environnement de production ne nécessitera pas de redémarrage car aucun logiciel ne continuera à verrouiller les fichiers que l'installateur est en train d'installer. Évidemment, n'oubliez pas de redémarrer chacun d'entre eux une fois l'installation terminée.
La bonne nouvelle à ce sujet est que, généralement, les verrous ne changent pas tant que ça. Donc, une fois que vous aurez compris ce modèle pour vos systèmes, cela vous évitera de nombreux redémarrages pendant toute la durée de vie de votre système.
Une autre astuce mérite d'être citée. Vous pouvez avoir plusieurs versions de SQL Server™ ou un autre produit installés côte à côte et ils peuvent se trouver à différents niveaux de version. Vous devez toujours mettre à jour la version la plus récente en premier. Il y a de bonnes chances que la mise à jour remplace tout par les versions les plus récentes et toutes les autres instances ne s'intéresseront pas du tout au verrouillage. Par exemple, si vous avez trois instances de SQL Server 2000 SP3, la première que vous mettez à niveau vers SP4 mettra à niveau le fichier MSXML3.dll et nécessitera un redémarrage. Supposons que vous effectuiez ce redémarrage maintenant. Vous pouvez alors mettre à niveau les deux instances suivantes vers SP4 sans avoir à redémarrer, car le fichier MSXML3.dll mis à jour est déjà présent. Il en va de même pour la mise à niveau de toutes les instances SQL Server 2005 avant les instances SQL Server 2000 et les instances SQL Server 2000 avant les instances SQL Server 7.0. Il s'agit d'une stratégie de minimisation des redémarrages qui fonctionne véritablement.
En étudiant le sujet, les équipes de développement Microsoft ont beaucoup œuvré pour stopper les redémarrages ou en limiter le nombre dans de nombreux scénarios. Dans la mesure où il s'agit de la rubrique Q&R SQL, prenons SQL Server comme exemple.
Dans SQL Server 2005, l'équipe SQL Server a fractionné le code Microsoft® Data Access Components (MDAC) nécessaire à SQL Server dans SQLNCLI (nouveaux fichiers) au lieu de mettre à jour le MDAC lui-même, puis a déplacé le MDAC en intrabande avec le système d'exploitation. En quoi cela aide-t-il ? Le système d'exploitation Windows® utilise le MDAC et maintient ces fichiers verrouillés. C'est pourquoi la plupart des service packs SQL Server ainsi que d'autres packages vous obligeaient à redémarrer. Désormais, SQL Server peut mettre à jour sa version du MDAC sans toucher aux fichiers MDAC du système d'exploitation en cours d'utilisation, donc vous n'avez pas à redémarrer.
En outre, il existe désormais un vérificateur de dépendance et une pause intégrés à l'installation de SQL Server 2005 SP1. Ceci vous montre ce qui est verrouillé et la cause du verrouillage et vous permet ensuite d'arrêter sur le champ tout ce qui est responsable du verrouillage et de continuer l'installation sans redémarrer. Cela signifie que vous pouvez faire ça en temps réel sans avoir besoin d'un laboratoire d'essai. Évidemment, vous pouvez toujours décider de continuer et effectuer le redémarrage si vous le souhaitez ou si vous en êtes en mode sans assistance. Remarquez combien il devient facile de découvrir ce qui bloque vos fichiers !
De plus, la technologie Microsoft Installer gère aussi beaucoup mieux les PendingFileRenameOperations (PFR) existantes. Vous vous rappelez peut-être que l'installation de SQL Server 2000 bloquait si des fichiers apparaissaient sur la clé de registre que nous avons évoquée plus tôt. L'installation de SQL Server 2005 est assez intelligente pour ne bloquer que si les fichiers appartiennent à SQL Server (ce qui signifie qu'il pourrait y avoir un conflit) et même dans ces cas-là, elle peut souvent explorer en profondeur la clé PFR et la mettre directement à jour sans redémarrer. Cette technologie est incluse à un certain niveau à la fois dans MSI et dans update.exe, qui sont les installateurs Microsoft standard actuels utilisés pour effectuer toutes les mises à jour.
Quelles sont certaines des erreurs connues qui provoquent les redémarrages ? MSXML3.dll est l'une des plus importantes. Ce fichier est toujours verrouillé par le service Windows SVCHost, donc tout ce qui inclut ce service devra redémarrer. Il est aussi présent dans la plupart des piles MDAC (mdac_typ.exe). Heureusement, MDAC est "intrabande" sur Windows Server® 2003 et Windows XP SP2 ou version ultérieure. L'équipe de développement SQL Server a beaucoup œuvré pour dissocier msxmlsql.dll de sorte que les mises à jour de SQL Server n'entraînent pas de redémarrage. Vous pouvez cependant vous attendre à ce que cela arrive de temps à autre. Il n'y a rien que vous puissiez faire dans ce cas - vous pouvez arrêter SVCHost et continuer à exécuter les mises à jour cependant..
De même, les packages update.exe présentent une légère anomalie au niveau du processus de désinstallation. Si vous en désinstallez un, il pose un verrou (en dehors des clés PFR, bien entendu) sur les fichiers en place de l'installateur. Cela évite que d'autres packages update.exe puissent s'exécuter jusqu'à ce que vous redémarriez et enleviez le verrou. La seule chose que vous pouvez faire est d'en être conscient et d'envisager de redémarrer après toute désinstallation de correctif que vous pouvez effectuer..
L'intermittence aussi est un problème Tous les programmes ne sont pas présents à 100 % au niveau d'un fichier. En fait, l'utilisation des DLL partagés est dans la plupart des cas ponctuelle, ce qui signifie que d'autres programmes y accèdent seulement si nécessaire, selon leur propre charge de travail et leurs chemins de code. Cela veut dire que vous pouvez faire le test 10 fois et ne voir aucun fichier verrouillé, puis rencontrer un fichier verrouillé lors du déploiement de production. Il n'existe pas de formule magique, malheureusement. Construisez simplement votre environnement de test un peu comme votre environnement de production, comme vous pouvez, en incluant le chargement (ce qui est un objectif honorable en soi) et exécutez suffisamment de tests pour dépiler ces permutations.
Les service packs SE et les mises à jour vont redémarrer. Remarquez que dans les versions anciennes (Windows 2000, Windows XP et toute version antérieure), l'installation n'est pas finie avant la fin du redémarrage - même si la clé de registre pendingfilerenameoperations est vide. Il existe des opérations d'inscription de package d'exception qui peuvent s'exécuter pour installer du code lors de ce redémarrage. Celles-ci ne font pas même pas partie de la définition du service pack mais sont des commandes intégrées à votre système d'exploitation courant déclenchées par des scénarios de mise à niveau pour permettre à certains morceaux de code que vous utilisez de leur survivre.
Au final, la clé PFR n'effectue pas de vérifications de version de fichier et ne fait pas appliquer un ordre via la sérialisation non plus. Cela signifie qu'elle lance le remplacement de fichiers dans l'ordre dans lequel ils sont répertoriés. Mais le moment où ils sont appliqués sur le disque dur s'est avéré être le moment où le dernier a terminé (non pas le moment où le premier a commencé). C'est logique mais cela signifie que le fait d'avoir deux copies du même fichier sur le même chemin, chacune pointant vers des versions différentes, produira un résultat aléatoire après le redémarrage. Si vous rencontrez cette situation, vous devez vous assurer que le problème est résolu. Si vous n'en êtes pas certain, exécutez simplement les deux installateurs une nouvelle fois après avoir redémarré. Si vous avez les bons fichiers, aucun des deux ne fera quoi que ce soit. Si vous avez les mauvais fichiers, alors le package possédant le fichier correct règlera alors le problème. Honnêtement, c'est une technique à la fois plus rapide et plus sûre que d'essayer de déterminer quel est le résultat voulu.

Installations de plusieurs Service Packs

Q Je possède huit instances en grappes SQL Server 2000 sur un cluster à 4 nœuds et je voudrais installer un SP4 avec un minimum de redémarrages. Puis-je installer SP4 sur les 8 instances successivement et redémarrer tous les nœuds à la fin ?

R Une fois que vous avez fini d'installer une seule instance de SQL Server SP4 - ce qui peut nécessiter un redémarrage - sur un serveur Windows donné (en grappes ou non), vous ne devriez pas avoir à effectuer de redémarrages supplémentaires lors de l'installation de SQL Server SP4 sur toute autre instance SQL Server de cette boîte. Ceci s'explique par le fait que tous les fichiers partagés - outils, MDAC, MSXML, ainsi de suite - sont déjà à la bonne version et, verrouillés ou non, qu'ils ne nécessitent pas une nouvelle mise à jour. Tous les fichiers non partagés sont uniquement utilisés par la première instance et elle sera fermée par l'installation. Il est important de remarquer que l'instance la plus récente de SQL Server doit être mise à jour en premier dans le cas où vous avez des instances multiples de versions multiples.

Exécuter en tant que Service réseau

Q Qu'est-ce que le compte NT AUTHORITY\NETWORK SERVICE exactement et quel est son principal objectif ? De même, quelles sont les implications au niveau sécurité de ce compte, particulièrement s'il est doté de droits sysadmin (sa) ?

R Le compte Service réseau a la même identité (identité machine) que Système sur le réseau mais ses privilèges sont réduits au niveau de la boîte locale. Donc, si un service demande l'accès aux ressources réseau, peut-être pour résoudre des noms de compte avec le contrôleur de domaine, il doit s'exécuter en tant que Système, compte de domaine ou Service réseau. Ce dernier est généralement le choix le plus sûr car il est configuré uniquement pour une boîte locale et même là, ses privilèges sont réduits.
Faire du Service réseau un sysadmin dans SQL Server signifie que tout autre service s'exécutant en tant que Service réseau sur une boîte locale contrôle totalement le serveur. Ceci se produit, par exemple, lorsque le compte de service SQL Server est configuré pour s'exécuter en tant que Service réseau. Faire d'un compte de service SQL Server un membre de sysadmin est nécessaire pour la fonctionnalité du serveur (par exemple, pour permettre des connexions de bouclage). Alors que le fait d'avoir le Service réseau exécuté comme admin sur SQL Server n'est pas une méthode très fiable du point de vue de la sécurité, cela peut (ou non) s'avérer être une meilleure solution que d'utiliser un compte de domaine dans ce but et c'est beaucoup plus fiable que d'avoir SQL Server exécuté en tant que LocalSystem.
Si vous ne voulez pas que le Service réseau ait des privilèges sysadmin, une autre possibilité à envisager est d'utiliser un compte de domaine spécialement dédié pour exécuter SQL Server sur une ou plusieurs installations de Windows NT®.
Les articles suivants peuvent apporter de l'aide : msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp et microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Créer plusieurs bases de données

Q Je prévois de partitionner des données dans des bases de données individuelles, peut-être jusqu'à 250 bases de données en ligne à la fois. J'estime que seulement 20 pour cent ne seront utilisés pour des requêtes actives à n'importe quel moment donné. Est-ce mieux d'avoir un plus grand nombre de bases de données ?

R Le nombre de bases de données dans une instance de serveur de base de données doit être motivé par des considérations de fonctionnement et des facteurs administratifs. Il y a très peu de surcharge lors de la création de plusieurs bases de données dans une seule instance de serveur, mais un plus grand nombre de bases de données signifie une surcharge administrative pour les tâches de maintenance comme les sauvegardes et les restaurations, la mise en miroir, les comptes utilisateur et les rôles utilisateur. Les complexités administratives supplémentaires peuvent l'emporter sur les avantages que constituent des bases de données supplémentaires.
En règle générale, toutes les données liées à une application doivent être conservées dans une seule base de données, ce qui rend la récupération après une panne plus facile. Si les données d'une application sont réparties sur plusieurs bases de données, toutes les bases de données doivent être récupérées lors d'un basculement. Cela peut retarder la récupération ou même empêcher une récupération si l'une des bases de données ne peut être récupérée.
Ceci dit, répartir des données sur plusieurs bases de données ne se fait pas sans raisons :
  • Un sous-ensemble de données a des exigences de backup différentes par rapport à d'autres données.
  • Certaines données ont besoin d'un contexte de sécurité à part, c'est-à-dire un d'un propriétaire de base de données différent.
  • Parfois les données existent pour des raisons historiques et doivent être conservées en mode lecture seule.

Merci aux informaticiens Microsoft ci-dessous pour l'apport de leur expertise technique : Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson et Madhusudhanan Vadlamaani.

Par Nancy Michell


 H&#233;, vous le Scripteur&#160;!: O&#249; sont les porte-gobelets&#160;?
Hé, vous le Scripteur !
Où sont les porte-gobelets ?
Les Scripteurs de Microsoft
Cette rubrique est basée sur une version préliminaire de Windows PowerShell. Toutes les informations contenues dans cette rubrique peuvent être amenées à évoluer.

Lorsqu'une nouvelle technologie est introduite, cela prend un peu de temps avant que le public puisse vraiment faire la différence entre la nouvelle technologie et ce qui existait précédemment. Prenons les premières automobiles, par exemple. Il y une raison pour laquelle ces engins étaient considérés comme des calèches sans chevaux : c'est en fait à peu près ce qu'elles étaient. En y réfléchissant, peut-être que la seule différence entre les premières automobiles et les calèches résidait dans le fait que les unes utilisaient des chevaux et les autres pas. À part ça, bien malin celui qui aurait pu les différencier.
Aujourd'hui, bien évidemment, peu de personnes confondraient une automobile avec une calèche. C'est qu'au fil du temps, les constructeurs automobiles ont fait les choses de telle sorte qu'on différencie maintenant clairement les voitures des calèches. Par exemple, les voitures d'aujourd'hui sortent de leurs usines équipées de lecteurs CD, de la climatisation et de systèmes de navigation par satellite ; peu de calèches peuvent en dire autant. De la même manière, imaginez que vous conduisiez une calèche dans les années 1880 et qu'à un moment, vous ayez eu besoin de poser le Frappuccino que vous tenez à la main ; désolé, vous n'avez vraiment pas de chance. De leur côté, certains utilitaires sportifs (SUV) disposent sur leur modèle de série de 17 porte-gobelets et il y a au moins une marque d'automobile qui propose trois porte-gobelets rien que pour le conducteur. Certains des modèles les plus récents disposent même de porte-gobelets capables de réchauffer ou de rafraîchir votre boisson si nécessaire.
Remarque En effet, il est dur de s'imaginer que les gens, à une époque, survivaient sans même avoir la possibilité de boire trois boissons différentes au volant. Comment peut-on imaginer conduire avec seulement une ou deux boissons à disposition ?
Avant qu'une technologie ne rencontre vraiment le succès, les gens ont besoin de savoir pourquoi ils doivent privilégier ce qui est nouveau et inconnu par rapport à ce qui est ancien et fiable. Lorsque les DVD sont sortis sur le marché, ils vous permettaient de regarder des films à la maison, exactement comme le faisaient les cassettes vidéo. En revanche, les DVD étaient plus chers que les cassettes vidéo et vous ne pouviez pas utiliser un lecteur DVD pour enregistrer vos propres programmes. Inutile de dire que les DVD n'ont pas pris le monde d'assaut ! En effet, il a fallu attendre que les fabricants de DVD commencent à truffer leurs disques de scènes coupées, de commentaires d'un acteur dont vous ignoriez même qu'il jouait dans le film et d'autres choses que vous ne pouviez pas avoir sur une cassette vidéo, pour que les DVD commencent à supplanter leurs contreparties VHS. Pouvoir regarder un film à la maison ne suffisait pas ; les fabricants de DVD ont dû fournir des options plus performantes que celles dont disposait déjà le public.
Remarque Le fait que les gens regardent ou pas les bonus importe peu : la nature humaine est ainsi faite que, lorsque quelque chose est disponible, vous n'avez de cesse de l'avoir. D'ailleurs, les Scripteurs projettent de sortir un DVD TechNet Magazine contenant principalement le texte supprimé des rubriques TechNet Magazine ainsi que des alternatives aux fins des scripts d'administration système.

Utilisation de Windows PowerShell
Windows PowerShell™, la nouvelle technologie de shell de commande et de script, sortie par Microsoft, en est un exemple. Lorsque les gens entendent parler de Windows PowerShell la première fois, on leur dit des choses du genre :
  • "Windows PowerShell vous permet de gérer des processus et des services."
  • "Windows PowerShell vous permet de récupérer les événements dans vos journaux d'événements."
  • "Windows PowerShell vous permet d'utiliser WMI pour gérer les ordinateurs."
Toutes ces affirmations sont bien sûr correctes ; et ce sont toutes des tâches importantes et utiles. Le seul problème, c'est que vous pouvez déjà effectuer toutes ces tâches à l'aide de VBScript et de Windows Script Host. La compatibilité descendante est importante et Windows PowerShell ne constituerait pas une grande innovation s'il ne pouvait même pas effectuer les mêmes tâches que VBScript. (Imaginez un lecteur DVD qui ne pourrait pas lire de films. En fait, inutile d'imaginer cela : l'un des scripteurs en possède un chez lui.)
Dans le même temps, cependant, si Windows PowerShell n'effectue que les mêmes tâches que VBScript, alors pourquoi devrions-nous nous préoccuper de cette nouvelle technologie ? Il est vrai que VBScript n'est pas équipé de porte-gobelets ; et d'ailleurs Windows PowerShell non plus. Alors quelle importance que nous utilisions une technologie de script plutôt qu'une autre ?
À vrai dire, il est possible que cela ne fasse aucune différence. Ceci dit, mise à part l'absence de porte-gobelets, Windows PowerShell possède certaines capacités que VBScript n'a pas. Si tout ce que vous devez faire, c'est gérer des processus et des services, il n'y a pas vraiment d'urgence à ce que vous vous intéressiez à Windows PowerShell ; comme on dit, on ne change pas une équipe qui gagne ! (Pour les Scripteurs, cette maxime aurait plutôt tendance à vouloir dire "N'essayez pas de changer quelque chose sinon vous pourriez avoir de gros problèmes.") Windows PowerShell ne devient intéressant que s'il vous permet d'effectuer une tâche que VBScript ne peut pas faire. Quelque chose comme, disons, modifier l'heure de la dernière écriture d'un fichier.

Modification de l'heure de la dernière écriture
Oui, vous avez bien entendu : modifier l'heure de la dernière écriture d'un fichier. Pour diverses raisons (telle qu'une sorte de contrôle de version rapide et simple), les auteurs de scripts ont toujours rêvé du jour où ils pourraient modifier l'heure de la dernière écriture (ou l'heure de création) d'un fichier ou d'un ensemble de fichiers. Mais malheureusement, cette capacité n'existe ni dans Windows Management Instrumentation (WMI) ni dans FileSystemObject ; dans ces deux technologies, les dates et les heures sont en lecture seule.
Avec Windows PowerShell, cependant, remplacer l'heure de la dernière écriture d'un fichier par la date et l'heure actuelles est aussi facile que d'exécuter cette commande :
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Avant d'expliquer le fonctionnement de cette commande, nous allons répondre à une question que tout le monde se pose sûrement : Comment Windows PowerShell peut-il modifier l'heure de la dernière écriture d'un fichier alors que WMI en est incapable ? Nous avons pensé que nous devions répondre à cette question avant tout autre chose simplement parce qui s'agit d'une idée fausse sur Windows PowerShell. Les gens ont tendance à croire que Windows PowerShell n'est qu'une nouvelle manière d'utiliser WMI. Certes, vous pouvez tout à fait utiliser Windows PowerShell pour accéder aux données WMI ; il est également vrai que, pendant que nous attendons que des cmdlets supplémentaires (natives de Windows Powershell) soient construites, la plupart des scripts d'administration système continueront de se baser principalement sur WMI. Au fond, cependant, Windows PowerShell se base sur .NET Framework et les cmdlets Windows PowerShell traitent généralement les objets .NET plutôt que les objets WMI. Et ceci est important car les propriétés disponibles via .NET Framework ne sont pas nécessairement les mêmes que celles disponibles via WMI.
Par exemple, lorsque nous utilisons la cmdlet Get-Item pour lier un fichier, on n'obtient pas une instance de la classe WMI CIM_Datafile en retour ; à la place, on obtient un objet .NET. Est-ce vraiment si grave ? Bien sûr que oui - l'objet .NET expose un ensemble de propriétés et des méthodes de gestion de fichiers légèrement différentes par rapport à WMI. Mais comme nous venons de le voir, ces légères différences peuvent s'avérer assez importantes, comme la différence entre une propriété de lecture seule et de lecture/écriture.
Une question piège : comment savons-nous qu'une cmdlet Get-Item renvoie un objet .NET ? Dans ce cas, comme dans la plupart des cas, la manière la plus facile de savoir à quel type d'objet on est confronté (ainsi que la manière la plus facile d'identifier les propriétés et les méthodes à votre disposition) consiste à lier le fichier, puis à transmettre cet objet à la cmdlet Get-Member :
Get-Item c:\scripts\test.txt | Get-Member
Les résultats de cette commande sont illustrés par la figure 1. Comme vous pouvez le voir, il s'agit bien d'un objet .NET (comme si les Scripteurs pouvaient se tromper sur quelque chose comme ça !)
Figure 1 Membres de l'objet renvoyé par Get-Item (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
D'ailleurs, cette simple petite commande illustre deux des capacités les plus intéressantes de Windows PowerShell : le traitement « pipeline » et les méta-informations. Même si nous n'entrerons pas dans les détails techniques aujourd'hui, l'idée de base du traitement « pipeline » est que vous pouvez utiliser une cmdlet pour extraire un objet puis transférer cet objet vers un autre cmdlet. Dans cette commande nous avons utilisé la cmdlet Get-Item pour obtenir un objet représentant le fichier C:\Scripts\Test.txt puis nous avons transmis cet objet (en tant qu'objet) à la cmdlet Get-Member via le pipeline. (Le symbole | représente le pipeline dans une commande Windows PowerShell.)
Get-Member fait ensuite son travail, qui consiste à récupérer les propriétés et les méthodes pour l'objet récupéré. C'est l'une des fonctionnalités sympathiques de Windows PowerShell : il est très simple d'avoir accès aux méta-informations qui sont des informations sur les informations. En utilisant des cmdlets telles que Get-Member et Get-Command vous pouvez interroger Windows PowerShell comme vous le souhaitez et de la même façon, vous pouvez écrire un script WMI pour récupérer les informations sur les classes, les propriétés et les méthodes WMI qui sont à votre disposition.
Remarquez que Get-Member va un peu plus loin que ce que vous pouvez faire avec WMI. Bien que vous puissiez utiliser WMI pour obtenir des informations sur les objets WMI, vous ne pouvez pas utiliser WMI pour obtenir des informations sur les objets COM (tel que FileSystemObject par exemple). Ce n'est pas le cas avec Windows PowerShell. Get-Member fonctionne avec tout objet que vous pouvez lier ou créer. Vous ne vous souvenez pas des méthodes disponibles lorsque vous utilisez FileSystemObject ? Alors exécutez la commande suivante :
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
C'est une capacité extrêmement utile - et donc incroyablement sous-utilisée.
Sympathique, n'est-ce pas ? Si nous faisons défiler la liste des propriétés et des méthodes disponibles lorsque nous travaillons avec le fichier C:\Scripts\Test.txt, nous finirons par voir cette ligne :
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Intéressant. Apparemment, LastWriteTime est une propriété qui prend en charge à la fois get (lecture) et set (écriture). Est-ce que cela signifie que nous pouvons utiliser Windows PowerShell pour modifier l'heure de la dernière écriture du fichier ? Sans commentaire....
Glossaire Windows PowerShell
Alias Nom personnalisable qui représente une cmdlet existante. Windows PowerShell propose un nombre d'alias par défaut qui mappent les commandes shell courantes vers leurs équivalents cmdlets.
Cmdlet Unité de fonctionnalité la plus petite dans Windows PowerShell, analogue aux commandes intégrées dans d'autres interpréteurs de commandes.
Commande Unité d'exécution dans Windows PowerShell. Les commandes peuvent comprendre plusieurs opérations canalisées et étendre des lignes à l'aide du caractère ;.
Frappuccino Boisson frappée au café vendue chez Starbucks.
Monad/MSH/Microsoft Command Shell Anciens noms de code pour Windows PowerShell.
Objet Données structurées récupérées dans le système ou dans une commande. Windows PowerShell manipule les données comme des objets .NET, en vous permettant de manipuler les propriétés d'objets par nom plutôt que d'avoir à analyser un résultat de commande de type texte.
Paramètre Les options définissent une cmdlet sur la ligne de commande. Windows PowerShell utilise un trait d'union initial (-) pour désigner un paramètre.
Pipeline Permet d'envoyer la sortie d'une commande vers l'entrée d'une autre commande. Également appelé canal ; représenté par le caractère | dans les commandes.
Profil Paramètres, chargés lorsque Windows PowerShell démarre, qui vous permettent de configurer le fonctionnement de l'interpréteur de commandes.
Script Une ou plusieurs commandes enregistrées sous et exécutées à partir d'un fichier. Windows PowerShell utilise une extension .ps1 pour les fichiers script.
Shell Environnement de ligne de commande dans lequel vous pouvez exécuter à la fois des commandes et des cmdlets.
Variable Objet ou paramètre dont la valeur peut être définie, modifiée ou récupérée pendant l'exécution de commande.

À présent, revenons sur la commande qui définit l'heure de la dernière écriture du Test.txt à la date et à l'heure actuelles. Voici à quoi cela ressemble :
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Comme vous pouvez le voir, cette commande est assez simple. Pour commencer, nous déclarons une variable nommée $a. Ensuite nous utilisons une cmdlet Get-Item pour connexion au fichier C:\Scripts\Test.txt. Ensuite, nous stockons cet objet dans la variable $a. Après avoir entré un point-virgule (qui nous permet d'effectuer plusieurs commandes sur une seule ligne), nous définissons la valeur de la propriété LastWriteTime à la date et à l'heure actuelles. Cela compense presque l'absence de porte-gobelets, n'est-ce pas ?

Allons un peu plus loin...
Évidemment, vous n'êtes pas limité non plus au fait de définir l'heure de la dernière écriture à la date et à l'heure actuelles. Par exemple, observez cette commande :
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Cette fois nous avons chaîné trois commandes. Pour commencer, nous utilisons la cmdlet Get-Date pour créer un objet date-heure égal à 5/22/2006, 8:15 PM. (22/05/2006, 20h15) Pour quelle raison n'avons nous pas eu besoin d'utiliser Get-Date pour créer un objet date-heure dans notre premier script, celui qui définit l'heure de la dernière écriture à la date et à l'heure actuelles ? C'est simple : la commande Date command renvoie automatiquement un objet date-heure. (Pour vérifier ceci par vous-même, entrez la commande suivante dans la console Windows : Date | Get-Member.)
Après avoir créé un objet date-heure égal à la date et à l'heure souhaitées, nous utilisons la commande Get-Item que nous connaissons bien pour obtenir un objet représentant le fichier Test.txt (objet que nous stockons dans la variable $a). Enfin, nous attribuons la valeur représentée par la variable $b à la propriété LastWriteTime.
$a.LastWriteTime = $b
Et que vous le croyiez ou non, vous n'avez pas encore vu la moitié des possibilités. Examinez cette commande qui a l'air complètement inoffensif :
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
Qu'a-t-elle de si intéressant ? Regardons ce qu'elle fait. La première partie est simple : une fois de plus, nous créons un objet date-heure équivalent à 8:15 PM le 5/22/2006 (20 h15 le 22/05/2006). Remarquez cependant que dans la deuxième partie, nous n'utilisons pas la cmdlet Get-Item mais plutôt cette commande :
Get-ChildItem c:\scripts
Quel intérêt y a t-il à cela ? Chaque fois que vous appliquez la cmdlet Get-ChildItem à un dossier, vous obtenez en retour un ensemble de tous les fichiers de ce dossier. Nous allons extraire cet ensemble de fichiers, puis transmettre tous les éléments de l'ensemble via le pipeline (le symbole | apparaît à nouveau) à la cmdlet ForEach-Object.
Et qu'est-ce que ForEach-Object va faire de tous ces fichiers ? Il va modifier la valeur de la propriété LastWriteTime pour chacun d'entre eux, évidemment :
ForEach-Object {$_.LastWriteTime = $b}
Remarque Bien que la rubrique de ce mois-ci ne soit pas supposée être un guide du débutant pour Windows PowerShell, il nous faut remarquer que $_ est une variable spéciale qui représente l'élément dans une boucle For Each. Il est équivalent à objItem dans la boucle VBScript suivante :
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Lorsque notre commande Windows PowerShell a terminé son exécution, tous les fichiers dans le dossier C:\Scripts auront la même heure de dernière écriture. Nous aimerions bien voir une de ces calèches ultra-modernes et sans chevaux faire cela !
Nous pourrions exécuter des variations de cette commande toute la nuit. Par exemple, peut-être souhaitez vous modifier l'heure de la dernière écriture des seuls fichiers .txt dans le fichier C:\Scripts ? Bon d'accord, il suffisait juste de demander :
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

Aiguiser votre appétit
C'est super. Toutefois, il nous faut remarquer que le but de cette rubrique n'est pas de vous "vendre" Windows PowerShell, ni de vous encourager à rejeter tous vos scripts VBScript et à les convertir en Windows PowerShell. Si ces scripts effectuent ce que voulez et ce que vous avez besoin qu'ils fassent, vous devriez laisser les choses tel que ; il en va de même pour les fichiers traités par lot, les outils à ligne de commande, les correcteurs orthographiques magiques et pour tous les autres outils que vous utilisez pour gérer vos ordinateurs. Rappelez-vous, on ne change pas une équipe qui gagne.....
Le but n'est pas que Windows PowerShell vous permette de faire des choses que vous êtes déjà capables de faire ; le but est que, notamment parce qu'il permet l'accès à .NET Framework, Windows PowerShell vous permet de faire des choses que vous n'avez pas réussi à faire auparavant. Modifier l'heure du dernier accès à un fichier (ou à un groupe de fichiers) en est un exemple. Le fait qu'il y ait ou pas d'autres exemples dépend de ce que vous avez besoin de faire. Ce sont ces capacités qui font que Windows PowerShell mérite qu'on s'intéresse à lui.
Pour beaucoup d'entre vous, cette présentation de Windows PowerShell a été inhabituelle : après tout, au lieu de commencer par un simple exemple du genre "Bonjour tout le monde" nous nous sommes lancés dans une commande Windows PowerShell à plusieurs parties, tout en agitant des termes tels que pipeline et cmdlet comme si tout le monde savait ce que nous entendions par là. C'était volontaire. Après tout, nous savons que beaucoup d'entre vous n'ont pas encore essayé Windows PowerShell ; nous avions peur que si nous vous montrions comment récupérer une liste de services sur un ordinateur, vous vous contenteriez de hausser les épaules et retourneriez à vos occupations.
Remarque Nous espérons que vous n'étiez pas en train de conduire. Pour la beaucoup d'entre nous, c'est déjà assez difficile de boire trois boissons, de regarder un DVD et d'utiliser son téléphone portable tout en conduisant, sans ajouter "la lecture de TechNet Magazine" à la liste.
Allez, ne le prenez pas mal : nous avons bien dit pour beaucoup d'entre nous. Par pour nous tous.

Les Scripteurs de Microsofttravaillent pour - enfin, disons qu'ils sont employés par - Microsoft. Lorsqu'ils ne jouent pas, ne regardent pas un match ou ne coachent pas une équipe de base-ball (voire un autre sport ou activité), ils gèrent le Centre de Script TechNet. Allez vérifier sur www.scriptingguys.com.


 Surveillance de la s&#233;curit&#233;: D&#233;ploiement d'une PKI globalement fiable
Surveillance de la sécurité
Déploiement d'une PKI globalement fiable
John Morello
Cette rubrique inclut des données de versions préliminaires susceptibles d'être modifiées.

Une Public Key Infrastructure (infrastructure de clé publique) ou PKI, est un élément essentiel à la construction de la confiance entre des applications, des systèmes d'exploitation et des domaines d'identité divers. Elle est construite sur un modèle hiérarchique fiable dans lequel les entités de fin font confiance à une clé commune au niveau le plus élevé de la racine et par conséquent, toutes les autres clés signées par cette racine sont implicitement fiables.
Grâce à cette structure, une PKI bien conçue peut être aisément améliorée par l'ajout de CA (autorités de certification) supplémentaires, sans introduire de modifications aux entités de fin.
Il existe généralement deux façons d'implémenter les PKI. L'approche la plus commune est d'acheter les certificats nécessaires auprès de l'un des fournisseurs de racines globales implicitement fiables, tels que Cybertrust ou VeriSign. Ces certificats sont souvent utilisés pour sécuriser les flux sur les sites Web mais peuvent également être utilisés pour crypter des VPN (réseaux privés virtuels), signer des courriers électroniques et effectuer d'autres tâches de ce type. Puisque ces racines globales sont intégrées à tous les navigateurs Web et à tous les systèmes d'exploitation modernes, cette méthode peut aisément déployer une relation de confiance au-delà des limites de l'organisation. Cependant, puisque ces certificats sont achetés en fonction des besoins, un large déploiement de cette approche dans une organisation de grande taille peut être coûteux.
Récemment, le modèle de PKI interne s'est répandu. Comme son nom l'indique, une PKI interne n'est fiable que dans le réseau propre à une organisation. Ce modèle permet à une organisation de fournir des services à chaque utilisateur et à chaque système informatique sur son réseau à un moindre coût grâce à l'utilisation de certificats. Cette approche est souvent utilisée pour faciliter des technologies telles que la connexion d'une carte à puce, l'EFS (Encrypting File System) et pour sécuriser la mise en réseau sans fil. Ces certificats ne sont pas adaptés aux applications externes puisqu'ils ne sont pas globalement fiables. C'est là l'inconvénient. Ainsi, la plupart des organisations qui ont déployé des PKI internes adoptent généralement une approche hybride, achetant des certificats pour des applications publiques à une racine globalement fiable.
Et que diriez-vous si vous pouviez obtenir le meilleur des deux approches ? Que se passerait-il si votre organisation pouvait exécuter sa propre PKI (avec la réduction des coûts induite par l'émission de certificats internes) et fournir des certificats publiquement fiables et tout cela depuis votre propre système local ? Une telle solution offrirait les avantages d'une PKI interne (comme l'intégration, l'auto-inscription et le support informatique localisé Active Directory®) tout en fournissant l'avantage majeur d'une racine globalement fiable. La Louisiana State University (LSU) est équipée de ce système. Dans cette partie de Surveillance de la sécurité, je passe en revue la solution que nous avons implémentée à la LSU, en abordant sa conception technique et en mettant en évidence les bonnes pratiques à utiliser lors du déploiement d'un système similaire. Il convient de noter que la solution que je m'apprête à décrire est l'une de celles qui répondent à nos besoins spécifiques compte tenu de notre environnement, de nos ressources et de nos exigences. Il vous est recommandé d'évaluer tous les aspects de votre entreprise au préalable afin de déterminer le type de solution qui vous convient.

Comment la LSU crée la PKI
La LSU est une université de recherche importante dont la population composée d'étudiants, de professeurs et d'autres personnels dépasse les 40 000 personnes. Elle possède de nombreux sites Web publics et nombre d'entre eux requièrent l'utilisation de Transport Layer Security (SSL) - le terme adéquat pour les certificats SSL.. La LSU avait l'habitude de dépenser des milliers de dollars chaque année pour l'achat de certificats provenant de fournisseurs de racines globalement fiables.
En outre, la LSU avait d'autres objectifs en matière de sécurité informatique pour lesquels une PKI interne bien conçue présentait des avantages évidents. Étant donné les objectifs et les exigences de la LSU, vous auriez pu vous attendre à ce que nous choisissions un modèle hybride. Mais au lieu de cela, nous nous sommes décidés pour une approche qui nous a semblé plus innovante.
Nous avons travaillé avec l'une des racines globalement fiables, Cybertrust, pour déployer une CA sur le site de la LSU, subordonné à une CA racine Cybertrust (voir figure 1). Cybertrust propose ce service dans son programme OmniRoot. Dans ce scénario, la LSU construit et fait fonctionner une CA qui s'exécute localement sur un équipement appartenant à la LSU. Cependant, contrairement au modèle interne abordé plus haut, la CA de la LSU n'est pas auto-signée et sa clé (avec celles qu'elle signe) est implicitement fiable dans pratiquement tous les systèmes d'exploitation et les navigateurs modernes. Techniquement, cette conception est une extension logique de l'ouverture des standards x.509. Une PKI étant construite sur ces standards, il est possible de raccorder des systèmes créés par différents fournisseurs dans une même hiérarchie globale. Ceci dit, les conditions d'utilisation de la solution OmniRoot sont particulièrement intéressantes.
Figure 1 Certificat racine global de Cybertrust
Figure 1 Certificat racine global de Cybertrust (Cliquer sur l'image pour la réduire)
Figure 1 Certificat racine global de Cybertrust
Figure 1 Certificat racine global de Cybertrust (Cliquer sur l'image pour l'agrandir)
Le service OmniRoot est conçu de manière spécifique pour le type de déploiement de la PKI que nous avons implémentée à la LSU. Dans le programme OmniRoot, les organisations paient une taxe annuelle fixe à Cybertrust pour pouvoir participer au programme et paient une taxe par certificat uniquement pour les certificats créés pour une utilisation publique. En d'autres termes, la LSU peut émettre autant de certificats que nécessaire pour une utilisation interne, sans avoir à se préoccuper des taxes supplémentaires par certificat qui seraient à payer. En outre, le coût des certificats publics est aujourd'hui nettement moins élevé que celui payé par l'université lorsqu'elle achetait des certificats en fonction de ses besoins.
En fait, les certificats internes et les certificats publics sont identiques d'un point de vue technique. Ils sont émis par la même chaîne de CA, possèdent la même efficacité cryptographique et sont fournis par le même système d'autorité d'enregistrement. Les termes de la licence constituent la seule différence.
Au final, nous avons pu développer et améliorer la plate-forme de sécurité informatique de la LSU à un coût moindre. Cette réalisation a constitué une application commerciale intéressante pour ce type de solution PKI à la LSU. Examinons à présent les aspects plus techniques du déploiement.

Hiérarchie de l'objet PKI
La hiérarchie de l'objet PKI de la LSU est basée sur une conception à deux niveaux, dont le niveau racine est géré par Cybertrust et une CA émettant en ligne, s'exécutant à la LSU (voir figure 2). Le niveau racine constitue le point d'ancrage permettant d'établir la fiabilité de la hiérarchie. En d'autres termes, la relation de confiance de tous les certificats émis par une CA quelconque dans la hiérarchie est soumise à la CA racine (voir figure 3). Ainsi, la CA racine constitue le lien commun à toutes les CA, les certificats et les entités de fin dans la hiérarchie. Comme la racine globale Cybertrust est déjà construite dans Windows® et sur tout autre système informatique récent, ce lien commun s'étend automatiquement au-delà du réseau de la LSU.
Figure 2 Hiérarchie PKI à deux niveaux (Close Figure 2)

Niveau racine (Cybertrust) | Niveau d'émission (LSU)
Géré par Cybertrust | Géré par LSU
Situé dans le centre de données sécurisé de Cybertrust | Situé sur le campus de Bâton Rouge de la LSU
Inclus dans le certificat racine par défaut de presque tous les systèmes informatiques modernes | Émet des certificats aux entités de fin au sein des organisations du système LSU
 | Les certificats émis par la LSU sont soumis à la racine Cybertrust et sont donc globalement fiables
Figure 3 Certificat émis par la CA émettrice CA de la LSU
Figure 3 Certificat émis par la CA émettrice CA de la LSU (Cliquer sur l'image pour la réduire)
Figure 3 Certificat émis par la CA émettrice CA de la LSU
Figure 3 Certificat émis par la CA émettrice CA de la LSU (Cliquer sur l'image pour l'agrandir)
Cybertrust gère la CA racine sur une de ses structures d'hébergement sécurisées. La structure d'hébergement utilise des contrôles de sécurité matériels très efficaces, comprenant des sas, des verrous biométriques et un local de stockage complètement gainé de cuivre. Cybertrust émet des certificats uniquement à l'attention des CA des organisations qui ont démontré qu'elles respectaient ses stratégies de sécurité et de certification.
La CA émettrice de la LSU est un système interface/entités de fin en charge de la fourniture des certificats aux utilisateurs et aux ordinateurs de la LSU. Son certificat est signé par la CA de Cybertrust qui se trouve à un niveau supérieur dans la hiérarchie et elle émet des certificats qui sont reliés à la CA racine de Cybertrust (voir figure 3).

Système d'exploitation et matériel d'émission
La LSU utilise Windows Server® 2003 Édition Entreprise Pack 1 pour sa CA émettrice. Le service d'autorité de certification Windows Server 2003 propose de nombreuses fonctionnalités nouvelles, dont un archivage de clés, des CRL delta (listes de révocation des certificats) et des modèles "version 2". L'instance de Windows utilisée en tant que CA émettrice est construite en fonction de la stratégie standard de construction Windows Server de la LSU. Elle est actualisée avec toutes les mises à jour de sécurité pertinentes et gérée à l'aide des méthodes de gestion de modifications standard de la LSU et des outils d'inventaire logiciel et de mise à jour. En résumé, alors que certains aspects de la gestion du service de CA lui-même sont uniques, le matériel et le système d'exploitation du serveur de base sont eux facilement intégrés aux opérations informatiques courantes de l'organisation.
En plus de se conformer aux bonnes pratiques standard de la LSU pour l'installation du serveur, nous avons pu profiter de l'Assistant de Configuration de la sécurité (SCW), disponible dans Windows Server 2003 Service Pack 1. Le SCW utilise une base de données qui contient des matrices de dépendance des diverses charges de travail qui peuvent être exécutées sur Windows Server et le paramètre de sécurité que ces charges de travail requièrent. Cette base de données comprend les deux rôles primaires que fournira la CA - le service CA lui-même et l'IIS (qui fournit le site Web libre-service de l'objet).
En utilisant le SCW, nous avons facilement créé un modèle de sécurité qui désactivait tous les services autres que ceux requis pour exécuter ces charges de travail. Nous avons également renforcé la pile réseau du serveur. Nous avons ensuite utilisé la commande scwcmd.exe pour transformer ce modèle en un Objet de stratégie de groupe (GPO) afin de pouvoir l'appliquer au serveur au niveau de l'unité d'organisation. Cette approche simplifie l'amélioration et la récupération après incident puisque la configuration de sécurité basée sur les rôles pour une CA LSU est maintenant stockée dans Active Directory plutôt que d'être spécifique à une machine.
La CA émettrice de la LSU est construite sur un serveur IBM xSeries 346, avec deux processeurs Intel Xeon 3.2GHz, 4 Go de RAM et cinq disques durs SCSI de 146 Go. Vu les exigences de performance du service de CA et le fait que la LSU utilise un module de sécurité matérielle, cette plate-forme devrait permettre une longévité importante et procurer de l'espace pour la croissance.
Nous nous sommes conformés aux bonnes pratiques standard pour séparer les bases de données et les fichiers journaux en deux groupes physiquement séparés en créant deux systèmes RAID 1. Le cinquième disque dur est gardé comme disque de rechange activable et disponible pour ces deux systèmes au choix. Nous avons installé le premier système comme étant notre volume système, où nous conservons la base de données CA. Le deuxième système est utilisé pour les fichiers journaux et d'autres fichiers de données divers, tels que les CRL. La base de données de la CA est basée sur la même technologie Jet que l'on trouve dans d'autres parties de Windows, comme Active Directory, c'est pourquoi les mêmes bonnes pratiques de maintenance et de configuration de disques pour d'autres solutions de stockage basées sur Jet s'appliquent ici.
Un module de sécurité physique (HSM) est un périphérique matériel dédié qui est géré séparément du système d'exploitation. Les HSM se présentent généralement sous la forme de cartes PCI mais sont aussi disponibles sous la forme de périphériques basés sur le réseau. Ces modules fournissent un lieu de stockage matériel sécurisé pour les clés CA, ainsi qu'un processeur cryptographique dédié pour accélérer la signature et le cryptage des opérations. Windows utilise le HSM via les interfaces CryptoAPI - le HSM est considéré comme un périphérique fournissant des services cryptographiques (cryptographic service provider ou CSP). Le programme OmniRoot nécessite que chaque CA utilise au moins un HSM certifié niveau 3 FIPS 140-2 (les périphériques niveau 4 sont plutôt rares) pour la génération et le stockage de clés. En tant que périphérique unique et très sûr, un HSM nécessite un investissement financier important. Les prix concernant les HSM basés sur PCI se situent généralement entre 10 000 et 15 000 $.
Dans la conception de la LSU, un nCipher nShield 500 TPS (modèle 500 transactions par seconde) est utilisé comme HSM lié directement. ("Lié directement" signifie qu'il est interne au serveur et ne peut être utilisé que par le serveur, plutôt que d'être un HSM basé sur le réseau qui peut être partagé par des hôtes multiples.) Le HSM est un périphérique FIPS 140-2 de niveau 3 et il fournit une protection K de N de l'élément de mise à clé. Le HSM fournit une protection importante contre la violation de la sécurité des clés privées - un pirate aurait besoin de posséder le stockage du HSM et un certain nombre de jetons d'accès et de codes PIN associés pour accéder à la clé.
Il est très important de noter que les HSM sont conçus pour empêcher leur contenu d'être violé par des tiers malveillants. Ainsi, les HSM appliquent une limite stricte aux tentatives d'ouverture de session consécutives ayant échoué. Dans la conception de la LSU, le stockage est irrévocablement effacé après 10 tentatives consécutives ayant échoué.
Notre installation ne comporte qu'une seule CA, de sorte que le supplément de prix pour un HSM basé sur le réseau ne se justifie pas Cependant, si une organisation envisage d'implémenter deux CA ou plus, cela peut s'avérer nettement moins coûteux d'acheter un seul HSM basé sur le réseau et de le partager entre les CA. Cette approche facilite également la gestion des jetons, puisque tout le stockage de clés peut être protégé par le même jeu de jetons.

Active Directory et inscription
L'un des avantages principaux de la solution PKI basée sur Windows est que la fourniture de certificats est effectuée sans avoir à installer de logiciel supplémentaire sur les entités qui participent au PKI. En fait, en associant inscription et stratégie de groupe, la plus grande partie de la fourniture de certificats peut se gérer de manière autonome, de manière transparente pour l'utilisateur final. La LSU utilise cette technologie pour distribuer automatiquement des certificats machines aux ordinateurs membres de son Active Directory. Et nous utilisons un site Web personnalisé pour fournir des fonctionnalités de demande de certificats en libre-service pour les hôtes non Windows.
Comme mentionné plus haut, le programme OmniRoot fait la distinction entre les certificats utilisés publiquement et ceux utilisés en interne. Les certificats sont considérés comme publics s'ils sont utilisés par des systèmes et des utilisateurs qui ne font pas partie de l'organisation LSU (par exemple, lorsqu'un éventuel futur étudiant soumet un formulaire d'admission via un site Web sécurisé SSL). Les certificats utilisés à l'intérieur de l'organisation LSU (tels que ceux utilisés pour crypter les données sur les serveurs LSU) sont considérés comme internes.
Puisque le coût du programme OmniRoot est basé sur le nombre de certificats publics, nous devons être capables de savoir le nombre de certificats publics émis et leurs destinataires. Ainsi, pour tout certificat destiné à être public, le nom distinctif du modèle commence par "PublicCertificate" et le nom complet par "Public Certificate". Par exemple, le modèle de certificat externe TLS de la LSU est basé sur le modèle de serveur Web Windows par défaut et est appelé Serveur Web certificat public LSU. Pour les serveurs Web utilisés en interne, il existe un second modèle appelé Serveur Web certificat interne LSU. Techniquement, les deux modèles sont identiques. La différenciation d'appellation sert uniquement à faciliter la comptabilité.
Pour des besoins d'inscription massive - tels que l'inscription de départements entiers pour des certificats devant être utilisés avec IPSec - nous comptons sur l'auto-inscription. Il s'agit d'un outil simple et très efficace construit dans Windows. Du point de vue d'un administrateur PKI, la seule action nécessaire est de modifier la liste de contrôle d'accès sur le modèle, accordant à n'importe quel groupe d'utilisateurs ou d'ordinateurs ayant besoin de certificats le droit de s'auto-inscrire. Ces entités vérifieront alors automatiquement Active Directory, dénombreront les modèles auxquels ils ont un accès en auto-inscription, trouveront les CA avec ces modèles et procéderont à une inscription automatique pour obtenir les certificats. De plus, la fonctionnalité d'auto-inscription garantira que les certificats sont remplacés si un modèle est remplacé et renouvelé automatiquement avant expiration.
Pour des besoins plus réduits, comme la fourniture de certificats aux serveurs Web, nous utilisons un site Web en libre-service qui permet aux utilisateurs de demander des certificats via un navigateur Web. Ce site est une version personnalisée des pages d'inscription Web fournies avec Windows Server 2003 (le répertoire virtuel /certsrv). Notre implémentation inclut l'homologation Web standard LSU et préremplit les entrées par défaut appropriées sur la page de la demande. Nous utilisons également le module de sortie par défaut dans le service CA de Windows pour automatiquement envoyer un courrier électronique à notre équipe d'administration PKI lorsqu'une demande envoyée via ce site nécessite une approbation.

Révocation
Chaque certificat a une durée de vie limitée. De temps à autre, la LSU doit invalider certains certificats avant la fin de la période de validité (par exemple, si un employé a reçu un certificat avec une période de validité qui expire en mai 2007, mais que cet employé quitte la LSU en janvier 2007). Ce type de révocation est effectué avec des CRL, qui sont des fichiers contenant une liste de numéros de série de certificats signés par une CA. Les numéros de série présents dans la CRL se réfèrent aux certificats dont la durée de validité n'a pas expiré, mais que la LSU ne considère plus comme fiables. Les clients peuvent alors télécharger cette CRL et la vérifier pour déterminer la validité des certificats.
N'importe quel certificat x.509 v3 (sauf le certificat de CA racine lui-même) devrait avoir un pointeur sur une CLR valide. Ce pointeur est connu comme point de distribution CRL ou CDP. Ce point de distribution CRL est inclus dans le certificat lui-même (voir figure 4) et ne peut être modifié après l'émission d'un certificat. La CRL est un élément essentiel pour assurer la validité des certificats d'une CA. De cette manière, nous nous assurons que les CLR LSU sont redondantes physiquement, complètement disponibles et accessibles par des parties externes.
Figure 4 Point de distribution CLR de la LSU
Figure 4 Point de distribution CLR de la LSU (Cliquer sur l'image pour la réduire)
Figure 4 Point de distribution CLR de la LSU
Figure 4 Point de distribution CLR de la LSU (Cliquer sur l'image pour l'agrandir)
Une CA basée sur Windows Server intégrée à Active Directory (comme celle de la LSU) publie automatiquement sa CLR dans Active Directory, la rendant accessible via le protocole LDAP (Lightweight Directory Access Protocol). L'emplacement de publication par défaut est le conteneur CDP (voir figure 5) dans le conteneur Public Key Services de la forêt. Cet emplacement de publication est une excellente option : il fournit une réplication automatique, une tolérance par défaut et un emplacement pour des recherches CDP.
Figure 5 Conteneur CDP
Figure 5 Conteneur CDP (Cliquer sur l'image pour la réduire)
Figure 5 Conteneur CDP
Figure 5 Conteneur CDP (Cliquer sur l'image pour l'agrandir)
Dans la conception LSU, cependant, il existe de nombreux ordinateurs non Windows et non Active Directory qui utilisent la PKI. Et bien que la LSU soit une organisation de grande taille, la grande majorité de ses utilisateurs se situent sur le même réseau de campus, avec une dorsale de 10 Gbps, minimisant les avantages de la publication CDP basée sur Active Directory.
Nous publions donc notre CRL uniquement sur un chemin HTTP, facilitant ainsi la construction d'une plate-forme d'hébergement redondante (notre principal site Web est en miroir). Cela supprime également les difficultés éventuelles associées à la possibilité de recherches LDAP client. Nous publions notre CRL tous les jours et publions les CLR delta toutes les heures.

Fonctions avancées
Alors que notre PKI en cours fournit une très bonne solution de sécurité pour la communauté universitaire, nous envisageons de renforcer ses fonctionnalités. Windows Vista™ et la prochaine version de Windows Server (nom de code "Longhorn") fourniront de nombreuses fonctionnalités de gestion nouvelles que nous prévoyons d'approfondir. Nous sommes particulièrement intéressés par les fonctionnalités client et répondeur OCSP (Online Certificate Status Protocol) attendues, la prise en charge d'Elliptic Curve Cryptography et les algorithmes SHA-256 et l'interface d'inscription automatique améliorée. De plus, Windows XP Service Pack 3 est programmé pour inclure une fonction connue sous le nom d'itinérance des informations d'identification, ce qui permettra une itinérance sécurisée des paires de clés sans la surcharge associée aux profils itinérants. Au final, nous nous intéressons à l'utilisation de Certificate Lifecycle Manager (disponible actuellement en version bêta) afin d'améliorer nos fonctionnalités de reporting et de gestion.
En résumé, la PKI de la LSU équipe l'université d'un service de sécurité fondamental utilisé pour de nombreuses fonctions informatiques critiques. En utilisant le service Omniroot de Cybertrust, nous pouvons exécuter une PKI qui est bien intégrée aux autres systèmes informatiques de la LSU mais dont la confiance se déploie globalement. De plus, en construisant la solution sur le service CA de Windows, nous obtenons des fonctionnalités efficaces de fourniture et de gestion de certificats, ainsi qu'une excellente intégration à notre répertoire existant et à notre système de gestion des identités. En résumé, la sécurité très élevée et la fiabilité transparente voulues pour la PKI sont déjà une réalité à la LSU.

John Morello a obtenu une mention très bien à la Louisiana State University et a passé six ans chez Microsoft en tant que consultant senior pour Microsoft Consulting Services (MCS). Chez MCS, il a élaboré des PKI pour des clients stratégiques tels que Deloitte, GE et diverses organisations fédérales. Il est maintenant Chef de la sécurité informatique (CISO) à la Louisiana State University (LSU).


 Les fichiers du bureau: Les coulisses du format Windows Imaging
Les fichiers du bureau
Les coulisses du format Windows Imaging
Wes Miller
Cette rubrique est basée sur des versions préliminaires des outils de déploiement Windows. Toutes les informations contenues dans le présent document peuvent faire l'objet de modifications.

La sortie de Windows Vista se traduit par des changements importants dans la manière dont Windows est installé et déployé. Le moteur d'installation et la série complète d'outils de déploiement pour Windows Vista (ainsi que la version à venir de Windows Server, dont le nom de code est « Longhorn », ont été réécrits. J'ai étudié ces modifications ainsi que le travail fourni par
l'équipe de déploiement Windows® pour les réaliser dans de récents articles de TechNet Magazine. Mais il y a beaucoup à dire à ce sujet ; dans cette nouvelle rubrique qui interviendra de manière régulière, je traiterai donc de Windows PE, de l'installation et du déploiement de Windows ainsi que d'autres sujets relatifs à la gestion et à la sécurité de Windows.
Dans cette première partie, je traiterai du nouveau format Windows Imaging (WIM). Si vous n'êtes pas encore familiarisé avec les détails de la création d'images, n'oubliez pas de lire la barre latérale "Le processus de création d'images type" pour avoir une vue d'ensemble. Ma prochaine rubrique traitera du kit d'installation automatisée (Windows AIK) £ une nouvelle série d'outils qui comprend ImageX (l'outil à ligne de commande utilisé pour créer et manipuler les images WIM) et les services de déploiement Windows (WDS), ce qui remplace les services d'installation à distance (RIS) £ en étudiant la façon dont ces outils facilitent les déploiements de système d'exploitation.

Le tournant
Année après année, l'équipe de déploiement Windows n'a cessé d'entendre les mêmes commentaires de la part des OEM et des entreprises clientes. Ceux-ci souhaitent une meilleure prise en charge de la création d'images et ils veulent que Microsoft leur fournisse des outils de création d'images unifiés. Ces utilisateurs ne veulent pas se charger du choix d'un fournisseur tiers et ne veulent pas non plus apprendre les subtilités de leur produit. En outre, nous avons par le passé fréquemment eu des plaintes, ces OEM et entreprises clientes estimant qu'ils ne devraient pas avoir à payer les outils de création d'images utilisés pour déployer Windows ; ils veulent au contraire que Microsoft leur fournisse ces outils.
À un stade précoce du développement de Windows Vista™, l'équipe de déploiement Windows a pris un très gros risque. Nous avons décidé d'abandonner complètement l'intégralité du moteur d'installation, dont de nombreux composants existaient depuis près de dix ans. L'installation avait toujours été délicate et comportait bien trop d'étapes. Nous souhaitions accélérer le processus, supprimer les étapes superflues et améliorer la fiabilité de l'installation Windows de façon globale. Pour ce faire, nous devions modifier le processus d'installation dans son intégralité en partant du moteur artisanal que nous avions utilisé pendant un certain temps et le remplacer par un processus d'installation entièrement basé sur les images.

Conception d'un nouveau format de création d'images
À un stade précoce du processus de reconception de l'installation, nous avons décidé de définir le type d'image à utiliser. Le débat classique opposait secteur et fichier. À savoir, fallait-il utiliser un format d'image qui stocke la copie d'un volume sous la forme d'une duplication secteur par secteur ou bien un format d'image qui stocke chaque fichier de façon individuelle ? L'avantage que la plupart des gens espèrent en retirer est la vitesse (avec une approche secteur) ou la compression (avec une approche basée sur les fichiers). Au final, nous avons opté pour un format que j'estime être un très bon compromis entre les deux. Il offre de très bonnes performances, mais permet également une grande compression.
Pour commencer, nous avons défini plusieurs objectifs clé que nous devions atteindre pour générer un format de création d'images qui réponde aux besoins des OEM et des entreprises clientes. Notre liste était fortement orientée vers une architecture basée sur les fichiers. Je pense que nous avons tous vu les avantages de cette approche et par conséquent nous nous sommes, dans un premier temps, lancés sur cette voie. Les fichiers WIM ont alors rapidement vu le jour. (Et au cas où vous vous poseriez la question, le "M" de WIM n'est pas là par hasard. Nous l'avons appelé WIM en nous basant sur les événements de l'équipe Windows qui se répètent lorsque se rapprochent les jalons de publication £ et *.WI aurait été une abréviation un peu bizarre). Examinons donc l'ensemble des objectifs que nous avons défini pour le nouveau format d'image.
Neutralité vis à vis du format du système de fichiers Windows Le format d'image devait fonctionner dans les deux architectures de système de fichiers que Windows prend en charge. Bien que presque tous les systèmes utilisent NTFS lors de leur exécution, un grand nombre d'OEM et d'entreprises utilisent les systèmes de fichiers FAT comme palliatif leur permettant d'utiliser MS-DOS® pour déployer Windows. Ils effectuent par la suite la conversion NTFS. Nous devions continuer à prendre en charge ceci pour Windows Vista.
Neutralité vis à vis de la géométrie de volume Nous devions trouver une solution au problème historique qui consiste à capturer un grand volume et à l'appliquer à un plus petit. Même lorsque l'outil de création d'images peut résoudre ce problème via des astuces de manipulation de partition, l'opération n'est pas fiable. Dans une architecture basée sur les fichiers, l'image occupe le même espace que les fichiers qui la composent. Le système de fichiers étant restauré indépendamment, vous ne pouvez pas vous fier à la taille du volume.
Le processus de création d'images type
Lorsqu'un OEM copie un grand nombre de systèmes ou qu'un grand organisme a besoin de déployer Windows sur un grand nombre de machines, ils utilisent en général la technologie de création d'images. Le principe de départ consiste à prendre le système hôte, à le générer exactement comme vous le souhaitez, puis à le dupliquer sur les systèmes cibles. Dans le cas où vous ne seriez pas familiarisé avec le processus de création d'images, en voici une rapide vue d'ensemble.
  1. L'administrateur installe Windows sur un système et le configure comme il le souhaite. Cela implique l'ajout ou la suppression de composants, l'installation d'applications couramment utilisées et le réglage de l'interface utilisateur et d'autres paramètres. Appelons ce système le système hôte.
  2. L'administrateur exécute alors Sysprep (fourni par Microsoft sous la forme des outils de déploiement Windows), qui effectue la tâche du nettoyage des attributs qui rendent une installation de Windows unique (tels que le nom de l'ordinateur, l'identificateur de sécurité Windows (SID) et d'autres identificateurs uniques sur le système). Ils sont réinitialisés lors de l'exécution de la seconde moitié de Sysprep.
  3. L'administrateur éteint ensuite l'ordinateur et le redémarre sous Windows PE, MS-DOS ou sous un autre système d'exploitation lui permettant d'exécuter l'application de création d'images.
  4. L'administrateur exécute maintenant l'outil de création d'images, en créant une image du système de référence. Cette image est un fichier (ou un ensemble de fichiers) qui contient une réplique exacte du disque de référence ou de la partition.
  5. Le système est éteint et l'administrateur archive l'image, qui peut être mise à jour (par l'ajout d'applications, de correctifs et de service packs) si nécessaire.
  6. L'image est dupliquée sur un ou plusieurs ordinateurs et Sysprep finalise son travail, en exécutant une version d'installation abrégée (appelée Mini-installation ou Accueil de Windows, en fonction de la version de Windows sur laquelle vous exécutez Sysprep et de la façon dont Sysprep est configuré). Cette étape est possible grâce à un minuscule exécutable en mode natif appelé setupcl.exe.

Neutralité vis à vis de l'architecture du système L'architecture de l'image devait fonctionner avec toute architecture que Windows était susceptible de prendre en charge. À l'époque, cela revenait à prendre en charge les architectures x86 et IA64 (Intel Itanium), très différentes l'une de l'autre. Aujourd'hui, cela inclut aussi l'architecture x64 (AMD64 et EM64T).
Rapidité de capture et d'application requise L'image devait être capturée de façon relativement rapide, étant donnée la compression. Le point le plus critique étant cependant que l'opération devait être très rapide lors de l'application de l'image.
Prise en charge non-destructive de l'application de l'image Puisque nous remplacions l'option de mise à niveau (qui remplace Windows sans endommager les données ou les applications utilisateur) et que nous élaborions un outil qui pouvait être utilisé pour la récupération système, nous voulions qu'elle soit capable de reproduire l'image d'un système sans détruire tous les éléments déjà présents sur le volume. Sans un travail considérable, les formats basés sur les secteurs ne permettent pas à l'utilisateur de faire cela £ en général, vous restaurez tout le volume ou rien du tout.
Prise en charge d'une compression importante Lorsque nous avons commencé à développer Windows Vista, nous pensions encore livrer sur CD-ROM. Compte tenu du fait qu'une image de Windows XP pèse presque 1Go, nous avons décidé qu'il était important de compresser l'image autant que possible. Il est possible d'utiliser certaines astuces avec une image basée sur les secteurs pour faire cela, mais nous étions préoccupés par les composants mobiles d'une telle implémentation. Beaucoup de formats basés sur les secteurs omettent les espaces blancs sur le disque pour économiser de l'espace. (Pourquoi enregistrer un 0 sur une image si ce 0 est constant ?) Cependant, grâce à l'approche basée sur les fichiers, nous avons traité cette question de manière intrinsèque, puisque nous ne captions pas d'espace blanc.
Prise en charge de l'instanciation unique de fichiers Même chose que pour le problème précédent. Windows est bien connu pour stocker plusieurs copies du même fichier dans différents emplacements. L'approche basée sur les fichiers permit de ne stocker qu'une seule instance de chaque fichier et d'utiliser le fichier selon besoin.
Prise en charge de la répartition sur des médias (disques) Même au début de WIM, lorsque nous pouvions faire tenir une image sur un seul CD-ROM, nous savions que nous devions prendre en charge plusieurs médias. Même si nous fournissions Windows sur un CD-ROM, une fois que les utilisateurs avaient ajouté les applications, les service packs, etc., leurs images avaient toutes les chances de dépasser la taille d'un seul CD-ROM ou DVD. Il nous fallait donc les laisser répartir leurs applications sur plusieurs médias pour leur propre installation et solutions de récupération.
Prise en charge de plusieurs images de volume dans un seul blob de fichiers Une image fonctionne rarement pour tout. Lorsque nous avons conçu l'"instanciation unique," nous avons également inclus la capacité de capter plus d'un volume £ et la même compression et instanciation unique fonctionne sur chaque volume. Aussi, si vous sélectionnez une image de Windows XP Professionnel et que vous ajoutez une nouvelle image de Windows XP Édition Tablet PC (qui est un sur-ensemble de Windows XP Professionnel), l'image se trouvera augmentée des fichiers qui sont explicitement différents d'une version à l'autre et de ceux-là uniquement.
Par conséquent, un OEM ou un utilisateur d'entreprise peut ajouter plusieurs images dérivées les unes aux autres sans augmentation exponentielle de la taille. Cette capacité n'aurait été pas facilement réalisable avec des formats basés sur les fichiers.

Fonctionnement de WIM
Le format WIM a été conçu pour être le plus simple possible, tout en respectant nos principes généraux. L'approche basée sur les fichiers nous a permis d'y parvenir. Mais comment ceci fonctionne-t-il exactement ?
En résumé, vous pouvez considérer un fichier WIM comme étant un fichier CAB (semblable au format ZIP, mais Microsoft est le concepteur et le détenteur des droits du format CAB). En fait, une fois, j'ai entendu quelqu'un faire référence à WIM comme étant le "fils de CAB." La différence clé entre un fichier WIM et un fichier CAB est que, outre la capture et la compression du fichier lui-même, une image WIM stocke les métadonnées qui concernent les fichiers et répertoires qui constituent le volume capturé dans une image de volume donnée. C'est donc comme une sorte de fichier d'archive comportant toutes les méta-informations nécessaires pour restaurer le volume tel qu'il était lorsque l'image a été créée £ listes de contrôle d'accès (ACL), noms de fichier courts/longs, attributs, etc.
Remarquez que les informations de partition (taille ou type) ne sont collectées à aucun moment du processus de capture. De même, le processus d'application ne partitionne pas le système. À la différence de la plupart des outils de création d'images, ImageX, étant neutre vis à vis de la partition, a besoin que la partition soit créée et formatée avant l'application. Afin d'automatiser le processus avant d'appliquer votre image, vous devez utiliser les outils à ligne de commande diskpart et format.
Rien ne limite ce qui peut être stocké dans une image de volume. Une image peut contenir deux volumes, le même volume capturé un mardi et un jeudi, une image comportant un service pack et une n'en comportant pas, ou tout autre élément correspondant à vos besoins. La principale chose à comprendre est que des fichiers identiques ne seront capturés qu'une fois. Moins les images de volume ont de choses en commun, plus elles utiliseront d'espace.
Je dois également signaler que rien dans la conception du format WIM ne l'empêche d'être utilisé avec des versions antérieures de Windows. Il fonctionnera aussi bien avec Windows 2000 qu'avec Windows Vista. Regardons maintenant de plus près ce qui se passe exactement lorsque des images sont capturées et appliquées.

Capture d'une image
Lorsque l'image d'un volume est capturée, les étapes suivantes sont effectuées :
Les métadonnées du volume sont capturées ImageX recueille les données correspondant aux noms de fichiers, aux ACL NTFS et d'autres attributs du système de fichiers du volume. (Vous pouvez choisir d'exclure certains fichiers à l'aide d'un fichier script.)
Les données de fichier sont capturées Le fichier est chargé par ImageX. Chaque fichier est chargé sur le volume et se prépare à collecter certaines des données s'y rapportant.
Le hachage de fichier est généré Un hachage cryptographique du fichier basé sur le fichier lui-même est généré. Ce hachage devient l'identificateur unique des fichiers de l'image.
Les doublons sont recherchés et supprimés Si un autre fichier avec le même hachage existe déjà dans l'image, on considère qu'il s'agit du même fichier et le nouveau fichier est référencé par pointage vers le fichier qui existe déjà.
Les données de fichier uniques sont compressées À la différence d'un CAB ou d'autres formats d'archive, chaque fichier d'un fichier WIM est compressé individuellement, plutôt que comme un ensemble de fichiers regroupés sous la forme d'un seul flux de données. Vous pouvez également choisir de ne pas tout compresser, auquel cas cette étape est sautée.
Les métadonnées du volume sont compressées et stockées Une fois la totalité des fichiers archivée, une entrée de métadonnées pour le volume est créée. Celle-ci répertorie chacun des fichiers qui ont été ajoutés à l'image pour le volume.
Les données de l'image XML sont générées et stockées Il s'agit d'une référence pour chaque image de volume capturée. Si vous exécutez ImageX /info, par exemple, ces données XML sont celles que vous verrez.
L'index des données WIM en mémoire cache est écrit Enfin, l'index principal des données (accompagné des données en mémoire cache) est écrit. Il s'agit de la table de fichiers principale pour la totalité du WIM ; elle comporte une entrée par hachage.
Comme vous pouvez le voir, un WIM est créé, fichier par fichier. En outre, vous disposez d'un fichier WIM, quel que soit le nombre de volumes que vous ajoutez à l'image.

Surcharge d'image
Plusieurs équipes développaient des solutions semblables lorsque nous avons commencé à travailler sur WIM. L'équipe des services automatisés de déploiement développait une solution de création d'images pour un segment de clientèle différent. Leur approche comprenait des détails d'implémentation de bas niveau très intéressants, mais leur moteur de création d'images, comme la plupart des moteurs de cette époque, était basé sur les secteurs. L'équipe Windows XP Embedded avait également généré un moteur de création d'images basé sur les secteurs pour permettre aux fabricants de matériel indépendant intégré (IHV) de déployer leurs propres images lors de la fabrication du système. Et lorsque l'équipe Virtual PC a été acquise par Microsoft en 2003, ils ont apporté avec eux un autre format de fichier pour les fichiers du disque dur virtuel (VHD).
Tous ces formats étaient essentiellement basés sur les secteurs. Ils correspondaient aux besoins de chacun des segments de leur clientèle, mais ces solutions n'auraient pas respecté nos instructions pour WIM. Par conséquent, nous avons poursuivi la construction du nouveau format WIM et de l'outil à ligne de commande ImageX pour la capture des images. En fin de compte, un certain nombre d'autres équipes a adopté notre format bien avant qu'il ne soit publiquement considéré comme faisant partie intégrante de Windows Vista bêta. L'équipe SMS, par exemple, a publié une implémentation anticipée de WIM dans leur Feature pack de déploiement du système d'exploitation.

Application d'une image
Intéressons-nous maintenant au processus de compteur : application d'une image.
Index des données WIM en mémoire cache chargé Cette étape est à mettre en corrélation avec la dernière étape de la procédure précédente. Puisqu'il s'agit de l'index principal, c'est le premier élément à charger à partir du WIM après avoir spécifié quelle image de volume appliquer.
Les métadonnées d'image sont récupérées et chargées ImageX charge les métadonnées propres à chaque image de volume.
La structure de répertoires est créée Afin de s'assurer que chaque fichier a un emplacement où être restauré, l'intégralité de l'arborescence de répertoire du volume est créée.
Les données de fichier sont extraites Les fichiers sont extraits à partir du WIM, suivant exactement le même ordre séquentiel dans lequel ils ont été archivés.
Les données de fichier sont appliquées Dans cette étape, les fichiers sont chargés, décompressés (si l'image de volume a été compressée dans le WIM) et copiés à chaque emplacement référencé. Enfin, toutes les métadonnées de chaque fichier sont appliquées.
Toutes les métadonnées de répertoire sont appliquées C'est important qu'il s'agisse de la dernière étape car il est possible qu'un ACL d'un répertoire empêche l'image d'être appliquée correctement.

Compression souple
L'un de nos objectifs clé avec le format de création d'images WIM était de fournir des options de compression souples. Nous avons donc donné la possibilité de capturer une image de volume avec compression lorsque nécessaire, tout en autorisant également la capture d'image sans compression. Cette dernière option est intéressante pour les scénarios où l'image n'a pas besoin d'être compressée de manière agressive ou lorsque la capture à vitesse élevée est critique.
Il existe quelques principes clé qu'il faut garder présents à l'esprit pour la compression. La compression prend toujours plus de temps que la décompression. Plus l'algorithme de compression est agressif, plus la compression d'un jeu de données défini sera longue. Et plus vous alimentez un algorithme de compression en données et mieux il effectuera la compression.
Les images WIM peuvent être compressées à l'aide de la compression XPress ou LZX £ et bien sûr, aucune compression n'est optionnelle. XPress est un bon compromis lorsque vous avez besoin d'effectuer une certaine compression, mais que vous ne souhaitez pas consacrer trop de temps au processus de capture. LZX offre un taux de compression optimal £ mais comme vous vous en doutez, cette méthode prend plus de temps.
Ne pas utiliser la compression permet de capturer l'image le plus rapidement, mais avec pour résultat l'image la plus grande. Le type de compression est une option propre au WIM. Une fois qu'une image de volume est capturée dans un WIM, toutes les images de volume suivantes doivent être capturées selon les mêmes paramètres de compression.
Remarquez qu'étant donné que les images WIM compressent fichier par fichier, la compression n'est pas aussi complète qu'elle pourrait l'être. Tout ceci participait d'une décision réfléchie £ nous avons procédé de la sorte afin que l'image puisse être modifiée plus facilement. La possibilité de modifier les images après la capture est une option importante. Pour qu'un fichier soit modifié après capture de l'image, les données du fichier et ses métadonnées doivent être remplacées. Si vous aviez compressé l'intégralité du WIM en une seule fois, il eut été pour nous incroyablement compliqué de concevoir la prise en charge des fichiers modifiables (en supposant bien sûr que cela soit possible) et remplacer un fichier dans l'image prendrait un temps considérable. Grâce au compromis que nous avons établi, nous avons obtenu un format qui est correctement compressé et peut encore être modifié à l'aide de nos outils.
J'espère que ces explications vous permettent de bien comprendre la façon dont fonctionnent les capacités de création d'images que nous avons conçues pour Windows Vista. Dans ma prochaine rubrique, je traiterai de certains des outils que vous pouvez utiliser pour gérer et déployer des images WIM images, en m'intéressant de plus près à ImageX et aux services de déploiement Windows.

Wes Miller est responsable du développement chez Pluck (www.pluck.com) à Austin, au Texas. Par le passé, Wes a travaillé chez Winternals Software à Austin et chez Microsoft en tant que responsable de programme et responsable de produit pour Windows. Vous pouvez contacter Wes à l'adresse suivante : technet@getwired.com. Wes souhaiterait remercier John Macintyre, l'actuel responsable du programme WIM/ImageX chez Microsoft pour sa collaboration à cette rubrique.


 Windows Confidential: En attendant RunOnce
Windows Confidential
En attendant RunOnce
Raymond Chen

PRENONS L'EXEMPLE D'UNE installation qui requiert un redémarrage du système au milieu du processus. Par exemple, le programme peut souhaiter mettre à niveau un système DLL en cours d'utilisation. Vous devriez effectuer un redémarrage intermédiaire pour que le nouveau fichier DLL soit installé et une fois le DLL mis à niveau, vous pourriez l'utiliser lors de la prochaine étape de l'installation.
La clé RunOnce était destinée à ce type de scénario£à être utilisée par les programmes d'installation pour terminer leur installation après un redémarrage intermédiaire. (Cela remonte à l'époque où l'on pensait que les programmes étaient fiables.)
Windows® Explorer attend que le programme RunOnce soit exécuté jusqu'à la fin avant de créer le bureau et la barre des tâches. Cela tient au fait que RunOnce fonctionne suivant le principe que c'est fait pour les programmes d'installation. Le programme RunOnce pourrait changer les données de configuration du système et vous ne voudriez pas que l'utilisateur utilise un système en cours de reconfiguration.
Imaginons, par exemple, que le programme RunOnce soit en train de relocaliser et de lier les fichiers qu'il vient d'installer - et que certains d'entre eux font partie d'une extension de l'interpréteur de commandes. Vous ne souhaitez certainement pas que l'utilisateur tente d'exécuter le programme ou d'activer l'extension alors que son exécutable est toujours en train d'être mis à jour.
Un autre inconvénient du principe « c'est fait pour les programmes d'installation » réside dans le fait que la clé RunOnce n'est traitée que si un utilisateur avec des privilèges d'administrateur ouvre une session. Ainsi, les utilisateurs qui ne sont pas des administrateurs ne seraient pas en mesure de terminer l'installation. Par ailleurs, si la clé RunOnce était exécutée pour des utilisateurs non-administrateurs, elle ne serait plus une clé « run once » (à exécution unique). En fait, cela pourrait créer un certain dilemme. Comment pourriez-vous dire « OK, j'ai exécuté cela une fois ; il ne faut plus l'exécuter » ? Pour modifier cet état global du système, il vous faudrait avoir des privilèges administratifs. Et, de toute évidence, l'utilisateur qui n'est pas administrateur ne dispose pas de privilèges administratifs ! Le programme ne serait plus « à exécution unique » : il serait « à exécution répétée jusqu'à ce qu'un administrateur ouvre une session ».

(Cliquer sur l'image pour la réduire)

(Cliquer sur l'image pour l'agrandir)
RunOnce, qui est destiné à la finalisation d'une installation de programme, est visible lors de l'installation de Windows proprement dite. Lorsque vous essayez d'installer un service pack ou d'effectuer une mise à niveau avec une version plus récente de Windows, l'assistant d'installation vérifie la clé RunOnce. Si elle n'est pas vide, vous obtiendrez un message d'erreur indiquant, « Attention, vous avez encore une installation de programme en cours qui n'est pas terminée. Veuillez la terminer avant d'essayer de mettre à niveau le système d'exploitation ». Quoi de plus normal, vous ne voudriez pas en effet, modifier le système d'exploitation au beau milieu de l'installation d'un programme.
L'ensemble de la structure de RunOnce dit tout sur son passé. Elle était hachée dans Windows 95, un système d'exploitation qui ne faisait pas de distinction entre les administrateurs et les non-administrateurs. Dans la mesure où tous les utilisateurs étaient, de fait, des administrateurs sur Windows 95, un programme d'installation qui utilisait RunOnce pouvait compter sur le fait que les actions RunOnce seraient effectuées lors du redémarrage suivant.
Sur les systèmes d'exploitation Windows plus récents (cela se vérifie particulièrement sur Windows Vista™) il est possible que personne ne disposant de privilèges administrateur ne se connecte pendant des mois. Par conséquent, un programme qui nécessite que RunOnce soit exécuté pourrait se retrouver en attente pendant très, très longtemps.
A ce propos, j'ai vu un RunOnce perpétuel. Il se rajoutait à la clé RunOnce lorsqu'il était exécuté. Cela va clairement à l'opposé de l'objectif de RunOnce, dans la mesure où cela ne fait plus partie de l'installation du programme mais plutôt du fonctionnement normal de ce dernier. De plus, ce comportement fait que l'installation de Windows persiste à signaler qu'une installation est en cours.
Ainsi, l'utilisateur ne peut jamais mettre à niveau le système d'exploitation car ce programme pesky répète à l'envi, « Il me reste encore quelques tâches à effectuer et après j'en aurai vraiment terminé ». Le programme ne terminera pas l'installation aujourd'hui, « mais à coup sûr, ce sera fait demain ». C'est un peu comme dans En attendant Godot, mais sans la crise existentielle, espérons-le.

Raymond Chen, The Old New Thing, dresse un historique de Windows et traite de la programmation Win32. Il prépare actuellement un livre, intitulé, par pure coïncidence, The Old New Thing (Addison-Wesley, 2007).