Il faut beaucoup de temps…

Article original publié le lundi 20 février 2012

Suite à notre récente annonce de la sortie des correctifs cumulatifs 1 pour Exchange 2010 Service Pack 2, vous verrez que nous avons effectué une tonne de corrections et je voulais en souligner une plus précisément et peut-être en même temps fournir des informations générales sur la façon dont ces problèmes sont découverts et comment nous procédons pour les corriger.

Ce correctif spécifique est celui astucieusement référencé 2556113, avec le titre Il faut beaucoup de temps pour télécharger un carnet d’adresses hors connexion (OAB) dans une organisation Exchange Server 2010.

Avec un titre comme ça, vous pourriez penser que nous avions trouvé un moyen d’accélérer les téléchargements de carnet d’adresses hors connexion. Par exemple, que nous avions réussi simplement en supprimant au hasard quelques utilisateurs du carnet d’adresses hors connexion, ceux que vous ne connaissez pas, comme les personnes qui travaillent à la comptabilité au quatrième étage. Ou peut-être, que nous avions essayé de réduire les détails inclus dans le carnet d’adresses hors connexion, par exemple en supprimant simplement les informations inutiles comme les noms de famille, l’emplacement du bureau ou les numéros de téléphone. Ou que nous avions tout simplement augmenté la vitesse d’Internet... c’est tellement simple.

Eh bien non, nous n’avons pas procédé de la sorte ; au lieu de cela, nous avons ajouté une logique pour s’assurer que Outlook tente de télécharger le carnet d’adresses hors connexion depuis le serveur d’accès client le plus proche de soi.

« Pourquoi? », vous demanderez-vous. Eh bien, c’est une bonne question, et je réponds comme l’article de la base de connaissances Microsoft « Considérez le scenario suivant… ».

• Vous avez deux sites Active Directory sur un réseau lent dans une organisation Microsoft Exchange Server 2010.
• Vous avez un serveur d’accès client Exchange Server 2010 et un serveur de boîtes aux lettres Exchange Server 2010 dans un site Active Directory.
• Vous avez un serveur d’accès client Exchange Server 2010 et ajoutez un utilisateur Office Outlook dans l’autre site Active Directory.
• L’utilisateur dont la boîte aux lettres se trouve dans le site Active Directory différent tente de télécharger le carnet d’adresses hors connexion Exchange.

Dans ce scénario,le téléchargement du carnet d’adresses hors connexion est très long.

Eh bien oui, sans blague, c’est tout à fait possible. Si vous avez un gros carnet d’adresses hors connexion, cela peut vraiment prendre beaucoup de temps. Mais étendons-nous un peu sur ce scénario, car il y a quelques informations dont vous avez besoin ; en effet, avoir un site AD avec rien d’autre mis à part un serveur d’accès client ne semble pas un coup très intelligent pour la plupart des gens.

Donc envisagez plutôt ce scénario plus détaillé :

• Vous avez un déploiement centralisé. Toutes les boîtes aux lettres sont dans un emplacement central.
• Vous avez beaucoup de petites antennes où les gens atterrissent et travaillent.
• Ces antennes sont connectées au site central au moyen de réseaux médiocres. Satellite, RNIS, RTCP, dispersion troposphérique(j’ai eu un client dans ce cas de figure une fois. Brillant, jusqu’à ce qu’il y ait eu une tempête), mauvaise liaison, etc.
• Votre carnet d’adresses hors connexion est important. Il est grand. Il n’est pas petit. Vous avez le choix de la définition que vous préférez. Il suffit de le dire : il est d’une taille dont vous vous souciez.
• Votre client Outlook tente de télécharger le carnet d’adresses hors connexion, à partir d’un centre de données centralisé. Le client Outlook utilisé par la personne assise à côté de vous fait de même, et le type au look marrant là-bas dans le coin aussi. Vous téléchargez tous le même carnet d’adresses hors connexion, via la même liaison médiocre. Cela devient très lent.

Avec un peu de chance, vous pouvez vous apercevoir que vous vous disputez la même bande passante, tout en essayant aussi de travailler, et même si la technologie de client BITS utilisée pour les téléchargements de carnet d’adresses hors connexion est bonne, cela ne va pas vraiment vous aider beaucoup.

Vous ajoutez donc un serveur d’accès client à chaque emplacement distant. En fait, comme le diagramme détaillé dans https://technet.microsoft.com/en-us/library/bb232155.aspx le suggère. L’idée étant que l’ordinateur client téléchargera le carnet d’adresses hors connexion à partir du serveur d’accès client local. Eh bien, ça semble être une bonne idée – mais ce n’est pas la façon dont Exchange a travaillé jusqu’à présent. Avant la version 2010 SP2 RU1…

