Démystifier l’objet CAS Array - Partie 2

Article d’origine publié le jeudi 29 mars 2012

Bienvenue ! Dans Démystifier l’objet CAS Array - Partie 1, nous avons couvert ces trois éléments pour commencer à démystifier l’objet CAS Array dans Exchange Server 2010 :

1. Un objet CAS Array n’équilibre pas la charge de votre trafic
2. Un objet CAS Array ne prend pas en charge OWA, ECP, EWS, Autodiscover, IMAP, SMTP ni POP
3. Un objet CAS Array n’a pas besoin de figurer sur votre certificat SSL

Dans cette partie 2, nous allons aborder les trois éléments suivants et lever une fois pour toutes le mystère de l’objet CAS Array pour vous aider à corriger des déploiements existants ou à planifier de façon plus stratégique vos déploiements futurs.

4. Un objet CAS Array ne doit pas être résolvable via DNS par des clients externes
5. Un objet CAS Array ne doit pas être configuré ou modifié après la création des bases de données de boîtes aux lettres Exchange Server 2010 et le déplacement de boîtes aux lettres dans ces bases
6. Un objet CAS Array doit être configuré même si vous avez seulement un CAS ou un seul serveur polyvalent.

Un objet CAS Array ne doit pas être résolvable via DNS par des clients externes

Tel que mentionné dans la partie 1 (au moins deux fois), le nom de domaine complet (FQDN) de votre objet CAS Array doit être différent de celui utilisé pour d’autres services tels que OWA, ECP, EWS, EE, Autodiscover ou du nom d’hôte externe Outlook Anywhere.

La raison principale en est qu’un client Outlook Anywhere tentera d’abord de résoudre le nom de domaine complet de l’objet CAS Array via DNS donc il sait s’il doit essayer une connexion RPC (via TCP) ou accéder directement à HTTPS. Autorisez-vous les connexions RPC (via TCP) à votre Intranet directement depuis Internet ? J’espère que non, et si vous le faites vous allez obtenir un drapeau rouge sur votre rapport du Programme d’évaluation des risques et de l’intégrité pour Exchange. Si le client essaie d’abord de se connecter via RPC (sur TCP), étant capable de résoudre correctement le nom de domaine complet de l’objet CAS Array, il peut y avoir un délai significatif avant que le client retombe pour tenter une connexion HTTPS à l’URL de proxy Outlook Anywhere. Ce délai peut entraîner une augmentation des appels au support technique si les utilisateurs perçoivent ce délai comme des performances dégradées ou une interruption du service.

Pour éviter cette situation, assurez-vous simplement que le nom de domaine complet de l’objet CAS Array interne est unique pour le DNS interne, peut-être comme outlook.corp.contoso.com alors que vos autres URL de service non-RPC (via TCP) utilisent quelque chose comme mail.contoso.com en interne et en externe via DNS divisé.

Si vous n’avez pas eu l’opportunité d’utiliser DNS divisé, c’est quand vous avez un ensemble de serveurs DNS internes ET externes qui gèrent les requêtes pour la même zone de recherche directe, par exemple contoso.com. Les deux infrastructures DNS sont complètement isolées l’une de l’autre. Il n’y a aucun transfert de zone, ni utilisation de l’autre infrastructure comme redirection DNS. Cette configuration permet aux utilisateurs internes se servant de l’infrastructure DNS interne de résoudre l’hôte mail.contoso.com en adresse IP interne (par exemple, 192.168.1.10) qui pointe sur l’IP virtuelle de votre équilibreur de charge, tandis que les utilisateurs externes la résolvent en adresse IP publique qui peut pointer sur votre infrastructure TMG/UAG Forefront orientée Internet dans le réseau de votre périmètre. Il est très courant que l’adresse IP de l’objet CAS Array et l’adresse IP interne des URL de service non-RPC (via TCP) (OWA, ECP, EWS, etc…) soient la même que l’adresse IP virtuelle de l’équilibreur de charge, mais elles peuvent utiliser différents contrôles is-alive afin de détecter si un service est en bon état de fonctionnement.

