Référence relative à la résolution de problèmes liés aux serveurs d’accès au client

Article
11/29/2016

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

Après avoir installé le rôle serveur d’accès au client sur un ordinateur exécutant MicrosoftExchange Server 2010, vous devrez peut-être tester la fonctionnalité du serveur ou bien résoudre les problèmes liés à la connectivité client. Les informations suivantes vous permettront de résoudre des problèmes courants et de procéder à des tests pour vous assurer que le serveur d’accès au client est correctement configuré. Cette rubrique sera régulièrement mise à jour.

Tester la connectivité du serveur d’accès au client

L’Analyseur de connectivité à distance Microsoft Exchange (ExRCA) vous permet de confirmer que la connectivité de vos serveurs Exchange est configurée correctement et de diagnostiquer les problèmes de connectivité. Le site Web de l’Analyseur de connectivité à distance propose des tests pour Microsoft Exchange ActiveSync, les services Web Exchange, Outlook et la messagerie électronique Internet.

Pour plus d’informations, voir Présentation de l’analyseur de connectivité à distance.

Connectivité du client Outlook

Les liens et informations suivantes vous permettront de résoudre des problèmes liés à la connectivité du client Outlook.

Impossible d’ouvrir une boîte aux lettres dans Outlook 2007

Si vous ne parvenez pas à ouvrir la boîte aux lettres d’un utilisateur dans MicrosoftOffice Outlook 2007 alors que vous pouvez ouvrir la boîte aux lettres dans MicrosoftOfficeOutlook Web App, vérifiez les données du serveur en exécutant la commande suivante :

Get-MailboxDatabase | fl RPCClientAccessServer

Si le résultat de cette commande correspond au nom du serveur de boîtes aux lettres Exchange 2010, il est fort probable que l’ordre dans lequel les rôles serveur d’accès au client et de boîtes aux lettres ont été installés est incorrect. La valeur du paramètre RPCClientAccessServer est définie sur le serveur de boîtes aux lettres et non sur le serveur d’accès au client. Pour résoudre ce problème, exécutez la commande suivante :

Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer <FQDN of the Client Access Server>

Impossible d’ouvrir une boîte aux lettres dans Outlook 2003 et Exchange 2010 RTM

Si vous tentez d’accéder à une boîte aux lettres sur un serveur de boîtes aux lettres Exchange 2010 avec OfficeOutlook 2003, un des messages d’erreur suivants peut s’afficher :

Impossible de démarrer Microsoft Office Outlook. Impossible d’ouvrir la fenêtre Office. Impossible d’ouvrir l’ensemble des dossiers.
Impossible d’ouvrir vos dossiers de messagerie par défaut. Impossible d’ouvrir la banque d’informations.

Dans Exchange 2010, le point de terminaison RPC est chiffré par défaut. Cependant, Outlook 2003 n’applique pas les connexions MAPI chiffrées. Lorsque vous procédez à la mise à niveau de votre organisation vers Exchange 2010, vos clients dotés d’Outlook 2007 ou de versions ultérieures deviennent automatiquement compatibles avec le changement apporté au service d’accès au client RPC, puisqu’ils prennent en charge le chiffrement RPC par défaut. Toutefois, Outlook 2003 n’utilise pas le chiffrement RPC alors que le service d’accès au client RPC l’exige par défaut.

Remarque :
Par défaut, Exchange 2010 Service Pack 1 (SP1) ne chiffre pas le point de terminaison RPC. Cette erreur ne devrait donc pas se produire.

Pour configurer Outlook 2003 afin d’utiliser le chiffrement RPC, procédez comme suit :

Cliquez sur Outils > Comptes de messagerie > Afficher ou modifier les comptes de messagerie existants.
Sélectionnez le compte, puis cliquez sur Paramètres supplémentaires.
Cliquez sur l’onglet Sécurité.
Cochez la case Chiffrer les données entre Microsoft Office Outlook et Microsoft Exchange Server.
Cliquez sur OK.

Le chargement des messages électroniques est lent pour les clients Outlook 2003

La prise en charge des notifications UDP a été supprimée d’Exchange 2010. C’est pourquoi Outlook 2003 autorise uniquement le recours aux notifications d’interrogation en mode en ligne. Cela génère un léger retard dans les mises à jour du statut des éléments (30 secondes en moyenne avec un retard pouvant atteindre une minute) en cas de modification d’éléments dans une boîte aux lettres ouverte avec Outlook 2003. Il y a deux solutions de contournement dans ce cas :

Utilisez Outlook 2003 en mode Exchange mis en cache.
Réglez l’intervalle d’interrogation sur le serveur d’accès au client. Ceci affectera le niveau de performance du serveur d’accès au client.

Pour plus d’informations à ce sujet, consultez la page L’envoi et la réception de messages électroniques prend beaucoup de temps.

L'ID d'événement 106 est enregistré lorsque vous faites démarrer le services d’accès au client RPC

