> Mobilité > Fonctions RPC sur HTTP du Service Pack 1 Exchange 2003

Fonctions RPC sur HTTP du Service Pack 1 Exchange 2003

Mobilité - Par iTPro.fr - Publié le 24 juin 2010
email

par Kieran McCorry, Mis en ligne le 05/07/06 - Publié en Mai 2005

Exchange Server 2003 vous permet d’utiliser les appels de procédure à distance (RPC) sur HTTP (RPC sur HTTP, une fonction également appelé fréquemment Outlook sur HTTP) de l’API de messagerie MAPI, afin de connecter Microsoft Office Outlook 2003 à un serveur Exchange. Lorsque Microsoft a lancé Exchange 2003, les utilisateurs ont encensé cette fonctionnalité car ils pouvaient enfin connecter Outlook à Exchange sur pratiquement n’importe quel réseau. Néanmoins, les possibilités d’administration de cette fonctionnalité étaient faibles.La configuration initiale était à la fois laborieuse et sujette à erreurs ; de nombreuses clés de Registre devaient être configurées sur les serveurs proxy RPC, les contrôleurs de domaine (DC) et les serveurs de catalogue global (GC). Par ailleurs, la tâche d’administration au quotidien n’était pas des plus aisées, notamment lors de l’ajout ou du retrait de serveurs Exchange. (Pour plus d’informations sur les exigences générales et sur les clés de Registre à configurer pour RPC sur HTTP avant d’installer Exchange 2003 Service Pack 1 (SP1), consultez l’article intitulé « Exchange 2003 RPC sur HTTP », publié en décembre 2003 (Windows IT Pro www.itpro.fr ).

Exchange 2003 SP1 résout largement ces problèmes. Vous pouvez désormais utiliser, ce que l’on appelle la « topologie gérée RPC sur HTTP » pour mettre en oeuvre RPC sur HTTP et les changements continus à l’environnement, par exemple l’ajout ou le retrait de serveurs, sont automatiquement reflétés dans la configuration. Ces nouvelles fonctionnalités rendent RPC sur HTTP encore plus indispensable.

Fonctions RPC sur HTTP du Service Pack 1 Exchange 2003

Avant la sortie d’Exchange 2003 SP1 par Microsoft, le terme de serveur proxy RPC faisait référence à un serveur Windows Server 2003 sur lequel la fonctionnalité RPC sur HTTP était installée (généralement via l’option Add/Remove Windows Components (Ajouter ou supprimer des composants Windows) de l’applet Add or Remove Programs (Ajout/Suppression de programmes) au niveau du Control Panel (Panneau de configuration)).

Le serveur proxy RPC n’avait pas besoin d’exécuter Exchange 2003 et ne le faisait généralement pas. Un client Outlook 2003 établissait une connexion au serveur proxy RPC (le plus souvent via un pare-feu) et ce serveur contactait un contrôleur de domaine ou un serveur de catalogue global, authentifiait la demande de connexion de l’utilisateur, puis établissait une connexion proxy à partir du client Outlook 2003 au serveur de boîtes aux lettres Exchange 2003 approprié, sur lequel se déroulait l’étape supplémentaire de l’authentification Exchange. En supposant que les authentifications aboutissaient, toutes les autres communications entre Outlook et Exchange pour la durée de la session se déroulaient via le serveur proxy RPC. Avec la demande de connexion initiale, le serveur de boîtes aux lettres Exchange 2003 délivrait une redirection de liste d’adresses globales (GAL) pour le serveur GC au client Outlook 2003. Dans la mesure où Outlook ne pouvait pas se connecter directement au serveur GC, le serveur proxy RPC établissait également une connexion proxy au nom du client Outlook, comme l’illustre la figure 1.

Dans ce mode opératoire, vous deviez définir spécifiquement les serveurs GC utilisés par le serveur proxy RPC pour fournir l’accès GAL RPC sur HTTP. Pour ce faire, il était nécessaire de modifier la sous-clé de Registre HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy\ValidPo rts sur le serveur proxy RPC en fournissant les détails de connexion et de port pour les serveurs GC spécifiques. Il fallait ensuite créer la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS\Parameters\NSPI Interface Protocol Sequences pour les serveurs GC et modifier sa valeur afin d’accepter les connexions RPC sur HTTP à partir du serveur proxy RPC.

Avec la topologie gérée RPC sur HTTP d’Exchange 2003 SP1, il n’est plus nécessaire de définir ces sous-clés, à condition que les conditions préalables soient respectées. Pour une configuration prise en charge, vous devez co-localiser le composant proxy RPC sur HTTP de Windows 2003 sur vos serveurs frontaux Exchange 2003. Le serveur proxy RPC illustré à la figure 1 passe alors du statut de serveur qui exécute uniquement Windows 2003 en serveur qui exécute Windows 2003 et Exchange 2003, comme le montre la figure 2.

Dans la topologie gérée RPC sur HTTP, le serveur frontal Exchange 2003 (qui assure la fonction de serveur proxy RPC) ne contient pas d’informations de configuration de serveur GC dans la sous-clé ValidPorts. Lorsque le serveur proxy RPC frontal Exchange 2003 établit une connexion proxy Outlook au serveur de boîtes aux lettres Exchange 2003, l’un des deux événements suivants se produit, en fonction de la version Exchange 2003 du serveur de boîtes aux lettres.

Premièrement, si le serveur de boîtes aux lettres exécute Exchange 2003 SP1, il détecte que la connexion de client Outlook utilise RPC sur HTTP car la demande de connexion provient de Microsoft IIS sur le serveur frontal au point final ncacn_http sur le serveur de boîtes aux lettres. Dans ce cas, ce dernier demande au client Outlook d’utiliser le serveur proxy de service d’annuaire (DS) sur le serveur de boîtes aux lettres, lequel accède au serveur GC pour le compte d’Outlook au lieu de rediriger Outlook directement vers un serveur GC. Cette nouvelle fonctionnalité d’Exchange 2003 SP1 redéfinit la priorité d’affectation des clients RPC sur HTTP à un serveur GC.

Deuxièmement, si le serveur de boîtes aux lettres exécute Exchange 2003 sans avoir appliqué le SP1, il essaie initialement de rediriger le client Outlook directement vers un serveur GC, comme d’habitude. Le client Outlook essaie consciencieusement d’atteindre le serveur GC via le serveur proxy RPC sur le serveur frontal Exchange 2003, mais comme ce dernier ne dispose pas d’informations de configuration afin de permettre une connexion RPC sur HTTP à n’importe quel catalogue global, la tentative de connexion échoue. Le client Outlook demande de nouveau une connexion au serveur GC à partir du serveur de boîtes aux lettres, mais comme celui-ci reconnaît l’échec de la première tentative de redirection, il propose le mécanisme proxy DS et fournit l’accès à un serveur GC.

Bien que ces deux mécanismes donnent le résultat escompté, le deuxième requiert un délai supplémentaire, en raison de la temporisation de la redirection initiale. L’approche la plus judicieuse consiste donc à installer le SP1 sur les serveurs frontal, de boîtes aux lettres et principal Exchange 2003.

Téléchargez gratuitement cette ressource

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Guide de facturation électronique, voie royale pour le DAF et la digitalisation de la fonction finance

Ce livre blanc expose les problématiques auxquelles sont confrontés les DAF modernes et souligne les bénéfices de la facturation électronique pour la trésorerie. Il dévoile également le processus de déploiement de ce projet de transformation digitale que la réglementation rendra bientôt obligatoire.

Mobilité - Par iTPro.fr - Publié le 24 juin 2010