Le groupe de routage Exchange 2003 était spécifique à Exchange, et la configuration était complètement distincte de la topologie de sites AD sous-jacente. Microsoft a joué la carte de la simplification et Exchange 2007 exploite la topologie de sites AD sous-jacente pour le routage. Les serveurs de boîtes aux lettres
Sites AD et routage Exchange
Exchange 2007 utilisent les serveurs de transport Hub du même site pour envoyer les messages en vue de leur remise à la boîte aux lettres d’un destinataire.
Le serveur de transport Hub remet ensuite le message directement à un serveur de boîtes aux lettres local si le destinataire réside sur le même site. Si sa boîte aux lettres se trouve sur un autre site, le serveur de transport Hub transmet le message directement à un serveur de transport Hub du site distant. Le message y est alors remis au serveur de boîtes aux lettres cible approprié. Si le comportement de routage direct par défaut entre les serveurs de transport Hub n’est pas optimal, les administrateurs Exchange ont la possibilité de l’adapter à leurs besoins.
Par exemple, ils peuvent configurer un site AD en tant que concentrateur (hub) de routage au moyen de la cmdlet PowerShell Set-AdSite, et supplanter ainsi le comportement de routage direct par défaut entre des serveurs de transport Hub résidant sur des sites distincts. La bonne nouvelle est que la cmdlet Set-AdSite n’a pas besoin d’un compte membre du groupe Administrateurs d’entreprise dans AD (un niveau d’autorisation généralement requis pour modifier la topologie de sites AD). Cela change-t-il quelque chose pour les administrateurs AD? En fait, pas grand chose, aussi longtemps que vos sites AD sont définis correctement et que vous avez enregistré comme il se doit les sous-réseaux.
Des enregistrements de sous-réseaux manquants peuvent entraîner de réels problèmes dans n’importe quel environnement, mais c’est particulièrement vrai avec les scénarios Exchange car le routage a besoin d’une configuration appropriée. Une approche conceptuelle relativement répandue dans Exchange 2003 consistait à créer un site AD distinct pour Exchange. Le raisonnement visait à fournir des contrôleurs de domaines AD et des serveurs de catalogue global dédiés pour Exchange. Cette approche présentait l’avantage d’éviter toute compétition d’Exchange avec d’autres services utilisant AD, ce qui pouvait garantir un certain niveau de performances.
Le revers de la médaille était un coût supplémentaire lié à la mise en place et à la maintenance de contrôleurs de domaine supplémentaires. Comme le routage Exchange 2007 est désormais mappé directement sur la topologie de sites AD, le concept de site séparé pour le routage n’a plus aucune raison d’être. Si vous avez un désir ardant de garder quelques contrôleurs de domaine dédiés pour Exchange, vous pouvez modifier la pondération et la priorité des enregistrements DNS SRV afin de séparer l’utilisation d’Exchange et les connexions client.
Téléchargez cette ressource
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
- Et si les clients n’avaient plus le choix ?
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- Activer la mise en veille prolongée dans Windows 10
- Cybersécurité Active Directory et les attaques de nouvelle génération
Les plus consultés sur iTPro.fr
- Cloud souverain : répondre aux enjeux d’hybridation et de maîtrise des dépendances
- Cybermenaces 2026 : l’IA devient la nouvelle arme des attaquants
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Editeurs, crawlers et équipes sécurité, les alliances qui feront tenir le web
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
