Tuesday, January 31, 2017

Exchange 2016 (8) : Outlook - MAPI/HTTP - Seconde partie

English summary: after examining aspects of RPC/HTTP (Outlook Anywhere), we install updates on our Windows 7 (SP1) client machine and then observe that the connection type changes to MAPI/HTTP (after reopening Outlook once or twice).


***


Dans mon billet précédent, j'ai configuré RPC/HTTP (Outlook Anywhere) de sorte qu'il utilise SSL (ce qui n'était pas le cas par défaut) et observé certaines propriétés de cette connexion avec l'outil "Etat de la connexion" ("Connection status"). Maintenant, nous allons faire le nécessaire pour qu'Outlook recoure plutôt à MAPI/HTTP.

Rappel : il s'agit d'Outlook 2010 SP2.

Précisons donc qu'en plus de "Service Pack 2 (SP2), il faut installer les deux mises à jour suivantes :

KB2956191

KB2965295

Il suffit de télécharger les deux fichiers et de les exécuter. Je le fais avec un compte administrateur et je fais redémarrer la machine.

Après le redémarrage, j'ouvre une session sous l'identité de Mark Patel. Outlook s'ouvre sans problème. Je tente de voir si nous sommes passé de RPC/HTTP à MAPI/HTTP mais ce n'est pas clair tout de suite. Nous fermons et rouvrons Outlook. Il semble qu'Autodiscover a besoin de plus d'un essai pour réussir la transition.

Quoi qu'il en soit, c'est bien MAPI/HTTP(S) qu'utilise Outlook à la fin.

Voici l'état de la connexion :





Je remarque d'abord que rien ne s'affiche pour "Proxy Server" et qu'on voit le nom du serveur dans la colonne "Server Name", ce qui est caractéristique d'une connexion MAPI/HTTP. Il s'agit en fait de l'Url que nous avons configuré pour nos répertoires virtuels : mail.machlinkit.biz.

Mieux encore, je vois, après la barre oblique de l'Url, que la connexion se fait avec le répertoire virtuel /mapi au lieu de /rpc. Nous sommes donc bien passé d'RPC/HTTP à MAPI/HTTP.  Le protocole indiqué dans la colonne du même nom est "HTTP" et la colonne "RPCPort" est vide, comme la colonne "Conn" qui ne semble plus être utilisée.


***

Jusqu'en avril 2015, MAPI/HTTP n'était pas une option pour Outlook 2010. Il aurait fallu utiliser Outlook 2013. Mais l'installation des deux mises à jour indiquées ci-dessus nous permet désormais de bénéficier des avantages de MAPI/HTTP avec Outlook 2010 aussi.



Friday, January 27, 2017

Exchange 2016 (7) : Outlook - MAPI/RPC/HTTP ou MAPI/HTTP ? - Première partie

English summary: we compare some Outlook connection protocols and evaluate various combinations on our new Exchange 2016 server with a Outlook 2010 client (on Windows 7). Most of this blog deals with aspects of Outlook Anywhere that were confusing at first glance. For example, Outlook Anywhere uses HTTP, and not HTTPS, when SSL Offloading is selected on the Exchange server. Because the text became rather long, I decided to dedicate a separate blog post to the use of MAPI/HTTP with Outlook 2010 (yes, it is possible with SP2 and two patches).


***

Dans le billet précédent, j'ai précisé qu'Outlook utilise désormais le protocole HTTP(S) pour accéder à la boîte aux lettres.

J'aurais pu ajouter : d'une façon ou d'une autre.

Autrefois, avec Exchange 2003, 2007 et 2010, les connexions Outlook "locales" se faisaient avec le concours du protocole RPC.

Je précise : c'est bel et bien le protocole MAPI qui permettait l'interaction entre Outlook et la boîte aux lettres. Mais il fallait un autre protocole pour les communications sur le réseau, entre client et serveur. La solution consistait à encapsuler MAPI dans RPC. 

Cela fonctionnait assez bien en interne mais pour les connexions qui passaient par l'Internet il fallait recourir à un autre protocole encore : HTTP. Cette nouvelle solution consistait à encapsuler MAPI dans RPC et RPC dans HTTP. MAPI faisait donc l'objet d'une double encapsulation. On aurait pu écrire : "MAPI/RPC/HTTP". En réalité, on écrit "RPC/HTTP" ou "Outlook Anywhere". De plus, même si la connexion est chiffrée la plupart du temps (voir plus bas), on ne précise pas "HTTPS" en général.

De nos jours, pour les versions d'Exchange et d'Outlook encore prises en charge (2010, 2013, 2016), nous nous trouvons devant plusieurs scénarios possibles. 

Pour communiquer avec Exchange 2013 ou 2016, Outlook 2010 utilise RPC/HTTP. RPC "tout seul" n'est donc plus une option, même derrière le pare-feu dans le réseau local.

A un moment, RPC/HTTP était aussi l'option par défaut pour Outlook 2013 mais depuis Outlook 2013 SP1 (et Exchange 2013 SP1) nous avons une option plus simple et plus efficace : MAPI/HTTP. Il s'agit d'encapsuler MAPI directement dans HTTP. Quant à RPC, il ne joue plus aucun rôle dans la connexion.


(You Had Me At EHLO… The Microsoft Exchange Team Blog)

Comme on pourrait s'y attendre, Outlook 2016 est capable d'utiliser MAPI/HTTP aussi.

A retenir :
  • MAPI/HTTP n'est pas activé par défaut dans Exchange 2013.
  • MAPI/HTTP est activé par défaut dans Exchange 2016 mais nous devons configurer les Urls pour le répertoire virtuel MAPI (ce que nous avons fait dans un autre billet de blogue). Toutefois, la documentation laisse penser que MAPI/HTTP ne serait pas activé par défaut dans un environnement mixte (Exchange 2010 et 2016 par exemple).

Note : document non encore traduit en français au moment de la composition de ce texte. Quant au blogue de l'Equipe Exchange (Exchange Team Blog), il n'existe, bien entendu, qu'en version anglaise.


***

Lors de mes premiers essais "accès client" (voir le billet de bloque précédent), j'ai remarqué qu'Outlook 2010 SP2 est capable d'accéder à une boîte à lettres stockée sur Exchange 2016 directement après l'installation de celui-ci. Aucune autre configuration n'est requise.

Il faut donc conclure qu'Outlook Anywhere est activé et deux simples cmdlets nous permettent de confirmer que c'est le cas, non seulement pour Outlook Anywhere, mais aussi pour MAPI/HTTP :



En ce qui concerne MAPI/HTTP, les Urls sont bien en place :



Par contre, je ne me souviens pas d'avoir configuré d'Url pour Outlook Anywhere (?).

En fait, pour Outlook Anywhere, il n'y a pas d'Url mais plutôt un "nom d'hôte", interne et externe :



Observez bien cette capture d'écran. Remarquez-vous quelque chose de bizarre ?

Réfléchissons...

Il n'y a pas de nom d'hôte externe, soit. Mais le nom d'hôte interne comporte encore le nom du serveur (ex16-3) et là, je ne comprends plus...

S'il s'agit, en fin de compte, d'une connexion en HTTP, comment se fait-il qu'Outlook s'ouvre sans afficher un message d'erreur à propos du certificat que nous avons installé pour valider les connexions en HTTP? En principe, les Urls que nous utilisons doivent correspondre aux noms qui figurent sur le certificat. Dans notre cas, ce serait, pour l'essentiel...
  • mail.machlinkit.biz
  • autodiscover.machlinkit.biz
Le nom du serveur ne figure pas parmi ces noms. Et pourtant, quand j'ouvre Outlook, utilisant a priori le protocole HTTP, rien ne semble gêné par l'absence du nom de serveur sur le certificat.

Deux questions se posent alors :
  • Est-ce bien en mode RPC/HTTP que la connexion se fait ?
  • A en juger par les paramètres "ExternalClientsRequireSsl" et "InternalClientsRequireSsl", je me demande si Outlook Anywhere fonctionne sans SSL ?

Qu'en est-il donc ?

D'abord, sachez qu'Outlook Anywhere utilise le répertoire virtuel : /rpc

De plus, comme nous avons cru remarquer plus haut, SSL n'est pas exigé (confirmation dans la console de gestion IIS) :



Et pourquoi pas ?

Parce que, par défaut, le "déchargement SSL" est coché (sous les noms d'hôte et la méthode d'authentification) :




Décharger SSL signifie qu'un autre dispositif (un répartiteur de charge par exemple) déchiffre le flux SSL avant le serveur Exchange. Le flux de données entre le répartiteur de charge et le serveur n'est pas chiffré. C'est ce qu'on observe dans notre cas.

Note : il est possible de (re)chiffrer les flux de données entre le répartiteur et le serveur si nous le souhaitons.

Selon les sources que j'ai consultées, c'est bien cette propriété qui gouverne l'obligation de recourir (ou non) à SSL : si elle est cochée (pour le déchargement) SSL n'est pas exigé et la correspondance entre les Urls et les noms sur le certificat n'entre même pas en jeu. Au contraire, si elle est décochée (aucun déchargement), SSL est exigé.

Puisque je n'ai pas l'intention d'utiliser un répartiteur de charge (pour le moment), allons désactiver le déchargement SSL et voyons si ce changement modifie les paramètres SSL.

Voici le statu quo :



Je tente de désactiver le déchargement avec cette cmdlet :


Mais ce message s'affiche en rouge :

La fonctionnalité Outlook Anywhere doit être configurée avec SSLOffloading défini sur true si des clients internes ou externes ne requièrent pas SSL. Si SSLOffloading est défini sur $false, RPC/HTTP vDir acceptera uniquement les connexions SSL.

Je fais attention alors à modifier les trois paramètres en même temps :


J'observe que la valeur ne change pas pour l'externe (ce qui s'explique, peut-être, par l'absence d'un nom d'hôte dans le champ correspondant ?).

En tout cas, ce changement se constate aussitôt dans la console de gestion IIS aussi (nul besoin de faire redémarrer tel ou tel service) :




Alors... qu'est-ce qui va se passer quand un de nos utilisateurs ouvre Outlook, maintenant que SSL est exigé ?

Attention ! C'est exprès que je n'ai pas (encore) changé les noms d'hôte afin de voir, justement, ce qui se passe.

Quand l'utilisateur "Mark Patel" essaie d'ouvrir Outlook, l'application lui demande son nom et mot de passe. Quand Mark les saisit et appuie sur OK, l'application les lui redemande et ainsi de suite. C'est un cycle sans fin : 



Bien que cela ne ressemble pas tellement à une erreur de certificat, je me dis qu'il est peut-être temps de mettre les noms d'hôte qui conviennent, c'est-à-dire des noms qui correspondent à l'un des noms de domaine figurant sur notre certificat SSL.

C'est ce que j'ai fait avec les cmdlets suivantes :



Note : vous pouvez cliquer sur les images pour les agrandir.

Mark ouvre une nouvelle session et cette fois-ci, un autre message d'erreur s'affiche :



C'est à ce genre de message que je me serais attendu parce qu'il désigne le nom du serveur comme source du problème. Cependant, je viens de changer les noms d'hôte, tant interne qu'externe. Que puis-je faire de plus ?

Nous fermons Outlook et mettons fin à la session Windows. Entre-temps, je fais redémarrer le serveur Exchange. J'allais me contenter de iisreset /noforce mais le service refusait de s'arrêter. Il fallait que je recoure aux grands moyens.

Ensuite, Mark Patel ouvre une nouvelle sessions sous Windows et ouvre Outlook. A ma surprise, la même erreur se manifeste de nouveau.

J'ouvre une autre session sous le nom de "Karen Roberts". Le premier message d'erreur s'affiche mais quand Karen ferme et rouvre Outlook le message n'apparaît plus.

Je crois que ces erreurs ont un rapport avec le profil Outlook de l'utilisateur. Que se passe-t-il si j'ouvre une session (et puis Outlook) sous le nom de Paul York, c'est-à-dire quelqu'un qui n'a pas encore ouvert une session sur le poste client ? Outlook ouvre sans peine et aucun message d'erreur s'affiche : rien au sujet des données de connexion, rien au sujet de notre certificat.

Mieux encore, quand j'essaie d'ouvrir une session sous le nom de Mark Patel à nouveau, les messages d'erreur ne s'affichent plus du tout. Je conclus que le profil avait gardé en cache des paramètres de connexion précédents et que Autodiscover les aurait mis à jour après un certain délai. Est-ce que je vois juste ? Je ne suis pas sûr mais je sais que nos utilisateurs peuvent désormais ouvrir Outlook sans accroc.


***


Et maintenant, tentons de répondre aux questions que nous nous sommes posé plus haut.

D'abord, la valeur pour la propriété "ExternalClientsRequireSsl" est "True" maintenant que le champ "ExternalHostname" est peuplé, sans que je puisse affirmer avec certitude que ceci explique cela : 



Les connexions se sont faites d'abord en mode RPC/HTTP et en RPC/HTTPS après que j'ai désactivé le déchargement SSL.

Nous pouvons observer cette évolution dans des captures d'écran successives de l'outil Outlook "Etat de la connexion" ou "Connection Status" en version originale.


Comment accéder à cet outil ? Il faut ouvrir Outlook d'abord et puis, tout en appuyant sur la touche Ctrl (sans relâcher), faire un clic-droite sur l'icône Outlook dans la barre des tâches et cliquer sur "Etat de la connexion" (ou "Connection Status") dans le menu :




A titre de comparaison, commençons par voir à quoi ressemble une simple connexion Outlook par opposition à une connexion Outlook Anywhere :



Le protocole est "RPC/TCP".

Quand nous avons ouvert Outlook 2010 SP2 avec le déchargement SSL activé sur notre serveur Exchange 2016 (CU3), l'état de la connexion ressemblait plutôt à ceci :





D'abord, la clarté de la présentation souffre de ce qui semble être des incohérences dans le nommage des colonnes. Nous n'avons plus de "Protocol" mais pour "Conn", le protocole affiché est "HTTP". Le "S" manque à la fin, sans qu'on puisse savoir si cela tient au déchargement SSL (encore activé à ce moment-là) ou à un simple choix de nommage. Dans la colonne "Encrypt", la valeur "None" (c'est-à-dire "aucun") tend à confirmer que la connexion ne bénéficie pas de protection par le chiffrement.