Votre DNS sert-il une réponse générique ?

J’ai eu au moins un client qui avait un serveur DNS externe qui utilisait un enregistrement générique en réponse à toute requête qu’il recevait pour un nom d’hôte inexistant. Cela signifiait que vous pouviez envoyer une requête à NomExtravagantInexistant.contoso.com et le serveur DNS retournait toujours l’adresse IP du site Web de l’entreprise. (Les dossiers génériques sont tout à fait valables du point de vue des normes Internet. Voir la section 4.3.3 dans RFC 1034 pour des détails).

De ce fait, leurs clients Outlook Anywhere pouvaient toujours résoudre le nom de domaine complet de l’objet CAS Array et tentaient d’abord une connexion RPC (via TCP) avant de passer à HTTPS. Si vous vous trouvez dans une situation similaire avec un serveur DNS externe utilisant des réponses génériques pour une zone de recherche directe particulière, je vous recommande d’éviter l’utilisation de cette zone de recherche directe pour votre URL de proxy Outlook Anywhere.

Un détour rapide, si vous le permettez, pour vous rappeler de ne pas oublier de configurer les écrans d’intégrité des services appropriés pour votre solution d’équilibrage de la charge. Pour optimiser les résultats de la surveillance des services, consultez le fournisseur de votre solution d’équilibrage de la charge. Découvrez le Déploiement de l’équilibreur de charge Exchange Server 2010 pour obtenir une liste de fournisseurs d’équilibreur de charge ayant testé des solutions Exchange 2010 avec les liens vers leurs pages Web pertinentes (pour Exchange 2010). Notez qu’il ne s’agit en aucune façon de la liste définitive des fournisseurs d’équilibrage de charge compatibles. C’est simplement une liste de fournisseurs qui ont choisi de s’engager avec Microsoft directement pour les tests et le support technique des solutions.

Un exemple rapide et brouillon peut être que vos noms de domaine complets basés sur le service HTTPS ont des tests is-alive effectués par rapport aux réponses TCP/443 et que la solution d’équilibrage de la charge arrête l’envoi de nouveau trafic client à tout serveur d’accès client (CAS) qui cesse de répondre sur TCP/443. Le nom de domaine complet du service RPC (via TCP) de l’objet CAS Array peut avoir des tests is-alive effectués sur le mappeur de point de terminaison RPC sur TCP/135, ainsi que sur les deux ports TCP statiques que vous avez choisis pour le service d’accès client RPC et le service de carnet d’adresses. Si l’un de ces trois ports cesse de répondre sur un serveur d’accès client particulier, la solution d’équilibrage de la charge n’envoie pas de nouveau trafic client à ce serveur CAS pour RPC (via TCP) tant que tous les ports ne recommencent pas à répondre. Si vous ne configurez pas les ports TCP statiques, Exchange va choisir un port TCP dynamique pour chaque service au démarrage, ce qui rend les tests is-alive plus difficiles voire impossibles pour certaines solutions d’équilibrage de la charge.

5. Un objet CAS Array ne doit pas être configuré après la création des bases de données Exchange Server 2010

Souvent, nous sommes pressés pour installer les serveurs de boîtes aux lettres, créer les bases de données de boîtes aux lettres et enfin commencer les tests de validation de la solution de stockage avec Jetstress. Puis-je suggérer de ralentir votre équipage un moment afin de vous éviter des problèmes ultérieurs ? Alors que les serveurs de boîtes aux lettres sont considérés par beaucoup comme le rôle de serveur le plus important, c’est n’est pas bon pour vous si la porte est clouée fermée, car vous ne pourrez pas accéder à ceux-ci par le biais des serveurs d’accès client.