Si le service d'accès au client Microsoft Exchange RPC démarre sur un serveur de boîtes aux lettres Exchange 2010 sur lequel le rôle serveur d'accès au client n'est pas installé, l'ID d'événement 106 est enregistré dans le journal des applications. Cette erreur survient parce que les compteurs de performances du service d'accès au client RPC ne sont pas installés lorsque le rôle serveur de boîtes aux lettres est installé sans le rôle serveur d'accès au client. Pour résoudre ce problème, installez le rôle serveur d'accès au client sur le serveur Exchange 2010.

La modification de DNS empêche l’utilisateur de se connecter à Outlook Web App

Lorsqu’un utilisateur tente de se connecter à Outlook Web App, le message d’erreur suivant peut s’afficher :

Une modification de configuration du serveur empêche provisoirement l’accès à votre compte. Veuillez fermer toutes les fenêtres Internet Explorer et renouveler votre essai dans quelques minutes. Si le problème persiste, contactez votre support technique.

Ceci peut se produire quand l’enregistrement DNS du serveur d’accès au client est modifié et qu’un utilisateur tente de se connecter à Outlook Web App avant que le cache DNS d’Internet Explorer soit actualisé. Pour résoudre ce problème, l’utilisateur doit fermer toutes les fenêtres du navigateur pour qu’Internet Explorer applique la mise à jour du cache DNS. Voir Utilisation du cache pour les entrées d’hôte DNS par Internet Explorer pour obtenir des informations sur le cache DNS dans Internet Explorer.

Pour éviter ceci, créez une seconde entrée DNS pour le serveur d’accès au client et utilisez la cmdlet Set-OwaVirtualDirectory pour configurer la mise en correspondance du paramètre FailbackUrl. Le paramètre FailbackUrl spécifie le nom d’hôte utilisé par Outlook Web App pour la connexion au serveur d’accès au client après la restauration automatique dans un processus de résilience de site et requiert une entrée DNS séparée qui pointe vers l’adresse IP initiale du serveur d’accès au client. Le paramètre FailbackUrl doit être différent du paramètre ExternalUrl.

Cet exemple configure le paramètre FailbackUrl.

Set-owavirtualdirectory -identity "owa (default web site)" -FailbackUrl "<failback URL>"

Pour en savoir plus sur la syntaxe et les paramètres, voir Set-OwaVirtualDirectory.

Résoudre les erreurs de l'Assistant Certificat

Exchange 2010 utilise les services HTTP Microsoft Windows (WinHTTP) pour gérer l'ensemble du trafic HTTP/HTTPS. De ce fait, Exchange 2010 n'utilise pas les paramètres de serveur proxy éventuellement configurés dans le navigateur Web. WinHTTP utilise le protocole WPAD (Web Proxy Auto-Discover Protocol) et demande de spécifier un fichier PAC (Proxy Access Control) via DHCP ou DNS.

Si les paramètres de proxy WinHTTP sont configurés de manière incorrecte, les problèmes suivants peuvent se produire :

Suite à l'importation d'un certificat tiers valide dans une CAS Exchange 2010, la console de gestion Exchange peut indiquer l'état suivant : L'état du certificat n'a pas pu être déterminé en raison d'un échec de vérification de la révocation
Si vous exécutez la cmdlet Get-ExchangeCertificate dans Environnement de ligne de commande Exchange Management Shell, l'état suivant apparaît pour le certificat importé : État : RevocationCheckFailure

Pour résoudre ces problèmes, procédez comme suit :

Pour répertorier les paramètres de proxy WinHTTP, saisissez la commande suivante dans l'invite, puis appuyez sur la touche Entrée : netsh winhttp show proxy. La réponse affiche les informations actuelles du proxy utilisé par Exchange. Vous recevez généralement une réponse similaire à ce qui suit :
```
C:\>netsh winhttp show proxy 

Current WinHTTP proxy settings: 

Direct access (no proxy server)
```
Si le serveur identifié dans la réponse n'est pas correct, configurez le paramètre du proxy WinHTTP à l'aide de la commande netsh. Configurez également le serveur du nom de domaine complet (FQDN) dans la liste d'exclusion pour que l'Environnement de ligne de commande Exchange Management Shell et la console de gestion Exchange puisse contacter le PowerShell à distance.

Pour ce faire, saisissez la commande suivante dans l'invite, puis appuyez sur la touche Entrée : netsh winhttp set proxy proxy-server="http=<Nom_serveur_proxy>" bypass-list="*.<Domaine_nomhôte_serveur_Exchange>"

Remarque :
Remplacez l'espace réservé <Nom_serveur_proxy> par le nom du serveur proxy. Remplacez également l'espace réservé <Domaine_nomhôte_serveur_Exchange> par un nom de domaine de deuxième niveau et le nom de domaine de premier niveau de MS Exchange Server (par exemple, microsoft.com)

Fermez et ouvrez la console de gestion Exchange. Vérifiez l'état du certificat. Si les paramètres de proxy sont corrects mais que l'état du certificat reste incorrect, exécutez les commandes suivantes à l'invite de commande pour effacer le cache OCSP/CRL :

certutil -urlcache ocsp delete

certutil -urlcache crl delete
Redémarrez le serveur, puis ouvrez la console de gestion Exchange pour vérifier l'état du certificat.