Les besoins croissants des utilisateurs ont fait émerger d'autres fonctionnalités :

Transcription

1 Ce que vous devez savoir sur Exchange 2007 Préambule La nouvelle version du serveur de messagerie Microsoft est enfin arrivée : Exchange Server Succédant aux versions Exchange 5.5, Exchange 2000 et Exchange 2003, celle nouvelle version apporte de nombreuses fonctionnalités supplémentaires. Vous pouvez considérer, dans ce contexte, que le passage de la version 2000/2003 à 2007 est analogue à la migration des versions 5.5 à Une fois de plus, les changements sont tellement importants que cela va vous obliger à revoir tous les concepts et méthodes de déploiement, d'administration et d'exploitation. L'utilisation de la messagerie dans les entreprises est devenue aujourd'hui incontournable. La solution Small Business Server de Microsoft a permis par exemple à des millions de petites sociétés de se doter de ce type d'outil et a contribué à démocratiser l'utilisation de la messagerie électronique dans le monde. Toutefois, l'utilisation de celle-ci a évolué durant toutes ces années. En effet, un simple outil d'envoi et de réception mail, à ses débuts, est devenu un serveur dédié au travail collaboratif et à la communication générale au sein de l'entreprise. Les besoins croissants des utilisateurs ont fait émerger d'autres fonctionnalités : - centraliser par exemple toutes les données rentrantes sur un seul point d'accès, - interroger sa messagerie depuis son téléphone portable à l'aide de la reconnaissance vocale, - permettre un accès à son client Microsoft Outlook depuis n'importe quel endroit tout en conservant toutes ses fonctionnalités ou encore permettre de pousser les mails jusqu'à l'utilisateur final. Microsoft Exchange 2007 a été conçu spécifiquement pour répondre à quatre demandes essentielles en ce qui concerne l'utilisation et l'exploitation d'un serveur de messagerie d'entreprises : sécurité, performance, fonctionnalité et coût. Les principales nouveautés d'exchange 2007 Parmi toutes les nouvelles fonctionnalités d'exchange Server 2007, voici les dix principales plébiscitées par Microsoft, et qui devraient, pour certains d'entre vous, vous ravir. Console de Management Exchange : la console est une des deux nouveautés des interfaces d'administration d'exchange 2007 et est basée sur la console Microsoft Management Console Version 3 (MMC V3). Cette console est requise pour pouvoir administrer Exchange En utilisant cette console, vous pouvez manager tous les serveurs Exchange, les destinataires et composants administratifs de votre organisation. Exchange Management Shell : le Shell Exchange est un nouvel outil d'administration basé sur des lignes de commandes. Le Shell Exchange est capable d'exécuter toutes les tâches d'administration que vous pouvez lancer dans la console MMC et peut même effectuer des fonctions non disponibles dans celle-ci. La Messagerie Unifiée : Exchange 2007 inclut le support pour la Messagerie Unifiée (UM : Unified Messaging). La messagerie unifiée combine de multiples infrastructures dans une seule architecture de messagerie. Grâce à la messagerie unifiée Exchange 2007, les utilisateurs peuvent recevoir tous les mails électroniques, fax, SMS et messages vocaux dans une seule boîte Exchange et y accéder par différents périphériques, tels que les téléphones mobiles, analogique ou numérique. Cela se réalise au moyen d'un système de

2 reconnaissance vocale. Amélioration des performances : Exchange 2007 supporte le déploiement d'exchange dans une architecture 64 bits et améliore par ce biais les performances et les capacités. En passant d'une version 32 bits à une version 64 bits, la version Entreprise d'exchange 2007 offre maintenant la possibilité de prendre en charge plus de groupes de stockage et de bases de données par serveur. Vous pourrez ainsi créer jusqu'à 50 groupes de stockage par serveur et 50 bases de données par serveur. Disponibilité : lorsque de multiples serveurs Exchange 2007 ayant le rôle Hub Transport Ser-ver sont déployés sur un site, un équilibre de charge ou load balancing est automatiquement assuré dans le flux des messages transitant entre le Hub Transport et les serveurs de boîtes aux lettres et ne nécessite aucune configuration de l'administrateur. Si le serveur Hub Transport Server, appelé serveur de pont, est indisponible à cause d'un incident ou d'une intervention programmée, un système de récupération est lancé automatiquement avec les autres serveurs de ponts. Hautes disponibilités pour les serveurs de boîtes aux lettres : Exchange Server 2007 inclut trois nouvelles fonctionnalités de haute disponibilité pour les serveurs de boîtes aux lettres : Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Single Copy Clusters (SCC). Ces fonctionnalités de réplication continue utilisent les logs pour charger une copie des groupes de stockage de production. Dans un environnement LCR, la copie est située sur le même serveur où se trouve le groupe de stockage de production. Dans un environnement CCR, la copie est située sur le nœud passif de votre cluster. Basé sur Active Directory : la complexité du routage SMTP Exchange a été réduite en la basant sur l'architecture des sites et services Active Directory. Cela signifie que vous n'avez plus à configurer le routage Exchange lors du déploiement. En revanche une configuration de routage entre Exchange 2003 et 2007 reste nécessaire durant une phase de migration. Diminution du trafic : Exchange 2007 route automatiquement les mails en utilisant le moins d'étapes possibles. Chaque site Active Directory est considéré comme une étape. Exchange 2007 sélectionne le chemin le plus direct entre le serveur source et le serveur destination. Si un serveur de transport (Serveur Hub Transport) est indisponible dans un site de manière temporaire les mails sont mis en attente dans un état échec. Résolution des destinataires : le serveur Hub Transport améliore la gestion des listes de distribution et listes de distribution dynamique (appelé groupe de distribution fondé sur des requêtes). Le serveur Hub Transport se sert d'active Directory pour communiquer avec d'autres serveurs dans le même site à l'aide de la structure site et service d'active Directory. Auto découverte : les clients Outlook 2007 peuvent automatiquement se connecter à leurs serveurs d'accès clients pour accéder à leurs boîtes aux lettres. Ainsi le paramétrage du poste client se fait automatiquement.

