Les bases d’une bonne configuration Exchange – Partie 3

Les bases d'une bonne configuration Exchange (Tutorial)

Les bases d’une bonne configuration Exchange – Partie 3

Ce tutoriel est en 4 parties:
Partie 1
Partie 2
Partie 3
Partie 4

Dans la première partie, nous avons fait une check-list de prérequis pour une installation sans soucis.
Dans la seconde partie, nous avons installé, puis configuré Exchange pour pouvoir envoyer des emails en interne.

Maintenant, nous allons voir la configuration d’Exchange pour pouvoir envoyer et recevoir des emails avec Internet.

Pour cela, nous avons déjà un serveur Exchange, et nous aurons besoin des éléments suivants (normalement, déjà déterminés dans la première partie) :

  • Nom de domaine Internet : sylvaincoudeville.fr
  • L’IP publique fixe de notre routeur : ici 109.xxx.yyy.111
  • Le login et mot de passe pour configurer le nom de domaine Internet chez votre hébergeur
  • Le FQDN qui sera utilisé pour dialoguer avec le serveur Exchange : mailhost.sylvaincoudeville.fr
  • Le login et mot de passe pour configurer les redirections de port sur votre routeur

Configuration du FQDN dans le DNS privé

Le concept

Le but est non plus de parler avec le serveur Exchange par son nom interne (exch2013.monAD.local), mais un nom qui est aussi utilisable sur Internet.
De cette manière, vos utilisateurs (et vos Outlook, accessoirement) n’ont qu’un nom à retenir (et à gérer) : votre FQDN public.

Dans notre exemple, nous utiliserons mailhost.sylvaincoudeville.fr.

Déclaration dans le DNS interne

Pour commencer, nous allons déclarer ce nom dans le DNS de notre Active Directory. Pour cela, à partir du contrôleur de domaine, allez dans le Gestionnaire DNS (dnsmgmt.msc) et créez une nouvelle zone de recherche directe :

Création du FQDN public sur le DNS AD - 1

Création du FQDN public sur le DNS AD - 2Création du FQDN public sur le DNS AD - 3

On saisit le FQDN public comme nouvelle zone recherche directe, pas le nom de domaine :

Création du FQDN public sur le DNS AD - 4Création du FQDN public sur le DNS AD - 15

Maintenant que la zone est créée, on créé un enregistrement ‘A’, sans nom, afin d’affecter l’IP privée au FQDN :
Création du FQDN public sur le DNS AD - 6

Création du FQDN public sur le DNS AD - 7

Vérification du fonctionnement

Si le travail a bien été fait, depuis un poste du réseau local, lancez la commande ‘ping fqdn’, et cela doit vous retourner l’IP privée de votre Exchange :

Ping du FQDN public en interne

Configuration du nom d’hôte dans Exchange

Le concept

Pourquoi déclarer le nom d’hôte dans Exchange ?

C’est très simple, tout les services Exchange reposent sur le nom des machines de l’infrastructure. Dans ce tutoriel, nous nous contentons d’une architecture mono-serveur Exchange, mais il est tout a fait possible de monter des topologies complètes avec plusieurs serveurs Exchange qui se partagent et répliquent des rôles.

Une des fonctionnalités très importantes dans une topologie Exchange c’est l’Autodiscover. L’Autodiscover est un mécanisme utilisé par Outlook pour déterminer automatiquement les noms des serveurs Exchange de votre organisation.

Il faut donc que ces noms soient correctement renseignés.

Quel(s) nom(s) utiliser ?

Comment nous l’avons vu au début de cette 3ème partie, nous avons mis un accent fort sur l’utilisation du FQDN public (mailhost.sylvaincoudeville.fr).

Mais pourquoi ce choix ?

Exchange sait gérer des noms d’hôtes internes et externes, c’est à dire qu’il est capable de présenter aux clients du LAN le nom d’hôte privé (exch2013.monAD.local), et de présenter le nom d’hôte public (mailhost.sylvaincoudeville.fr) aux clients externes (ceux se connectant depuis Internet).

Cependant, Exchange travaille exclusivement en HTTPS. Du coup, le serveur Exchange présente un certificat (nous en avons parlé dans la première partie). Ce certificat peut 1 ou plusieurs noms d’hôtes.

Mais, dès la fin de l’année (octobre 2016), les autorités de certification ne fourniront plus de certificat pour des noms d’hôtes internes (monAD.local) – voir la RoadMap de Globalsign : https://www.globalsign.fr/centre-information-ssl/nouvelles-exigences.html.

De ce fait, il sera possible d’obtenir des certificats que pour les noms d’hôtes externes (societe.com, societe.fr etc.).

Il est donc préférable de travailler uniquement avec un nom d’hôte externe (mailhost.sylvaincoudeville.fr) puisqu’il sera bientôt le seul type de noms d’hôte qui pourra être « protégé » par un certificat.

Configuration dans Exchange

Il y a 2 manières de configurer les noms d’hôte dans Exchange : l’interface graphique (ECP) ou le PowerShell.

Étant donné le nombre d’occurrences à remplacer il est préférable de mettre de côté l’ECP et de réaliser cette opération uniquement en PowerShell.