Dès que nous désactivons le déchargement SSL et imposons le chiffrement, la colonne "Conn" change de valeur : HTTPS (avec "S" donc) :



Pour combler l'incohérence, la colonne "Encrypt" montre "SSL" mais, entre crochets, la négation "No". Cela veut-il dire que malgré la valeur de la colonne "Conn", il n'y a toujours aucun chiffrement ?

En fait, ce serait un bogue :



***

Nous avons donc résolu quelques mystères entourant Outlook Anywhere dans un environnement d'essai qui comprend un serveur Exchange 2016 (CU3) et un client Outlook 2010 (SP2). Mais l'explication a allongé le texte au point que je vais remettre l'utilisation de MAPI/HTTP au billet de blogue suivant. Nous installerons les mises à jour nécessaires et verrons ce qu'il faut faire pour passer de "MAPI/RPC/HTTP(S)" à "MAPI/HTTP(S)". Nous verrons aussi à quoi ressemble ce genre de connexion dans l'outil "Etat de la connexion".

Saturday, January 21, 2017

Exchange 2016 (6) : connecteurs d'envoi et de réception

English summary: after the creation of several mailboxes in a previous post, users were able to send and receive messages internally with very little additional configuration. In this blog post, I create a send connector with certain parameters and observe that the receive connector, in Exchange 2016, is already configured with the proper settings for the reception of external messages. We take note of some other related elements to ensure successful inbound mail flow. 