3 À qui est destiné cet ouvrage Cet ouvrage est spécialement dédié à tous les administrateurs de messagerie Exchange mais également à tous ceux qui souhaitent simplement découvrir ce nouveau produit. Que vous soyez débutants ou confirmés en administration de messagerie, ce livre est écrit dans l'esprit d'une autoformation. L'administrateur Exchange utilisant une version antérieure à 2007 trouvera l'ensemble des informations nécessaires à la mise en œuvre du produit dans un contexte de migration. Il pourra en effet, se constituer un ensemble de méthodes à mettre en œuvre pour optimiser ses chances de réussites dans le cadre d'une migration d'exchange 200X ou Exchange 5.5 à Exchange Les administrateurs de serveurs de messageries tiers pourront établir un comparatif objectif entre les solutions qu'ils connaissent et Exchange Ils auront à disposition un ensemble d'éléments leur permettant de tester toutes les fonctionnalités du produit et d'étudier des possibilités de migration ou de collaboration entre les différents environnements. Les débutants, quant à eux, auront matière à travailler grâce à cet ouvrage en raison des nombreux concepts théoriques mais aussi de ses exemples. Ils auront le loisir de valider leurs connaissances grâce aux nombreux exercices de chaque chapitre et de s'assurer ainsi qu'ils ont bien intégré toutes les notions fondamentales qui leur ont été enseignées. Toutefois, pour apprécier pleinement cet ouvrage, vous allez devoir vous familiariser avec certaines technologies telles que Active Directory, Annuaire ADAM, Schéma, Domaine et bien d'autres encore. Pour ceux qui sont encore novices dans ces environnements, vous trouverez au chapitre Architecture Active Directory toutes les notions nécessaires pour vous aider dans la lecture de ce livre. Si vous ne comprenez pas ces concepts, vous aurez beaucoup de difficultés à lire les autres chapitres. Soyez attentif et prenez le temps de bien assimiler l'ensemble de ces notions fondamentales avant de passer à la suite.

4 Comment lire cet ouvrage Comme nous l'avons vu précédemment, cet ouvrage est conçu pour trois types de public différents, les administrateurs Exchange, les administrateurs de serveurs de messagerie tiers et les débutants. Ce qui vous donne donc trois manières d'aborder ce livre. Pour les administrateurs Exchange : il peut tout d'abord être lu sans tenir compte du plan. Vous pouvez prendre un chapitre de manière aléatoire qui traite d'un sujet particulier et exploiter les informations qui vous intéressent. Vous pouvez également réaliser certaines manipulations détaillées au cours des différents chapitres, afin de vous assurer que vous en avez retenu l'essentiel. Pour les administrateurs de serveurs de messagerie tiers : vous pouvez lire cet ouvrage en ne consultant que les points qui vous intéressent. Si par exemple, vous voulez aborder le thème de la messagerie unifiée, vous avez simplement à regarder le chapitre concerné et bien étudier les concepts et méthodes indiquées. Ainsi, vous aurez une vision concise du sujet et vous serez en mesure de juger de la qualité du logiciel et de ses fonctions. Pour tous les autres : vous avez une dernière option qui consiste à lire l'ouvrage du début à la fin en respectant attentivement l'ordre des chapitres pour valider vos acquis. Cela permet de réaliser une autoformation efficace, et vous donne ainsi, les aspects méthodologiques mais également techniques de la mise en œuvre complète d'une solution de serveur de messagerie sous Exchange Quel que soit le type de public auquel vous appartenez, vous remarquerez que le livre suit une chronologie bien précise. Vous allez démarrer par une partie planification avant de vous lancer dans la réalisation. Cela vous permettra de maîtriser l'outil ou bien seulement de pouvoir en parler de manière objective.

5 Comment gérer un projet Avant de démarrer cet ouvrage, vous devez dans un premier temps vous concentrer sur une méthode d'organisation, d'implémentation, d'exploitation pour mener à bien votre projet. Mais, vous devez surtout prendre en compte la problématique suivante : - Comment vais-je mettre en place une solution de ce type pour qu'elle réponde aux besoins actuels et futurs? - Comment vais-je démarrer mon projet? - Quelles sont les clefs de la réussite pour mener à bien la réalisation d'un tel projet? Dans toutes ces questions, se cache une méthode simple que vous allez découvrir.» Si vous avez déjà des notions de gestion de projets ou que seule la partie technique vous intéresse, alors vous pouvez passer au chapitre suivant. Pour les autres, apprenez à prendre vos repères dans la gestion de projet et inspirez-vous de cette méthode avant de vous attaquer directement à l'aspect technique du produit. Connaissez-vous la méthode du QQOQCP? Le Qui, Quoi, Où, Quand, Comment et Pourquoi ne vous dit rien? Alors lisez ce qui suit. Pour réussir un projet, vous devez poser les bonnes questions, et ce dans le but d'obtenir les bonnes réponses. Cela peut paraître simple, mais détrompez-vous, il s'agit de la tâche la plus difficile à réaliser. Si votre responsable vous demande de mettre en place un serveur de messagerie, cela ne vous indique pas si tous les employés de la société sont concernés ni d'ailleurs si vous devez mettre en place des quotas sur les boîtes aux lettres ou si le serveur devra être accessible depuis l'extérieur.

