Exchange On-Premises : architecture et exploitation des serveurs

Exchange On-Premises signifie que l’organisation exploite des serveurs Exchange dans sa propre infrastructure. Elle contrôle les hôtes Windows, Active Directory, les certificats, les services de transport, les files d’attente, les bases de données de boîtes aux lettres et la récupération. Microsoft fournit le code produit, la documentation et les mises à jour ; la disponibilité et une maintenance sécurisée restent à la charge de l’exploitant (Documentation Exchange Server, Architecture Exchange Server).

La différence pratique avec Exchange Online apparaît immédiatement lors d’une panne. Un administrateur On-Prem peut examiner une file de transport sur un serveur précis, vérifier l’état d’une copie de base de données et basculer de manière contrôlée vers une autre copie. Il doit toutefois aussi comprendre comment SMTP, Active Directory, ESE, Windows Failover Clustering, IIS et les services Exchange interagissent.

Le serveur Mailbox est l’élément central

Les serveurs Exchange modernes utilisent le serveur Mailbox comme composant commun. Il contient les services Client Access qui acceptent et transmettent les connexions, les services de transport pour le flux de messages ainsi que l’Information Store avec les bases de données de boîtes aux lettres. Une installation peut démarrer modestement ; plusieurs serveurs et copies de bases de données étendent le même modèle de base pour la haute disponibilité (Architecture Exchange Server).

Cette consolidation ne signifie pas que toutes les fonctions présentent le même état. Un frontal HTTPS peut être accessible alors que la base de données sollicitée n’est pas montée. SMTP peut accepter des connexions alors qu’un message attend ensuite dans une file d’attente. Le diagnostic suit donc le chemin réel, et pas seulement l’état général du serveur.

Le rôle Edge Transport facultatif se situe généralement dans le réseau périmétrique et traite exclusivement le trafic SMTP. EdgeSync transfère des informations sélectionnées sur les destinataires et la configuration vers une instance AD LDS locale. Edge ne contient aucune base de données de boîtes aux lettres et ne remplace pas les serveurs Mailbox internes (Serveurs Edge Transport).

Pile technologique et dépendances

Le composant serveur détermine la pile technologique. Exchange s’exécute sur des versions prises en charge de Windows Server et utilise Active Directory pour la configuration de l’organisation, des serveurs et des destinataires. IIS fournit les points de terminaison HTTP. PowerShell constitue l’interface d’administration. ESE stocke les données des boîtes aux lettres et des files d’attente dans des bases de données distinctes (Configuration requise pour Exchange Server, Active Directory dans Exchange Server).

Pour les experts, la dépendance à Active Directory est particulièrement importante. Le programme d’installation d’Exchange étend le schéma et inscrit la configuration de l’organisation dans la partition Configuration. Les attributs des destinataires se trouvent dans la partition de domaine. Un délai de réplication ou un contrôleur de domaine inaccessible peut donc affecter différemment diverses fonctions.

Le pipeline de transport étape par étape

Avec ces fondations techniques, il est possible de lire plus précisément le cheminement des messages. Une connexion SMTP entrante atteint d’abord le Front End Transport Service. Il accepte le dialogue et le transmet au Transport Service ; il ne place pas lui-même le message dans une boîte aux lettres (Flux de messagerie et pipeline de transport).

Le Transport Service stocke le message dans sa base de données de file d’attente. Il le catégorise ensuite : les destinataires sont résolus, les règles et les agents de transport sont exécutés, et le routage détermine le saut suivant. Pour une boîte aux lettres locale, Mailbox Transport Delivery remet le message au Store. Un message envoyé depuis une boîte aux lettres retourne vers le transport via Mailbox Transport Submission.

Cet ordre explique les observations typiques. Un test SMTP réussi prouve uniquement l’acceptation par le frontal. Un événement RECEIVE dans le suivi des messages ne prouve pas encore la remise. Seuls les événements ultérieurs, la file d’attente et, le cas échéant, l’état du Store indiquent où le processus s’est arrêté (Suivi des messages).