Comment fonctionnait-il alors ? Et pourquoi suis-je en train de vous dire que TechNet vous a menti ?

Eh bien, pour répondre à la première question, l’URL à partir de laquelle le client télécharge le carnet d’adresses hors connexion est fournie au client par le service de découverte automatique. Et le code AutoDiscover a toujours choisi une URL depuis laquelle télécharger le carnet d’adresses hors connexion à partir du site AD où se trouve votre boîte aux lettres, et pas du site AD où se trouve votre ordinateur client.

Pour répondre à la seconde de ces questions, vous devez d’abord comprendre que TechNet n’a jamais tort (mes amis dans l’UE, comme Scott Schnoll, se vexent si vous sous-entendez que leurs articles sont inexacts). C’est juste que parfois, d’un certain point de vue, il ne sont pas justes. TechNet décrit cela comme si ça faisait partie des spécifications d’origine quand 2007 a été conçu. Je n’aurais probablement pas dû vous dire ça, mais flûte, c’était le cas et ça n’a pas été réalisé. Ces choses se produisent dans un produit logiciel avec plus de 20 millions de lignes de code et que, vous le savez, les choses changent tout le temps. TechNet ne ment généralement pas, enfin pas beaucoup.

Revenons-en à comment ça fonctionne. Réfléchissez-y seulement un moment. Vous avez un carnet d’adresses hors connexion de 1 Go. Et vous ajoutez un réplica du carnet sur un serveur d’accès client sur le site AD distant éloigné où les utilisateurs se trouvent. Cependant, ils ne l’utilisent jamais. (Ok, à moins que leurs boîtes aux lettres soient également sur le même site AD, mais ce n’est pas le scénario n’est-ce pas ?). Ça ressemble un peu à ce diagramme.

Outlook utilise le serveur d’accès client le plus proche de l’ordinateur client pour les demandes de découverte automatique du client (bon, il devrait, nous allons y revenir dans un moment) mais l’URL du carnet d’adresses hors connexion qu’il retourne est celle du serveur d’accès client sur le même site AD que la boîte aux lettres. Donc, même si nous répliquons le carnet sur le site AD B, le client extrait le carnet du site AD A.

Ainsi, un client important ayant beaucoup de petits sites et un carnet d’adresses hors connexion énorme raconte que cela ne fonctionne pas et que les téléchargements terrassent la bande passante WAN, quelle qu’elle soit. Alors, que pouvons-nous faire à ce sujet ? Il s’avère qu’il y a quelques façons de résoudre ce problème, et je dois ajouter que c’est l’une des parties de plaisir de mon travail, d’essayer de résoudre ce genre de question.

1. Ils pourraient réduire la taille de leur carnet d’adresses hors connexion, accélérer leur WAN, rapprocher les bureaux éloignés. Aucune de ces solutions n’étaient envisageables, bien que nous le leur ayons demandé.
2. Nous pourrions créer beaucoup de carnets d’adresses hors connexion ayant le même contenu et spécifier, à un niveau utilisateur ou base de données, le carnet que l’utilisateur doit télécharger. Et ensuite, nous n’avons que ce carnet-là disponible à l’emplacement distant, donc la découverte automatique fournit la seule URL possible pour le carnet, à l’emplacement distant. Maintenant, cela semble bien, sauf que les utilisateurs se déplacent d’un site à l’autre et un téléchargement signifierait alors un double saut en réseau lent. Aïe, oubliez donc ça.
3. Même chose avec les boîtes aux lettres – déplacer les boîtes aux lettres vers les emplacements distants lorsqu’ils se déplacent plus la complication administrative et la question de la haute disponibilité... cela entrainerait une augmentation des coûts.
4. Nous pourrions faire une sorte d’adresse IP inverse de mappage au site AD. Maintenant, je crois que c’était la façon dont nous avions prévu de résoudre ce problème à l’origine, et c’est en fait assez difficile. C’est difficile parce que vous devez vous assurer que tous les sous-réseaux d’où un client pourrait provenir se trouvent dans des Sites et services AD, puis essayer une rétroconception du site AD dans lequel l’utilisateur se trouve, puis regarder les coûts de liaison au site et… vous avez l’idée, je pense. C’est complexe et vaincu par NAT, et si l’admin ne liste pas tous les sous-réseaux possibles dans Sites et services AD.
5. Nous pourrions nous « immiscer » dans DNS ou le code XML AutoDiscover pour essayer de faire croire au client qu’il communique avec l’emplacement centralisé alors qu’en fait il communique avec une instance IIS locale. Encore une fois, c’est complexe, difficile à implémenter et à maintenir, et tout simplement vilain.
6. Quelque chose d’autre : j’ai choisi cet exemple, car les autres semblaient vraiment difficiles.