6 Vous n'avez aucune de ces informations car votre responsable ne vous les a pas transmises. C'est justement là que commence votre travail. Imaginez à présent la situation suivante : un utilisateur appelle la hotline pour signaler que toutes les applications, Word, Excel et même sa comptabilité fonctionnent de manière irrégulière le matin et également en début d'après-midi. Le hotliner lui demande alors un peu plus de précision et il l'informe que cela concerne beaucoup de personnes dans l'entreprise et cela se produit de manière aléatoire dans la semaine. Considérez dès maintenant qu'il s'agit en fait d'un problème réseau sur un élément physique, le Switch. Si le hotliner considère que l'origine du problème est système ou viral, il démarre la résolution de l'incident en partant d'une solution fausse. Cela reviendrait à imaginer un mathématicien essayant de résoudre une équation en partant du résultat. Le hotliner devra donc utiliser le mode de résolution entonnoir. Ce mode consiste à prendre plusieurs causes et à traiter tous les cas possibles de pannes. Il peut ainsi éliminer au fur et à mesure certaines d'entre elles jusqu'au moment où il ne restera plus qu'une cause possible. Comme quoi, peu importe le détail technique mais importe la méthode.» Tout cela nous ramène à la conclusion suivante : lors de votre étude, ne partez jamais dans l'idée que vous avez déjà la solution mais construisez-la en fonction des réponses que vous avez obtenues. N'hésitez surtout pas à poser de nouveau les questions pour vous assurer d'avoir bien compris ce que demande votre Direction Technique. À présent, voici les questions que vous serez amené à vous poser. Le Qui Le Qui est la première question essentielle que vous devez vous poser. Elle va répondre naturellement à une éventuelle faisabilité de votre projet. Si aucune personne de votre service ne sait implémenter un serveur Exchange, vous aurez sans nul doute, beaucoup de mal à le réaliser. Vous devez connaître parfaitement tous les acteurs actifs ou passifs du projet afin que chacun puisse trouver sa place dans la fonction et dans le temps. Elle permet également de constituer un ensemble de ressources qui sera votre soutien permanent durant toute la phase d'étude et de réalisation. Quelques exemples : - Qui est concerné par le projet? - Qui, au contraire, n'est pas concerné? - Qui va répondre aux questions techniques? - Qui va répondre aux questions fonctionnelles? - Qui fera partie de l'équipe projet? - Qui est à l'initiative du projet? - Qui est le financeur? - Qui peut vous aider dans la réalisation de ce projet? - Qui peut avoir un rôle à court, moyen et long terme?

7 - Qui peut poser des contraintes? - Qui a déjà réalisé ce type de projet? - Qui va me fournir les éléments matériels et logiciels? Le Qui répond à une question simple : qui va, de près ou de loin, interagir dans le projet et comment? Si nous devions faire un schéma, nous le représenterions ainsi :» Dans le cas où vous êtes seul à mener le projet, vous devriez avoir alors toutes les compétences nécessaires pour mener à bien cette mission. Si ce n'est pas le cas, il vous reste deux solutions, trouver une aide externe qui puisse vous aider ou lire entièrement ce livre. Le Quoi Cette question demeure la plus sensible. Vous vous demandez pourquoi? Tout simplement parce qu'elle va définir l'essentiel de votre architecture. C'est le noyau dur de votre projet et vous devez impérativement en prendre conscience dès que vous vous lancerez dans cette fabuleuse aventure. Quelques exemples : - Quelles versions d'exchange installer? - Quelle architecture de messagerie installer? - Migrer ou mettre à jour? - Quelles sont les spécificités du(des) serveur(s)?

8 - Quels types de matériels? - Quelles marques de matériels? - Quelles versions du système d'exploitation? - Quels sont les besoins en terme de redondance, de sauvegarde? - Quelles sont les répartitions de charges souhaitables? - Quelle architecture pour maintenant et pour demain? Cette liste de questions est loin d'être exhaustive mais vous donne quelques éléments de base pour démarrer votre recherche de besoins. La question essentielle est de positionner votre architecture dans le temps. Le Où Cette question du Où vous fait très certainement sourire. Vous devez vous demander pourquoi la question Où se pose? C'est très simple : votre vision de l'architecture Exchange ne doit pas être uniquement liée à une installation d'un serveur, soumis à des contraintes et des spécifications techniques, mais elle doit aussi se situer dans l'espace. En effet, sous Exchange 2007, la structure site et service Active Directory sert de base à toute la communication des serveurs de messagerie. Les administrateurs Exchange 5.5 qui ont déjà du absorber le changement de l'administration Exchange 2000 devront encore faire un pas de plus vers l'administration Active Directory. Il suffit de se dire que la messagerie va devenir une application simple qui se greffe autour d'un annuaire qui devient le noyau dur de votre architecture. À cette étape du livre, il vous reste encore deux possibilités : fermer ce livre et vous dire que finalement les précédentes versions d'exchange vous conviennent et que la migration ne se fera pas chez vous ou alors relever le défi et poursuivre la lecture de ce livre. Quelques exemples : - Où vont se situer mes serveurs? - Où se trouveront les clients? - Depuis quel endroit vais-je devoir administrer mon serveur Exchange? - Mon serveur sera-t-il joignable depuis n'importe quel endroit? - Où se situent les autres serveurs de l'architecture? - Où se trouvent les serveurs qui gèrent l'active Directory? - Où se trouvent toutes les applications nécessaires à mon installation? - Où vais-je pouvoir trouver des informations nécessaires à l'installation?» Ne confondez pas avec le "ou" sans accent qui entre dans le cadre des questions du quoi. N'oubliez pas : plus vous aurez d'informations avant de commencer, plus votre projet se

