Les différents accès au travers d’une connexion Web (Outlook Anywhere)

de l’entreprise. Contrairement à une connexion locale, la connexion avec le serveur Exchange ne peut pas être établie directement, mais cette connexion passe par une communication de type HTTPS. Il suffit donc de disposer sur son PC portable d’une connexion Internet.

En fait, la communication entre Outlook et le serveur Exchange est établie de manière cryptée en passant par un tunnel, c’est-à-dire une encapsulation au sein d’une communication HTTPS. L’avantage pour l’utilisateur est qu’il n’y a aucune modification ou manipulation à effectuer sur son poste car Outlook détecte automatiquement le mode de connexion en réseau local ou au travers d’une connexion HTTPS. Ce mode est connu sous le nom de RPC over HTTPS et il fonctionne avec Outlook 2003 et 2007 en connexion avec des serveurs Exchange 2003 SP1 et Exchange 2007. Pour cela il faut disposer d’une infrastructure sous Windows 2003 Server (AD, GC et serveurs Exchange). Côté client, la plateforme Windows XP SP2 (ou supérieur) sera requise, sinon il faudra vérifier que la version de la dll rpcrt4.dll est bien 5.1.2600.1142 ou supérieure. Avec Exchange 2007 et Outlook 2007, cette fonctionnalité a été largement améliorée et renommée au passage en Outlook Anywhere. Cette solution évite donc la mise en place de solutions de connexion à distance au réseau de l’entreprise, telles que des infrastructures VPN, pour permettre uniquement l’accès à distance à la messagerie Exchange.

Les contraintes pour la mise en place de cette solution sont plus importantes que la simple publication Web avec Outlook Web Access. Il faut en fait mettre en place un serveur Exchange qui doit assurer le rôle de Proxy pour la gestion des requêtes RPC over HTTPS. Cette fonction de proxy RPC over HTTP est mise en place au niveau des composants Windows sur le serveur qui assure la communication avec les clients Outlook. Cela signifie que ce composant doit être installé sur le serveur Exchange Front End (FE) dans une architecture Exchange 2003 et sur le serveur qui supporte le rôle CAS (Client Access Server) dans une architecture Exchange 2007. Une fois ce composant installé, il reste simplement à configurer le client Outlook et le serveur firewall reverse-proxy pour la publication de ces flux, car du côté serveur Exchange, le service IIS intègre automatiquement la publication RPC over HTTPS avec la mise en place d’un serveur virtuel nommé RPC. Il faut donc prévoir la publication de cette URL mail.msexchange.fr/RPC, mais aussi des autres répertoires tels que OAB, ou encore Autodiscover, ews dans le cas de serveurs Exchange 2007. Dans le cas d’une publication avec ISA Server 2006, un assistant simplifie la mise en place de cette configuration avec un serveur Exchange 2003, mais aussi pour les publications requises avec Exchange 2007. Avec Exchange 2003 la publication RPC over HTTPS impose une configuration manuelle du client Outlook, point qui a été amélioré avec Exchange 2007 avec la fonction Autodiscover comme cela sera abordé plus loin dans ce dossier.

L’utilisation du protocole HTTPS impose l’utilisation de certificats. Dans ce cadre, la problématique du choix du nom du domaine et de l’autorité de certification se pose de manière similaire à celle qui se pose lors de la publication OWA. Le nom de domaine reste inchangé, car seules des extensions de sous-répertoires sont utilisées avec RPC over HTTPS. Mais dans le cadre de l’utilisation d’une autorité de certification propre à l’entreprise, il faudra mettre en place le certificat racine sur le poste de travail afin que, lors de la phase d’authentification de l’utilisateur, le certificat exposé pour la connexion RPC over HTTPS soit validé par ce certificat racine. Le nom de domaine et la date du certificat doivent être valides. Les paramètres de configuration de la connexion RPC over HTTPS sur un client outlook 2003 sont définis dans les paramètres de connexion, paramètres supplémentaires puis l’onglet connexion et enfin en cliquant sur le bouton Paramètres Proxy Exchange.