***

Dans le billet de blogue précédent, j'ai créé une boîte à lettres pour chacun de mes deux utilisateurs et ceux-ci ont pu échanger des messages en interne. Il s'agit, vous l'aurez compris, d'utilisateurs "imaginaires" par l'intermédiaire desquels nous pouvons mettre à l'essai divers aspects d'Exchange 2016, comme l'accès client via Outlook et OWA. A mon grand contentement, cet accès s'est fait presque tout seul. Maintenant, nous allons passer à la prochaine étape : envoyer des messages vers l'extérieur et en recevoir.

***

Connecteur d'envoi

Notre première tâche consiste à créer ce qui s'appelle un "connecteur d'envoi". Pour ce faire, nous devons ouvrir l'EAC (Centre d'administration Exchange) et nous rendre à la section "flux de messagerie" et puis "connecteurs d'envoi" :



A regarder la capture d'écran ci-dessus, vous avez sans doute deviné qu'il faudra cliquer sur le signe "+ " pour lancer le processus de création d'un nouveau connecteur d'envoi - et vous avez raison. Mais d'abord, je tiens à faire quelques précisions sur ces connecteurs d'envoi.

Comme vous avez probablement remarqué, aucun connecteur d'envoi n'existe par défaut après une nouvelle installation d'Exchange. Dans le scénario d'une migration, en revanche, nous verrions des connecteurs d'envoi déjà en place. En effet, les connecteurs d'envoi existent au niveau de l'organisation Exchange plutôt qu'au niveau d'un serveur particulier. Ainsi, quand un nouveau serveur est installé, il "hérite" en quelques sorte les objets qui existent au niveau de l'organisation (et qui sont stockés dans Active Directory au final).