9 déroulera correctement, et plus les questions afflueront en amont de la mise en place, plus vous vous rapprocherez de la réussite. Le Quand Cette question est celle que vous entendez le plus souvent, et pour cause : ne dit-on pas le temps c'est de l'argent? Combien de fois avez-vous entendu "nous allons vous faire gagner du temps"? Quelle remarque générale pouvons-nous faire sur le temps? Il est incompressible! Combien de fois avez-vous entendu votre responsable vous dire "il me faut cela pour hier"? Tout le monde, qu'il soit issu du monde informatique ou non, a déjà entendu ces questions. Alors quoi de plus normal que de les poser pour votre projet. Les questions relatives aux "quand" sont nombreuses. Il est question du temps d'implémentation de la solution, il est question du temps d'étude, etc... À tous les niveaux, nous aurons cette problématique. Pourquoi me direz-vous? Car cette question est celle qui vous permettra d'estimer le coût d'implémentation de votre solution. Grâce à la maîtrise du temps, vous maîtrisez les coûts et donc la réussite de votre projet. Quelle que soit la problématique, vous avez toujours une question de temps, de délai et d'objectifs. Quelques exemples : - Quelles sont les dates de début et de fin du projet? - Quels sont les délais de chaque équipe? - Avez-vous des pénalités de retard sur le projet? - Avez-vous des délais sur les livraisons des logiciels? - Quelle est la durée hebdomadaire de travail? - Quelles sont les réunions planifiées? - Quelle est la durée maximale de mise en place? - À quel moment installerez-vous tel ou tel serveur? La liste est loin d'être complète mais il vous appartient de trouver les questions suivantes. L'objectif de cette partie du livre étant de vous donner des bases et non de traiter uniquement de la gestion d'un projet de mise en place Exchange Le Comment Dans cette question, vous entendez essentiellement le mot méthode. La méthode ou plutôt votre méthode est importante pour la réussite du projet. Sans méthode, vous ne pouvez pas correctement lier toutes les tâches, vous ne pouvez pas non plus gérer et traiter toutes les exceptions, vous ne saurez pas quelle décision prendre lors de situation critique. Le comment résume à lui tout seul les méthodes que vous allez utiliser et les moyens que vous mettrez en place pour y arriver. Dans cette question, vous aurez la responsabilité des choix qui seront faits. Vous devrez gérer, organiser, planifier votre projet d'architecture

10 Exchange Quelques exemples : - Comment vais-je mettre en place l'architecture? - Comment vais-je mettre en place une sécurité centralisée? - De quelle manière vais-je installer mon serveur Exchange? - Quelles sont les méthodes d'installation? - Quelles sont les différentes architectures? - Comment vais-je gérer le projet? - De quelle manière dois-je aborder les contraintes de l'entreprise? - Comment vais-je présenter la solution de manière objective? Vous comprenez que la méthode que vous choisirez aura des impacts non négligeables sur l'ensemble du projet. Prenez l'exemple suivant : vous décidez d'installer Exchange de manière automatique sur tous les domaines de votre forêt mais vous n'avez pas prévu les méthodes de préparation du schéma et des domaines. Vous serez confronté à des ralentissements importants dans la phase de réalisation. Ne négligez surtout pas ce point. Le Pourquoi Grâce à cette question, vous serez en mesure de trouver les réponses aux objections qui vous seront émises lors de votre présentation de la solution que vous souhaitez mettre en place. En effet, vous aurez certainement à argumenter, à convaincre devant un public qui sera parfois sceptique, voire contestataire ou bien carrément opposé. Si vous croyez en votre projet, sachez que tout le monde ne sera pas forcément de votre avis. Si vous connaissez parfaitement votre sujet, vous serez plus à même de le défendre objectivement, avec force et conviction. Quelques exemples : - Pourquoi dois-je implémenter cette solution? - Qu'est-ce que cela va apporter à ma société? - Quels sont les avantages et inconvénients? - Quelles sont les solutions concurrentes? - Quels sont les coûts directs et indirects? - Quelles sont les contraintes à court, moyen et long terme? - Est-ce que cette solution est fiable? - Est-ce que cette solution peut s'intégrer dans mon système d'information?

11 - Pourquoi une solution de messagerie interne et non pas hébergée? - Quelles sont les objections potentielles? - Pourquoi cette solution va-t-elle optimiser la production de l'entreprise? - À quels besoins cette solution va-t-elle répondre? - En quoi la solution choisie devra être retenue? Une fois de plus, la liste n'est pas complète. Mais vous avez maintenant un ensemble d'éléments vous permettant de commencer votre étude. Avez-vous remarquez que vous avez, au travers de ces questions, déjà dessiné le plan de votre mission? Avez-vous remarqué que vous allez savoir répondre aux objections avant même qu'elles vous soient soumises? Cette méthode du pourquoi doit vous permettre de défendre efficacement le projet. Vous voilà arrivé maintenant à la phase pratique de ce livre. Vous allez démarrer par une phase de conception et d'implémentation et vous abordez au fur et à mesure toutes les notions techniques essentielles pour la mise en place d'une solution Exchange 2007.