Les agents de transport et les règles de flux de messagerie peuvent rejeter, rediriger, copier ou modifier des messages. Comme plusieurs instances de transport peuvent alors être créées, la recherche ne devrait pas reposer uniquement sur l’objet. Network Message ID, Internet Message ID, expéditeur, destinataire, heure et serveur forment ensemble une piste plus fiable.

Routage, domaines et connecteurs

Après l’acceptation, Exchange doit savoir si un destinataire est local ou si le message doit être transféré. Les Accepted Domains décrivent cette relation. Un domaine autoritaire attend tous les destinataires valides dans sa propre organisation. Un domaine de relais interne permet de transférer les destinataires inconnus. Le relais externe remet entièrement le domaine à un autre serveur de messagerie (Domaines acceptés dans Exchange Server).

Les connecteurs de réception classifient les sessions entrantes selon la liaison locale, la plage d’adresses IP distantes, l’authentification et les autorisations. Les connecteurs d’envoi sélectionnent un chemin sortant à partir de l’espace d’adressage, du coût, des serveurs sources et du routage DNS ou via hôte intelligent. Plusieurs connecteurs correspondants sont évalués selon les règles de routage documentées ; le nom d’un connecteur ne détermine pas la sélection (Connecteurs sur les serveurs Exchange, Routage du courrier dans Exchange Server).

Pour l’exploitation courante, un modèle simple suffit : le connecteur de réception explique comment un message arrive ; le domaine accepté et la résolution du destinataire expliquent si Exchange est responsable ; le connecteur d’envoi et le routage expliquent où il est envoyé ensuite. Les experts ajoutent les sites AD, les groupes de remise, l’appartenance à une DAG, la portée des connecteurs et les règles de transport.

Base de données de boîtes aux lettres, journaux et point de contrôle

Lorsque le transport remet le message au Store, une autre partie du système commence. Exchange stocke les boîtes aux lettres dans des bases de données ESE. Les modifications sont d’abord écrites dans des journaux de transactions, puis transférées dans le fichier .edb. Le fichier de point de contrôle indique jusqu’à quelle position de journal les pages de la base de données ont été écrites (Journaux de transactions et fichiers de point de contrôle).

Cet ordre permet la récupération après incident, mais exige des fichiers associés. Un fichier .edb copié sans les journaux correspondants et sans état d’arrêt connu n’est pas automatiquement récupérable. De même, une sauvegarde ne doit pas supprimer de manière non contrôlée des fichiers journaux encore nécessaires à la récupération ou à la réplication.

La file de transport utilise également ESE, mais constitue une base de données distincte avec ses propres journaux. La base de données de boîtes aux lettres et la file d’attente sont donc supervisées et restaurées séparément. Une base de données de boîtes aux lettres saine ne résout pas un saut SMTP suivant bloqué ; une file vide ne répare pas une copie de boîte aux lettres endommagée (Files d’attente et base de données de file d’attente).

Database Availability Group et Active Manager

Un seul serveur Mailbox explique le fonctionnement normal. Pour la haute disponibilité, plusieurs serveurs sont regroupés dans une Database Availability Group, ou DAG. Chaque base de données de boîtes aux lettres possède exactement une copie active et peut avoir des copies passives sur d’autres membres de la DAG. Les modifications sont transférées par réplication de journaux et de blocs, puis rejouées sur les copies passives (Groupes de disponibilité des bases de données, Copies de bases de données de boîtes aux lettres).

L’Active Manager du Microsoft Exchange Replication Service décide quelle copie est active. Best Copy and Server Selection évalue notamment l’état de copie et de relecture, les blocages d’activation et l’état de santé du serveur. Une Copy Queue à zéro est donc utile, mais ne prouve pas entièrement qu’une copie peut être activée immédiatement (Active Manager).

