Dans un environnement Exchange on‑prem multi‑FAI, comment garantir EWS/OWA/ActiveSync et Autodiscover malgré la bascule automatique des routeurs et la coexistence de MX multiples ? Ce guide fournit des architectures éprouvées, des commandes Exchange et des playbooks de bascule.
Problématique
Votre entreprise dispose de deux fournisseurs d’accès Internet (FAI). Chaque FAI publie ses propres enregistrements MX pour le domaine, et vos routeurs basculent automatiquement d’un lien à l’autre en cas d’incident. Vous devez garantir la continuité de service pour les protocoles EWS (Exchange Web Services), OWA, ActiveSync, MAPI/HTTP et le flux Autodiscover, tout en assurant une réception/émission SMTP fiable. Le défi : éviter les coupures côté utilisateurs (Outlook, iOS/Android, postes nomades) lors d’une perte de lien, sans reconfigurer les clients.
Points de friction classiques : mise en cache DNS côté clients, certificats ne couvrant pas un FQDN unique, bascule de session sur un nœud Exchange indisponible, politiques de NAT asymétriques, absence d’alignement SPF/DKIM/DMARC lorsque les MX appartiennent à des IP différentes, et méthodes de bascule DNS « optimistes » qui ne garantissent pas l’instantanéité.
Solutions proposées
| Volet | Idée clé | Points d’attention | Avantages |
|---|---|---|---|
| Répartition de charge (hardware ou virtuelle) | Placer un load balancer (LB) en frontal, doté d’adresses publiques sur les deux FAI ; publier un FQDN logique (ex. mail.exemple.com) pour EWS, OWA et Autodiscover qui pointe vers le LB. | Health‑checks actifs ; certificats SSL wildcard ou SAN couvrant le FQDN unique ; règles NAT/firewall ouvertes sur les deux liaisons. | Bascule transparente ; pas de modification côté clients iOS/Outlook ; même URL interne/externe. |
| DNS round‑robin / failover | Créer plusieurs enregistrements A (ou CNAME) pour chaque service, chacun résolvant vers l’IP publique d’un FAI. | Réduire le TTL (30–60 s) ; prévoir qu’iOS/Outlook peut mettre en cache une mauvaise IP jusqu’à expiration ; pas de garantie de bascule instantanée. | Mise en œuvre simple ; aucun matériel supplémentaire. |
| DNS dynamique | Utiliser un service DDNS pour mettre à jour automatiquement les enregistrements quand l’adresse d’un FAI change ou devient indisponible. | Dépendance à un tiers ; nécessite script ou client DDNS sur le pare‑feu. | Adapté si les adresses IP publiques changent fréquemment (4G/5G). |
| Configuration Exchange | Set‑WebServicesVirtualDirectory et Set‑OwaVirtualDirectory pour publier les URL externes sur le FQDN logique ; Set‑ClientAccessService pour Autodiscover. | S’assurer que les certificats couvrent le FQDN ; tester via Test‑OutlookConnectivity ou l’outil « Microsoft Remote Connectivity Analyzer ». | Noms cohérents ; simplifie la découverte automatique des appareils iOS. |
| Surveillance & scripts de bascule | Superviser la disponibilité de chaque lien ; lorsque l’un échoue, mettre à jour le LB ou le DNS. | Scripts PowerShell ou API du LB ; journaliser les bascules pour analyse. | Réduction du temps moyen de réparation (MTTR). |
Recommandation pragmatique : si vous avez la main sur l’architecture, privilégiez un LB multi‑WAN avec un FQDN unique. À défaut, combinez DNS round‑robin/failover + DNS dynamique + URL Exchange unifiées.
Architecture de référence avec load balancer multi‑WAN
Le LB (physique/virtuel) publie mail.exemple.com et effectue des checks actifs vers vos serveurs Exchange (CAS/Front‑End). Il possède deux adresses publiques : une annoncée côté FAI A, l’autre côté FAI B. Votre DNS public pointe le FQDN unique vers ces IP (soit en A multiples, soit via un FQDN → CDN/LB). En interne (split‑DNS), le même nom résout vers l’IP virtuelle du LB sur le LAN. Ainsi, aucune différence d’URL entre interne et externe.
# Vue logique (simplifiée)
[Clients Outlook/iOS] --Internet--> [IP Pub A] \
[LB multi-WAN] ---> [CAS/FE 1]
[Clients nomades] --Internet--> [IP Pub B] / |
---> [CAS/FE 2]
# FQDN unique : mail.exemple.com (certificat SAN/autodiscover inclus)
Bonne pratiques de configuration LB
- Health‑checks L7 : utilisez des probes HTTP(S) spécifiques (ex.
/owa/healthcheck.htm) plutôt que des simples pings TCP. - Affinité de session : avec Exchange 2016/2019, l’affinité n’est généralement pas requise pour OWA/ECP/EWS/ActiveSync/MAPI ; laissez le LB en stateless si possible.
- Termination TLS ou pass‑through : le pass‑through simplifie les certificats (hébergés sur Exchange) et limite l’exposition. Le termination côté LB permet WAF, inspection, HTTP/2 et offload TLS. Choisissez selon vos exigences sécurité/observabilité.
- Time‑outs : remontez les time‑outs pour les requêtes EWS longues (téléchargements pièce jointe volumineuse) afin d’éviter des réinitialisations lors d’une bascule.
- IPv6 : activez dual‑stack (A+AAAA) si vos deux FAI le supportent ; vérifiez « Happy Eyeballs » côté clients.
Exemple minimal HAProxy (mode TCP, pass‑through TLS)
frontend https_in
bind 0.0.0.0:443
mode tcp
option tcplog
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
default_backend exchange_https
backend exchange_https
mode tcp
balance roundrobin
option tcp-check
tcp-check connect port 443
server exch01 10.0.0.11:443 check
server exch02 10.0.0.12:443 check Design DNS, split‑DNS et certificats
L’objectif est d’exposer un FQDN unique pour tous les services web Exchange, avec un certificat valide partout. Le split‑DNS évite les avertissements de certificat et les différences d’URL entre réseau interne et Internet.
Jeu d’enregistrements conseillé
| Nom | Type | Valeur | TTL | Remarques |
|---|---|---|---|---|
| mail.exemple.com | A / AAAA | IP Pub FAI A et IP Pub FAI B | 30–60 s | Round‑robin/failover. Ajuster TTL selon stratégie. |
| autodiscover.exemple.com | CNAME | mail.exemple.com | 300 s | Simple et robuste (iOS/Outlook honorent CNAME). |
| _autodiscover._tcp.exemple.com | SRV | prio 0, poids 0, port 443, cible mail.exemple.com | 300 s | Pour les clients qui ne suivent pas le CNAME. |
| exemple.com | MX | mx1.exemple.com (prio 10), mx2.exemple.com (prio 20) | 3600 s | Réception SMTP. À faire coïncider avec les IP publiques. |
| mx1.exemple.com / mx2.exemple.com | A / AAAA | IP Pub FAI A / IP Pub FAI B | 600–1800 s | Prévoir rDNS PTR et cohérence HELO/EHLO. |
| exemple.com | TXT (SPF) | v=spf1 ip4:<IP_A> ip4:<IP_B> -all | 3600 s | Inclure toutes les sorties SMTP possibles. |
Certificats
- Utilisez un wildcard (
*.exemple.com) ou un certificat SAN contenantmail.exemple.cometautodiscover.exemple.com. - Activez TLS 1.2+ partout, avec suites ECDHE et OCSP stapling si possible.
- Renouvelez sans interruption (chevauchement de validité) et automatisez l’installation côté Exchange / LB.
Commandes Exchange pour des URL unifiées
Exemple de configuration type (Exchange 2016/2019) avec un FQDN unique :
$domain = "exemple.com"
$fqdn = "mail.$domain"
# Autodiscover (interne)
Get-ClientAccessService | Set-ClientAccessService `
-AutoDiscoverServiceInternalUri "[https://autodiscover.$domain/autodiscover/autodiscover.xml](https://autodiscover.$domain/autodiscover/autodiscover.xml)"
# EWS
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory ` -ExternalUrl "https://$fqdn/EWS/Exchange.asmx"`
-InternalUrl "https://$fqdn/EWS/Exchange.asmx"
# OWA
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory `
-ExternalUrl "https://$fqdn/owa" -InternalUrl "https://$fqdn/owa"
# ActiveSync
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory ` -ExternalUrl "https://$fqdn/Microsoft-Server-ActiveSync"`
-InternalUrl "https://$fqdn/Microsoft-Server-ActiveSync"
# MAPI/HTTP
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory `
-ExternalUrl "https://$fqdn/mapi" -InternalUrl "https://$fqdn/mapi"
# OAB
Get-OabVirtualDirectory | Set-OabVirtualDirectory `
-ExternalUrl "https://$fqdn/OAB" -InternalUrl "https://$fqdn/OAB"
# Vérifications
Test-OutlookConnectivity -ProbeIdentity OutlookMapiHttpSelfTestProbe Après modification, validez avec l’outil « Microsoft Remote Connectivity Analyzer » (tests Autodiscover, ActiveSync, Outlook Anywhere/MAPI, etc.).
SMTP : réception et émission en multi‑FAI
Réception (MX multiples)
- Publiez deux MX (
prio 10etprio 20) pointant vers des IP publiques différentes de vos deux FAI, NATées vers vos Edge/Front‑End. - Assurez la symétrie de routage : une session SMTP qui entre par le FAI B doit ressortir par le même FAI, sinon RST/timeout probables si votre pare‑feu est stateful.
- Déployez rDNS (PTR) cohérent : chaque IP publique doit résoudre vers un nom aligné (ex.
mx1.exemple.com,mx2.exemple.com). - Configurez TLS opportuniste/forcé côté Receive Connector, et alignez SPF/DKIM/DMARC.
Émission
- Send Connector vers Internet : utilisez la résolution DNS ou des smart‑hosts redondants (un par FAI).
- Si vous forcez les smart‑hosts : listez les deux, activez UseExternalDNSServersEnabled, et définissez le FQDN d’annonce EHLO (ex.
mail.exemple.com). - SPF doit inclure toutes les IP de sortie (FAI A et FAI B). Mettez à jour DKIM sur la même clé ou une clé par flux si besoin.
Exemple Send Connector (multi smarthosts)
New-SendConnector -Name "Internet-MultiFAI" `
-Usage Internet -AddressSpaces "SMTP:*;1" `
-SmartHosts "smtp.faia.net","smtp.faib.net" `
-DNSRoutingEnabled:$false -UseExternalDNSServersEnabled:$true `
-TlsAuthLevel EncryptionOnly -Fqdn "mail.exemple.com"
DNS round‑robin et DNS dynamique : quand et comment
Si vous n’avez pas de LB, un round‑robin (deux enregistrements A/AAAA) pour mail.exemple.com est acceptable mais non déterministe : certains clients garderont une IP « morte » jusqu’à l’expiration du TTL. Pour plus de contrôle, utilisez un DNS dynamique qui désactive l’IP en panne (failover DNS) suivant un sondage actif (HTTP 200 attendu sur /owa/healthcheck.htm).
Script simple de bascule DNS (DNS Windows, RFC 2136)
$recordName = "mail"
$zone = "exemple.com"
$ipPrim = "198.51.100.10" # FAI A
$ipSec = "203.0.113.20" # FAI B
function Test-Service {
param([string]$url)
try { (Invoke-WebRequest -Uri $url -UseBasicParsing -TimeoutSec 5).StatusCode -eq 200 }
catch { $false }
}
if (-not (Test-Service "https://$recordName.$zone/owa/healthcheck.htm")) {
Write-Host "Bascule vers FAI B..."
# Supprimons l'A vers FAI A, ajoutons FAI B
Remove-DnsServerResourceRecord -ZoneName $zone -RRType "A" -Name $recordName -RecordData $ipPrim -Force
Add-DnsServerResourceRecordA -ZoneName $zone -Name $recordName -IPv4Address $ipSec -TimeToLive ([TimeSpan]::FromSeconds(30))
} Ce mécanisme suppose que votre serveur DNS faisant autorité est exposé ou que vous utilisez une API de votre fournisseur DNS. Journalisez toutes les bascules et prévoyez un retour arrière automatique.
Pare‑feu, NAT et ports à ouvrir
| Service | Ports | Origine → Destination | Remarques |
|---|---|---|---|
| OWA/EWS/ActiveSync/MAPI | TCP 443 (HTTP redir : 80) | Internet → LB → Exchange | TLS obligatoire, rediriger 80 → 443. |
| SMTP réception | TCP 25 | Internet → Edge/Front‑End | Activer TLS opportuniste/forcé. |
| SMTP soumission | TCP 587 | Clients → Exchange | Authentifié, STARTTLS. |
| OCSP/CRL | TCP 80/443 | Exchange → Internet | Validation des certificats. |
- NAT symétrique entre entrée et sortie par le même FAI pour préserver l’état (stateful).
- Hairpin NAT si des clients internes passent par l’IP publique : à éviter avec un split‑DNS correctement conçu.
Autodiscover : s’assurer d’un parcours robuste
Les clients suivent un ordre de découverte qui peut varier (SCP AD pour machines jointes au domaine, autodiscover.exemple.com, SRV, etc.). Avec un FQDN unique et un CNAME autodiscover → mail, vous simplifiez fortement le parcours. Ajoutez l’enregistrement SRV pour la compatibilité large.
_autodiscover._tcp.exemple.com. 300 IN SRV 0 0 443 mail.exemple.com.
autodiscover.exemple.com. 300 IN CNAME mail.exemple.com.
Compléments utiles
- Split‑DNS : conserver le même FQDN pour l’accès interne et externe évite les avertissements de certificat et simplifie la mobilité (VPN, Always On VPN, etc.).
- SRV Autodiscover : pour les clients qui n’honorent pas le CNAME, ajouter un enregistrement
_autodiscover._tcppointant vers le FQDN unique. - SMTP haute disponibilité : si les MX diffèrent par priorité, assurez‑vous que le relais sortant utilise la même stratégie de bascule que les clients (smart‑host redondant ou send connector multivalué).
- Chiffrement : vérifiez que chaque chemin (FAI, LB, serveur) supporte TLS 1.2+ afin d’éviter les dégradations lors des bascules.
- Tests périodiques : planifiez des bascules simulées pour valider que toutes les URL (EWS, OWA, ActiveSync) suivent correctement le trafic.
Plan de mise en œuvre pas à pas
- Nommer : choisissez
mail.exemple.comcomme point d’entrée unique. Réservezautodiscover.exemple.com. - Certifier : générez un certificat SAN ou wildcard couvrant
mailetautodiscover. Déployez‑le sur Exchange (et LB si termination TLS). - Publier : configurez le LB avec deux adresses publiques (FAI A/B). Créez A/AAAA publics pour
mailvers ces IP. - DNS interne : créez A interne
mail → VIP_LB. Ajoutezautodiscoveren CNAME versmail. - Exchange : appliquez les Set‑*VirtualDirectory pour EWS/OWA/ActiveSync/MAPI/OAB.
- SMTP : publiez MX 10/20 et Receive Connectors adéquats. Alignez SPF/DKIM/DMARC et rDNS.
- Surveillance : mettez en place des probes HTTP(s), un tableau de bord et des alertes. Écrivez un script de bascule DNS si pas de LB.
- Tests : utilisez des postes de test (Windows, macOS, iOS, Android), créez de nouveaux profils Outlook et vérifiez l’expérience lors d’une coupure volontaire d’un FAI.
Scénarios d’échec et remèdes rapides
| Symptôme | Cause probable | Correctif |
|---|---|---|
| Outlook reste déconnecté après perte FAI A | TTL DNS trop long, cache client | Réduisez TTL à 30–60 s, videz le cache DNS local, préférez un LB. |
| Avertissement certificat sur iOS | Nom du certificat ne couvre pas le FQDN utilisé | Utilisez mail.exemple.com partout + SAN autodiscover. |
| Rebonds SMTP sporadiques | SPF incomplet ou rDNS manquant | Ajoutez les deux IP publiques dans SPF et créez les PTR correspondants. |
| OWA/EWS très lents après bascule | Health‑checks L4 uniquement | Passez à des checks L7 (HTTP 200 sur endpoint de santé). |
| Timeout SMTP | NAT asymétrique entre entrée/sortie | Forcer le retour par le même FAI (PBR, règles d’outbound groupées). |
Playbook de bascule (exercice trimestriel)
- Pré‑vérifications :
Get-ServerHealth,Test-OutlookConnectivity, et disponibilité LB/DNS. - Désactiver temporairement le lien FAI A (down administrativement).
- Observer la réaction : LB re‑route, health‑checks OK, logs 200 stables.
- Tester clients : démarrage d’Outlook neuf, ajout compte iOS, test EWS (free/busy), envoi SMTP/TLS.
- Rétablir FAI A. Vérifier l’équilibrage, temps total de bascule et absence d’erreurs applicatives.
- Rédiger un compte‑rendu (MTTD/MTTR, points durs, actions correctives).
FAQ
Les enregistrements MX influencent‑ils EWS/OWA/Autodiscover ?
Non. Les MX concernent la réception SMTP. EWS/OWA/Autodiscover s’appuient sur des A/AAAA/CNAME/SRV pointant vers un FQDN HTTP(S). D’où l’intérêt d’un FQDN unique côté web.
Dois‑je utiliser un wildcard ou un SAN ?
Les deux conviennent. Un SAN offre plus de contrôle fin, un wildcard simplifie l’extension future. Priorité : couvrir mail et autodiscover avec TLS 1.2+.
Le round‑robin suffit‑il ?
Il fonctionne, mais reste probabiliste. Pour une haute disponibilité réelle, combinez‑le avec des checks actifs (LB ou DNS dynamique) qui retirent l’IP défaillante.
Faut‑il une affinité de session sur le LB ?
Sur Exchange 2016/2019, non dans la majorité des cas (EWS/OWA/MAPI/ActiveSync). Sur des versions plus anciennes, l’affinité pouvait être utile ; validez selon votre version.
Comment réduire l’impact du cache DNS des mobiles ?
Baissez le TTL (30–60 s) et utilisez un LB. En dernier recours, envisagez une URL de « sonde » différente pour accélérer la détection côté DNS.
Étude de cas condensée
PME de 350 postes, deux FAI (fibre + 5G), deux serveurs Exchange 2019 et un LB virtuel. Mise en place d’un FQDN unique, certificat SAN, A/AAAA en double, SRV Autodiscover, MX 10/20. Résultat : bascules < 15 s visibles uniquement comme une courte reconnection dans Outlook, aucune action côté utilisateurs, et élimination des avertissements de certificat sur iOS.
Checklist opérationnelle
- Un FQDN unique pour tous les services web Exchange.
- Certificat SAN ou wildcard couvrant
mailetautodiscover. - Split‑DNS configuré, mêmes noms internes/externes.
- LB avec checks L7 ou DNS dynamique avec failover actif.
- MX redondants, rDNS et SPF/DKIM/DMARC alignés.
- Règles firewall/NAT symétriques vias FAI A et FAI B.
- Scripts de bascule et monitoring documentés, alertes en place.
- Tests périodiques et playbooks de crise validés.
Conclusion
En appliquant soit un load balancer multi‑WAN, soit une stratégie DNS dynamique/round‑robin associée à des URL Exchange unifiées et des scripts de surveillance, vous garantirez aux appareils iOS (et aux autres clients) un accès ininterrompu aux services Exchange malgré la bascule automatique entre FAI. La clé réside dans un FQDN unique, des checks actifs, une sécurité TLS irréprochable et une discipline opérationnelle (tests réguliers, journaux, KPIs MTTR).