12 Planification de l'infrastructure Vous souhaitez implémenter une solution Exchange 2007 dans un système d'information existant? Vous devez procéder à une nouvelle installation au sein d'une société? Vous avez besoin d'optimiser votre méthode et vos connaissances en gestion de projet? Cette première partie de l'ouvrage vous est directement destinée. Avant de développer les concepts techniques, vous allez apprendre dans cette section comment gérer un projet pour atteindre vos objectifs. Vous allez découvrir comment identifier la source et la cible, comment mettre en place une maquette de test, et enfin comment planifier l'ensemble des tâches qui sont définies. Les points techniques sont peu abordés dans ce chapitre. Cela n'est d'ailleurs pas l'objet de celui-ci. En revanche, il vous apporte un savoir-faire sur les méthodes à appliquer pour votre organisation. De manière plus globale, la lecture de la section qui suit, s'applique à la mise en place d'un logiciel de messagerie mais peut également vous servir pour tout type de projet, quel qu'il soit. Identification de l'architecture source L'une des premières actions à réaliser est de prendre connaissance de votre architecture source. Celle-ci définit l'ensemble de votre système d'information actuel ainsi que les composants additionnels qui lui sont associés. Elle constitue le point de départ de votre étude. Plus vous connaissez votre source, mieux vous savez définir la cible. Dans votre projet, vous pouvez considérer que vous partez d'un point A (la source) et que vous devez vous rendre vers un point B (la cible). Du point A au point B, vous devez définir toutes les étapes appelées tâches. Il est important d'aborder ces points qui peuvent toutefois vous paraître basiques. En effet, segmenter le plus possible chacune de ces étapes est indispensable si vous voulez vous assurer du bon déroulement du projet. Ainsi la partie ci-après présente une approche simplifiée de ce dont vous devez disposer avant de démarrer un projet. Enfin, pour savoir comment détailler les tâches que vous allez identifier, il est nécessaire de tracer deux lignes directrices : l'une fonctionnelle et organisationnelle et l'autre technique. C'est pourquoi, disposer de compétences en gestion de projet ne suffit pas à mener de telles études. Ces compétences doivent être complétées par un appui technique qui vous garantit un haut niveau d'expertise. En effet, vous ne pouvez pas quantifier des durées de tâches si vous n'en connaissez pas les détails, vous ne pouvez pas non plus identifier des exceptions dans le déroulement d'un processus si vous n'avez jamais eu à les traiter. Toutefois, cet aspect technique n'intervient que dans la partie détaillée du projet. Cela signifie que vous pouvez d'ores et déjà tracer les grands traits de celui-ci et vous faire uniquement aider sur les aspects techniques en fin de pré-étude et d'étude sur l'existant.

13 Cela signifie également, qu'après la lecture de cet ouvrage, vous serez en mesure de prendre en charge l'ensemble du projet même s'il s'avère complexe. Par exemple, imaginez que vous devez mettre en place une solution Exchange 2007 sur un environnement Active Directory monodomaine et multisites. Vous savez ce qu'il faut mettre en place mais vous ne savez pas comment le faire. Vous avez vu dans différentes réunions de présentations du produit qu'il vous faut deux serveurs HUB, un serveur d'accès client et un serveur EDGE. Ces derniers points constituent ce que l'on peut considérer comme étant le détail technique. Si ce dernier constitue votre maillon faible, ce livre va essayer de vous aider à combler cette lacune.» Mais n'oubliez jamais ceci : peu importe le "comment faire", tant que vous savez "où trouver comment faire". Dans les parties suivantes, vous allez apprendre à réaliser une étude et à mettre en place une organisation efficace. Vous allez pouvoir identifier toutes les étapes du début à la fin du projet. Pour mener à bien cette partie étude, il vous est conseillé de mettre en place des tableaux simples afin de consolider dans un seul fichier toutes les données récoltées. FORÊTS DOMAINES SITES OU OU N-1 OU N-2 GPO Groupes Dossiers FORÊT A DOMAINE 1A SITE 1A OU 1A DOMAINE 2A SITE 2A OU 2A DOMAINE 3A. OU 3A OU11A OU111A GPO1A GL1A DOS A OU12A OU112A GPO2A GL2A DOS B... GG1A DOS C DOMAINE 4A DOS D FORÊT B DOMAINE 1B SITE 1B OU 1B.. GPO 1B GG1B DOS 1 DOMAINE 2B SITE 2B... GPO 2B GG2B DOS 2 DOMAINE 3B..... GL1B. DOMAINE 4B..... GL2B. DOMAINE 5B DOMAINE 6B Architecture Système L'architecture système : elle constitue l'essence même de votre structure puisqu'elle reflète votre organisation et son fonctionnement. Comme toute structure, elle apporte son lot d'avantages et d'inconvénients. Il vous appartient d'identifier tous ses éléments. Le terme "système" peut être divisé en deux lots : les contenants et le contenu. Les contenants Les forêts Les domaines Les sites Les unités d'organisation (OU) Les stratégies de sécurité (GPO) Les groupes Les dossiers Le contenu Les systèmes serveurs Les systèmes clients Les applications serveurs Les applications clientes Les bases de données Les logiciels bureautiques La volumétrie des données serveurs La volumétrie des données clients