Si vous démarrez la création des bases de données de boîtes aux lettres avant qu’un objet CAS Array ne soit en place, vous verrez dans le même site Active Directory un serveur d’accès client aléatoire sur l’attribut RpcClientAccessServer de chaque base de données.

Au lieu de paraître comme il se doit (utiliser le nom de domaine complet de l’objet CAS Array)

Figure 1 : Si un objet CAS Array est créé, la propriété RpcClientAccessServer de la base de données de boîtes aux lettres est remplie avec le nom de domaine complet de l’objet CAS Array

Il ressemblerait à ceci :

Figure 2 : Si l’objet CAS Array n’est pas créé, la propriété RpcClientAccessServer de la base de données de boîtes aux lettres est remplie avec le nom de domaine complet du serveur d’accès client

Les profils clients ressembleraient à cela…

Figure 3 : Si l’objet CAS Array n’est pas créé, les clients Outlook seront configurés avec le nom de domaine complet du serveur d’accès client

Les clients se connecteraient comme suit…

Figure 4 : Les clients se connectent au nom de domaine complet du serveur d’accès client

À première vue, cela peut sembler très inoffensif et tout fonctionne très bien, mais vous configurez vous-même des difficultés ultérieures. Si vous commencez à déplacer les boîtes aux lettres vers Exchange Server 2010 avec cette configuration en place, Outlook utilisera le nom du CAS dans le champ Serveur du profil utilisateur. Cela fonctionnera, à moins que le serveur d’accès client devienne indisponible ou peut-être hors service à une date ultérieure et remplacé par un serveur nommé différemment. Ne préfèreriez-vous pas utiliser un pool de serveurs d’accès client dont la charge est équilibrée avant que ça arrive ? Oui, certainement !

Vous pensez peut-être « OK monsieur je-sais-tout, mais si ce jour arrive, je créerai un objet CAS Array et corrigerai RpcClientAccessServer sur les bases de données et tout ira bien ». Je suis ici pour vous dire que cela ne fonctionnera que pour les boîtes aux lettres que vous déplacez vers Exchange 2010 après ce fait. Tout utilisateur avec un profil Outlook déjà configuré pour pointer sur un nom de CAS et non sur l’objet CAS Array continuera à se connecter au nom du CAS et ne s’actualisera pas lui-même afin d’utiliser le nom de domaine complet de l’objet CAS Array.

Le profil ne s’actualisera pas parce que le client ne recevra pas une réponse ecWrongServer du CAS. Il ne recevra pas cette réponse car tout CAS est un point de connexion valide pour toute base de données de boîtes aux lettres via RPC (sur TCP) ; les clients peuvent donc survivre aux événements permutation/basculement de centre de données sans reconfiguration et tout ce qu’un administrateur doit faire est de basculer l’enregistrement DNS de l’objet CAS Array pour le faire pointer vers un pool survivant de CAS. Actuellement, la seule façon de corriger les profils de boîte aux lettres serait de réparer manuellement les profils dans Outlook, en publiant un fichier PRF Office via l’Objet de stratégie de groupe (GPO) (ne fonctionnera pas pour des machines non jointes à un domaine) ou par la mise hors service du serveur CAS nommé dans les profils des utilisateurs de sorte que le point de terminaison n’est plus disponible. Cette dernière option devrait (test test test !!!) déclencher une réparation complète des profils par Autodiscover dans Outlook 2007 ou Outlook 2010. Outlook 2003 n’est réparable que par réparation des profils ou avec un fichier PRF. AutoDiscover ne mettra pas à jour un profil avec un nouveau nom de serveur dans le cadre du processus Autodiscover normal qui met à jour la configuration Outlook Anywhere et découvre les URL EWS pour les autres fonctionnalités telles que la gestion OOF (absent du bureau), la publication disponible/occupé et la gestion des règles de boîte de réception.

