Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Le blog d'Alexandre GIRAUD MVP Forefront

oct. 25
UAG 2010 : résoudre les problèmes de publication Exchange 2003 avec UAG

J'ai récemment eu un client avec les services Microsoft Exchange 2003 en tant que Front-End, qui souhaitait publier les services Exchange (EWS). Bien sûr, j'ai suggéré sans hésitation la meilleure solution : Microsoft Forefront UAG.

Quel surprise de découvrir après avoir utilisé l'assistant que les publications ne fonctionnaient pas nativement que j'ai eu besoin de quelques personnalisations pour un fonctionnement global.

La première anomalie que les utilisateurs Exchange ont rencontrée est un message d'accès refusé (Access Denied). La raison vient que les chemins par défaut dans le modèle fourni est incorrect, et donc a besoin d'une petite modification.

Comme vous le voyez ci-dessus dans l'impression écran, le dernier chemin est: |/Microsoft-Server-ActiveSync|/rpc/rpcproxy.dll\?(?!localhost).*

Solution de contournement: Remplacez le chemin entouré en rouge par ces deux chemins séparés :

  • /Microsoft-Server-ActiveSync/
  • /rpc/rpcproxy.dll\?(?!localhost).*

 Ce n'est pas tout … si vos utilisateurs ont des terminaux Apple IPhone, vous devrez également changer "/Microsoft-Server-ActiveSync/" vers "/Microsoft-Server-ActiveSync.*". Cette modification est nécessaire parce que les IPhone utilisent les informations de commande dans l'URL. Nous verrons facilement ce comportement dans le moniteur UAG :

A request on trunk ***; Secure=1 failed because of an unknown application. The URL is /Microsoft-Server-ActiveSync?User=***&DeviceId=***&DeviceType=iPhone&Cmd=FolderSync. The source IP address is a.b.c.d.

Apparemment, Apple a simplement oublié d'ajouter un slash (/) dans les requêtes ActiveSync.

Donc, les chemins corrects devront être :

OWA n'est pas accessible, l'accès est refusé !

Après la publication d'un portail dédié messagerie (Exchange portal trunk), les utilisateurs qui tenteront d'accéder à Outlook Web Access auront un message d'accès refusé. La raison de cette erreur, est que le formulaire OWA fourni par UAG n'est pas compatible avec Exchange 2003. Le formulaire fourni est similaire à celui d'Exchange 2010.

Solution de contournement: Pour cela, vous devrez désactiver la fonction "Owa look and feel" présente dans la configuration avancée du portail afin d'éviter d'utiliser ce formulaire et utiliser la version basique à la place.

Outlook Anywhere (RPC over HTTPS) ne peut pas synchroniser la boite aux lettres!

Vous ne pourrez pas synchroniser et configurer la fonction « Outlook Anywhere », et la boite aux lettres ne sera jamais découverte. Cela arriver car les méthodes http RPC_IN_DATA et RPC_OUT_DATA sont bloqués (on le voit dans le moniteur Web également):

A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll?exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_IN_DATA.

A request from source IP address a.b.c.d on trunk xxx; Secure=1 for application xxx of type ExchangePub2003SP1 failed. The URL /rpc/rpcproxy.dll? exchange.fqdn.local:6001 contains an illegal path. The rule applied is Default rule. The method is RPC_OUT_DATA.

Pour permettre cette fonctionnalité, vous devez suivre les deux actions suivantes. Tout d'abord rajouter les méthodes http « RPC_OUT_DATA » et « RPC_IN_DATA » dans la configuration avancée du portail :

Puis vous devrez créer une nouvelle règle d'accès pour accepter RPC_IN_DATA et RPC_OUT_DATA pour le chemin /rpc/rpcproxy\.dll.* comme le démontre l'impression écran ci-dessous :

Pour finir, certains mails en "Plain Text" peuvent ne pas être visibles dans OWA.

Dans certains cas, les mails affichés dans Outlook Web Acces auront une erreur lors de la tentative de visualisation "Internet Explorer cannot display the webpage". Cette erreur est spécifique aux messages de type "plain text". Il se peut que le message puisse finalement être visible en rafraîchissant de nombreuses fois la page.

L'erreur ressemble à ceci :

Si nous utilisons un outil de sniffer http comme httpwatch, on peut remarquer que la page « InitParams.aspx » et « InstallAndDetect.asp » sont appelés depuis la requête « blank.htm » ….

Pourquoi? Parce que quand un mail est ouvert ou en prévisualisation, le code serveur utiliser un iframe avec des paramètres de sécurité restreintes vers la page « blank.htm ». Avec ces paramètres de sécurité, le cookie est perdu. Le code en question est :

<IFRAME security="restricted" id="idHtmlBody" src="/uniquesigxxx/uniquesig1/exchweb/6.5.7651.60/controls/blank.htm" frameborder="0" width="100%" height="100%"></IFRAME>

Pour résoudre ce problème, J'ai utilisé une méthode de réécriture avec AppWrap pour retirer cette sécurité restreinte depuis l'Iframe. Le tableau ci-dessous donne les détails du code, avec la colone de gauche non encodé en Base64 pour une meilleure visibilité. Lors de l'insertion du code dans UAG, pensez à utiliser la colonne de droite.

Not encoded in Base 64

Encoded

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">
                <MANIPULATION>
                               <MANIPULATION_PER_APPLICATION>
                                               <APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE>
                                               <DATA_CHANGE>
                                                               <URL case_sensitive="false">/exchange/.*\.EML(\?cmd=open|\?cmd=preview)</URL>
                                                               <SAR>
                                                                              <SEARCH encoding="base64"><IFRAME security="restricted" </SEARCH>
                                                                              <REPLACE encoding="base64"><IFRAME </REPLACE>
                                                               </SAR>
                                               </DATA_CHANGE>
                               </MANIPULATION_PER_APPLICATION>
                </MANIPULATION>
</APP_WRAP>

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">
                <MANIPULATION>
                               <MANIPULATION_PER_APPLICATION>
                                               <APPLICATION_TYPE>ExchangePub2003SP1</APPLICATION_TYPE>
                                               <DATA_CHANGE>
                                                               <URL case_sensitive="false">/exchange/.*\.EML(\?cmd=open|\?cmd=preview)</URL>
                                                               <SAR>
                                                                              <SEARCH encoding="base64">PElGUkFNRSBzZWN1cml0eT0icmVzdHJpY3RlZCIg</SEARCH>
                                                                              <REPLACE encoding="base64">PElGUkFNRSA=</REPLACE>
                                                               </SAR>
                                               </DATA_CHANGE>
                               </MANIPULATION_PER_APPLICATION>
                </MANIPULATION>
</APP_WRAP>

     

A présent, vous pouvez utiliser ActiveSync, Outlook Anywhere et Outlook Web Access pour les services Exchange 2003 avec UAG ! Toutes ces défauts seront corrigés dans le prochain Service Pack pour UAG, planifié pour Q4 2010.

Profitez-en bien de toutes les astuces données ici !

An English version of this article is available on Ben Ari blog site http://blogs.technet.com/b/ben/archive/2010/10/26/publish-exchange-2003-with-uag.aspx