La haute disponibilité du transport protège une autre partie du trajet. Shadow Redundancy conserve une copie supplémentaire tant que le message est en transit. Safety Net conserve les messages déjà traités pour une éventuelle retransmission après l’activation d’une base de données. DAG, Shadow Redundancy et Safety Net se complètent ; aucune de ces trois fonctions ne remplace une sauvegarde contre une suppression accidentelle ou une corruption non détectée durant une longue période (Haute disponibilité du transport).

Accès client et Autodiscover

La base de données peut être saine sans qu’un utilisateur puisse pour autant ouvrir Outlook. Les services Client Access acceptent les connexions HTTPS et les transmettent au backend du serveur détenant la base de données active. Un équilibreur de charge nécessite donc plus qu’un port TCP ouvert : le nom, le certificat, le point de terminaison du protocole et la santé du backend doivent correspondre (Architecture du protocole Client Access).

Autodiscover fournit au client les paramètres appropriés. Les clients internes au domaine peuvent utiliser les Service Connection Points dans Active Directory ; les clients externes et les autres clients suivent les procédures DNS et HTTPS. Les erreurs sont souvent causées par des SCP obsolètes, des réponses DNS contradictoires, des noms de certificat incorrects ou un frontal qui transfère vers le mauvais backend (Service Autodiscover).

MAPI over HTTP est le transport Outlook habituel. Outlook sur le web, EWS et ActiveSync utilisent également HTTPS, mais disposent de leurs propres répertoires virtuels, mécanismes d’authentification et caractéristiques applicatives. Un test OWA réussi ne prouve donc pas automatiquement qu’une session MAPI/HTTP est saine (MAPI over HTTP).

Active Directory et destinataires

Après le transport et l’accès client, l’annuaire reste la base commune. Exchange stocke la configuration de l’organisation et des serveurs ainsi que les attributs des destinataires dans Active Directory. Les cmdlets n’écrivent pas ces données dans une base de données Exchange privée, mais dans AD via la logique Exchange (Active Directory dans Exchange Server).

Un problème de destinataire est donc examiné selon trois questions : le bon objet existe-t-il ? Le type, l’adresse principale, les adresses proxy et les attributs cibles sont-ils corrects ? La modification a-t-elle atteint le contrôleur de domaine utilisé par le service Exchange concerné ? Ce n’est qu’ensuite qu’il est utile d’effectuer une recherche dans le transport.

Pour les experts, s’ajoutent les catalogues globaux, les sites AD, Recipient Update, les stratégies de carnet d’adresses et les attributs hybrides. Les modifications directes à l’aide d’outils AD génériques contournent la validation Exchange et peuvent créer des configurations syntaxiquement présentes mais fonctionnellement incohérentes.

Sécurité et contrôle administratif

Exchange publie des services SMTP et HTTPS et traite des données d’annuaire et de boîtes aux lettres hautement privilégiées. La base repose sur des Security Updates appliquées en temps utile, des points de terminaison accessibles réduits au minimum, des certificats appropriés, des comptes d’administration sécurisés et des modifications traçables (Security Updates pour Exchange Server, Certificats TLS dans Exchange Server).

RBAC sépare les tâches par rôles, groupes de rôles et étendues. Les droits de boîte aux lettres tels que Full Access ou Send As restent distincts. Administrator Audit Logging enregistre les modifications de cmdlets, mais ne remplace pas les journaux du système d’exploitation, d’Active Directory et de sécurité (Autorisations dans Exchange Server, Journalisation d’audit des administrateurs).

Pour les experts, l’interface d’administration elle-même fait partie du modèle de protection. EAC, Exchange Management Shell, Remote PowerShell, WinRM, RDP et l’accès à l’hyperviseur disposent de droits et de protocoles différents. Un administrateur de serveur compromis peut effectuer des actions en dehors d’Exchange RBAC ; la séparation par niveaux et les comptes privilégiés distincts restent donc importants.

Exploitation : du symptôme au serveur concret

Managed Availability exécute des probes, des moniteurs et des responders. Les Health Sets regroupent ces résultats par fonction et peuvent déclencher des actions de récupération automatique. Ils constituent un bon point de départ, mais pas une vérification complète de bout en bout (Managed Availability).