14 Une fois que vous avez listé tous ces éléments, il ne vous reste plus qu'à faire un inventaire exhaustif dans chacun des lots. Ces derniers vont vous permettre d'identifier votre structure et de vous assurer que vous n'aurez oublié aucun détail pour la suite. Cette étape d'audit vous permet de mieux vous imprégner des problématiques de l'entreprise. En effet, grâce à la découverte de l'environnement source et le listing des ressources acquises, vous pouvez déjà percevoir les limites et contraintes auxquelles vous allez être confrontées. Exemple : Vous devez installer votre serveur Exchange 2007 et vous souhaitez mettre en place la communication "RPC via http" pour les postes itinérants qui possèdent Outlook. Sur un aspect technique, seule la version Outlook 2003 peut prendre en charge cette fonction. Or, si votre parc ne contient que des versions Outlook2000 ou XP, vous ne pouvez donc pas mettre en place cette solution sans mettre à jour les versions Outlook, engendrant de ce fait une augmentation du coût de la mise en œuvre. À présent, nous allons détailler chacun des points qui sont listés ci-dessus. Les contenants Ces contenants sont un ensemble logique identifiant votre structure. Cet ensemble est compris dans un cercle dit de sécurité. Tout ce qui rentre dans ce cercle est soumis à ses règles. C'est la définition même de l'environnement en domaine contrairement à l'environnement en groupe de travail. Le domaine est défini par une limite de sécurité dans laquelle tout objet appartenant au domaine est géré de manière centralisée. Le groupe de travail est défini par la règle de gestion poste à poste. Dans ce contexte, il ne vous reste plus qu'à identifier et positionner tous les contenants de votre infrastructure. En ce qui vous concerne, vous n'aborderez ici que les aspects du domaine. Identification des forêts Les forêts sont les contenants de plus haut niveau. Pourquoi est-il si important de commencer par elles? Parce qu'elles représentent le point de départ de la préparation à l'installation d'une solution Exchange Si vous n'avez pas de forêt, vous ne pouvez pas

15 avoir d'organisation Exchange. Les forêts constituent la base de l'architecture système. Les forêts contiennent tous les autres contenants ci-dessous. En effet, dans une forêt, vous avez les domaines, les OU, les stratégies de sécurité, les relations d'approbation, les réplications, les rôles des serveurs, les droits et autorisations, les dossiers et les arborescences associées. Il vous faut lister le nombre de forêts, leurs niveaux fonctionnels mais également leurs noms et les relations d'approbation existantes entre elles. En effet, si votre structure a fusionné avec une autre société et que les deux entités partagent les mêmes données, il y a fort à parier qu'elles souhaiteront par la même occasion avoir un système de messagerie unique.» La forêt constitue la limite de sécurité pour les domaines qu'elle contient et elle apporte à ceux-ci un schéma unique. L'ensemble des éléments du schéma est répliqué sur tous les contrôleurs des domaines de la forêt. Relation forêt et source : étant donné que l'installation d'exchange modifie considérablement le schéma de votre forêt, vous devez donc connaître le niveau de changement que votre structure est prête à accepter. Vous pouvez rencontrer le cas d'une société ayant deux forêts : une dite de production et une de recette. Vous devez, avant de commencer, savoir quelle est celle qui est modifiable et toujours considérer les possibilités de retour à la configuration initiale. Sans cela, vous pourriez avoir à gérer des situations très délicates. Identification des domaines Les domaines sont les contenants de deuxième niveau. Placés sous la forêt, ils hébergent les objets dits "actifs" de la structure : les comptes, les ordinateurs, les imprimantes, etc. Ces domaines constituent également une limite de sécurité pour les objets qu'ils contiennent. En

16 effet, le contrôleur d'un domaine reçoit une accréditation du contrôleur racine qui à son tour donnera des accréditations à ses objets. Chaque domaine est un ensemble de sécurités qui va autoriser ou interdire l'accès à une ressource à l'intérieur de celui-ci. Vous devez donc identifier le nombre de domaines, leurs niveaux fonctionnels, le nombre de contrôleurs de chacun d'entre eux, les liens de réplication mis en place et les différentes relations d'approbation existantes. Relation domaine et source : identifiez les domaines qui peuvent être impactés par les changements de votre projet. Prenez par exemple la situation qui suit : vous avez une forêt avec trois domaines. Vous souhaitez implémenter une solution Exchange 2007 pour votre entreprise dans laquelle un seul domaine hébergera les serveurs de messagerie. Vous devez alors identifier toutes les étapes nécessaires à la mise en œuvre de cette solution : préparation des domaines, renseignement des catalogues globaux, etc. N'oubliez pas que l'analyse de votre source reste votre seul moyen d'arriver à la cible. Identification des sites Les sites sont les contenants de niveaux dits physiques. Ils représentent la topologie géographique de votre structure et hébergent un grand nombre d'informations notamment les stratégies de réplication dans votre forêt Active Directory. Certains prétendent que la structure Sites et Services Active Directory n'a pas d'importance dans un déploiement et que tout est fait de manière automatique. Ne vous fiez pas à cela car ce point est capital pour la suite. Les notions de réplications, de liens de sites, d'istg ou encore de KCC ne doivent avoir pour vous aucun secret. Si vous connaissez peu la partie théorique, retenez juste ceci : le schéma et les domaines