Nous cliquons donc sur le signe " + " pour créer un nouveau connecteur d'envoi et nous devons aussitôt prendre une décision : quel nom donnerons-nous à notre nouveau connecteur ? Pour nos essais, un simple nom comme "cde_principal" suffira. De plus, comme il s'agit d'échanger des messages avec le dehors, nous allons choisir l'option "Internet" : 



A l'étape suivante, nous devons choisir entre deux options que je résume ainsi :

  • Déterminer l'adresse IP du destinataire par le moyen des enregistrements DNS (MX et A) et puis envoyer directement à cette destination.
  • Faire transiter les messages par ce qu'on appelle un "hôte actif" ou "hôte intelligent" selon les traductions (c'est traduit de deux manières différentes dans la capture d'écran ci-dessous d'ailleurs).

Je choisis la seconde option et je clique sur le signe "+ " pour ajouter l'hôte actif :



L'hôte actif est, en substance, un serveur (un "hôte") qu'un fournisseur met à la disposition des clients afin qu'ils puissent faire transiter leurs messages par ce serveur au lieu d'envoyer directement aux serveurs de messagerie des destinataires. L'hôte actif se révèle utile, en particulier, si on monte un réseau d'essai chez soi et l'interface extérieure de notre pare-feu se voit assigner une adresse IP de façon dynamique. Autrement dit : si c'est une "adresse DHCP".