Pour le flux de messagerie, le diagnostic local commence avec Get-Queue et Get-MessageTrackingLog. Le nombre de files d’attente, le saut suivant, l’heure de nouvelle tentative et LastError doivent être considérés ensemble. Pour les bases de données, suivent Get-MailboxDatabaseCopyStatus et Test-ReplicationHealth. Get-ServerHealth affiche les Health Sets et les moniteurs.

Ces cmdlets s’exécutent dans Exchange Management Shell sur des Windows Server pris en charge. Les tests réseau et DNS peuvent en revanche être effectués depuis les deux plateformes d’administration. Test-NetConnection vérifie un point de terminaison TCP sous Windows ; nc effectue le même test de port sous Unix. Resolve-DnsName et dig vérifient le DNS. Pour SMTP avec STARTTLS, openssl s_client convient ; pour un dialogue SMTP contrôlé, swaks.

L’ordre de diagnostic est le suivant : résoudre le nom public ou interne, vérifier la connexion au bon frontal, confirmer l’acceptation dans le journal de protocole, suivre les événements de suivi, vérifier la file d’attente et le saut suivant, puis n’examiner le Store et la base de données qu’en cas de remise locale.

Sauvegarde et récupération

La haute disponibilité maintient le service disponible lors de pannes isolées ; la récupération restaure un état antérieur souhaité ou perdu. Exchange documente Server Recovery, la restauration de base de données et Recovery Database comme des procédures distinctes (Sauvegarde, restauration et reprise après sinistre).

Un inventaire récupérable comprend au minimum Active Directory, l’organisation Exchange et la configuration des serveurs, les certificats et les clés privées, les bases de données de boîtes aux lettres avec leurs journaux, la configuration des connecteurs et des règles, ainsi que les paramètres d’installation et de récupération documentés. La Recovery Database permet de monter une base de données restaurée de manière isolée et de transférer son contenu vers des boîtes aux lettres actives (Restaurer des données à l’aide d’une base de données de récupération).

Les experts ne vérifient pas seulement si un travail de sauvegarde a réussi. Ils mesurent le temps nécessaire pour restaurer réellement Active Directory, un serveur défaillant, une base de données et le contenu de boîtes aux lettres individuelles. Ils vérifient alors les séquences de journaux requises, les dépendances DNS et de certificats, ainsi que le bon fonctionnement des chemins clients et SMTP après la restauration.

Évolution technique et limites

Exchange 4.0 est apparu en 1996. Les premières versions utilisaient leur propre annuaire, MAPI et ESE ; SMTP et Active Directory sont devenus des composants centraux de la plateforme avec Exchange 2000. Exchange 2007 a introduit les rôles serveur et Exchange Management Shell. Exchange 2010 a remplacé les anciens modèles de cluster par la Database Availability Group (Exchange Team : une brève histoire du temps, Exchange Server 2007 : refonte du transport).

Les versions ultérieures ont à nouveau regroupé les fonctions Client Access et Mailbox dans un composant serveur commun. Exchange Server Subscription Edition a poursuivi la gamme de produits locale en 2025 dans le cadre du Modern Lifecycle. Les numéros de build, les chemins de mise à niveau pris en charge et les Security Updates doivent être vérifiés avant toute modification dans la documentation Microsoft en cours (Notes de publication d’Exchange Server SE, Numéros de build et dates de publication d’Exchange Server).

Exchange On-Premises convient lorsque l’organisation a besoin de contrôler l’exploitation des bases de données, les chemins réseau et l’intégration locale, et qu’elle peut assurer l’exploitation 24 h/24 et 7 j/7 requise. En contrepartie, il implique des dépendances complexes, une maintenance de sécurité continue et la responsabilité de la récupération. Un seul serveur peut sembler simple ; un service Exchange robuste est toujours aussi un projet Active Directory, réseau, certificats, stockage et exploitation.