> Mobilité > Exchange 2003 : RPC sur HTTP

Exchange 2003 : RPC sur HTTP

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

par Kieran McCorry - Mis en ligne le 28/01/2004

Utilisez Outlook 2003 pour atteindre votre boîte à  lettres Exchange à  partir de n'importe quel réseau

La combinaison du trio Microsoft Outlook 2003, Windows Server 2003 et Microsoft Exchange Server 2003 ouvre de nouveaux horizons qui permettent à  un client Outlook 2003 de se connecter à  Exchange 2003 sur HTTP.La communication ne se contente pas d'utiliser HTTP; Outlook met une enveloppe HTTP autour des RPC (Remote Procedure Calls) vers Exchange 2003, permettant ainsi de connecter un client Outlook 2003 local à  un serveur Exchange 2003 à  distance, partout où l'on dispose d'un navigateur pour surfer sur le Web. Cette possibilité est utile si l'on considère les alternatives : utiliser OWA (Outlook Web Access), qui continue à  s'améliorer mais ne vaut encore pas le client Outlook complet, ou accéder à  Outlook par une connexion VPN, que les fournisseurs de réseaux bloquent souvent. Pour utiliser RPC sur HTTP, il faut comprendre le mécanisme et la configuration nécessaires sur le client et le serveur.

Toutes les versions d’Outlook utilise MAPI (Messaging API) pour interagir avec
n’importe quelle versions Exchange Server, et Outlook utilise les RPC pour
exécuter ses appels MAPI. Les RPC n’ont pas de fiabilité en propre et ils dépendent
pour cela d’un protocole de transport sous-jacent, tel que TCP/IP.
Lorsqu’une application de type RPC est mise en oeuvre sur des transports
moins fiables comme UDP, elle doit comporter des fonctionnalités de time-out
et de retransmission.
Les communications d’Outlook vers Exchange RPC commencent par un
handshake initial entre le client Outlook et le serveur Exchange sur un port
bien connu (port UDP 135, par exemple – le port RPC Endpoint Mapper) avant
d’établir un canal de communications sur un port attribué dynamiquement,
qui se situe généralement dans la fourchette de 1024 à  1100. Bien que l’on
puisse utiliser les paramètres de registres pour contrôler l’attribution de ce
port, les administrateurs de réseau et de pare-feu n’autorisent généralement
pas de communications RPC sur des réseaux TCP/IP publics. De plus, compte
tenu des nombreux problèmes de sécurité du service Windows NT RPC, la plupart des administrateurs de réseau
bloquent les ports 135, 137, 139 et 445
pour empêcher les sondes RPC extérieures
de transiter par le pare-feu.
Pratiquement, ces restrictions font
qu’on ne peut pas utiliser Outlook du
réseau d’une société pour se connecter
sur Internet à  un serveur Exchange
du réseau d’une autre société. Plutôt
que de vous faire négocier avec les administrateurs
de réseau et de pare-feu
pour valider RPC sur des communications
TCP/IP, Microsoft a mis à  niveau
les communications Outlook et
Exchange RPC pour qu’elles se superposent
au protocole HTTP.
Cette nouveauté signifie que si
vous établissez un serveur proxy reverse
HTTP, vous pouvez utiliser HTTP
à  partir du réseau d’une société pour
communiquer avec l’extérieur. En principe,
cette communication utilise le
port 80 HTTP standard ou l’une de ses
variantes (8080 ou 8088, par exemple).
Une fois que vous avez configuré
Microsoft IE (Internet Explorer) d’un
PC client avec un serveur proxy, toute
application peut utiliser le protocole
HTTP pour la communication client/
serveur. A noter que HTTPS (HTTP
Secure) est aussi généralement accessible
par le port 443.

Téléchargez gratuitement cette ressource

Les 7 étapes d’un projet de dématérialisation RH

Les 7 étapes d’un projet de dématérialisation RH

Dans ce livre blanc, nous vous donnons les clés pour concevoir votre projet de dématérialisation RH. Vous découvrirez chacune des étapes qui vous permettront d’apporter de nouveaux services aux collaborateurs, de vous adapter aux nouvelles pratiques et de renforcer la marque employeur.

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