Quel est le problème ? Certains fournisseurs bloquent le trafic SMTP sortant de ces adresses et même si le vôtre le permet (c'est mon cas), certains services antispam rejettent tout message envoyé à partir de ces adresses "dynamiques". Il faut penser qu'ils ont pris la peine de dresser une telle liste.

Quoi qu'il en soit, l'hôte actif nous permet de reprendre certaines options pour l'étude des systèmes de messagerie dans un milieu temporaire d'essai, et sans devoir faire l'achat d'une adresse IP statique.

Dans le cas présent, j'ai choisi le service "Alternate-Port SMTP" de No-IP. Je ne présenterai pas toutes les démarches à faire, pas à pas, mais, en abrégé, il s'agit de créer un compte chez No-IP, de faire l'achat du service en question, et de protéger l'accès à l'hôte actif avec un mot de passe.

Cela accompli, je reviens à notre serveur Exchange où je spécifie le domaine de l'hôte actif :



Note : où ai-je trouvé ce FQDN au juste ? No-IP vous envoie ces informations par courriel.

Voici notre hôte actif :



Note : comme j'ai expliqué dans mes autres billets de blogue, je cadre mes captures d'écran de manière à se concentrer sur l'essentiel. Les boutons "Enregistrer", "Suivant" et "Terminer" sont souvent hors cadre. Je fais confiance au lecteur de comprendre qu'il faut cliquer dessus pour passer à la page suivante.

J'ai mentionné un mot de passe qu'il fallait saisir en configurant son hôte actif chez No-IP. A l'étape de la configuration du connecteur d'envoi illustrée ci-dessus, il faut choisir "authentification de base" avec TLS et puis saisir les données de connexion qui correspondent aux données chez No-IP :


Encore une fois, No-IP vous communique ces données par courriel (à l'exception du mot de passe choisi qu'il faut simplement retenir).


A l'étape suivante, nous devons spécifier l'espace d'adresse dont ce connecteur va s'occuper. Il faut cliquer sur le signe " + " :


Note : je n'ai pas besoin de cocher (tout en bas)  "Connecteur d'envoi délimité" pour mes objectifs.


Nous ajoutons un domaine et puisque nous utiliserons ce connecteur d'envoi pour tout, il suffit de mettre un astérisque (étoile) dans la case FQDN :


Ce qui nous donne ceci :


Note : vous pouvez cliquer sur les images pour les agrandir.

Si, plus tard, nous avions besoin de créer un connecteur d'envoi pour un autre domaine (un partenaire avec des exigences spéciales, par exemple), nous mettrions le nom de ce domaine dans la case FQDN afin que le nouveau connecteur s'occupe de ces envois (avec les paramètres appropriés). C'est donc le connecteur avec la référence la plus spécifique à tel domaine qui s'occupe de ce domaine-là.

Enfin, nous devons choisir les serveurs associés à ce connecteur. Nous cliquons donc sur le signe " + "...



Et nous ajoutons notre seul serveur, EX16-3 :



Voici le résultat :



Nous cliquons sur "Suivant", "Terminer", etc.. pour fermer l'Assistant.

A cette étape, nous pouvons tenter d'envoyer un message à un destinataire extérieur (quelqu'un avec un compte Gmail ou Hotmail, etc.). C'est ce que j'ai fait et cela a réussi. Nous pouvons en conclure que le connecteur d'envoi, correctement configuré, est désormais fonctionnel.