Cela signifie aussi que si vous déplacez une boîte aux lettres d’une base de données dans un Site-A AD qui utilise un objet CAS Array nommé Boston-CASArray vers une base de données dans un Site-B AD qui utilise un objet CAS Array nommé Redmond-CASArray, le profil ne s’actualisera pas et le champ Nom du serveur restera le nom de domaine complet de Boston-CASArray. Vous pouvez garder cela à l’esprit si vous avez une population d’utilisateurs qui migre vers différents sites en raison de changements de poste, ou si vous effectuez un déplacement massif interne de boîtes aux lettres vers un autre site au cours du cycle de vie de la solution. Si jamais vous créez des bases de données Exchange 2010 avant de créer un objet CAS Array, il est impératif que vous corrigiez l’attribut RpcClientAccessServer des bases de données de sorte à utiliser l’objet CAS Array avant de déplacer des boîtes aux lettres dans les bases de données.

6. Un objet CAS Array doit être configuré même si vous avez un seul serveur CAS ou un seul serveur polyvalent.

Réfléchissez un instant à l’argumentation du point précédent. Un client ne s’actualisera pas de sorte à utiliser l’objet CAS Array si vous ajoutez ce dernier ultérieurement. Mais que se passe-t-il si vous n’avez qu’un seul CAS ? Vous pensez peut-être que cela n’importe pas. Je suppose qu’on pourrait dire que ça importe peu à ce moment-là, mais pourquoi ne pas anticiper les choses quand c’est possible et économiser du temps et de la frustration plus tard ? Si jamais dans un an, vous aviez besoin de remplacer ce CAS ? Si vous avez des profils de clients qui pointent tous vers un nom de CAS, vous n’avez aucun moyen de les mettre à jour proprement sans une interruption de service et un travail manuel. Vous devrez réparer les profils avec l’un des moyens déjà mentionnés après l’ajout du nouveau CAS, ou mettre hors service le CAS existant et introduire un nouveau CAS avec le même nom d’hôte, ce qui nécessitera un temps d’arrêt. Pour moi, aucune de ces options n’est acceptable.

Si plus tard les besoins de l’entreprise changent et exigent de vous la disponibilité élevée de l’accès client ? Vous pouvez seulement atteindre ce but en ajoutant un deuxième CAS et une solution d’équilibrage de la charge. Vous vous trouverez à nouveau dans la même galère à devoir réparer le profil de chaque utilisateur par le biais d’un des moyens déjà discutés. Encore une fois, ce ne sont pas des solutions acceptables pour moi.

Ce que je propose, c’est de créer un objet CAS Array dès le début. Comment faire si vous n’avez pas d’équilibreur de charge et seulement un CAS unique ? Simple ! Configurez l’objet CAS Array comme vous le feriez normalement. Donnez-lui un nom, un site AD, un nom de domaine complet et faites simplement pointer l’enregistrement DNS « A » vers l’adresse IP du seul CAS ou du serveur polyvalent unique existant que vous avez à ce moment-là. Vous êtes ainsi paré pour le futur et si jamais vous deviez remplacer le seul CAS ou le serveur polyvalent unique existant, tout ce que vous aurez à faire sera de construire le nouveau serveur, puis changer l’adresse IP de l’enregistrement DNS et tout continuera de fonctionner sans interruption. Si jamais vous voulez ajouter la haute disponibilité ultérieurement, tout ce que vous aurez à faire sera de rendre opérationnelle votre solution d’équilibrage de la charge, puis de changer l’adresse IP de l’enregistrement DNS de l’objet CAS Array pour pointer vers l’adresse IP virtuelle de la solution d’équilibrage de la charge. Facile !

J’espère que cet article vous a été utile pour éclaircir certaines idées fausses sur l’objet CAS Array et fera son chemin en aidant chacun à anticiper une migration d’Exchange Server 2010 saine.

Brian Day
Ingénieur principal de terrain, Messagerie

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici Demystifying the CAS Array Object - Part 2