17 contiennent des informations qui se répliquent entre les différents contrôleurs de domaine. La structure des Sites et Services Active Directory est là pour en assurer la cohérence et la disponibilité. Exemple : Vous êtes un utilisateur du domaine societe.com et votre société est divisée en plusieurs sites répartis dans plusieurs villes. Le matin, vous êtes sur un site et vous changez votre mot de passe. Vous partez l'aprèsmidi sur un autre site dans une autre ville. Si votre infrastructure a prévu ce genre de situation, alors vous n'aurez aucun souci d'ouverture de session sur l'autre site. Dans le cas contraire, vous ne saurez pas quel mot de passe utiliser et vous serez forcé de contacter le support technique. Relation sites et source : la relation qui existe entre les sites et la source est simple. Si vous avez prévu d'installer une organisation Exchange 2007 dans une structure multisites, alors vous devez considérer que les préparations nécessaires des domaines et de la forêt doivent se répliquer sur toute la structure. Si les liens ne sont pas opérationnels ou ne sont pas fiables, vous devez faire face à une contrainte importante. Cette remarque s'avère encore plus vraie pour des déploiements de grande envergure. Identification des Unités d'organisation (OU) L'Unité d'organisation (OU) justifie son rôle par le fait qu'elle permet d'organiser les objets. Si ceux-ci étaient tous placés à la racine du domaine, il serait difficile de les trouver et de les administrer. Si vous deviez placer une stratégie de sécurité pour certains utilisateurs, cela deviendrait difficile à réaliser techniquement. Vous trouvez une situation identique sur un serveur de fichiers. En effet, mieux vaut placer ceux-ci dans un répertoire plutôt que de les avoir à la racine d'un seul dossier. Les unités d'organisation sont là pour vous aider à répartir les objets d'un domaine afin que vous puissiez les administrer plus simplement. Dans votre structure, vous devez les identifier puis lister les besoins en fonction de leurs contenus. Relation Unités d'organisation et source : avoir une structure souple et évolutive permet de mieux organiser la cible. Dès lors que vous avez identifié les besoins de chacun, vous pouvez mieux définir l'organisation et la structure de votre solution Exchange Identification des Stratégies de sécurité Les stratégies de sécurité appelées aussi GPO (Group Policy Object) sont liées à un contenant (Domaine, Site ou OU) et permettent de configurer des politiques de sécurité communes pour tous les objets inclus dans ce contenant. Ces GPO contiennent des paramétrages sur les ordinateurs et les utilisateurs. Ces stratégies vous permettent de mieux gérer l'environnement des utilisateurs et également de centraliser un certain nombre d'actions d'administration. Quelles sont les stratégies de sécurité au sein de votre entreprise? Quelle politique de mot de passe a été choisie? Quelles sont les politiques d'environnement du bureau qui ont été prises? Vous pouvez constater au travers de ces différentes questions qu'il va vous falloir identifier chacune d'entre elles mais également décrire les paramètres de configuration. Relation GPO et source : entre les GPO de votre structure et l'analyse de la source, vous devez juste comprendre que toute politique de sécurité mise en œuvre diminue votre champ d'actions sur les clients et les serveurs. Sachez voir les politiques de sécurité mais surtout maîtrisez l'étendue de leurs actions. Identification des groupes Les groupes sont les contenants de bas niveaux. Vous devez savoir qu'il existe trois types de

18 groupes : les groupes locaux, les groupes globaux et les groupes universels. Ces groupes ont deux types d'étendue, ce sont soit des groupes de sécurité soit des groupes de distribution. Vous devez établir un listing complet avec le nom des groupes, leurs types et leurs étendues. Vous devez considérer un autre type de groupe lorsque vous mettez en place une architecture Exchange. Ce sont les groupes "fondés sur des requêtes". Ces nouveaux groupes apparus sous Exchange 2003, ont la particularité suivante : les objets (utilisateurs ou groupes) ayant la valeur d'attribut spécifié dans la requête ldap du groupe dynamique, sont automatiquement rendus membres de celui-ci. Relation Groupes et source : la présence des groupes permet d'organiser votre architecture Active Directory et d'attribuer des permissions à des ensembles plutôt qu'à l'unité. Si vous connaissez les groupes de votre entreprise, alors vous pourrez mieux organiser le fonctionnement de la messagerie. Si les utilisateurs sont regroupés dans un ensemble c'est qu'ils partagent en général les mêmes types d'accès. En analysant le nombre de groupes ainsi que leurs contenus, vous pouvez établir en amont des ensembles fonctionnels partageant les mêmes droits d'accès dans l'organisation Exchange. Identification des dossiers L'analyse des dossiers utilisateurs est certes intéressante mais elle reste facultative. Dans une organisation standard (sans Exchange), vos données peuvent être organisées de deux manières : via l'accès à un serveur de fichiers (ou NAS) ou via l'accès à un portail d'entreprise comme SharePoint Portal Dans une organisation comprenant Exchange pré 2007, vous pouviez également le faire par le biais des dossiers publics. Cela vous permettait de rendre disponible certaines informations par le biais du client Outlook ou Web Access. Ces dossiers publics présents dans les anciennes versions ne figurent plus sur les environnements intégralement composés d'exchange 2007 et Outlook La sortie de SharePoint Portal 2007 supplante désormais les dossiers publics. Cette nouvelle version de SharePoint travaille en étroite collaboration avec Exchange 2007 pour offrir aux utilisateurs des services collaboratifs. Dans la source, les utilisateurs accèdent aux données par différents moyens. Mais ils ont pour principales attentes de pouvoir accéder à toutes les ressources du réseau quel que soit l'endroit où ils se trouvent.» Exchange Server 2007 est la dernière version qui supporte encore les dossiers publics. Relation dossiers et source : elle doit retenir toute votre attention du fait qu'elle peut amener des changements profonds dans le mode de fonctionnement d'accès aux données de vos utilisateurs. Si vous souhaitez associer une solution Exchange 2007 à une solution SharePoint 2007, vous devrez la prendre en considération dans le projet afin de préparer et de construire la cible en fonction de ce choix. Le contenu Dans cette partie, vous devez analyser l'impact que va engendrer la mise en place d'exchange sur les éléments de la structure. En effet, vous devez savoir dans quelle mesure la solution choisie peut agir sur la production en cours et quels sont les éléments sensibles aux changements. Rassurez-vous, dans cette étape d'inventaire, vous n'avez pas encore à choisir ce que vous allez faire ou sur quel serveur vous allez installer Exchange Vous devez juste comprendre l'intérêt du processus d'audit du contenu.