***


Connecteur de réception

Mais attendez ! Peut-on nous répondre de l'extérieur? La réponse est oui... en principe.

En ce qui concerne Exchange 2016 (je précise bien 2016), aucune configuration manuelle n'est requise pour le connecteur de réception. Les paramètres par défaut acceptent les messages du dehors à condition que l'adresse corresponde à un de nos "domaines acceptés". Nous pouvons vérifier ceux-ci, et les modifier au besoin, à cet endroit :



Ce n'était pas le cas dans certaines versions précédentes comme Exchange 2007 et 2010 où il fallait ajuster les permissions afin d'accepter des messages des expéditeurs "anonymes".

Pour Exchange donc, tout va bien. Il faut tenir compte de deux autres facteurs quand nous planifions ou dépannons le flux de messagerie entrant :

  • Il faut que les enregistrements DNS soient justes. En particulier, les "MX" doivent renvoyer vers l'"A" et celui-ci doit renvoyer à l'adresse IP de l'interface externe du pare-feu de l'organisation (à moins qu'un tiers s'occupe de l'hygiène des messages, auquel cas nous réglerions nos enregistrements en conséquence).
  • Une fois que les messages arrivent à notre pare-feu (ou dispositif équivalent), il faut que l'appareil puisse relayer les messages vers le serveur Exchange. Il s'agit de configurer ce qu'on appelle le plus souvent "1 to 1 NAT". Encore une fois, la situation sera sans doute différente pour chacun. Le pare-feu pourrait plutôt relayer les messages vers un répartiteur de charge qui, à son tour, les enverrait vers un ensemble de serveurs Exchange. Le matériel pour le pare-feu va sans doute varier aussi. Les uns utilisent Cisco alors que les autres utilisent CheckPoint (etc.). Voilà pourquoi je ne présente pas la configuration de ces éléments en détail : mes instructions ne seraient pas valables pour le matériel d'un autre vendeur.

Note : et n'oublions pas les "domaines acceptés". Si nous utilisons seulement le nom de domaine par défaut, il sera ajouté automatiquement en tant que "domaine accepté". Si nous utilisons d'autres domaines dans les adresses de notre courriel, nous devons ajouter ces domaines à la liste des domaines acceptés de façon manuelle.

Pour récapituler, il est donc possible de recevoir des messages de l'extérieur si toutes les conditions ci-dessus sont remplies : bonne configuration de DNS, du pare-feu, et des domaines acceptés. Mais je n'ai pas encore montré le connecteur de réception et il le faut afin de clarifier certaines choses.

D'abord, il n'y pas un seul connecteur de réception (1) après une installation normale d'Exchange 2016 mais plutôt cinq (5). Les voici :




C'est le "Default Frontend [Nom du serveur]" qui nous intéresse pour le flux des messages avec l'extérieur. En cliquant sur l'icône du stylo, nous pouvons afficher ses propriétés...




Et en particulier, dans la section "sécurité", nous voyons que la dernière case pour les permissions, "Utilisateurs anonymes", est cochée par défaut :



Qu'en est-il des autres connecteurs de réception ? A quoi servent-ils ?

  • Outbound Proxy Frontend : par défaut, les messages sortants passent par le connecteur d'envoi qui les expédie directement vers les destinataires à l'extérieur (éventuellement par le biais d'un hôte actif). Nous avons l'option de faire transiter ces messages par le service "Front End Transport". C'est ce connecteur qui s'en occuperait alors. Dans la plupart des cas, nous n'avons pas besoin de recourir à cette option.
  •  Client Frontend et Client Proxy : les connecteurs avec le mot  "Client" concernent les connexions  POP et IMAP. Si nous n'utilisons ni l'un ni l'autre, nous n'avons pas besoin d'en tenir compte. C'est mon cas.
  • Default : cela nous laisse avec le connecteur "Default"...

Quelle est la différence entre le connecteur "
Default Frontend" et "Default" tout court ? Je vous l'explique :

Le connecteur "Default Frontend" se rattache au service "Front End Transport"...

Alors que...

Le connecteur "Default" se rattache au service "Transport".

Mais en quoi cette explication nous avance-t-elle ? Je le reconnais : elle ne fait que déplacer la question, c'est-à-dire...

Quelle est la différence entre le service "Front End Transport" et le service "Transport" tout court ?

Le service "Front End Transport" joue le rôle de "proxy" (ou intermédiaire) entre les serveurs SMTP extérieurs et le service "Transport". Il fait passer les messages entre les deux sans autre forme de traitement.

Le service "Transport" s'occupe des tâches de catégorisation des messages et de l'inspection de leur contenu (antivirus/antispam - souvent avec les "agents" d'un logiciel tiers). Il agit lui-même comme un intermédiaire entre le service "Front End Transport" et le service "Mailbox Transport".

Ce dernier service s'occupe de l'interaction directe avec les boîtes à lettres. En fait, il se compose lui-même de deux services : le service "Mailbox Transport Delivery" et "Mailbox Transport Submission". De ces deux services, le premier pose les messages qui arrivent du service "Transport" dans les boîtes à lettres et le second ramasse les messages sortants en attente et les transmet au service "Transport".

Comme vous avez vu dans certaines des captures d'écran plus haut, la version française d'Exchange retient parfois les noms anglais des connecteurs. J'ai moi-même utilisé les noms de service anglais car la documentation officielle en français n'est pas toujours disponible (voir le lien plus bas par exemple). Toutefois, je me rends compte, en consultant la console des Services, que les noms de services sont bel et bien traduits dans la version française de Windows 2012 R2, soit...

  • Transport frontal (pour "Front End")
  • Transport (d'accord, aucun changement là)
  • Remise de transport de boîtes aux lettres (pour "Delivery")
  • Transmission de transport de boîtes aux lettres (pour "Submission")


***

Pour de plus amples renseignements, veuillez vous reporter à la documentation officielle à ce sujet (au moment où je compose ce billet, la documentation n'a pas été traduite en français) :


En conclusion, ce billet a fini par être assez long et complexe mais, à la fin, j'ai été capable d'envoyer des messages d'essai vers l'extérieur et aussi d'en recevoir.

Thursday, January 19, 2017

Exchange 2016 (5) : création de boîtes aux lettres, accès avec OWA et Outlook

English summary: we create some user mailboxes, review certain mailbox properties and then have users attempt to send messages to each other internally. It appears that even with older software (Windows 7 and Outlook 2010), Autodiscover configures settings automatically and client access to mailboxes encounters no errors or obstacles. Outlook 2010 interaction with Exchange 2016 takes place in "Outlook Anywhere" mode but this does not seem to require any additional adjustments.

***

Nous avons maintenant une base de données de boîtes aux lettres qui correspond à nos besoins (voir le billet précédent) et nous sommes prêts à passer à la prochaine étape : créer quelques boîtes aux lettres pour nos utilisateurs qui vont tenter d'accéder à ces boîtes, soit par Outlook soit par OWA. Nous pourrons ainsi vérifier le bon fonctionnement de l'accès client ainsi que l'envoi et la réception entre boîtes aux lettres en interne.

***

Il s'agit donc d'ouvrir l'EAC (Centre d'administration Exchange) et de nous rendre à la rubrique "destinataires" et puis, à la section "boîtes aux lettres". Nous cliquons sur le signe " + " et choisissons "Boîte aux lettres utilisateur" :





J'ai déjà créé des utilisateurs dans Active Directory, ce qui nous permet de choisir l'option "Utilisateur existant"...




Et d'en chercher un dans notre annuaire (note : nul besoin de mettre l'alias - première capture d'écran de l'Assistant ci-dessus. Exchange le fera pour nous) :





Notre premier utilisateur s'appelle Karen Roberts :



Note : à chaque étape du processus, cliquez "Enregistrer" ou "Suivant" ou "Terminer" selon le cas. Il me semble fastidieux - et inutile - de le répéter sous chaque capture d'écran.


Quelques notes sur nos options dans les propriétés de la boîte aux lettres (désormais abrégé en "BAL")...

En cliquant sur les trois points, nous pouvons désactiver la BAL au besoin : 



La section "générale" nous résume les différents noms associé à la BAL...



Ainsi que l'unité d'organisation où le compte utilisateur se trouve et la base de données qui abrite la BAL :




Si je passe à "utilisation des boîtes aux lettres", un message d'erreur s'affiche parce que Karen n'a pas encore ouvert sa BAL. Une fois qu'elle l'aura fait, le message n'apparaîtra plus :




Nous verrons d'ailleurs (après sa première connexion), la dernière ouverture de session et le pourcentage de l'espace utilisé (mais rien pour le moment) :



En faisant défiler l'écran encore plus vers le haut, nous pouvons observer (plus bas) les paramètres de quota, et de rétention pour les éléments supprimés. Par défaut, les valeurs configurées pour la base de données sont utilisées mais nous pouvons les changer pour une BAL particulière :



  • Les "informations sur le contact" et "organisation" contiennent divers champs qu'on peut renseigner : Ville, Titre, Service, etc..
  • "membre de" affiche les groupes de distribution dont l'utilisateur est membre.
  • "info courrier" permet d'afficher un message à ceux qui envoient un message à cet utilisateur.
  • "délégation de boîte aux lettres" c'est ici que nous pouvons assigner un délégué à la boîte aux lettres : Accès complet, Envoyer en tant que et Envoyer pour le compte de. Rappel : dans ce dernier cas, il est indiqué que le délégué envoie le message au nom du propriétaire de la boîte.


La section "adresse de messagerie" montre l'adresse associée à la BAL :



Nous pouvons en ajouter d'autres comme, par exemple, celle d'un ancien salarié de l'organisation à qui des partenaires externes pourraient encore envoyer des messages que nous ne voudrions pas perdre. La personne à qui nous ajouterions cette seconde adresse serait chargé de s'en occuper.


Enfin, nous pouvons faire appliquer différentes "stratégies" comme une stratégie de rétention qui supprime les vieux messages ou les déplace vers une archive :  




***

Et maintenant, Karen Roberts va ouvrir une session sur un client Windows 7 (SP1) avec IE 11 (je le fais exprès : je suis curieux de voir comment Exchange 2016 va se comporter avec des clients plus anciens. Ce sera encore plus intéressant, me semble-t-il, avec Outlook 2010).

Elle met l'Url suivant :

https://mail.machlinkit.biz/owa




Elle saisit son nom et mot de passe, attend un moment et... OWA s'ouvre, lui donnant accès à une boîte aux lettres... complètement vide :




Elle va commencer une conversation avec Mark Patel, un autre utilisateur pour qui j'ai créé une BAL. A cette étape, je compose un message quelconque mais je vous épargne les captures d'écran, supposant que vous vous débrouillez assez bien en OWA / Outlook et que vous gagneriez bien peu à me voir présenter les étapes de la composition d'un courriel).

En résumé, Karen envoie le message à Mark. Mark arrive lui aussi à ouvrir une session OWA et répond à Karen. Tout se passe comme je m'y attendais.

Ensuite, j'essaie Outlook. Karen Roberts ouvre l'application et Autodiscover remplit automatiquement les cases :





Attention : digression !

Note: vous avez peut-être remarqué que j'ai fait cet essai (par curiosité) avec la version anglaise d'Outlook (le client Windows 7 est bien en version anglaise aussi). Le comportement est intéressant : Outlook est en version anglaise mais les éléments de la boîte à lettres en français (voir les captures d'écran plus bas). Nous sommes bel et bien en "mode cache" :


Fin de digression


Outlook s'ouvre alors. Nous voyons les messages envoyés et reçus avec OWA et nous pouvons en échanger d'autres avec Outlook :



***

En conclusion, l'accès client à une boîte aux lettres stockée sur notre serveur Exchange 2016 se fait sans peine. Nous créons la boîte à lettres, le client ouvre une session sur son poste de travail, et puis une session OWA ou Outlook. Autodiscover fonctionne parfaitement bien : les cases se remplissent automatiquement et les utilisateurs en interne peuvent s'envoyer des messages sans autre intervention. Cela est valable même pour un client plus ancien comme Windows 7 SP1 avec IE 11 et Outlook 2010. Il faut préciser que cette version d'Outlook (2010) doit fonctionner en mode "Outlook Anywhere" car Exchange 2016 n'accepte plus les connexions RPC. Cet ajustement semble se faire automatiquement aussi. En effet, je n'ai touché à aucun paramètre d'Outlook Anywhere, ni au serveur, ni au client. Tout compte fait, l'accès client se réalise de façon rapide et transparente.