Questions et réponses sur Exchange : tableaux CAS - Rôles serveur, création de client, équilibrage de charge et autres
Henrik Walther
Comprendre les rôles serveur
Q : j'envisage de mettre à niveau notre environnement Microsoft Exchange 2007 vers Exchange 2010. Cette implémentation doit être entièrement redondante à tous les niveaux. Notre organisation comptant environ 3 000 utilisateurs, je souhaite pour commencer installer Exchange sur deux ordinateurs. Chaque ordinateur sera doté des rôles serveur de transport Hub, d'accès au client et de boîtes aux lettres. Les deux ordinateurs seront également membres d'un groupe de disponibilité de base de données, ce qui permettra aux serveurs de répliquer les bases de données entre eux.
De par mon expérience personnelle dans l'environnement Exchange actuel, je sais que si les rôles de transport Hub et de boîtes aux lettres sont présents sur le même ordinateur, le service de dépôt du courrier de Microsoft Exchange privilégie toujours le serveur de transport Hub local. Il n'utilise pas d'autres serveurs de transport Hub dans le site Active Directory en mode tourniquet (round robin), contrairement aux serveurs de boîtes aux lettres qui ne sont pas dotés du rôle serveur de transport Hub.
Si la même chose se produit dans Exchange 2010, il y a un problème. Le fait de conserver la benne de transport sur un membre d'un groupe de disponibilité de base de données n'a aucun sens. Si le serveur membre devient indisponible et que les bases de données de boîtes aux lettres basculent sur l'autre membre du groupe de disponibilité de base de données, les messages dans la benne de transport ne peuvent pas être resoumis.
R : je comprends votre préoccupation. En premier lieu, je peux vous assurer que le groupe de produits Exchange a pris en compte ce scénario. Au tout début de la phase de développement d'Exchange 2010, l'équipe a apporté une modification de conception. Si le service de dépôt du courrier d'Exchange détecte qu'il s'exécute sur un serveur de boîtes aux lettres faisant partie d'un groupe de disponibilité de base de données, il ne privilégie pas le serveur de transport Hub local. Au lieu de cela, la charge est équilibrée sur les autres serveurs de transport Hub dans le même site Active Directory. Si aucun serveur n'est trouvé, il se tourne vers le serveur de transport Hub local.
La cohabitation du service de dépôt du courrier d'Exchange et du rôle de boîtes aux lettres n'est pas la seule chose que les développeurs ont modifiée. Ils sont ainsi intervenus au niveau du rôle de transport Hub pour rediriger un message vers un autre serveur de transport Hub dans le site Active Directory lorsque le rôle de transport Hub est installé sur un serveur qui est aussi doté du rôle de boîtes aux lettres et qui fait partie d'un groupe de disponibilité de base de données. Ces deux modifications ont été apportées pour assurer un haut niveau de disponibilité lorsque les rôles de transport Hub et de boîtes aux lettres coexistent sur un serveur qui est aussi membre d'un groupe de disponibilité de base de données.
Conception de l'accès client
Q : nous concevons actuellement notre solution Exchange 2010, et nous devons déterminer le nombre de tableaux de serveurs d'accès au client (CAS) à créer. Nous aurons deux centres de données, avec pour chaque centre son propre site Active Directory. Devons-nous créer un tableau par site ou serait-il plus judicieux d'avoir plusieurs tableaux par site ?
Par ailleurs, nous utiliserons des groupes de disponibilité de base de données pour protéger les bases de données de boîtes aux lettres, et des copies de chaque base de données seront réparties sur les deux sites. Est-ce qu'un basculement vers une copie sur l'autre site, auquel des utilisateurs sont connectés, nous oblige à reconfigurer manuellement le DNS de manière à pointer les clients vers le tableau CAS de l'autre site ?
R : la décision concernant le nombre de tableaux CAS est simple, car vous ne pouvez créer qu'un tableau par site Active Directory. Si vous essayez d'en créer plus, vous obtiendrez le message d'erreur indiqué dans la figure 1.
.png)
Figure 1 Message d'erreur résultant de la création d'un deuxième tableau CAS dans un site Active Directory.
Comme vous pouvez accéder à une base de données de boîtes aux lettres par le biais de n'importe quel tableau CAS dans votre environnement, il est inutile d'en créer plusieurs. Même si vous pouviez en créer d'autres, seul le premier serait utilisé.
Quant à votre autre question, tant qu'il y a au moins un serveur CAS dans le tableau CAS dans le site 1 de disponible, il est inutile de reconfigurer le DNS de manière à pointer les clients vers le tableau de l'autre site après un basculement. Les serveurs CAS disponibles dans le site 1 communiquent directement avec les serveurs de boîtes aux lettres (qui stockent les bases de données actives pour les utilisateurs dans le site 1) via RPC.
Création d'un client
Q : existe-t-il des pratiques recommandées pour la création d'un tableau CAS Exchange 2010 dans un site Active Directory ?
R : je vous conseille de créer le tableau CAS avant de créer les bases de données de boîtes aux lettres ou de déplacer les boîtes aux lettres sur un serveur de boîtes aux lettres Exchange 2010. Les bases de données de boîtes aux lettres Exchange 2010 ont un attribut appelé RpcClientAccessServer. Si aucun tableau CAS ne figure dans le site Active Directory au moment où la base de données est créée, le nom de domaine complet (FQDN) d'un serveur CAS Exchange 2010 dans le site Active Directory est affecté à l'attribut. Si vous créez le tableau CAS avant les bases de données de boîtes aux lettres, cet attribut recevra à la place le FQDN du tableau CAS, comme le montre la figure 2.
.png)
Figure 2 Attribut RpcClientAccessServer sur une base de données de boîtes aux lettres.
En quoi cela est-il une bonne idée ? Le client Outlook (qu'il s'agisse d'Outlook 2003, 2007 ou 2010) ne prendra pas automatiquement en compte la modification. Si vous utilisez Outlook 2007 ou 2010, vous pouvez forcer la mise à jour du profil en rendant l'ancien point de terminaison RPC indisponible ou en procédant à une réparation du profil. Toutefois, Outlook 2003 ne peut pas modifier le point de terminaison et n'inclut pas de fonctionnalité de réparation du profil. Vous devrez donc accéder au profil et le modifier manuellement en supprimant le nom d'utilisateur, en le rajoutant, puis en cliquant sur le bouton Vérifier le nom. Cette approche n'est pas idéale, et implique de surcroît les utilisateurs finaux. Par conséquent, il est fortement conseillé de créer le tableau CAS à l'avance.
Équilibrage de charge pour les tableaux CAS
Q : nous comptons utiliser un équilibrage de charge matériel à la place de Windows NLB pour notre tableau CAS, et nous nous demandons s'il est possible de définir des ports statiques pour le nouveau service d'accès au client RPC Exchange 2010. Notre fournisseur d'équilibrage de charge matériel nous recommande de ne pas utiliser de ports dynamiques. Si nous pouvons définir des ports statiques pour ce service, recommandez-vous d'utiliser certains ports en particulier ?
R : comme dans les versions précédentes, Exchange 2010 vous permet de définir des ports statiques pour le service d'accès au client RPC. Vous devez procéder ainsi pour ce service et le service de carnet d'adresses Exchange, car Outlook communique avec ces deux services via MAPI. Par ailleurs, les connexions de dossier public ont toujours lieu sur les serveurs de boîtes aux lettres.
Pour définir un port statique pour le service d'accès au client RPC sur un serveur CAS, vous devez ouvrir le Registre sur chaque serveur CAS dans le tableau CAS, et naviguer jusqu'à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC. Créez une clé nommée ParametersSystem, puis sous celle-ci, créez une entrée REG_DWORD nommée Port TCP/IP. La valeur de DWORD doit correspondre au numéro de port désiré (voir figure 3).
Il n'y a aucune méthode recommandée concernant les ports RPC statiques. La seule recommandation est d'utiliser un port non affecté et inutilisé sur votre réseau d'entreprise. Le service informatique de Microsoft a opté pour le port TCP/IP 7575 dans son réseau d'entreprise. Utilisez un port qui est adapté à votre situation.
Pour définir un port statique pour le service de carnet d'adresses Exchange, ouvrez le fichier microsoft.exchange.addressbook.service.exe.config situé à l'emplacement C:\Program Files\Microsoft\Exchange Server\V14\Bin dans le Bloc-notes. Remplacez ensuite la valeur par le port TCP/IP que vous voulez utiliser. Vous ne pouvez pas utiliser le même port TCP/IP pour le service d'accès au client RPC et le service de carnet d'adresses Exchange.
.png)
Figure 3 Configuration d'un port statique pour le service d'accès au client RPC sur un serveur CAS.
Après avoir configuré le port, vous devez redémarrer le carnet d'adresses Microsoft Exchange et le service d'accès au client RPC Microsoft Exchange. Pour définir un port statique pour les connexions de dossier public, suivez les mêmes étapes que celles que vous avez effectuées pour modifier le port TCP/IP utilisé pour le service d'accès au client RPC. La seule différence est que vous devez également suivre cette procédure sur les serveurs de boîtes aux lettres Exchange 2010, et ce en raison des connexions de dossier public au niveau du service d'accès au client RPC sur le rôle serveur de boîtes aux lettres. Une fois le port défini pour les connexions de dossier public, vous devez redémarrer le service d'accès au client RPC Microsoft Exchange sur chaque serveur de boîtes aux lettres.
Connexions Outlook
Q : j'ai entendu dire que seuls Outlook 2007 et 2010 peuvent se connecter à un service d'accès au client RPC ou à un tableau CAS. Est-ce que cela est vrai ?
R : par le passé, la documentation d'Exchange 2010 indiquait à tort que vous ne pouviez pas vous connecter au service d'accès au client RPC ou à un tableau CAS à l'aide d'un client Outlook 2003. C'est ce que l'on appelle un « bogue de documentation ». En fait, les clients Outlook 2003 sont entièrement pris en charge. Vous devez simplement veiller à activer le chiffrement RPC dans le profil Outlook ou à désactiver l'exigence de chiffrement RPC sur les serveurs CAS. Du point de vue de la sécurité, Microsoft vous recommande d'activer le chiffrement RPC dans le profil Outlook. Pour cela, vous pouvez utiliser une stratégie de groupe. Pour les étapes à suivre, consultez l'article de la Base de connaissances Problèmes de connexion d'Outlook avec des boîtes aux lettres Exchange 2010 en raison de l'exigence de chiffrement RPC.”
Équilibrage de la charge avec Windows NLB
Q : lorsque l'équilibrage de la charge réseau Windows (WNLB) est utilisé pour équilibrer la charge du trafic vers un tableau CAS Exchange 2010, le FQDN de WNLB doit-il correspondre à celui du tableau CAS ?
R : il ne s'agit en aucun cas d'une obligation. Par exemple, si vous utilisez Windows NLB pour équilibrer la charge du trafic à destination du tableau CAS, vous pouvez spécifier un FQDN pour WNLB (par exemple, casarray01.contoso.com), et assigner outlook.contoso.com au tableau CAS. Cette approche fonctionne parfaitement et est entièrement prise en charge. Tant que l'enregistrement DNS interne pour le tableau CAS pointe vers l'adresse IP virtuelle de WNLB, tout doit fonctionner sans accrocs.
Henrik Walther* est un Microsoft Certified Master : Exchange 2007 et un MVP Exchange, avec plus de 15 ans d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour Timengo Consulting (Microsoft Gold Certified Partner basé au Danemark) et comme rédacteur technique pour Biblioso Corporation (société basée aux États-Unis et spécialisée dans les services de documentation et de localisation gérés). Vous pouvez envoyer un message électronique à Walther à l'adresse exqa@microsoft.com.*