Présentation de la transmission par proxy et de la redirection
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
Dans une organisation Microsoft Exchange Server 2010, un serveur d’accès au client peut agir comme proxy pour d’autres serveurs d’accès au client au sein de l’organisation. Cela peut s’avérer utile lorsque plusieurs serveurs d’accès au client sont présents dans différents sites Active Directory d’une organisation et que l’un de ces sites n’a pas accès à Internet.
Un serveur d’accès au client peut également opérer une redirection des adresses URL Microsoft Office Outlook Web App et des périphériques Exchange ActiveSync. La redirection est utile lorsqu’un utilisateur se connecte à un serveur d’accès au client situé hors de son site Active Directory local ou si une boîte aux lettres est déplacée entre des sites Active Directory. Elle est également utile si les utilisateurs doivent utiliser une URL plus efficace. Par exemple, les utilisateurs doivent utiliser une URL qui est plus proche du site Active Directory sur lequel résident leurs boîtes aux lettres.
La réponse du serveur d’accès au client peut varier en fonction du protocole. En règle générale cependant, un serveur d’accès au client entreprend l’action suivante s’il reçoit une demande pour un utilisateur dont la boîte aux lettres est située dans un site Active Directory autre que celui auquel appartient le serveur d’accès au client : Dans ce cas, le serveur recherche la présence d’une propriété ExternalURL sur le répertoire virtuel approprié sur un serveur d’accès au client situé dans le même site Active Directory que la boîte aux lettres de l’utilisateur. Si la propriété ExternalURL existe et que le type de client prend en charge la redirection (par exemple, Outlook Web App ou Exchange ActiveSync), le serveur d’accès au client met en place une redirection vers ce client. Si aucune propriété ExternalURL n’est présente ou si le type de client ne prend pas en charge la redirection (par exemple, POP3 ou IMAP4), le serveur d’accès au client tente de transmettre la connexion au site Active Directory cible par proxy.
Cette rubrique décrit la transmission par proxy et la redirection, les circonstances au cours desquelles ces fonctionnalités sont utilisées, ainsi que la configuration de vos serveurs d’accès au client pour chaque scénario.
.gif "Remarque") Remarque : |
|---|
| Si votre organisation ne dispose pas de plusieurs sites Active Directory, vous n’avez pas à configurer Exchange 2010 pour la transmission par proxy et la redirection. Vous pouvez toutefois configurer l’équilibrage de charge des URL, comme décrit plus loin dans cette rubrique. |
| Remarque : |
|---|
| Les serveurs d’accès au client qui ne sont pas connectés à Internet ne disposent pas de certificats SSL (Secure Sockets Layer) séparés pour autoriser le trafic transmis par proxy à partir d’un autre serveur d’accès au client. Par défaut, ils peuvent utiliser le certificat auto-signé installé avec Exchange 2010. Toutefois, ces certificats ne sont généralement pas approuvés par les clients internes, tels que Outlook Web App ou Outlook, et provoquent des avertissements de certificats. S’il existe des clients internes dans les mêmes sites Active Directory que les serveurs d’accès au client avec des certificats auto-signés, vous devez remplacer ces derniers par des certificats émis par une autorité de certification approuvée par les clients. |
Contenu de cette rubrique
Vue d’ensemble de la transmission par proxy
Vue d’ensemble de la redirection
Transmission par proxy avec équilibrage de la charge réseau
Résumé des méthodes d’accès au client
Performances et évolutivité de la transmission par proxy
Vue d’ensemble de la transmission par proxy
Dans Microsoft Exchange Server 2003, le serveur frontal communique avec le serveur principal sur HTTP. Dans Exchange Server 2007 et Exchange 2010, le serveur d’accès au client communique avec un serveur de boîtes aux lettres Exchange sur RPC. Vous devez disposer d’un serveur d’accès au client Exchange 2010 dans chaque site Active Directory contenant un serveur de boîtes aux lettres Exchange 2010. La transmission par proxy intervient quand un serveur d’accès au client envoie du trafic vers un autre serveur d’accès au client. Un serveur d’accès au client Exchange 2010 peut transmettre des demandes par proxy dans les situations suivantes :
Entre serveurs d’accès au client Exchange 2010 La transmission par proxy des demandes entre deux serveurs d’accès au client Exchange 2010 permet aux organisations disposant de plusieurs sites Active Directory de désigner un serveur d’accès au client comme serveur côté Internet, et de faire en sorte que ce serveur transmette par proxy les demandes adressées à des serveurs d’accès au client dans des sites n’ayant pas de présence Internet. Le serveur d’accès au client côté Internet transmet ensuite par proxy la demande adressée au serveur d’accès au client le plus proche de la boîte aux lettres de l’utilisateur.
Entre un serveur d’accès au client Exchange 2010 et des serveurs d’accès au client Exchange 2007 La transmission des demandes par proxy entre un serveur d’accès au client Exchange 2010 et un serveur d’accès au client Exchange 2007 avec un site Active Directory ou entre des sites Active Directory permet à Exchange 2010 et à Exchange 2007 de coexister dans la même organisation. Pour plus d’informations sur la mise à niveau et la coexistence, voir Mettre à niveau à partir d'un accès au client Exchange 2003 et Mettre à niveau à partir d'un accès au client Exchange 2007.
La transmission par proxy est prise en charge pour les clients qui utilisent Outlook Web App, Exchange ActiveSync, le Panneau de configuration Exchange (ECP), POP3, IMAP4 et les services Web Exchange. La transmission par proxy est prise en charge entre deux serveurs d’accès au client lorsque le serveur d’accès au client de destination exécute une version de Microsoft Exchange équivalente ou antérieure à celle du serveur d’accès au client source, sauf pour les instances dans lesquelles une URL propre à la version est requise. Pour plus d’informations sur les URL propres à une version et les noms d’hôte hérités dans un environnement mixte Exchange 2007/Exchange 2010, voir Mettre à niveau à partir d'un accès au client Exchange 2007. Pour plus d’informations sur les URL propres à une version et les noms d’hôte hérités dans un environnement mixte Exchange 2010/Exchange 2013, voir Créer un nom d’hôte Exchange hérité.
.gif "Avertissement") Avertissement : |
|---|
| Lorsqu’un client IMAP4 utilisant l’authentification NTLM tente de se connecter à un serveur d’accès au client sur un site Active Directory ne contenant pas la boîte aux lettres cible, la connexion échoue. Pour qu’un client IMAP4 client soit acheminé par proxy d’un site Active Directory vers un autre, vous devez choisir une autre méthode d’authentification. |
| Remarque : |
|---|
| L’organisation Exchange souhaitant autoriser l’accès à partir de clients basés sur Internet doit disposer d’au moins un site Active Directory exposé à Internet. Tous les sites Active Directory non reliés à Internet reposent sur le ou les serveurs d’accès au client pour transmettre par proxy toutes les demandes pertinentes en provenance des clients externes. |
Transmission par proxy de l’accès au client
Dans la figure précédente, la boîte aux lettres de l’utilisateur 1 se trouve sur le serveur de boîtes aux lettres 1. La boîte aux lettres de l’utilisateur 2 se trouve sur le serveur de boîtes aux lettres 2, et la boîte aux lettres de l’utilisateur 3 se trouve sur le serveur de boîtes aux lettres 3. Chaque serveur de boîtes aux lettres se situe sur un site Active Directory différent. L’utilisateur 1 peut accéder à sa boîte aux lettres via le serveur d’accès au client 1 sans utiliser la transmission par proxy, et l’utilisateur 2 peut accéder à sa boîte aux lettres via le serveur d’accès au client 2. Si l’utilisateur 3 essaye d’accéder à sa boîte aux lettres via le serveur d’accès au client 1 ou 2, l’un de ces serveurs va transmettre la demande par proxy au serveur d’accès au client 3. Le serveur d’accès au client 3 n’est pas relié à Internet mais peut recevoir des demandes en provenance des autres serveurs, sous la protection du pare-feu. La transmission par proxy n’est pas visible pour l’utilisateur.
| Remarque : |
|---|
| Les communications entre les serveurs d’accès au client des différents sites s’effectuent par HTTPS (Secure HTTP), mais les serveurs d’accès au client ne vérifient pas l’état du certificat utilisé par défaut. Le certificat est employé uniquement pour le chiffrement, pas pour l’authentification. Par conséquent, les différences entre les noms, les dates d’expiration et l’état de confiance ne sont pas pris en compte. |
Vue d’ensemble de la transmission par proxy
Vue d’ensemble de la redirection
Les utilisateurs d’Outlook Web App qui accèdent à un serveur d’accès au client connecté à Internet se trouvant dans un autre site Active Directory que celui contenant leur boîte aux lettres peuvent être redirigés vers le serveur d’accès au client se trouvant dans le même site que leur serveur de boîtes aux lettres si ce serveur d’accès au client est connecté à Internet. Quand un utilisateur d’Outlook Web App tente de se connecter à un serveur d’accès au client situé en dehors du site Active Directory contenant son serveur de boîtes aux lettres, il voit s’afficher une page Web contenant un lien vers le serveur d’accès au client correct pour sa boîte aux lettres. C’est ce que l’on appelle la redirection manuelle. Dans Exchange 2010 SP2, les administrateurs peuvent configurer une redirection silencieuse intersite afin que ce processus de redirection ait lieu à l’insu de l’utilisateur. Pour plus d’informations, consultez la section Redirection silencieuse intersite plus loin dans cette rubrique.
| Remarque : |
|---|
| Vous ne pouvez pas utiliser une redirection silencieuse intersite dans un environnement hybride qui utilise un serveur Exchange Server local et Office 365. |
Les utilisateurs d’Exchange ActiveSync qui accèdent à un serveur d’accès au client relié à Internet hors du site Active Directory contenant leur boîte aux lettres peuvent être redirigés vers le serveur d’accès au client situé sur le même site que leur serveur de boîtes aux lettres si ce serveur d’accès au client est relié à Internet et si le téléphone mobile ou le périphérique client a correctement mis en place la logique de redirection intégrée au protocole utilisé pour communiquer avec Exchange 2007 et Exchange 2010. La redirection des utilisateurs d’Exchange ActiveSync s’effectue via l’envoi au périphérique d’un code d’erreur HTTP 451 contenant la nouvelle URL à utiliser. Le périphérique se reconfigure alors pour utiliser la nouvelle URL.
La figure suivante illustre le fonctionnement de la redirection au sein d’une organisation disposant de plusieurs serveurs d’accès au client dans plusieurs sites Active Directory.
Redirection pour Exchange ActiveSync et Outlook Web App dans Exchange 2010
Dans la figure précédente, l’utilisateur 1 accède généralement à sa boîte aux lettres dans le site 1 Active Directory à l’aide de son téléphone mobile. L’administrateur déplace alors sa boîte aux lettres vers le serveur de boîtes aux lettres 2 dans le site 2 Active Directory. Ainsi, lorsque le périphérique effectue une nouvelle synchronisation, le serveur répond par une erreur d’état HTTP 451. Cet onglet contient l’URL que le périphérique doit désormais utiliser pour cet utilisateur. À l’étape 3 de la séquence, le périphérique se reconfigure et se connecte à l’URL spécifiée. L’utilisateur 2, dont la boîte aux lettres se situe sur le site 2 Active Directory, essaye d’ouvrir sa boîte aux lettres à l’aide d’Outlook Web App en se connectant au serveur d’accès au client 1 sur Internet. Dans une redirection manuelle, dès que l’utilisateur s’authentifie, le serveur d’accès au client 1 présente à l’utilisateur une page contenant un lien vers l’URL Outlook Web App du serveur d’accès au client du site Active Directory 2. L’utilisateur clique sur ce lien, est renvoyé vers le site Active Directory 2 et se reconnecte pour accéder à sa boîte aux lettres. Dans une redirection silencieuse, lorsque l’utilisateur s’authentifie, il est redirigé en silence vers l’URL Outlook Web App du serveur d’accès au client du site Active Directory 2.
Redirection silencieuse intersite
| Remarque : |
|---|
| Vous ne pouvez pas utiliser une redirection silencieuse intersite dans un environnement hybride qui utilise un serveur Exchange Server local et Office 365. |
Exchange 2010 SP2 permet aux administrateurs de configurer la redirection silencieuse intersite. Ce type de redirection consiste en une redirection silencieuse des demandes de clients qui sont destinées à un CAS situé sur un site Active Directory différent de la même organisation Exchange. Par exemple, un utilisateur dont la boîte aux lettres est située sur le site Active Directory A et qui accède à l’URL Outlook Web App du site Active Directory B sera redirigé en silence vers l’URL Outlook Web App du site Active Directory A.
Pour configurer la redirection silencieuse intersite, l’administrateur doit utiliser le nouveau paramètre CrossSiteRedirectType qui a été ajouté à la cmdlet Set-OWAVirtualDirectory. Le paramètre comporte deux valeurs possibles. Le paramètre par défaut est Manual.
Silencieux Lorsque ce paramètre est configuré, le navigateur Web d’un utilisateur est redirigé automatiquement chaque fois qu’un serveur d’accès au client doit rediriger une demande Outlook Web App vers le serveur ou la matrice de serveurs d’accès au client située sur un autre site Active Directory. Lorsque l’authentification basée sur les formulaires est configurée sur les répertoires virtuels OWA du CAS source et cible (SSL est requis), la redirection silencieuse est également un événement d’authentification unique. Pour que la redirection ait lieu, la valeur
ExternalURLdoit être configurée pour le répertoire virtuel d’Outlook Web App du serveur d’accès au client.Manuel Si ce paramètre est configuré, les utilisateurs reçoivent une notification indiquant qu’ils accèdent à l’URL incorrecte et qu’ils doivent cliquer sur un lien pour accéder à la bonne URL Outlook Web App correspondant à leur boîte aux lettres. Cette notification est uniquement activée lorsqu’un serveur d’accès au client détermine qu’il doit rediriger une demande Outlook Web App vers le serveur ou la matrice de serveurs d’accès au client sur un autre site Active Directory. Pour que la redirection ait lieu, la valeur
ExternalURLdoit être configurée pour le répertoire virtuel d’Outlook Web App du serveur d’accès au client.
Par exemple :
Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent
Pour plus d’informations sur la cmdlet Set-OwaVirtualDirectory, consultez la rubrique suivante : Set-OwaVirtualDirectory
Transmission par proxy et redirection pour Exchange ActiveSync
Le scénario suivant illustre la manière dont les demandes entrantes sont gérées pour un utilisateur qui se connecte à un serveur d’accès au client Exchange 2010 nommé CAS-01 à l’aide d’un téléphone mobile.
Le serveur d’accès au client interroge Active Directory pour déterminer l’emplacement de la boîte aux lettres de l’utilisateur et la version de Microsoft Exchange installée sur le serveur de boîtes aux lettres.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur Exchange 2003, la demande entrante est transmise directement par proxy vers le serveur Exchange 2003 hébergeant la boîte aux lettres de l’utilisateur et le répertoire virtuel Exchange ActiveSync. Par défaut, dans Exchange 2003, le répertoire virtuel Exchange ActiveSync à été installé sur tous les serveurs de boîtes aux lettres. Le site Active Directory de la boîte aux lettres de l’utilisateur ne s’applique pas dans ce cas car Exchange 2003 n’utilise pas les sites Active Directory pour déterminer l’emplacement. La connexion est toujours établie à partir du serveur d’accès au client Exchange 2010 vers le serveur de boîtes aux lettres Exchange 2003.
Remarque :Des utilisateurs disposant de boîtes aux lettres sur un serveur Exchange 2003, qui tentent d’utiliser Exchange ActiveSync via un serveur d’accès au client Exchange 2010 voient s’afficher un message d’erreur et ne peuvent pas opérer de synchronisation à moins que l’authentification Windows intégrée ne soit activée pour le répertoire virtuel Microsoft-Server-ActiveSync sur le serveur Exchange 2003. L’authentification intégrée Windows permet au serveur d’accès au client Exchange 2010 et au serveur principal Exchange 2003 de communiquer. Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2007, CAS-01 localise un serveur d’accès au client Exchange 2007 situé sur le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur. Il peut s’agir du même site Active Directory que CAS-01. CAS-01 envoie par proxy la demande Exchange ActiveSync à l’InternalURL du serveur Client Access Exchange 2007, quels que soient les paramètres ExternalURL. La demande est envoyée au répertoire virtuel /Proxy situé dans le répertoire virtuel Exchange ActiveSync Microsoft Server dans IIS, et, par défaut, comporte l’authentification Windows intégrée.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans le même site Active Directory que CAS-01, CAS-01 fournit l’accès à la boîte aux lettres. Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans un site Active Directory différent, CAS-01 localise un serveur d’accès au client situé sur le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur. CAS-01 détermine si un serveur d’accès au client Exchange 2010 de ce site Active Directory présente la propriété ExternalURL configurée correctement dans le répertoire virtuel Exchange ActiveSync. Si c’est le cas, CAS-01 envoie au client le code d’erreur HTTP 451 qui contient la valeur de la propriété ExternalURL, puis indique au client de procéder à une redirection vers cet emplacement. Si aucune valeur ExternalURL n’est définie, la connexion sera transmise par proxy au serveur d’accès client à l’aide du nom de domaine complet (FQDN) spécifié par la propriété InternalURL, plus précisément vers le répertoire virtuel /Proxy. Ce répertoire virtuel se situe sous le répertoire virtuel Exchange ActiveSync dans IIS ; l’authentification Windows intégrée est activée par défaut pour ce répertoire.
.gif "Important")
Important :La transmission par proxy n’est pas possible entre des répertoires virtuels utilisant une authentification de base. Pour que les communications de client soit transmises par proxy entre des répertoires virtuels Exchange ActiveSync sur des serveurs différents, le répertoire virtuel /Proxy doit utiliser l’authentification Windows intégrée.
Vue d’ensemble de la transmission par proxy
Transmission par proxy et redirection pour Outlook Web App
Le scénario suivant illustre la manière dont les demandes entrantes sont gérées pour un utilisateur qui se connecte à un serveur d’accès au client Exchange 2010 nommé CAS-01 à l’aide d’Outlook Web App.
Le serveur d’accès au client interroge Active Directory pour déterminer l’emplacement de la boîte aux lettres de l’utilisateur et la version de Microsoft Exchange installée sur le serveur de boîtes aux lettres.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur Exchange 2003 et que l’utilisateur essaye d’accéder à Outlook Web App avec l’adresse https://domain name/owa, il reçoit un message d’erreur. En effet, le serveur d’accès au client Exchange 2010 n’est pas en mesure de fournir à Outlook Web App un accès direct à une boîte à lettres Exchange 2003. Toutefois, si l’administrateur a configuré la redirection à partir d’Exchange 2010 vers Exchange 2003, une opération habituellement réalisée lors des migrations de Exchange 2003 vers Exchange 2010, la propriété Exchange2003URL du répertoire virtuel Outlook Web App a été définie sur la valeur d’un serveur Exchange 2003 ayant accès à Internet.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2007, CAS-01 localise un serveur d’accès au client situé dans le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur. Si le serveur de boîtes aux lettres Exchange 2007 se trouve dans le même site Active Directory que CAS-01, quatre cas de figure sont possibles.
CAS-01 recherche une propriété Exchange 2007 ExternalURL dont le paramètre ExternalAuthenticationMethods est identique au paramètre InternalAuthenticationMethods sur le serveur d’accès au client Exchange 2010. Si les paramètres correspondent, CAS-01 effectue une redirection vers cette URL externe. Si l’authentification basée sur les formulaires est activée pour les CAS source et cible, le CAS source publie de nouveau un formulaire masqué dans le navigateur qui contient les informations d’identification de l’utilisateur et les paramètres FBA, ainsi que l’URL de redirection. Ce processus est transparent pour l’utilisateur.
Si aucun paramètre ExternalURL coïncidant n’est trouvé, CAS-01 recherche un serveur d’accès au client Exchange 2007 dont la propriété ExternalURL est correctement configurée, sans tenir compte de la correspondance. S’il en trouve un, CAS-01 effectue une redirection vers cette URL externe. L’utilisateur est alors invité à s’authentifier.
Si aucun paramètre ExternalURL correspondant n’est trouvé, CAS-01 recherche un serveur d’accès au client Exchange 2007 dont la propriété InternalURL présente un paramètre InternalAuthenticationMethods identique au paramètre InternalAuthenticationMethods sur le serveur d’accès au client Exchange 2010. S’il en trouve un, CAS 01 effectue une redirection vers cette URL interne. Si l’authentification basée sur les formulaires est active, la redirection réalisée est de type connexion unique.
Si aucun paramètre InternalURL coïncidant n’est trouvé, CAS-01 recherche un serveur d’accès au client Exchange 2007 dont le paramètre InternalURL serait configuré, sans tenir compte des correspondances. S’il en trouve un, CAS 01 effectue une redirection vers cette URL interne. L’utilisateur est alors invité à s’authentifier.
Si le serveur de boîtes aux lettres Exchange 2007 se situe sur un autre site Active Directory, CAS-01 vérifie si la propriété ExternalURL est définie sur ce site Active Directory. Si tel est le cas et que la redirection silencieuse intersite n’est pas activée, la valeur CrossSiteRedirectType est définie sur Manuel et une redirection manuelle se produit. Dans ce scénario, l’utilisateur peut alors cliquer sur un lien qui le redirige vers l’URL spécifiée.
Si la redirection silencieuse intersite a été activée, la valeur CrossSiteRedirectType est définie sur Silencieux et l’utilisateur est redirigé automatiquement vers l’URL spécifiée. Si la propriété ExternalURL n’est pas présente et que la méthode d’authentification du répertoire virtuel /OWA est définie sur Authentification Windows intégrée, CAS-01 transmet par proxy la demande de l’utilisateur au serveur d’accès au client spécifié dans la propriété InternalURL.
Important :Pour permettre à un serveur d’accès au client Exchange 2010 de transmettre par proxy des demandes Outlook Web App à un serveur d’accès au client Exchange 2007 situé sur un autre site Active Directory, vous devez copier le dossier présentant la version la plus élevée d’un serveur d’accès au client Exchange 2007 dans le site de destination Active Directory à partir du dossier %installpath%\ClientAccess\OWA\ vers le même chemin d’accès sur le serveur d’accès au client Exchange 2010 qui effectue la demande par proxy. Important :Un serveur d’accès au client Exchange 2010 ne transmettra jamais par proxy des demandes Outlook Web App à un serveur d’accès au client Exchange 2007 sur le même site Active Directory. Toutes les demandes au sein du même site Active Directory sont redirigées vers un serveur d’accès au client Exchange 2007, à l’aide de la propriété InternalURL ou ExternalURL du serveur d’accès au client (en fonction des propriétés configurées). Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans le même site Active Directory que CAS-01, CAS-01 fournit l’accès à la boîte aux lettres. Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans un site Active Directory différent, CAS-01 localise un serveur d’accès au client situé sur le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur. Lorsqu’il en trouve un, Exchange 2010 vérifie si la propriété ExternalURL est définie pour le serveur d’accès au client situé sur ce site Active Directory. Si tel est le cas et que la redirection silencieuse intersite n’a pas été activée, l’utilisateur reçoit un message contenant un lien sur lequel il peut cliquer afin d’être redirigé vers l’URL spécifiée. Si la redirection silencieuse intersite a été activée, l’utilisateur sera redirigé automatiquement vers l’URL spécifiée. Si le paramètre ExternalURL n’est pas défini et que la méthode d’authentification du répertoire virtuel est définie sur Authentification Windows intégrée, CAS-01 transmet par proxy la demande de l’utilisateur au serveur d’accès au client spécifié dans la propriété InternalURL.
Transmission par proxy pour le Panneau de configuration Exchange
Exchange 2010 fournit une interface Web aux utilisateurs et aux administrateurs de l’organisation permettant de configurer les paramètres des boîtes aux lettres ou de l’organisation. Vous accédez au Panneau de configuration Exchange (ECP) via le menu Options dans Outlook Web App ou, dans Outlook 2010, lorsque vous sélectionnez les options de messagerie vocale, que vous demandez des informations de suivi des messages ou que vous configurez les notifications pour dispositifs mobiles. Sélectionnez l’une de ces options dans Outlook pour ouvrir une session dans votre navigateur Web.
La destination de la session dépend de l’état en cours de la connexion au client Outlook. Si le client Outlook est connecté via RPC sur TCP, le client se connecte à la valeur InternalURL du répertoire virtuel ECP. Si le client est connecté à l’aide d’Outlook Anywhere, le client Outlook démarre une session dans un navigateur Web. La session de navigateur essaiera d’établir une connexion avec la valeur ExternalURL du répertoire virtuel ECP. Les URL sont fournies au client Outlook via le service de découverte automatique.
Lorsqu’un client interne est connecté via TCP, la session ECP essaye toujours de se connecter à un serveur d’accès au client situé sur le même site Active Directory que la boîte aux lettres de l’utilisateur. La transmission par proxy n’est pas utilisée dans ce scénario. Lorsqu’un client situé hors du réseau d’entreprise utilise Outlook Anywhere pour établir une connexion, il ouvre une session de navigateur en utilisant l’URL externe du répertoire virtuel ECP ou l’URL externe d’un site Active Directory connecté à Internet si la boîte aux lettres de l’utilisateur se trouve sur un site non relié à Internet.
La logique de mise en proxy pour l’ECP est identique à celle d’Outlook Web App. Si la boîte aux lettres de l’utilisateur se situe sur un serveur de boîtes aux lettres Exchange 2010 dans le même site Active Directory que le serveur d’accès au client qui reçoit la demande, ce serveur fournit l’accès à la boîte aux lettres. Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans un site Active Directory différent, le serveur d’accès au client localise un serveur d’accès au client situé sur le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur. Le serveur d’accès au client d’origine transmet par proxy la demande de l’utilisateur vers ce serveur d’accès au client.
L’ECP est capable de réaliser une redirection, mais il s’en charge rarement, sauf si l’utilisateur saisit explicitement l’URL d’accès à l’ECP. Si un utilisateur accède à l’ECP à partir d’Outlook Web App, Outlook Web App doit s’assurer que l’utilisateur se sert l’URL correcte. Si l’utilisateur utilise Outlook 2010, Outlook et le service de découverte automatique doivent s’assurer que l’utilisateur emploie l’URL correcte pour l’ECP
Vue d’ensemble de la transmission par proxy
Transmission par proxy pour les services Web Exchange
Les services Web Exchange fournissent une interface de messagerie XML qui vous permet de gérer les éléments de la banque d’informations Exchange et d’accéder à la fonctionnalité du serveur Exchange à partir d’applications clientes. Sous une perspective client, de transmission par proxy et de redirection, cette fonctionnalité est généralement utilisée dans les contextes suivants :
Demandes de service de disponibilité
Demandes de découverte automatique
Définition et vérification de l’état des réponses automatiques (OOF)
Une application écrite à l’aide des services Web Exchange peut utiliser la transmission par proxy pour la mise en place de réponses automatiques (absence du bureau), lesquelles seront transmises par proxy entre les sites Active Directory, au besoin.
Les étapes suivantes présentent la façon dont les demandes entrantes sont traitées pour un utilisateur réalisant une demande de service de disponibilité à un serveur d’accès au client Exchange 2010 appelé CAS-01. L’utilisateur emploie Outlook Web App pour vérifier la disponibilité d’un autre utilisateur dans la même organisation Exchange.
CAS-01 interroge Active Directory pour déterminer l’emplacement de la boîte aux lettres de l’utilisateur et la version de Microsoft Exchange installée sur le serveur de boîtes aux lettres.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur Exchange 2003, Outlook Web App établit une connexion HTTP au répertoire virtuel /Public du serveur Exchange 2003 et récupère les informations demandées dans le dossier système Disponible/Occupé.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2007, une erreur est renvoyée à l’utilisateur. Dans toute organisation Exchange qui contient des boîtes aux lettres sur un serveur de boîtes aux lettres Exchange 2007, un serveur d’accès au client Exchange 2007 doit être accessible en externe. Le service de découverte automatique est chargé de renvoyer l’URL des services Web Exchange correcte au client. Cette URL doit correspondre à la version du serveur de boîtes aux lettres sur lequel se trouve la boîte aux lettres de l’utilisateur.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans le même site Active Directory que CAS-01, CAS-01 accède à la boîte aux lettres pour récupérer les informations demandées. Si la boîte aux lettres de l’utilisateur se situe sur un serveur de boîtes aux lettres Exchange 2010 dans un site Active Directory différent, CAS-01 communique par proxy avec un serveur d’accès au client dans ce site Active Directory à l’aide du nom de domaine complet (FQDN) spécifié par la propriété InternalURL du répertoire virtuel /EWS.
Important :Un serveur d’accès au client Exchange transmettra par proxy les demandes au service de disponibilité d’un serveur à un autre, que la propriété ExternalURL soit définie ou pas. Important :Certaines applications basées sur les services Web Exchange emploient des méthodes Web, telles que GetEvents et Unsubscribe, lesquelles présentent une forte affinité avec le serveur d’accès au client. Lorsqu’un serveur d’accès au client doit transmettre par proxy l’une de ces demandes à un autre site Active Directory, il peut utiliser la propriété InternalNLBBypassURL du serveur d’accès au client, qui doit toujours être définie sur le FQDN (nom complet du domaine) du serveur de l’hôte. Le serveur d’accès au client effectuant la demande est ainsi en mesure de conserver l’affinité avec un serveur d’accès au client spécifique dans le site Active Directory cible.
Les services Web Exchange ne fournissent pas directement de fonctionnalité de redirection. En effet, le serveur de découverte automatique, utilisé pour fournir des URL à une application, fournit les URL nécessaires pour accéder à une boîte aux lettres spécifique. Par exemple, lorsqu’une boîte aux lettres est déplacée entre des sites Active Directory, Outlook reçoit les URL spécifiques au site Active Directory en provenance du service de découverte automatique lors de l’émission de demande suivante. Cela peut parfois amener un client à effectuer des demandes de service de disponibilité à un serveur d’accès au client dans un site Active Directory différente de celui contenant sa boîte aux lettres. Mais comme le service de disponibilité continuera de traiter les demandes de les transmettre par proxy, au besoin, l’utilisateur ne subit aucune conséquence.
| Important : |
|---|
| Dans toute organisation Exchange qui contient des boîtes aux lettres sur un serveur de boîtes aux lettres Exchange 2007, un serveur d’accès au client Exchange 2007 doit être accessible en externe. Lorsque le service de découverte automatique renvoie l’URL des services Web Exchange correcte à un client demandeur, cette URL correspond à la version du serveur contenant la boîte aux lettres de l’utilisateur. Pour toute organisation Exchange qui contient des boîtes aux lettres à la fois sur des serveurs de boîtes aux lettres Exchange 2007 et Exchange 2010, deux URL externes doivent être configurées pour les services Web Exchange, chacune étant destinée à chaque version installée de Exchange. |
Transmission par proxy pour POP3 et IMAP4
Exchange 2010 peut transmettre par proxy des sessions POP3 et IMAP4 entre des serveurs d’accès au client et des sites Active Directory.
Le scénario suivant illustre la manière dont les demandes entrantes sont gérées pour un utilisateur qui effectue une demande à un serveur d’accès au client Exchange 2010 nommé CAS-01 à l’aide d’un client POP3.
CAS-01 interroge Active Directory pour déterminer l’emplacement de la boîte aux lettres de l’utilisateur et la version de Microsoft Exchange installée sur le serveur de boîtes aux lettres.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur Exchange 2003, CAS-01 transmet par proxy la connexion au service POP3 en cours d’exécution sur le serveur Exchange 2003 hébergeant la boîte aux lettres de l’utilisateur.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2007, CAS-01 localise un serveur d’accès au client Exchange 2007 dans le même site Active Directory que le serveur de boîtes aux lettres de l’utilisateur, qui peut être identique au site Active Directory de CAS-01. CAS-01 transmet par proxy la demande au serveur d’accès au client.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010 dans le même site Active Directory que CAS-01, CAS-01 accède lui-même à la boîte aux lettres. Si la boîte aux lettres de l’utilisateur se situe sur un serveur de boîtes aux lettres Exchange 2010 dans un site Active Directory différent, CAS-01 communique par proxy avec un serveur d’accès au client dans ce site à l’aide du nom de domaine complet (FQDN) spécifié par la propriété InternalConnectionSettings de la configuration POP de ce serveur.
Important :Il n’existe pas de paramètres InternalURL ou ExternalURL pour les services POP3 ou IMAP4, et un serveur d’accès au client Exchange 2010 transmettra par proxy les demandes de service POP3 et IMAP4 d’un serveur à un autre, dès que nécessaire. Important :Les serveurs d’accès au client essayant de transmettre par proxy à un autre site Active Directory ne vérifient pas si le service POP3 ou IMAP4 est en cours d’exécution sur le serveur d’accès au client distant. Il est donc important de vérifier que les services sont en cours d’exécution sur chaque serveur d’accès au client dans le site Active Directory distant, mais aussi de songer à utiliser un outil d’équilibrage de charge pour le service. Le sujet des équilibrages de charge est abordé plus loin dans cette rubrique.
Vue d’ensemble de la transmission par proxy
Configuration de la transmission par proxy
Si votre serveur d’accès au client est connecté à Internet, définissez la propriété ExternalURL sur les répertoires virtuels /Microsoft-Server-ActiveSync, /OWA, /ECP et /EWS à l’aide de la console de gestion Exchange (EMC) ou de l’environnement de ligne de commande Exchange Management Shell. Le répertoire virtuel EWS peut uniquement être configuré à l’aide de l’environnement Shell. La propriété InternalURL est définie automatiquement au cours de la configuration initiale d’Exchange 2010. Modifiez-la uniquement si vous souhaitez utiliser une solution d’équilibrage de charge. La propriété ExternalURL doit contenir le nom de domaine complet (FQDN) enregistré pour votre organisation Exchange dans le DNS.
Le tableau suivant comprend les valeurs appropriées des propriétés ExternalURL et InternalURL d’un serveur d’accès au client relié à Internet pour une organisation Exchange accédant à Outlook Web App à l’aide de l’URL https://mail.contoso.com. Le deuxième tableau contient les valeurs appropriées des propriétés ExternalURL et InternalURL d’un serveur d’accès au client non connecté à Internet, situé dans un autre site Active Directory de la même organisation. Assurez-vous que la méthode d’authentification de tous ces répertoires virtuels est définie sur Authentification Windows intégrée. La transmission par proxy n’est pas prise en charge pour les répertoires virtuels utilisant d’autres méthodes d’authentification, à l’exception de POP3 et IMAP4, qui utilisent SSL/TLS et transmettent par proxy les informations d’identification pour l’authentification de base de l’utilisateur.
| Remarque : |
|---|
| En cas de création de répertoires virtuels Outlook Web App à l’aide de l’environnement Shell, vous devez configurer manuellement la propriété InternalURL de ces répertoires virtuels. |
Paramètres InternalURL et ExternalURL pour un serveur d’accès au client côté Internet
| Service Exchange 2010 | Paramètre InternalURL | Paramètre ExternalURL |
|---|---|---|
Outlook Web App |
https://nomordinateurcomplet/OWA |
https://mail.contoso.com/OWA |
Exchange ActiveSync |
https://nomordinateurcomplet/Microsoft-Server-ActiveSync |
https://mail.contoso.com/Microsoft-Server-ActiveSync |
Services Web Exchange |
https://nomordinateurcomplet/EWS/Exchange.asmx |
https://mail.contoso.com/EWS/Exchange.asmx |
Panneau de configuration Exchange |
https://nomordinateurcomplet/ECP |
https://mail.contoso.com/ECP |
Paramètres InternalURL et ExternalURL pour un serveur d’accès au client non connecté à Internet
| Service Exchange 2010 | Paramètre InternalURL | Paramètre ExternalURL |
|---|---|---|
Outlook Web App |
https://nomordinateurcomplet/OWA |
|
Exchange ActiveSync |
https://nomordinateurcomplet/Microsoft-Server-ActiveSync |
|
Services web Exchange |
https://nomordinateurcomplet/EWS/Exchange.asmx |
|
Panneau de configuration Exchange |
https://nomordinateurcomplet/ECP |
|
Configuration de la redirection
Si plusieurs de vos sites Active Directory sont connectés à Internet, définissez la propriété ExternalURL sur les répertoires virtuels /OWA et /Microsoft-Server-ActiveSync à l’aide la console EMC ou de l’environnement Shell pour activer la redirection entre eux. La propriété InternalURL est définie automatiquement au cours de la configuration initiale d’Exchange 2010. Modifiez-la uniquement si vous souhaitez utiliser une solution d’équilibrage de charge. Les deux tableaux suivants répertorient les paramètres ExternalURL et InternalURL pour les serveurs d’accès au client dans deux sites Active Directory d’une société appelée Contoso. Les deux sites sont usa.contoso.com et europe.contoso.com.
| Remarque : |
|---|
| En cas de création de répertoires virtuels Outlook Web App à l’aide de l’environnement Shell, vous devez configurer manuellement la propriété InternalURL de ces répertoires virtuels. |
Paramètres des propriétés InternalURL et ExternalURL pour un serveur d’accès au client côté Internet dans le site usa.contoso.com
| Service Exchange 2010 | Paramètre InternalURL | Paramètre ExternalURL |
|---|---|---|
Outlook Web App |
https://nomcompletordinateur/OWA |
https://usa.contoso.com/OWA |
Panneau de configuration Exchange |
https://nomcompletordinateur/ECP |
https://usa.contoso.com/ECP |
Exchange ActiveSync |
https://nomcompletordinateur/Microsoft-Server-ActiveSync |
https://usa.contoso.com/ Microsoft-Server-ActiveSync |
Services web Exchange |
https://nomcompletordinateur/EWS/Exchange.asmx |
https://usa.contoso.com/EWS/Exchange.asmx |
Paramètres des propriétés InternalURL et ExternalURL pour un serveur d’accès au client côté Internet dans le site europe.contoso.com
| Service Exchange 2010 | Paramètre InternalURL | Paramètre ExternalURL |
|---|---|---|
Outlook Web App |
https://nomcompletordinateur/OWA |
https://europe.contoso.com/OWA |
Panneau de configuration Exchange |
https://nomcompletordinateur/ECP |
https://europe.contoso.com/ECP |
Exchange ActiveSync |
https://nomcompletordinateur/Microsoft-Server-ActiveSync |
https://europe.contoso.com/Microsoft-Server-ActiveSync |
Services web Exchange |
https://nomcompletordinateur/EWS/Exchange.asmx |
https://europe.contoso.com/EWS/Exchange.asmx |
| Remarque : |
|---|
| Si la propriété ExternalURL n’est pas définie sur le répertoire virtuel Exchange ActiveSync d’au moins un site Active Directory, le service de découverte automatique ne réussira pas à configurer ces téléphones mobiles car la valeur définie pour la propriété ExternalURL est transmise aux téléphones mobiles durant le processus de découverte automatique. |
Vue d’ensemble de la transmission par proxy
Transmission par proxy avec équilibrage de la charge réseau
Dans une organisation comptant plusieurs sites Active Directory et plusieurs serveurs d’accès au client sur chaque site, vous pouvez utiliser la fonctionnalité d’équilibrage de la charge réseau pour équilibrer la charge du trafic entre les serveurs d’accès au client de chaque site et pour les utilisateurs accédant directement à ces serveurs. Le simple déploiement d’un équilibreur de charge n’est pas suffisant pour assurer un équilibrage efficace de la charge. Vous devez également effectuer une configuration supplémentaire des propriétés InternalURL et ExternalURL. Il est recommandé de n’inclure que des serveurs d’accès au client dans le même site Active Directory dans une baie d’équilibrage de charge. Vous pouvez déployer l’équilibrage de la charge réseau dans un site Active Directory connecté à Internet et dans un site Active Directory non connecté à Internet.
Le tableau suivant répertorie les paramètres à configurer pour les répertoires virtuels sur les serveurs d’accès au client, aussi pour les sites connectés à Internet que pour les sites qui ne le sont pas. Le nom de domaine complet de l’équilibrage de charge réseau doit être configuré dans le DNS pour mener vers le service ou le périphérique d’équilibrage de charge. La solution d’équilibrage de charge sera alors responsable de transmettre le trafic vers les serveurs d’accès au client appropriés.
Paramètres de répertoire virtuel pour les serveurs d’accès au client d’une organisation utilisant l’équilibrage de la charge réseau
| Répertoire virtuel /service | InternalURL | ExternalURL (Site Active Directory connecté à Internet) | ExternalURL (Site Active Directory non connecté à Internet) |
|---|---|---|---|
/OWA |
Nom de domaine complet de l’équilibrage de charge réseau (voir les recommandations suivantes) |
Nom de domaine complet de l’équilibrage de charge réseau |
$null |
/ECP |
Nom de domaine complet de l’équilibrage de charge réseau (voir les recommandations suivantes) |
Nom de domaine complet de l’équilibrage de charge réseau |
$null |
/Microsoft-Server-ActiveSync |
Nom de domaine complet de l’équilibrage de charge réseau |
Nom de domaine complet de l’équilibrage de charge réseau |
$null |
/OAB |
Nom de domaine complet de l’équilibrage de charge réseau |
Nom de domaine complet de l’équilibrage de charge réseau |
$null |
/EWS |
Nom de domaine complet de l’équilibrage de charge réseau |
Nom de domaine complet de l’équilibrage de charge réseau |
$null |
POP/IMAP |
(InternalConnectionsSettings) Nom de domaine complet de l’équilibrage de charge réseau |
Non applicable |
Non applicable |
Il est recommandé de suivre les recommandations suivantes pour définir la propriété InternalURL :
La propriété InternalURL des répertoires virtuels /OWA et /ECP sur tous les serveurs d’accès au client d’un site Active Directory peut être définie sur le nom de domaine complet de l’équilibrage de charge réseau des serveurs de ce site s’il existe des utilisateurs d’Outlook 2010 internes.
Si un serveur d’accès au client d’un site Active Directory est la cible d’une demande de proxy Outlook Web App ou ECP provenant d’un serveur d’accès au client de tout autre site Active Directory, assurez-vous de configurer votre équilibreur de charge pour assurer le maintien de l’affinité. En effet, le serveur d’accès au client du site connecté à Internet ne peut pas sélectionner un serveur pour chaque demande et maintenir sa propre affinité
Le tableau suivant répertorie les différents paramètres d’authentification nécessaires sur les répertoires virtuels d’une organisation qui utilise l’équilibrage de charge réseau (NLB). Dans une organisation qui utilise l’équilibrage NLB, l’URL de cet équilibrage est utilisé à la place d’une URL de serveur d’accès au client spécifique pour la connectivité du client.
Paramètres d’authentification des répertoires virtuels pour les serveurs d’accès au client d’une organisation utilisant des URL NLB pour la tolérance aux pannes et l’équilibrage de charge
| Répertoire virtuel /service | Site Active Directory connecté à Internet | Site Active Directory non connecté à Internet |
|---|---|---|
/OWA |
Si Microsoft Threat Management Gateway 2010 (Forefront TMG) ou Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) est en cours d’utilisation et que l’authentification basée sur les formulaires est active, utilisez l’Authentification de base ou intégrée Windows, en fonction des paramètres de délégation des règles de pare-feu. Si le trafic en provenance d’Internet parvient au serveur d’accès au client sans pré-authentification, utilisez l’authentification basée sur les formulaires. La même méthode d’authentification doit être activée sur les répertoires virtuels /OWA et /ECP. |
Authentification Windows intégrée |
/ECP |
Si Forefront TMG ou Forefront UAFG est en cours d’utilisation et que l’authentification basée sur les formulaires est active, utilisez l’Authentification Windows de base ou intégrée, en fonction des paramètres de délégation des règles de pare-feu. Si le trafic en provenance d’Internet parvient au serveur d’accès au client sans pré-authentification, utilisez l’authentification basée sur les formulaires. La même méthode d’authentification doit être activée sur les répertoires virtuels /OWA et /ECP. |
Authentification Windows intégrée |
/Microsoft-Server-ActiveSync |
Authentification de base. |
Authentification de base (la transmission par proxy est effectuée à l’aide du répertoire virtuel /Proxy sub.) |
/OAB |
Authentification Windows de base ou intégrée, en fonction des paramètres de délégation des règles de pare-feu. |
Authentification Windows de base ou intégrée, en fonction des paramètres de délégation des règles de pare-feu (les demandes OAB ne sont jamais transmises par proxy entre les sites Active Directory. Ce répertoire virtuel est utilisé uniquement par les clients Outlook.) |
/EWS |
De base (facultatif - en fonction des paramètres de délégation des règles de pare-feu). Authentification Windows intégrée nécessaire. |
Authentification Windows intégrée |
POP/IMAP |
Tel que requis par la méthode de connexion client. |
Tel que requis par la méthode de connexion client |
Vue d’ensemble de la transmission par proxy
Logique de l’équilibrage de charge utilisée par les serveurs d’accès au client lors de la transmission par proxy entre les sites Active Directory
Lorsque plusieurs serveurs d’accès au client existent dans le même site ciblé par une tentative de transmission par proxy, et que le serveur de la boîte aux lettres de l’utilisateur se trouve sur un serveur combiné (d’accès au client/de boîtes aux lettres), le serveur d’accès au client du site Active Directory source choisira toujours le serveur combiné (d’accès au client/de boîtes aux lettres) comme cible de la tentative.
Outlook Web App, l’ECP et les services Web Exchange traitent l’équilibrage de charge de manière différente que le service de disponibilité et Exchange ActiveSync. Outlook Web App, l’ECP et les services Web Exchange mettent en place leur propre équilibrage de charge lorsqu’ils sont déployés sur plusieurs serveurs d’accès au client dans le même site Active Directory. Si un utilisateur tente d’accéder à Outlook Web App via https://mail.contoso.com/owa et est acheminé par proxy vers CAS-01, lors de sa prochaine tentative d’accès à Outlook Web App, il est de réacheminé par proxy vers CAS-01. Cela se produit, même si CAS-02 a moins de connexions simultanées. Ce mode de fonctionnement permet de traiter correctement les transactions longue durée sans besoin de nouvelle authentification ou sans redemander des données. Ce c’est que l’on appelle l’affinité. Si CAS-01 n’est pas disponible, l’utilisateur sera acheminé par proxy vers CAS-02 et il sera invité à s’authentifier de nouveau.
Les services Web Exchange peuvent maintenir l’affinité lorsqu’ils sont transmis par proxy entre des sites Active Directory, même si la propriété InternalURL du serveur ciblé est configurée avec une URL NLB. En effet, le serveur d’accès au client effectuant la demande par proxy au sujet d’une application qui requiert l’affinité utilise la propriété InternalNLBBypassURL sur le serveur cible. La propriété InternalNLBBypassURL est configurée avec le nom de domaine complet du serveur ciblé et utilise par défaut l’authentificationWindows.
| Remarque : |
|---|
| Pour Outlook Web App, l’ECP et les services Web Exchange, votre pare-feu doit être configuré pour IP Affinity ou une affinité par cookie. Cela permet à une application cliente particulière de se connecter au même serveur à chaque fois. Cela étant obligatoire, la négociation SSL n’est pas répétée pour chaque demande. Il est important de conserver l’affinité de l’application client pour le serveur d’accès au client impliqué dans la transaction. |
| Remarque : |
|---|
| Vous ne devez pas modifier la valeur de la propriétéInternalNLBBypassURL sur un serveur d’accès au client. Si vous le faites, vous interrompez les demandes de services Web Exchange transmises par proxy. |
Le processus est différent pour Exchange ActiveSync. Lorsqu’un serveur d’accès au client relié à Internet transmet par proxy une demande à un serveur d’accès au client non connecté à Internet, le serveur effectuant la demande recherche un serveur d’accès au client sur le site ciblé, puis essaye de s’y connecter à l’aide de la valeur configurée dans la propriété InternalURL. Si le serveur ne répond pas, la demande échoue et une erreur est renvoyée au client. Nous conseillons de mettre en place l’équilibrage de charge tourniquet (round-robin) au sein d’un tableau d’équilibrage de charge réseau, et de définir la propriété InternalURL sur une valeur à charge équilibrée.
Nous vous recommandons également d’équilibrer la charge du service de disponibilité. Les demandes du service de disponibilité ne sont pas tenues de maintenir leur état de connexion. Autrement dit, deux demandes consécutives au service de disponibilité en provenance du même client peuvent être transmises par proxy à des serveurs d’accès au client différents dans le site Active Directory de destination, sans que les performances ne soient affectées ; l’authentification ne pose aucun problème si la propriété InternalURL est définie sur valeur à charge équilibrée. En outre, définir la propriété InternalURL sur une valeur à charge équilibrée est bénéfique (en interne) aux clients Outlook 2007 et Outlook 2010 car le serveur de découverte automatique fournit à ces clients la valeur à charge équilibrée définie dans la propriété InternalURL pour leur permettre de réaliser des demandes au service de disponibilité.
Pour plus d’informations sur l’équilibrage de charge réseau, voir Présentation de l’équilibrage de la charge dans Exchange 2010.
| Remarque : |
|---|
| Dans de nombreux déploiements, le rôle serveur d’accès au client et le rôle serveur de transport Hub sont installés sur le même ordinateur. Dans cette topologie, vous pouvez configurer l’équilibrage de la charge réseau pour le rôle serveur d’accès au client séparément du rôle serveur de transport Hub. Actuellement, l’équilibrage de la charge réseau n’est pas pris en charge dans le rôle serveur de transport Hub. En revanche, il est pris en charge pour le rôle serveur d’accès au client. Pour configurer l’équilibrage de la charge réseau pour le rôle serveur d’accès au client mais pas pour le rôle serveur de transport Hub, configurez les ports 80 et 443 pour l’accès au client. Le rôle serveur de transport Hub implémente sa propre disponibilité dans le logiciel. |
Vue d’ensemble de la transmission par proxy
Résumé des méthodes d’accès au client
Le tableau suivant résume les protocoles utilisés pour accéder à Exchange 2010 et la manière dont ils sont utilisés pour les fonctions de transmission par proxy et de redirection.
Protocoles d’accès au client pour les fonctions de redirection et de transmission par proxy
| Protocole/Application | Redirection prise en charge entre serveurs d’accès au client | Transmission par proxy prise en charge entre serveurs d’accès au client | Commentaires |
|---|---|---|---|
Outlook Web App |
Oui |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour pouvoir utiliser Outlook Web App. |
Panneau de configuration Exchange |
Oui |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour pouvoir utiliser l’ECP. |
Exchange ActiveSync |
Oui |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour pouvoir utiliser Exchange ActiveSync. |
Services web Exchange |
Non (le service de découverte automatique fournit à l’application la valeur ExternalURL correcte) |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour utiliser les services Web Exchange. |
Service de disponibilité |
Non (le service de découverte automatique fournit à l’application la valeur ExternalURL correcte) |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour utiliser le service de disponibilité. |
POP3 et IMAP4 |
Non |
Oui |
Un serveur d’accès au client doit être disponible dans chaque site Active Directory pour pouvoir utiliser POP3 et IMAP4. |
Performances et évolutivité de la transmission par proxy
Dans un environnement Exchange 2010 utilisant la transmission par proxy, des performances médiocres résultent souvent de la réception par des serveurs d’accès au client d’une grande quantité de demandes simultanées. Ce problème est souvent dû à un épuisement des threads et des connexions disponibles en raison des demandes de service Web en provenance d’ASP.NET. Cela peut entraîner le refus du traitement des demandes ou une latence élevée lors du traitement des demandes par le serveur d’accès au client.
Pour résoudre ces problèmes, vous pouvez configurer plusieurs paramètres ASP.NET en modifiant le fichier Machine.config sur les serveurs d’accès au client. Pour plus d’informations sur la configuration de ces paramètres, consultez l’article 821268 de la Base de connaissances Microsoft sur la contention, les performances médiocres et les blocages lorsque vous faites des demandes de service Web à partir d’applications ASP.NET.
Deux des paramètres expliqués dans l’article de la Base de connaissances 821268 doivent être définis différemment dans un environnement de transmission par proxy Exchange 2010. Il est recommandé d’autoriser 36 threads par processeur et de définir la valeur maxconnections sur 2 000.
Pour en savoir plus sur les performances des serveurs, voir Gestion de .NET Framework sur Windows Server 2003.
© 2010 Microsoft Corporation. Tous droits réservés.