par Tony Redmond
Il y a un an, avaient lieu les premières livraisons de Microsoft Exchange 2000. Pendant les 12 mois qui ont suivi, ceux qui ont déployé le nouveau produit ont appris beaucoup de choses : entre autres, que l'expérience acquise avec Exchange Server 5.5 ne garantit pas que nous comprendrons automatiquement Exchange 2000. Chaque jour, quelque chose de nouveau vient me rappeler la différence entre ces deux produits. (Ces changements sont un bon argument pour tester les nouveaux déploiements d'Exchange 2000 avant de les introduire dans l'environnement de production, comme l'explique l'encadré " Tester d'abord ".) Rien n'apprend autant que l'expérience d'un déploiement concret. Nous sommes désormais en mesure d'identifier les éléments les plus importants dans les déploiements d'Exchange 2000 réussis. Si vous avez attendu pour déployer Exchange 2000, vous pouvez bénéficier de cette expérience. Pour que l'organisation d'Exchange 2000 fonctionne en souplesse, il faut tenir compte des facteurs suivants : où placer les serveurs GC (Global Catalog), comment utiliser l'ADC (Active Directory Connector), comment les produits add-on travaillent avec Exchange 2000, quels clients Exchange vous employez, quelles fonctions de Windows 2000 affectent Exchange 2000, et si l'on peut regrouper ou non les serveurs Exchange.
Tirer des enseignements des déploiements d’Exchange 2000
Chaque GC (Global Catalog) est un DC (Domain Controller) Win2K spécialement configuré qui contient des copies lecture/écriture complètes des objets dans son domaine et des copies lecture seule partielles des objets dans tous les autres domaines d’une forêt AD (Active Directory). Exchange 2000 atteint la GAL (Global Address List) à partir d’un GC et utilise le GC pour résoudre les adresses de messages pendant l’acheminement.
A moins que l’Exchange Server puisse établir et maintenir le contact avec un GC, Exchange 2000 ne peut pas démarrer ses services ou acheminer les messages. Sans un GC, les utilisateurs d’Exchange ne peuvent pas voir le GAL et le composant Exchange DSAccess émet d’innombrables messages d’erreur.
DSAccess est le composant d’Exchange qui traite l’accès aux répertoires. (En fait, DSAccess remplace le Directory Service – DS – livré avec les précédentes versions d’Exchange.) Le composant de DSAccess travaille de façon simple et directe : quand les services Exchange (le Routing Engine, le Message Transfer Agent – MTA, par exemple) démarrent, le composant se connecte (c’est-à -dire se relie) à un GC approprié et maintient la connectivité tant que le serveur Exchange est en action.
Pour savoir à quel GC il va se connecter, le composant DSAccess examine en profondeur les informations du site. Exchange engendre une charge importante sur un GC, qui doit répondre aux requêtes adressées au répertoire pour des informations de routage, des données de configuration et des détails sur les utilisateurs. (La charge exacte dépend du volume du trafic de messages, mais on admet généralement qu’il faut un GC pour quatre serveurs Exchange.) L’interaction constante entre Exchange et le GC oblige à connecter chaque serveur Exchange 2000 au GC le plus proche (du point de vue du réseau). Pour déterminer à quel GC un serveur Exchange se connecte, ouvrez la console ESM (Exchange System Manager) de MMC (Microsoft Management Console). Sélectionnez le serveur Exchange, ouvrez la boîte de dialogue Properties du serveur et allez à l’onglet General. Le nom du GC apparaît dans la boîte de texte Domain controller used by services on this server, en bas de l’onglet.
On constate souvent des problèmes (livraison de messages lente, gel des clients Microsoft Outlook, par exemple) quand un serveur Exchange 2000 se connecte à un GC dans un site Win2K distant (parfois parce qu’un administrateur a placé le serveur Exchange dans le mauvais site Win2K pendant l’installation). Mon expérience confirme qu’il est important de déployer les serveurs Exchange 2000 près des GC. Dans ce contexte, l’adverbe près signifie que la liaison réseau entre les serveurs Exchange et GC doit être fiable, rapide et résistante à l’interruption. Le moyen le plus sûr consiste à placer un GC sur le même LAN que le serveur Exchange. Ne choisissez une autre méthode que si vous avez toute confiance dans la liaison envisagée.
Il faut donc réfléchir à la structure pendant la mise en oeuvre de Win2K pour déterminer combien de GC sont nécessaires et leurs meilleurs emplacements. Si l’on a la chance d’avoir un seul domaine, la tâche est bien plus simple parce que chaque DC peut fonctionner comme un GC. En réalité, le multidomaine est le mode le plus courant dans l’univers des entreprises. Bien sûr, on peut encore faire un GC de chaque DC, mais dans un environnement multidomaine, cette technique entraîne beaucoup de trafic de réplication. La plupart d’entre nous préfèrent réserver les précieuses ressources du réseau à d’autres tâches et donc il faut trouver le juste milieu entre le besoin de proximité des GC et la bande passante disponible. Le choixest simple : restreindre la réplication et obliger Exchange à se connecter sur des liaisons étendues avec des niveaux de services imprévisibles, ou faire le saut et déployer davantage de GC pour être certain qu’Exchange (et les utilisateurs) pourra toujours accéder au répertoire.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- 5 tendances 2025 pour un virage technologique stratégique
- Comment éviter les fuites de données ? un webinaire des experts Kyocera
- Black Friday le 29 novembre : les cybercriminels en embuscade, prudence !
- DSI & directeurs financiers : une relation plus solide pour de meilleurs résultats
- Le support IT traditionnel pourrait disparaitre d’ici 2027