Nous allons donc configurer Exchange pour utiliser le nom d’hôte externe (mailhost.sylvaincoudeville.fr) que cela soit en interne, ou en externe.

Ouvrez un Exchange Management Shell et tapez les commandes suivantes :

Get-OABVirtualDirectory|Set-OABVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/OAB -ExternalUrl https://mailhost.sylvaincoudeville.fr/OAB
Get-WebServicesVirtualDirectory|Set-WebServicesVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/EWS/Exchange.asmx -ExternalUrl https://mailhost.sylvaincoudeville.fr/EWS/Exchange.asmx
Get-EcpVirtualDirectory|Set-EcpVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/ecp -ExternalUrl https://mailhost.sylvaincoudeville.fr/ecp
Get-OwaVirtualDirectory|Set-OwaVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/owa -ExternalUrl https://mailhost.sylvaincoudeville.fr/owa
Get-ActiveSyncVirtualDirectory|Set-ActiveSyncVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/Microsoft-Server-ActiveSync -ExternalUrl https://mailhost.sylvaincoudeville.fr/Microsoft-Server-ActiveSync
Get-ReceiveConnector "Default Frontend EXCH2013"|Set-ReceiveConnector -Fqdn mailhost.sylvaincoudeville.fr
Get-ClientAccessServer|Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mailhost.sylvaincoudeville.fr/Autodiscover/Autodiscover.xml

Sous Exchange 2010, vous devrez aussi fixer le paramètre InternalUrl et ExternalUrl pour Autodiscover :

Get-AutodiscoverVirtualDirectory|Set-AutodiscoverVirtualDirectory -InternalUrl https://mailhost.sylvaincoudeville.fr/Autodiscover/Autodiscover.xml -ExternalUrl https://mailhost.sylvaincoudeville.fr/Autodiscover/Autodiscover.xml

Connecteurs d’envoi et de réception

A quoi ça sert ?

Les connecteurs d’envoi et réception sont les passerelles vers le monde extérieur.

Le connecteur d’envoi, comme son nom l’indique, permet d’envoyer des emails vers l’extérieur.

Le connecteur de réception permet quant à lui de recevoir des emails provenant de l’extérieur.

Le connecteur d’envoi

Avant-propos : méthode d’envoi sur Internet

Le connecteur d’envoi n’est pas créé par défaut.

Avant de le créer, il va falloir se poser la question de comment votre Exchange va distribuer le courrier sur Internet :

  • Soit votre FAI (Fournisseur d’Accès à Internet) vous fournit un serveur SMTP de relais (SmartHost)
  • Soit vous souhaitez distribuer le courrier directement sur les serveurs de messagerie des destinataires (résolution MX)