Revenons à quelques courts paragraphes plus haut à la phrase disant « Outlook utilise le serveur d’accès client le plus proche de l’ordinateur client pour les demandes de découverte automatique du client » (j’avais dit que j’y reviendrais). Eh bien, cela vaut la peine de s’y attarder à cause de ce qu’on appelle AutoDiscoverServiceSiteScope.

AutoDiscoverServiceSiteScope est un paramètre de serveur d’accès client (CAS) qui permet au client Outlook de mapper des sites AD au CAS dans le but de trouver le CAS le plus proche du client pour les demandes de découverte automatique. Pour cela, il cherche des Points de connexion de service (SCP) qui sont en fait des pointeurs vers le service de découverte automatique.

Voici comment ça fonctionne. Quand un client Outlook démarre, il se détourne vers AD et recherche tous les SCP mis là par la configuration Exchange. Il en trouve plusieurs (nous espérons), et chacun a un attribut, l’attribut Keywords, qui est défini/modifié/parfois bousillé par l’utilisation de Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB, etc. L’attribut Keywords est utilisé pour spécifier de quels sites AD ce CAS est responsable pour les demandes de découverte automatique.

Lorsque le client Outlook détecte plus d’un SCP, il construit une liste des SCP utilisables en comparant la valeur stockée dans l’attribut Keywords avec son propre site AD (qui est actualisé dynamiquement par le service Netlogon local, lorsqu’il démarre ou change d’adresse IP).

Il construit ensuite une seule liste, soit avec tous ceux qui correspondent à son site AD (où l’attribut Keywords = Site AD du client) soit, s’il n’y en a aucun, il met tous les SCP dans la liste. Ce sont les serveurs qu’il peut utiliser pour ses demandes de découverte automatique.

Il démarre ensuite par la tête de liste (la liste est toujours dans le même ordre, à la date d’installation) et essaie de se connecter à l’URI contenue dans l’attribut ServiceBindingInformation – qui est l’emplacement du service AutoDiscover lui-même. Il publie ensuite le code XML, obtient une réponse, etc... et vit heureux jusqu’à la fin des temps. Vous trouverez plus de détails sur tous ces aspects de la découverte automatique ici.

Pourquoi est-ce intéressant ? Eh bien ce paramètre AutoDiscoverServiceSiteScopeaide Outlook à trouver le CAS le plus proche de l’emplacement du client, en supposant que l’administrateur a configuré correctement les étendues de site (nous leur expliquons comment le faire). Nous n’avons donc pas besoin de savoir quel CAS est le plus proche du client lorsque nous recevons la demande, puisque ça s’est déjà produit lorsque la demande atteint le CAS.

Lorsque cette demande atteint le CAS, nous découvrons les paramètres à retourner au client – mais nous oublions toujours une chose : que le carnet d’adresses hors connexion dont l’utilisateur a besoin, peut être local au CAS sur lequel nous exécutons la demande, et au lieu de cela, nous avons toujours donné à l’utilisateur une URL d’un CAS très éloigné. Et c’est ce qu’il fallait corriger.

La solution à ce problème est donc théoriquement très simple et signifie que nous n’avons pas à inventer une nouvelle façon de découvrir le CAS le plus proche du client, puisque nous en avons déjà un qui fonctionne très bien !

Si nous faisons l’hypothèse que l’administrateur a configuré AutoDiscoverServiceSiteScope correctement, le CAS auquel le client se connecte pour la découverte automatique (AutoDiscover) sera le plus proche du client. Si cette hypothèse est vrai, le CAS pour déterminer ce qu’il faut retourner dans le code XML AutoDiscover doit simplement vérifier s’il a une copie du carnet d’adresses hors connexion dont l’utilisateur a besoin, auquel cas il fournit simplement sa propre URL de carnet. Pas pour un CAS dans le site AD où se trouve la boîte aux lettres de l’utilisateur. Bien sûr, s’il n’a pas de copie du carnet dont l’utilisateur a besoin, l’ancien comportement devraient l’emporter, c’est-à-dire que le CAS retournera l’URL du carnet d’un CAS sur le site AD de boîtes aux lettres.

Donc, fondamentalement le diagramme après changement ressemble à ceci :

Maintenant c’est beaucoup plus favorable pour le WAN n’est-ce pas ? Une copie se réplique sur le WAN et tous les clients à cet emplacement obtiendront désormais le carnet d’adresses hors connexion à partir de leur CAS local.

Que devez-vous faire pour bénéficier de ce nouveau comportement ? Simplement deux choses : déployez SP2 RU1 sur le CAS et vérifiez que vos paramètres AutoDiscoverServiceSiteScope sont configurés correctement.

J’espère que ce billet vous sera utile. Puisse votre WAN être éternellement performant.

Greg Taylor
Responsable de programme principal
Expérience Client Exchange

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici It Takes a Long Time…