Je vais mettre en place une architecture simple. Je vais dans un premier temps configurer un serveur Exchange avec les rôles CAS, Hub et Mailbox colocalisés. Ensuite, j'ajouterai un serveur Edge pour gérer l'hygiène des messages et enfin je finirai par installer le rôle UM en collaboration avec Office Communications Server. Cette partie UM fera l'objet d'un autre article. Voici les besoins auxquels l'architecture devra répondre :

• envoi d'emails sur Internet ;
• réception d'emails ayant passé une hygiène de messagerie (antispam, antivirus) ;
• accès OWA depuis Internet et depuis le réseau interne avec la même adresse ;
• accès Outlook Anywhere ;
• Autodiscover.

Tous les rôles d'Exchange sont supportés en environnement virtualisé à l'exception de l'UM. Dans le cadre d'une maquette, il est possible de virtualiser l'UM dans une certaine limite de performance.

Le serveur Exchange doit avoir une configuration IP fixe et faire partie du domaine Active Directory. Avant de procéder à l'installation d'Exchange, je conseille de mettre totalement à jour votre serveur.

Le serveur Exchange (exchange.todorovic.adds) possède les rôles CAS, Hub et Mailbox (MBX). Ce serveur devra posséder un certificat signé par une autorité de certification afin de ne pas avoir de problème de validation de certificat lors des accès client. L'autorité que j'utilise a été installée avec mon tutoriel Configuration d'une infrastructure à clés publiques à 2 niveaux sous Windows 2008 (R2). Le certificat portera le nom NetBios du serveur à savoir "exchange" (sinon pas de validation de certificat lors de l'Autodiscover) et aura quatre noms alternatifs (SAN) : exchange.todorovic.adds (FQDN du serveur), mail.todorovic.fr (pour l'accès OWA, Outlook Anywhere et éventuellement Active Sync), Autodiscover.todorovic.fr (pour le service Autodiscover) et um.todorovic.adds (pour la messagerie unifiée si vous souhaitez l'activer plus tard : cela vous évitera de créer un nouveau certificat). Si vous voulez prendre en charge plusieurs domaines sur votre serveur Exchange, vous devrez ajouter ces domaines aux noms alternatifs de votre certificat.

Il faudra créer des alias dans le DNS pour que les noms alternatifs du serveur Exchange pointent sur celui-ci. Je vais utiliser encore une fois le principe du split-DNS pour simplifier la vie aux utilisateurs et aux administrateurs (même si cela requiert une petite gymnastique). Voici pourquoi j'utilise ce principe : Nom de domaine privé/public ? suvi de l'explication du split-DNS.

En DMZ, je vais placer un autre serveur Exchange qui ne sera pas dans Active Directory. Ce serveur aura le rôle Edge et assurera l'hygiène des messages. Ce serveur devra avoir un nom public pour fonctionner correctement. L'installation de ce serveur Edge sera traitée dans un prochain article.

Cette architecture est loin d'être complexe puisqu'il n'y a qu'un seul serveur. Elle permettra cependant de comprendre les bases d'Exchange. Cette partie architecture demande des précisions sur les licences. C'est en effet un point généralement mal compris.