Attention ! Si vous faites le 2ème choix, vous devez montrer patte blanche sur Internet, sous peine de voir le courrier distribué de manière aléatoire :

  • Votre IP publique ne doit pas être Blacklistée (vérifiez sur http://mxtoolbox.com/blacklists.aspx)
  • Vous devez vérifier périodiquement que votre IP n’est pas Blacklistée
  • Vous devez disposer d’un Reverse DNS qui pointe sur votre nom de domaine (si votre nom de domaine est ‘societe.com’, la commande ‘tracert IP-Publique’ doit vous retourner un nom d’hôte finissant par ‘societe.com’).
    Le paramétrage du Reverse DNS s’effectue par votre FAI, à votre demande.
    Ce paramétrage n’est réalisable que lorsque vous avez fait la demande d’un pool d’IP auprès de votre FAI (abonnements SDSL, Fibre, ou chez certains opérateurs comme OVH)

Si vous débutez, je vous conseille d’opter pour le SmartHost. Si votre FAI ne vous fournit pas de serveur SMTP, vous pouvez louer un relais SMTP chez un hébergeur.

Création du connecteur

Allez dans l’ECP, « Flux de messagerie » > « Connecteur d’envoi » > « (+) ».
Donnez un nom à votre connecteur et sélectionnez « Internet » comme Type :

Création connecteur d'envoi

Si vous utilisez un SmartHost (serveur SMTP relais de votre FAI, ou d’un hébergeur), sélectionnez « Acheminer les messages électroniques via des hôtes actifs » puis cliquez sur Ajouter (+) :

Connecteur envoi SmartHost

Si vous préférez router les messages directement vers les serveurs de messagerie de vos destinataires, choisissez « Enregistrement MX associé au domaine du destinataire » (attention aux prérequis étudiés dans l’avant-propos de ce chapitre) :

Connecteur d'envoi routage MX

Si vous avez opté pour le SmartHost, vous devez spécifier l’adresse du serveur relais que vous utilisez :

Connecteur Envoi SmartHost Adresse

Puis, le cas échéant, si le serveur relais SMTP nécessite une authentification, spécifiez les identifiants (et activez le TLS si nécessaire) :

Connecteur envoi SmartHost Authentification

Dans tous les cas, il faut maintenant spécifier l’espace d’adressage, c’est à dire les domaines qui seront gérés par ce connecteur d’envoi à savoir, tous (*) :

Connecteur d'envoi Espace d'adresse

Enfin, sélectionnez votre serveur Exchange (seul et unique serveur dans notre topologie) :
Connecteur envoi Serveur Source

Une fois le formulaire validé, le connecteur est créé. Cependant, il va falloir le modifier (l’option en question n’étant pas disponible dans l’assistant).

Après avoir cliqué sur « Modifier », allez dans « Étendue » et fixez le nom d’hôte :

Connecteur d'envoi FQDN

Une fois terminé, votre connecteur d’envoi est prêt et vous pouvez envoyer des emails vers l’extérieur.

Mais comme votre connecteur de réception n’est pas prêt à recevoir du courrier, vous ne recevrez pas de réponse à vos mails.

Configuration du connecteur de réception

Il existe plusieurs connecteurs de réception créés dès l’installation d’Exchange.

Selon la version, vous en trouverez 2 ou 5.

En Exchange 2010 :

  • Client
  • Default

En Exchange 2013 :

  • Client Frontend
  • Client Proxy
  • Default
  • Default Frontend
  • Outbound Proxy Frontend

Le plus important pour nous est le « Default Frontend » (sous Exchange 2010) ou « Default » sous Exchange 2010.

Ce connecteur écoute le port 25 et a pour but de recevoir le courrier en provenance d’Internet.

Cependant, il y a une petite modification à effectuer dessus afin de pouvoir fixer son nom d’hôte convenablement.

Connectez-vous à l’ECP et allez dans « Flux de messagerie » > « Connecteurs de réception » et modifiez le connecteur « Default Frontend EXCH2013 » :

Exchange 2013 Configuration ReceiveConnector

Allez dans l’onglet « Sécurité » et décochez la case « Authentification du serveur Exchange » :

Exchange 2013 Configuration authentification Receive Connector

Allez ensuite dans l’onglet « Étendue » et paramétrez le nom d’hôte externe :

Exchange 2013 Configuration FQDN ReceiveConnector

Configuration du routeur

Pourquoi?

Et bien, tout simplement parce qu’il faut que vos correspondants sur Internet puissent accéder au Connecteur de réception de votre Exchange pour y déposer du courrier !

Rappelez-vous le schéma de flux vu en première partie :

 

Flux Exchange

Les emails sont distribués par le biais du protocole SMTP, qui utilise le port 25 en TCP (flux rouge).

Il faut donc ouvrir et rediriger le port 25 de votre routeur, vers le port 25 de votre Exchange.

Comment rediriger le port 25 ?

Ce serait très long à expliquer ici, car totalement dépendant de votre routeur/firewall.

Mais vous trouverez de très nombreux tutoriels en tapant sur Google « Redirection port 25 Freebox » ou encore « Redirection port 25 ZyWall 50 » etc.

Attention tout de même à un point important : vous voulez jouer dans la cour des grands en hébergeant votre serveur de messagerie, alors équipez-vous !

Vous devriez faire l’acquisition d’un routeur/firewall avec des fonctionnalités de détection et de blocage d’attaques (IDS/IPS), antivirus et antispam (voir les pré-requis en première partie).

Et le port 443 ?

Et bien c’est la même chose pour le port 443 (TCP). Mais ça, c’est seulement si vous souhaitez pouvoir accéder à votre messagerie depuis l’extérieur de votre LAN, via OWA, Outlook ou votre Smartphone.

Configuration du domaine Internet

Le concept

Tout d’abord, nous allons nous attarder sur le concept de la configuration du domaine.
Vous n’êtes pas forcément habitués à travailler avec des noms de domaine Internet, mais vous connaissez les domaines DNS dans Active Directory.

La bonne nouvelle, c’est que c’est la même chose. La mauvaise, c’est que votre nom de domaine Internet n’est pas géré par votre Active Directory, mais par l’hébergeur qui vous a fourni le nom de domaine (OVH, Gandi, Amen, etc.).

Avant de continuer, il vous faudra les accès à la configuration de votre domaine chez votre hébergeur. Vous trouverez ci-dessous les guides d’administration des DNS des principaux hébergeurs.

Guides d’administration des principaux hébergeurs

OVH : http://guide.ovh.com/ManagerServicesDomaine – Voir la section « Configurer vos DNS »
GANDI : https://wiki.gandi.net/fr/dns/zone/mx-record
AMEN : http://www.amenwiki.com/index.php/Domaine_-_Configuration_de_votre_zone_DNS

Configuration du FQDN

Au même titre que vous créez des enregistrements de type ‘A’ (Alias) sur le DNS de votre Active Directory, pour faire correspondre une IP à un nom, il existe d’autres type d’enregistrements :
– MX : Mail eXchanger
– SRV : Server
– TXT : Text
– CNAME : Canonical Name
– NS : Name Server

Tous ces type d’enregistrements que vous pouvez créer dans la zone DNS de votre nom de domaine Internet ont un rôle précis, qui permettent d’aiguiller les requêtes Web, mail, etc. sur la toile.

Pour commencer, il faut que l’on déclare notre FQDN. Nous avons choisi mailhost.sylvaincoudeville.fr dans notre exemple. Mon hébergeur utilise un outil nommé Plesk pour la gestion des noms de domaine :

Zone DNS publique

On trouve plein de renseignements dans la zone DNS comme, l’adresse IP du site (sylvaincoudeville.fr; masquée dans cet exemple), des enregistrements A (comme ipv4.sylvaincoudeville.fr), les serveurs de noms autoritaires pour le domaine (NS), un code de vérification Google (TXT) etc.

Nous allons créer un enregistrement A qui va faire correspondre mailhost.sylvaincoudeville.fr à l’IP publique de notre routeur :

Zone DNS ajouter enregistrement 1

Choisissez le type d’enregistrement « A » (Alias), saisissez le nom d’hôte choisi (mailhost) et l’IP publique associée (109.xxx.yyy.111 dans cet exemple) :
Zone DNS ajouter enregistrement 2

Configuration du MX

L’enregistrement de type MX (Mail eXchanger) est une donnée qui permet de gérer le routage du courrier Internet (emails).
Pour faire simple, lorsque vous envoyez un email à quelqu’un dont l’adresse est toto@gmail.com, voici l’équivalent des commandes que lance votre serveur de messagerie :

nslookup -q=MX gmail.com
Serveur :   google-public-dns-a.google.com
Address:  8.8.8.8

Réponse ne faisant pas autorité :
gmail.com       MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
gmail.com       MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com
gmail.com       MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
gmail.com       MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com       MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com

alt4.gmail-smtp-in.l.google.com internet address = 173.194.72.27
alt4.gmail-smtp-in.l.google.com AAAA IPv6 address = 2404:6800:4008:c01::1b
alt2.gmail-smtp-in.l.google.com internet address = 74.125.200.27
alt2.gmail-smtp-in.l.google.com AAAA IPv6 address = 2404:6800:4003:c00::1a
alt3.gmail-smtp-in.l.google.com internet address = 64.233.187.27
alt3.gmail-smtp-in.l.google.com AAAA IPv6 address = 2404:6800:4008:c05::1b
gmail-smtp-in.l.google.com      internet address = 74.125.195.27
gmail-smtp-in.l.google.com      AAAA IPv6 address = 2a00:1450:400c:c01::1b
alt1.gmail-smtp-in.l.google.com internet address = 173.194.71.27
alt1.gmail-smtp-in.l.google.com AAAA IPv6 address = 2a00:1450:4010:c04::1b

La commande retourne le nom des 4 serveurs de messagerie acceptant le courrier pour « gmail.com » : gmail-smtp-in.l.google.com, alt1.gmail-smtp-in.l.google.com etc.

La suite du retour de la commande nous retourne toutes les adresses IP correspondant à ces serveurs :
– gmail-smtp-in.l.google.com -> 74.125.195.27
– alt1.gmail-smtp-in.l.google.com -> 173.194.71.27

Je ne m’attarde pas sur les IPv6.

Maintenant, ajoutez d’un nouvel enregistrement, mais de type « MX » (Mail eXchanger), pour le domaine « sylvaincoudeville.fr », et pointant vers le FQDN créé juste avant (mailhost.sylvaincoudeville.fr) :
Zone DNS ajouter champ MX

Attention ! Si vous utilisez déjà votre nom de domaine Internet avec un hébergeur de messagerie, changer ce paramètre provoquera l’arrêt de la réception d’email chez votre hébergeur actuel, pour les router vers votre serveur Exchange.
Je vous conseille donc d’effectuer cette manipulation en dernier lieu, une fois que votre infrastructure est prête et vérifiée.

Selon l’hébergeur, vous avez peut-être un bouton à cliquer pour valider la configuration.

Vérification

Une fois effectué, selon le temps de refresh associé à votre domaine (que vous pouvez vérifier en tapant la commande ‘nslookup -q=SOA votredomaine.com’), les modifications pourront prendre 4 à 48 heures pour être effectives sur l’ensemble de la toile.

C’est à cause de ce délai de prise en compte que vous devez réfléchir et préparer à l’avance votre migration avant de faire des modifications dans votre DNS.

Une fois ce délai passé, vous pouvez vérifier l’ensemble de la configuration (je vous conseille de le faire depuis une connexion Internet différente de celle de votre LAN).

Pour cela, il y a plusieurs tests à faire :

Vérification des enregistrements DNS

Ouvrez une ligne de commande et tapez les commandes suivantes : le résultat doit refléter votre configuration :

nslookup -q=MX votredomaine.fr

Cette première commande doit vous retourner un nom d’hôte : mail.votredomaine.fr, par exemple.

nslookup -q=A mail.votredomaine.fr

Cette seconde commande doit vous retourner l’IP publique de l’hôte déclaré comme MX pour votre domaine.

Vérification de l’ouverture des ports

Téléchargez Putty (ou un autre client de type Telnet) à cette adresse http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

Ouvrez Putty, et connectez vous en « Telnet », sur le port « 25 » de votre FQDN :

Connection SMTP via Telnet port 25

Après avoir cliqué sur « Open », vous devriez avoir un retour similaire à celui-ci :

Telnet port 25 OK

Maintenant, vous pouvez faire la même chose avec un navigateur et aller à l’adresse https://mail.votredomaine.fr/owa : hormis une erreur de certificat, vous devriez pouvoir accéder à la fenêtre de login :

Connexion OWA https depuis exterieur

Vérification de l’acceptation de mail

Maintenant que nous avons contrôlé que les ports étaient bien ouverts, nous allons vérifier que notre Connecteur de réception accepte bien les emails provenant d’internet.

Pour cela, nous allons simuler la connexion d’un serveur et tenter de distribuer un email de toto@gmail.com à scoudeville@sylvaincoudeville.fr.

Pour cela, il va falloir taper les commandes suivantes dans Putty (toujours en Telnet, et toujours sur le port 25) :

ehlo esmtp

A l’issue de cette première commande, le serveur doit répondre « 250-mail.votredomaine.com Hello [IP publique depuis laquelle vous testez] ».

Continuons ensuite avec le reste des commandes (respectez les retours à la ligne, les espaces etc.) :

mail from:<toto@gmail.com>
rcpt to:<destinataire@votredomaine.fr>
data
From:<toto@gmail.com>
To:<destinataire@votredomaine.fr>
Subject: Sujet de votre message
Blah blah blah....
.

Il est très important de finir par une ligne vierge, puis un point, puis Entrée afin de marquer la fin du message.
Le serveur doit répondre « 250 2.6.0 …. Queued mail for delivery » :

Test envoi mail en Telnet

Et si vous regardez votre boîte mail, vous devriez avoir du courrier…

 

Dans la quatrième et dernière partie, nous installerons un VRAI certificat pour faire de l’OWA sans erreur, nous activerons OutlookAnywhere (pour synchroniser Outlook même à l’extérieur du LAN), et nous pourrons paramétrer des Smartphones pour synchroniser les mails, calendrier etc.

40 réflexions sur “Les bases d’une bonne configuration Exchange – Partie 3

  1. Bonjour,

    Dans la partie « Configuration du nom d’hôte dans Exchange », le copier-coller de commandes Powershell était incomplet.
    Il faut aussi mettre à jour l’URL interne d’Autodiscover sur le CAS (Client Access Server) :

    Get-ClientAccessServer|Set-ClientAccessServer -AutodiscoverServiceInternalUri https://mailhost.sylvaincoudeville.fr/Autodiscover/Autodiscover.xml

    La commande a été ajoutée dans l’article

  2. Pingback: Les bases d’une bonne configuration Exchange – Partie 1 | Sylvain COUDEVILLE
  3. Bonjour Sylvain,
    Je te remercie pour ce tuto.
    J’installe le serveur en suivant ton tuto. J’ai réussi à recevoir un email depuis l’extérieur mais depuis un moment quand je me logue sur https://mailhost.domaine.fr/owa, j’ai une page blanche qui s’affiche avec « importation… » dans l’onglet  » c’est le cas sur tous les navigateurs.
    En local sur le serveur, j’arrive bien à me loger sur l’ECP depuis : https://mailhost.domaine.fr/ecp/
    par contre sur : https://mailhost.domaine.fr/owa/ il affiche la messagerie avec des images non chargées et du texte sans mise en page.

    J’ai lancé le script : UpdateCas.ps1 et redémarré le serveur mais rien n’y fait.

    Aussi lors de l’installation, au lancement de :
    Get-ReceiveConnector|Set-ReceiveConnector -Fqdn mailhost.domaine.fr ; j’ai eu une erreur disant que lorsque l’attribut Authmechanism sur un connecteur de réception contient la valeur Exchange server, vous devez affecter au FQDN soit le mailhost.domaine.local / Exch2013 ou $null.

    Ca fait pas mal temps que je bloque dessus, j’espère que tu pourras m’aider.

    Merci Beaucoup

    YK

    • Bonjour,

      Pour ton premier problème (page blanche), je te conseille de créer un sujet sur le Forum Technet Exchange avec des photos d’écran du phénomène, ce sera plus simple à comprendre.

      Pour le problème avec la commande « Get-ReceiveConnector|Set-ReceiveConnector -Fqdn mailhost.domaine.fr » : en effet, seul le connecteur de réception exposé à Internet est concerné en réalité par cette commande (Default FrontEnd).
      Le FQDN de ce connecteur a normalement déjà été configuré dans la Partie 3 – « Configuration du connecteur de réception ».

      Je vais corriger l’article en fonction.

      Merci pour ce retour.

  4. Pingback: Les bases d'une bonne configuration Exchange - Partie 4
  5. Bonjour,
    Merci pour vos topics.
    En suivant vos tutos presque tout fonctionne sur ma configuration. Il ne reste plus qu’a réaliser la partie configuration du domaine internet chez l’hébergeur.
    Je dois néanmoins avoir un problème de configuration DNS ou IP.
    Ma particularité est que l’exchange est installé sur le serveur controleur de domaine.
    Quand j’utilise un PC du LAN non connecté au domaine mais dans les memes plages IP je ne parviens à réussir le ping du fqdn.
    La commande ping mailhost.mondomaine.fr me renvoi « la requete pong n’a pas pu trouver l’hote… »
    Le serveur repond au ping sur son adresse IP locale 192.168.x.x

    Une idée ? Merci pour votre lecture
    Cdt

    • Bonjour,

      Vous n’avez pas installé Exchange dans les bonnes pratiques. Je vous rappelle les pré-requis d’installation (notés dans la partie 1 du Tutoriel) : « Pour une installation réussie, vous devrez dédier une machine (ou une VM) à Exchange ».

      L’installation d’Exchange sur un contrôleur de domaine, même si elle est acceptée par le setup, n’est pas supportée.

      Concernant votre problème de résolution du FQDN depuis un poste hors-LAN, je vous conseille de vérifier que le DNS principal paramétré sur la carte réseau de ce poste est bien votre contrôleur de domaine.

      • Re,
        +1 – Merci de votre réponse.
        Ok, autant pour moi alors pour le setup qui laisse passer l’installation qui ne sera au final pas supportée. Je peut néanmoins modifier cette configuration qui me sert de test avant déploiement.
        Pouvez-vous me préciser alors si l’installation d’exchange 2013 sur une MV est possible sur le serveur physique qui est contrôleur de domaine ? Comment mettre en place une VM sur Windows serveur 2012 R2?
        Cdt

        • Le rôle Hyper-V n’est pas supporté sur un contrôleur de domaine.
          Pour faire votre maquette dans les bonnes pratiques, il vous faut:
          – Installer Windows Server 2012 R2 sur le serveur physique en tant que serveur autonome (pas de rôle ADDS, pas de jonction AD)
          – Activer le rôle Hyper-V et créer 2 VM (vous trouverez de nombreux tutoriels sur le Net)
          – Dans la première VM, vous installerez WS 2012 R2 avec le rôle ADDS
          – Dans la seconde VM, vous installerez Exchange

          • Bonsoir,
            J’ai suivi vos conseils et modifier ma config.
            J’ai donc un serveur physique (que nous utilisons pour partager des fichiers entre autres) autonome avec le rôle Hyper V avec une VM ADDS. Un second serveur sur lequel est installé exchange. Beaucoup de choses sont fonctionnelles, je rencontre un souci avec l’envoi de mail. Je dispose d’un nom de domaine chez OVH, auparavant nous utilisions des comptes mails pop chez ovh. Devrais-je configurer différemment le connecteur d’envoi ? La réception de mail fonctionne parfaitement. La configuration des clients Outlook hors domaine est automatique.
            Mes paramétrages en « pop » pour le serveur SMTP chez OVH nous oblige à cocher mon serveur sortant requiert une authentification en utilisant le port 587. Comment indiquer ce paramètre pour le connecteur SMTP ? Merci pour votre aide.
            Cdt

          • Désolé de vous avoir dérangé, j’ai résolu mon pb. Le post peut être supprimé merci.
            Cdt

  6. Bonsoir,

    J’ai configurer mon organisation sur vos bases. Je rencontre un problème pour la configuration d’un client hors domaine et non connecté à exchange. Il est configuré en POP3 (qui est activé dans exchange et fonctionne). Côté réception pas de souci, le pop3 avec le FQDN fonctionne. En revanche le SMTP ne fonctionne pas. Pour configurer le client j’utilise le FQDN comme serveur Pop et comme serveur SMTP. En utilisant ce paramétrage, la réception fonctionne (pop sur le port 995 etc..) mais le SMTP me pose pb. Il m’est possible de configurer le client avec le SMTP avec le smarthost de l’hébergeur, mais cela n’est pas très net comme config, en revanche les mails partent.
    Auriez-vous une idée sur ce problème ? Merci par avance. Cdt

  7. Bonjour Sylvain,

    Je trouve votre approche concernant le nom FQDN public intéressant, et je souhaite l’appliqué à un échange 2010.
    J’ai repris vos commandes power shell pour modifier le FQDN public, cela fonctionne correctement sauf sur une commande :

    [PS] C:\Users\Administrateur\Desktop>Get-ReceiveConnector « Default SRV-EXCH1″|Set-ReceiveConnector -Fqdn mail.totoland.fr

    Lorsque l’attribut AuthMechanism sur un connecteur de réception contient la valeur ExchangeServer, vous devez affecter
    au paramètre FQDN sur le connecteur de réception l’une des valeurs suivantes : le FQDN du serveur de transport « SRV-EXC
    H1.totoland.fr », le nom NetBIOS du serveur de transport « SRV-EXCH1 » ou $null.
    + CategoryInfo : InvalidOperation: (SRV-EXCH1\Default SRV-EXCH1:ReceiveConnector) [Set-ReceiveConnector],
    InvalidFqdnUnde…erAuthException
    + FullyQualifiedErrorId : 3313F335,Microsoft.Exchange.Management.SystemConfigurationTasks.SetReceiveConnector

    Pouvez vous me dire si le comportement et normal ?

    Merci pour votre retour.

    Julien.

    • Bonjour,
      Ce comportement est normal si votre connecteur de réception utilise l’authentification Windows.
      Désactivez l’authentification Windows (si vous ne l’utilisez pas, bien sûr) et vous pourrez fixer votre FQDN public.

      • Bonjour Sylvain,

        Je viens de faire le test, depuis un exchange 2013 SP1.
        Par power shell j’obtient le meme message.
        Idem via la console :


        erreur
        Lorsque l'attribut AuthMechanism sur un connecteur de réception contient la valeur ExchangeServer, vous devez affecter au paramètre FQDN sur le connecteur de réception l'une des valeurs suivantes : le FQDN du serveur de transport "SRV-EXCH.fa49.fr", le nom NetBIOS du serveur de transport "SRV-EXCH" ou $null.

        • Je viens de trouver le problème, il faut décocher Authentification du serveur Exchange.
          Mais cela ne change pas grand chose, vu qu’on répète l’opération a la configuration du connecteur de réception et qu’on config le FQDN.

          Merci.

  8. Bonjour Sylvain,

    la commande suivante nslookup -q=A mail.votredomaine.fr retourne l’IP privée 192.168.1.xxx.
    Est-ce normal?
    Merci de me tenir informé.
    Cordialement,

    • Bonjour,
      C’est normal si la commande est exécutée depuis le réseau local (c’est le DNS local qui répond).
      Ce n’est pas normal si la commande est exécutée en dehors du réseau local (serveur DNS public).

  9. Bonjour et merci pour ce super tuto
    j’ai pour ma part un souci quand je fais le test exchnage connectivity sachant que je suis sur exchnage 2013
    Tentative pour localiser l’enregistrement SRV _autodiscover._tcp.toto.fr dans DNS.
    Échec de recherche d’un enregistrement SRV de découverte automatique dans DNS.

    l’envoi et reception de mail fonctionne
    l’ajout d’une boite sur un pc dans le domaine est ok

    au niveau du dns je suis chez elb
    j’ai rajouter
    les entrees
    mail.toto.fr type a qui pointe sur 89.xxx.xxx.134
    webmail.toto.fr type a qui pointe sur 89.xxx.xxx.134
    .toto.fr type MX qui pointe sur mail.toto.fr
    autodiscover.toto.fr de type cname qui pointe sur webmail.toto.fr
    _autodiscover._tcp.toto.fr de type srv priorite 0 / poids 1 / port 443 pointe sur autodiscover.toto.fr

    quand je fais get-client accessserver | fl autodiscoverserviceinternaluri
    j’ai
    autodiscoverserviceinternauri : https://autodiscover.toto.fr/autodiscover/autodiscover.xml

    et du coup je ne sais pas si le problème est liée a l’erreur mais pour les clients qui veulent se connecter depuis leur pc perso
    donc pas dans le domaine sur leur outlook cela ne marche pas

    Merci d’avance

  10. Bonjour,

    D’abord, je vous remercie infiniment pour votre tuto autour d’Exchange 2013.

    Je suis nouveau dans le monde de la messagerie d’entreprises. J’ai pas bien compris dans votre exemple si le nom « mailhost.sylvaincoudeville.fr » est le nom de la machine ou celui utilisé pour OWA depuis Internet? ou tout simplement c’est le nom de votre organisation Exchange?
    – Est ce que vous vous connecter à OWA avec mailhost.sylvaincoudeville.fr sans avoir besoin de créer un enregistrement CNAME pour OWA?
    – Pour appliquer votre exemple, est ce que j’ai besoin de mettre en place un serveur DNS Public en DMZ?

    Merci d’avance à vous et à tout ceux qui peuvent m’aider à travers des exemple

    • Bonjour,

      En effet, mailhost.sylvaincoudeville.fr est le nom DNS qui sera utilisé pour accéder à OWA (comme vous avez pu le voir dans les partie suivantes du tuto).
      De la même manière, nous déclarons ce nom dans le DNS public de ce nom de domaine (pour qu’il puisse être résolu par les utilisateurs d’Internet) mais sous la forme d’un enregistrement A et non un CNAME comme on le voit partout (car un CNAME est une sorte d’alias qui nécessite qu’un enregistrement DNS existe déjà).
      Maintenant, que le serveur DNS public soit hébergé dans une DMZ, une VM chez AWS ou sur un serveur dédié chez 1&1, c’est une autre histoire!

  11. Bonjour,

    Merci pour votre tutoriel. Si j’ai bien compris nous sommes obligé d’avoir une ip fixe de notre FAI, si il faut lié un nom de domaine à un ip publique elle ne sera jamais mis à jour, de ce fait lorsque l’on obtiendra une autre ip ça ne marche plus.

    Pouvez-vous me confirmer cela svp ?

    Cordialement

  12. Bonjour

    je souhaite faire de la réception et de l’envois de mail depuis plusieurs domaines.
    que me conseilliez vous , de créer des serveurs virtuel sur mon ad (1 par domaine) ?
    est il possible de réceptionner plusieurs domaine sur un Exchange 2k13SP1 avec un seul Ad 2K12R2DC?

    j’ai actuelement 9 domaines ?
    mon serveur est un dual xeon L5520 avec 26 GB de DDR3 . 2 connections fibre noir 10GB directement relieé au reseau LYON IX et NEOTELECOM. donc pas de problème de BP ni de charge CPU, je peux monter un cluster en moin de 4H.

    merci de votre retour.

    • Bonsoir,

      Vous pouvez réceptionner plusieurs domaines avec un seul domaine Active Directory.
      Vous pouvez avec votre AD unique et votre configuration matérielle gérer sans soucis 9 domaines internet.

      Pour ajouter des domaines supplémentaires, il suffit d’utiliser le cmdlet New-AcceptedDomain.

  13. Merci pour cet excellent tuto. les adresses de mon domaine reçoivent sans pouvoir émettre vers l’extérieur. a quoi cela pourrait etre du???

  14. Bonjour
    J’ai besoin d’aide au niveau de configuration du nom d’hôte dans Exchange, j’ai une commande qui passe pas :
    Get-ReceiveConnector « Default Frontend Exch2013″|Set-ReceiveConnector -Fqdn mailhost.tsgeri.fr
    Get-ReceiveConnector « Default Frontend Exch2013.techbis.local »|Set-ReceiveConnector -Fqdn mailhost.tsgeri.fr

    Le nom de mon serveur est « EXCH2013 »
    J’ai les deux messages d’erreur:
    https://drive.google.com/open?id=0B_1pPuQ5VrGGUkNqR0xuMW5OVDA

    Est-ce qu’il y a un moyen de corriger ça en dans l’ ECP??

    Merci

  15. Super! Ton article présente le concept, ce qui est souvent oublié dans les différents tuto que l’on peut trouver! Merci.

  16. Bonjour,
    Merci pour ce tutoriel.
    Je bloque au début de la partie 3 lorsque je dois ping mon fqdn.
    Malgré le suivi des indications, le ping indique l’ip publique et non celle privée.
    Une idée ? Est-ce qu’il y a un délai ?

  17. bonjour le boss tu es vraiment cool avec tes tutoriel
    Mais jai un soucis avec mon exchange j peux envoyer le mail a exterieur je n’arrive pas a recevoir
    quand je tape telnet nomdomain port
    ESMTP mail service is ready yet
    apres je tape ehlo
    il me retourme :
    250-imail.domain.com hell0[192.168.1.11] il me renvois pas ip publique
    sauf IP prive que j’utilise pr mon serveur exchangr
    je compt sur vous

    • Bonjour,
      Je pense qu’il y a confusion entre la communication interne et externe.
      En effet, même si le nom de domaine public (ex: mail.camara.com) est disponible en interne et en externe, selon si le Telnet est effectué sur le réseau local ou depuis Internet, le résultat ne sera pas le même :
      – si le Telnet est fait depuis le réseau local, l’IP retournée lors de la communication SMTP (192.168.1.11 ici) sera l’IP privée de ta machine cliente
      – si le Telnet est fait depuis Internet vers l’IP publique de ton Exchange, l’IP sera l’IP publique de la connexion Internet depuis laquelle tu fais ton essai.

      Si le résultat est le même dans les 2 cas, cela signifie que la redirection de ports faite sur ton routeur est incorrecte et que tu masques l’IP publique de l’appelant sur l’IP privée de ton routeur (dans ce cas, 192.168.1.11 serait l’IP de ton routeur).

      Espérant que cela aide.

      A bientôt.

  18. Bonjour Sylvain, merci deja pour ces supers tuto. Je suis un peu confus dans l’implementation de Exchange. J’ai souvent vu dans certains posts des personnes qui utilisent un troisieme serveur Exchange dans lequel ils installent uniquement le role transport edge dans une DMZ. Es ce vraiment necessaire?

    • Bonjour,
      Ceci est une très bonne remarque.
      L’usage d’un serveur supplémentaire avec le rôle Edge dont je n’ai pas parlé dans ce tuto est en effet répandu, mais pas obligatoire.

      Le rôle Edge est un rôle qui n’est pas cumulable avec l’un des autres CAS, Mailbox et Transport Hub. Edge est un rôle spécifiquement conçu pour créer un Frontal (réception MX des emails) avec des fonctionnalités de filtrage et antispam avancées.
      Il est de bonne augure de le mettre en DMZ (puisqu’il est en frontal sur Internet).

      Mais je vous confirme qu’il n’est pas obligatoire.

  19. Bonjour, j’essaie pas à pas de configurer un serveur exchange 2013 sur une machine virtuel (Hyper-V/Server 2012r2), tout se passe bien sauf quand je tape la commande suivante dans le shell exchange :
    Get-ReceiveConnector « Default Frontend SRV-EXCHANGE »|Set-ReceiveConnector -Fqdn mailhost.manaoure.ovh
    J’obtiens toujours l’erreur :
    Impossible d’effectuer l’opération, car l’objet ‘SRV-EXCHANGE.manaoure.lan\Default Frontend SRV-EXCHANGE.manaoure.ovh’ est introuvable sur SRV-2017.manaoure.lan’

    SRV-2017 est mon serveur AD sous 2012r2

    Avez-vous une idée ? D’avance merci

    Istinen JL FIETTE

    • Bonjour,
      Vérifiez que votre connecteur de réception se nomme bien « Default Frontend SRV-EXCHANGE » car le message d’erreur parle de ‘SRV-EXCHANGE.manaoure.lan\Default Frontend SRV-EXCHANGE.manaoure.ovh’
      Faites éventuellement un « Get-ReceiveConnector » afin d’obtenir la liste de tous les connecteurs de réception de votre serveur pour vérifier

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *