Présentation de l'accès au client RPC
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
Dans MicrosoftExchange Server 2007, le rôle serveur d’accès au client a été introduit pour gérer les connexions client entrantes vers les boîtes aux lettres Exchange. Même si la majorité des types de connexions client ont été effectués vers le serveur d’accès au client, Microsoft Office Outlook est toujours directement connecté au serveur de boîtes aux lettres lorsqu’il était exécuté en interne avec le protocole MAPI.
Un nouveau service a été introduit avec Exchange Server 2010 pour permettre au serveur d’accès au client de gérer les connexions MAPI. Le service d’accès au client RCP fournit un accès aux données à l’aide d’un seul chemin d’accès commun du serveur d’accès au client, à l’exception des demandes de dossiers publics qui sont toujours effectuées directement vers le serveur de boîtes aux lettres. Cette modification applique une logique métier aux clients de manière plus cohérente et améliore l’expérience utilisateur des clients en cas de basculement.
Contenu de cette rubrique
Service d’accès au client RPC et service de carnet d’adresses
Avantages du service d’accès au client RPC
Groupe de serveurs d’accès au client
Configuration du service d’accès au client RPC et du service de carnet d’adresses
Service d’accès au client RPC et service de carnet d’adresses
En plus du déplacement des connexions de boîtes aux lettres Outlook entrantes vers le serveur d’accès au client dans Exchange 2010, l’accès au répertoire est également géré par le serveur d’accès au client. Pour plus d’informations sur l’accès au répertoire, consultez la rubrique Présentation du service de carnet d'adresses.
Microsoft Outlook est toujours directement connecté au serveur de boîtes aux lettres pour accéder aux bases de données de dossiers publics. Si un client tente de se connecter à un serveur de boîtes aux lettres pour avoir accès à un dossier public, le service d’accès au client RPC (MsExchangeRpc) répond au point final RPC. Si le point final se trouve sur un serveur sur lequel le serveur de boîtes aux lettres est installé, le service d’accès au client RPC autorisera seulement les ouvertures de sessions de dossiers publics et fournira une redirection vers un serveur d’accès au client ou vers un groupe de serveurs d’accès au client. Si le point final se trouve sur un serveur d’accès au client ou sur un groupe de serveurs d’accès au client, il autorisera uniquement les ouvertures de sessions de dossiers privés et fournira une redirection vers un serveur de boîtes aux lettres pour avoir accès au dossier public.
Différences de connectivité client entre Exchange 2007 et Exchange 2010
Avantages du service d’accès au client RPC
Il existe un certain nombre d’avantages pour le service d’accès au client RPC. Les clients rencontrent moins de temps d’arrêt lors d’un basculement de boîte aux lettres, car toutes les connexions sont effectuées à travers les serveurs d’accès au client. En cas de basculement sur Exchange 2007, les clients Outlook seraient déconnectés du serveur de boîtes aux lettres pour une période qui dépendrait de leur configuration réseau. Sur Exchange 2010, en cas d’échec d’un serveur d’accès au client dans un groupe de serveurs d’accès au client, le client sera immédiatement redirigé vers un autre serveur d’accès au client du groupe. Si un serveur de boîtes aux lettres faisant partie d’un Groupe de disponibilité de base de données (DAG) échoue, le client n’est déconnecté que pendant le temps nécessaire au montage d’une base de données de basculement.
Un tableau à charge équilibrée de serveurs d’accès au client vous permet de répartir la charge du trafic de manière égale sur tous les serveurs d’accès au client du groupe.
Les autres problèmes résolus par cette nouvelle architecture sont les suivants :
Problèmes avec des messages s’affichant différemment sur différents clients.
Problèmes de téléchargement des certificats dans la liste d’adresses globale.
Incapacité à créer des profils pour les utilisateurs masqués.
Application incohérente de la logique métier aux clients.
Les dossiers publics se connectant au service d’accès au client RPC sur le serveur de boîtes aux lettres plutôt que sur le serveur d’accès au client.
En outre, le service DSProxy a été supprimé et le nouveau service de carnet d’adresses est chargé de la mise à jour des certificats et de l’appartenance aux listes de distribution ainsi que des informations de délégués pour les clients Outlook.
Connexions de client MAPI
Dans Exchange 2007, Outlook et autres clients MAPI en communication avec le serveur d’accès au client pour des connexions HTTPS comme Exchange Web Services (y compris le service de disponibilité et les paramètres d’absence du bureau), et les téléchargements de Carnet d’adresses en mode hors connexion, mais en communication directe avec le composant RPC MAPI du serveur de boîtes aux lettres et le point final NSPI sur les serveurs de catalogue global pour des requêtes dans le service d’annuaire.
Dans Exchange 2010, ces connexions sont faites au point de connexion MAPI RPC sur le serveur d’accès au client ou le groupe de serveurs d’accès au client.
Service de carnet d’adresses
Dans les versions précédentes d’Exchange, DSProxy, un service de redirection qui indiquait aux clients Outlook où trouver le point final NSPI (Name Service Provider Interface), était chargé de diriger Outlook vers un serveur de catalogue global. DSProxy se trouvait sur le serveur de boîtes aux lettres. DSProxy a été supprimé dans Exchange 2010 et remplacé par le service de carnet d’adresses.
Actuellement, lorsqu’un client Outlook effectue une requête sur le serveur d’accès au client, cela aboutit à l’une des deux actions possibles.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange 2010, la requête est gérée par un serveur d’accès au client sur le site Active Directory actuel, ou si la boîte aux lettres de l’utilisateur se trouve sur un site Active Directory différent, la requête est transmise par proxy au site Active Directory de destination.
Si la boîte aux lettres de l’utilisateur se trouve sur un serveur de boîtes aux lettres Exchange hérité, la requête d’annuaire est redirigée vers le serveur de boîtes aux lettres de l’utilisateur. Les serveurs de boîtes aux lettres hérités ne peuvent pas communiquer directement avec les serveurs d’accès au client Exchange 2010 pour les informations d’annuaire.
Le service de carnet d’adresses fournit également des informations sur les contrôleurs de domaine accessibles en écriture ainsi que sur l’accès à la liste d’adresses globales. Pour plus d’informations sur le service de carnet d’adresses, consultez la rubrique Présentation du service de carnet d'adresses.
Groupe de serveurs d’accès au client
En plus du service d’accès au client RPC, Exchange 2010 offre une nouvelle structure logique à l’organisation Exchange : le groupe de serveurs d’accès au client. Lorsqu’un groupe de serveurs d’accès au client est défini sur un site Active Directory, il sert de point de contact unique pour toutes les connexions client au sein de ce site Active Directory. Un groupe de serveurs d’accès au client peut inclure un ou plusieurs serveurs d’accès au client.
Architecture du groupe de serveurs d’accès au client.
Chaque site Active Directory peut avoir un seul groupe de serveurs d’accès au client. Un groupe de serveurs d’accès au client ne fournit pas l’équilibrage de charge. Une solution d’équilibrage de charge distincte est encore nécessaire. Pour plus d’informations sur l’équilibrage de charge, consultez la rubrique Présentation de l’équilibrage de la charge dans Exchange 2010.
Il est recommandé de créer un groupe de serveurs d’accès au client même si vous n’avez qu’un seul serveur d’accès au client au sein de votre organisation. Lorsqu’un groupe de serveurs d’accès au client est créé, les clients se connectent via le nom virtuel du groupe de serveurs d’accès au client plutôt que directement sur le nom de domaine complet de votre serveur d’accès au client unique. Si un seul serveur d’accès au client doit être remplacé au sein d’un site Active Directory ou si un deuxième serveur d’accès au client est ajouté, aucune mise à jour de profils n’est nécessaire sur les clients.
Après la définition d’un groupe de serveurs d’accès au client au sein d’un site Active Directory, tous les serveurs d’accès au client au sein de ce site Active Directory font automatiquement partie du groupe de serveurs d’accès au client.
Configuration du service d’accès au client RPC et du service de carnet d’adresses
Pour configurer le service d’accès au client RPC et le service de carnet d’adresses, vous devez effectuer les étapes suivantes.
Créer un groupe d’accès au client
Configurer l’équilibrage de charge
Configurer les ports IP
Configurer les paramètres de chiffrement RPC
Configurer vos bases de données de boîtes aux lettres
Vous assurer de la faible latence et de la vitesse du réseau suffisante
Créer un groupe d’accès au client
Vous pouvez créer un groupe d’accès au client au sein de votre site Active Directory à l’aide de la commande suivante.
New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN
.gif "Remarque") Remarque : |
|---|
| Après avoir créé le groupe d’accès au client, vous devrez également créer l’adresse dans le DNS et l’associer à l’adresse IP virtuelle utilisée pour le groupe d’accès au client. |
Il est important que le nom de domaine complet spécifié dans la commande ne puisse être résolu qu’en interne. Si le nom peut également être résolu en externe, les clients externes tenteront de se connecter au groupe via une connexion TCP plutôt que HTTPS.
Configurer l’équilibrage de charge
L’équilibrage de charge est recommandé en cas de disponibilité élevée, de basculement et pour répartir la charge du trafic sur plusieurs serveurs pour augmenter les performances. Lorsque vous choisissez une solution d’équilibrage de charge, prenez en compte les éléments suivants :
Windows L’équilibrage de charge réseau n’est pas pris en charge sur les serveurs de cluster de basculement Windows.
Vous ne pouvez pas utiliser un groupe d’accès au client sur plusieurs sites Active Directory. Au lieu de cela, créez deux groupes d’accès au client et un équilibrage de charge séparément au sein des sites.
Les équilibreurs de charge matériel analysent généralement le trafic de retour, la disponibilité des ports ou des services pour s’assurer que les serveurs qui ne peuvent pas répondre aux requêtes des clients ne reçoivent pas de connexions réseau.
Certaines solutions d’équilibrage de charges, comme ISA 2006 ou TMG 2010, ne peuvent pas effectuer l’équilibrage de charge RPC ou analyser les services RPC. Ces solutions ne sont pas recommandées sauf si tous les clients se connectent via Outlook Anywhere et que tout le trafic est encapsulé dans le protocole HTTP.
Pour plus d’informations sur l’équilibrage de charge, consultez la rubrique Présentation de l’équilibrage de la charge dans Exchange 2010.
Configurer les ports IP
Un port IP est une ouverture à travers laquelle les informations peuvent passer de l’ordinateur d’origine à l’ordinateur de destination. Par défaut, la plage de ports dynamique pour les connexions sortantes sur Windows Server 2008 R2 va de 49152 à 65535. L’accès client Exchange 2010 modifie cette plage de 6005 à 65535. La plage a été étendue afin de fournir une évolution suffisante pour les déploiements vastes. C’est une vaste plage de ports à équilibrer par le biais de votre pare-feu entre le client et les serveurs d’accès au client ou le groupe d’accès au client.
En corrigeant les points finaux MAPI et d’annuaire, vous pouvez réduire considérablement le nombre de ports ayant besoin d’un équilibrage de charge. Le point final MAPI peut être configuré de manière statique dans le registre et le point final d’annuaire peut être corrigé dans un fichier de configuration.
Pour corriger le point final MAPI, utilisez le paramètre suivant dans le registre.
HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystem\TCP/IP Port [DWORD] correspond à la valeur du port IP à utiliser.
Pour corriger le point final de services d’annuaire, éditez la valeur RpcTcpPort dans le registre.
HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters\RpcTcpPort [String] est la valeur à utiliser par le port IP.
| Remarque : |
|---|
| Il n’est pas conseillé de modifier la valeur par défaut des ports Outlook Anywhere. |
Configurer les paramètres de chiffrement RPC
Dans la version RTM d’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 mettez votre organisation à niveau vers la version RTM d’Exchange 2010, vos clients exécutant Outlook 2007 ou des 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. Si vous n’avez pas désactivé le chiffrement RPC, ce qui n’est pas conseillé, vos utilisateurs devront configurer sa prise en charge dans Outlook 2003 ou vous devrez faire appel à une stratégie de groupe pour contraindre Outlook 2003 à recourir au chiffrement RPC.
Les messages d’erreur suivants sont des symptômes de ce problème :
Impossible de démarrer Microsoft Office Outlook. Impossible d’ouvrir la fenêtre Office. Impossible d’ouvrir l’ensemble de dossiers.
Impossible d’ouvrir vos dossiers de messagerie par défaut. Impossible d’ouvrir la banque d’informations.
Si vos utilisateurs travaillent en mode Exchange mis en cache, Office n’affichera pas de message d’erreur mais démarrera en mode déconnecté.
Par défaut, Exchange 2010 Service Pack 1 (SP1) ne chiffre pas le point de terminaison RPC. Si vous avez terminé l’installation d’Exchange 2010 SP1 dans votre organisation, les clients Outlook 2003 pourront se connecter au serveur Exchange sans configuration supplémentaire.
Pour plus d’informations sur ce problème et ses solutions, consultez la page Problèmes de connexion à Outlook avec les boîtes aux lettres Exchange 2010.
Configurer Outlook 2003 pour utiliser le chiffrement RPC
Pour configurer les Outlook 2003 pour utiliser le cryptage 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.
Sélectionnez l’onglet Sécurité.
Sélectionnez Chiffrer les données entre Microsoft Office Outlook et Microsoft Exchange Server.
Cliquez sur OK.
Configurer votre base de données de boîte aux lettres
Chaque base de données de boîtes aux lettres contient une valeur RPCClientAccessServer. Cette valeur est établie lorsque la base de données est créée ; elle détermine le serveur d’accès au client ou le groupe d’accès au client qui sera utilisé par les clients qui possèdent des boîtes aux lettres sur ce serveur de boîtes aux lettres. Cette valeur détermine également l’emplacement du point final RPC. Pour les clients Outlook 2007 et Outlook 2010, cette valeur est obtenue à partir du service de découverte automatique.
La valeur par défaut de RPCClientAccessServer est déterminée par les règles suivantes :
Si vous avez configuré un groupe de serveurs d’accès au client au sein de votre site Active Directory, l’adresse de ce groupe sera utilisée.
Si un groupe n’existe pas au sein du site Active Directory et si vous avez le rôle serveur d’accès au client et le rôle de serveur de boîtes aux lettres sur le même serveur physique, la valeur de la propriété RPCClientAccessServer d’un serveur de boîtes aux lettres en particulier sera la même que celle du serveur de boîtes aux lettres.
Sinon, la valeur de la propriété RPCClientAccessServer d’un serveur de boîtes aux lettres en particulier sera définie pour un serveur d’accès au client aléatoire au sein du site Active Directory.
Remarque :Il n’est pas recommandé d’installer tous les rôles serveur sur un seul ordinateur qui est également un contrôleur de domaine. Bien que cette configuration soit prise en charge, elle n’est pas recommandée. Si vous avez créé une base de données de boîtes aux lettres avant la création d’un groupe d’accès au client ou l’installation d’un serveur d’accès au client au sein du site Active Directory, vous devrez reconfigurer la valeur de la propriété RPCClientAccessServer. Si aucun serveur d’accès au client n’existe sur le site Active Directory lorsque la base de données de boîtes aux lettres est créée, la valeur de la propriété RPCClientAccessServer sera définie sur le nom de domaine complet du serveur de boîtes aux lettres. Pour configurer la valeur de la propriété RPCClientAccessServer, utilisez la commande suivante.
Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>
Besoins de latence et de bande passante
Pour les utilisateurs exécutant Outlook sans le mode Exchange mis en cache, d’importants temps de latence entre le client et le serveur affectent directement la fréquence à laquelle Outlook ne répond pas. En général, une latence supérieure à 200 millisecondes (ms) vers le serveur de boîtes aux lettres associé entraînera une faible performance du client.
Étant donné que la latence entre le serveur d’accès au client et la boîte aux lettres doit être inférieure à 10 ms, il est conseillé de toujours configurer la valeur de la propriété RPCClientAccessServer sur un groupe d’accès au client dans le site de base de données de boîtes aux lettres actif.
| Remarque : |
|---|
| Modifier la valeur de la propriété RPCClientAccessServer obligera tous les clients à se reconnecter. |
Configurer le service de carnet d’adresses
Le service de carnet d’adresses est configuré via le fichier Microsoft.Exchange.AddressBook.Service.config. Ce fichier vous permet de configurer les éléments suivants :
Le nombre de connexions simultanées par utilisateur (la limite par défaut est 50).
Désactiver ou activer la journalisation.
L’emplacement, la taille et la période de rétention des fichiers journaux.
Pour activer la journalisation, utilisez la valeur suivante :
< add key="ProtocolLoggingEnabled" value="true" />
© 2010 Microsoft Corporation. Tous droits réservés.