19 Identification des systèmes serveurs Établissez la liste de tous les systèmes d'exploitation (OS) serveurs présents dans votre structure ainsi que les services qui tournent dessus ou encore les tâches planifiées, les transferts de données, etc. Quelle relation existe-t-il entre vos systèmes d'exploitation et votre projet de messagerie? La réponse est simple : vous devez vous assurer qu'aucun problème de compatibilité n'existe entre Exchange 2007 et la structure système en place. Exemple : Vous avez prévu d'installer Exchange 2007 sur un serveur de votre entreprise qui fait office de serveur WEB et sur lequel les services SMTP et NNTP sont installés. Comme vous le verrez dans les chapitres suivants, ces services sont incompatibles avec Exchange Le choix que vous avez donc à prendre sera, soit de supprimer ces services s'ils ne sont pas utilisés, soit de changer de serveur. Mais en aucun cas, vous ne devez vous trouver face à cette situation au moment de l'installation. Créez pour cela un fichier Excel sur lequel vous listerez tous les systèmes recensés, les services pack, les correctifs spécifiques, les applications présentes, les tâches, les services. Analysez également tous les transferts de fichiers ou autres qui existent entre vos serveurs. Mettez en place une colonne indiquant les capacités de chacun de vos serveurs. L'objectif étant de dessiner une cartographie applicative afin de vous assurer de n'avoir omis aucun élément. Identification des rôles des serveurs Le rôle d'un serveur est de savoir ce qu'il fait. Vous avez dans un premier temps listé l'ensemble des rôles de chaque serveur. Vous devez ajouter une colonne dans votre tableau Excel indiquant son rôle au sein de l'entreprise. Savoir si c'est un serveur membre, autonome ou contrôleur de domaine ou savoir s'il y a des serveurs de bases de données ou des serveurs de fichiers vous aidera également par la suite. Si vous décidez d'installer Exchange 2007 sur des serveurs de votre entreprise, vous choisirez plutôt un serveur membre qu'un contrôleur de domaine. Si vous devez mettre en place un serveur EDGE, vous aurez besoin d'un serveur autonome. Dans votre fichier Excel, vous n'avez plus qu'à insérer une colonne supplémentaire pour intégrer ces notions de rôles et de fonctions. Identification des systèmes clients Auditer les postes clients peut vous paraître moins important mais sachez que c'est sur ce type de point que vous pouvez faire basculer un projet de la réussite à l'échec. Le traitement des postes clients est en général une étape très longue dans le projet car il constitue un volume de travail important (déploiement, mise à niveau, paramétrage, etc). Si le parc client n'est pas homogène et que les versions du client Outlook sont nombreuses, vous devez prendre soin de le signaler dans votre rapport et positionner dans votre planification des tâches la charge nécessaire pour la réalisation.» Le déploiement client est et restera toujours la tâche la plus laborieuse d'une réalisation par la charge de travail que cela représente. Identification des applications serveurs Vous savez à présent qu'un des serveurs de l'entreprise héberge une base de données. Analysez de manière plus détaillée cet aspect pour savoir si le serveur est dédié à l'application qu'il héberge, s'il est rebooté ou s'il est capable de prendre en charge une autre application. L'objectif étant de savoir si vous pouvez mutualiser des logiciels au sein d'un même serveur. Vous dresserez pour cela un plan de faisabilité pour chaque serveur. Prenez l'exemple

20 suivant : vous avez un serveur qui sert au service Helpdesk. Vous souhaitez y installer Exchange. Si on vous informe que ce serveur n'est quasiment jamais rebooté en journée et que l'application Helpdesk est extrêmement sensible, vous ne prendrez pas le risque de choisir celui-ci. Identification des applications clientes L'étude des applications clientes a pour seul intérêt de savoir s'il peut y avoir un impact significatif entre la mise en place d'un serveur Exchange et une application tierce de type client/serveur. Si votre structure possède également un système client léger (Citrix, TSE), vous devez alors prendre en compte cette information pour savoir si les clients s'intégreront dans cette topologie. Identification des bases de données Vous devez identifier toutes les bases de données de votre infrastructure dans la mesure où Exchange 2007 pourrait avoir une interaction forte avec SharePoint Portal. Mettez toutes les chances de votre côté : identifiez celles qui sont susceptibles de prendre en charge cette nouvelle fonction, vous économiserez ainsi du temps pour la suite. Cette étape reste cependant facultative si aucun projet de ce type ne doit voir le jour dans votre société. Identification des volumétries des données clients La volumétrie des données est un point sensible. Si votre société utilise déjà la messagerie électronique de manière non centralisée (type client pop), vous devez dans ce cas récupérer les données utilisateurs. Pour cela, vous devez évaluer la taille totale de leurs dossiers et planifier dans votre cible suffisamment d'espace disque pour prendre en charge ces données.» Plus votre analyse de départ est précise, plus la cible est correctement proportionnée à vos besoins. Architecture Réseau Cette analyse présente un aspect délicat mais demeure relativement simple. Il s'agit ici d'identifier le réseau en deux points : les services réseaux présents sur la structure et la structure physique Active Directory. Les services réseaux Les trois services principaux à auditer sont : le DNS, le DHCP et le WINS. Vous devrez établir le plan de fonctionnement de ceux-ci. Votre schéma récapitulatif doit établir l'ensemble de l'architecture existante comme dans l'exemple donné dans le schéma ci-dessous :