INFO: Démystifier le carnet d'adresses OCS 2007 R2 et son utilisation avec MOC 2007 R2

Le carnet d'adresses d'Office Communications Server 2007 (et R2) a toujours été le *gros* défaut du produit...

A titre d'exemple aux débuts d'OCS 2007: nous avons connu des problématiques chez un client, où la génération entrait en erreur (deux frontaux généraient les carnet d'adresses en même temps) et badaboom, les clients s'amusaient à télécharger une carnet d'adresses complet à chaque démarrage. A 15 Mo le carnet d'adresses et 20 000 clients en pilote dit "étendu" dans un Active Directory qui comportait plus de 75 000 utilisateurs "actifs", je vous laisse imaginer les dégâts sur la consommation réseau... Ce bug avait été remonté à Microsoft à l'époque et un correctif "privé" fourni en retour, pour enfin être intégré dans un hotfix "officiel".

Heureusement depuis, le service de carnet d'adresses a évolué. Le but de cert article est de résumer les améliorations apportées dans OCS 2007 R2 visant à réduire les impacts sur la consommation réseau des téléchargements du carnet d'adresses, et surtout comment les configurer afin qu'elles soient 100% fonctionnelles.

Compact Deltas

Dans la mise à jour cumlative #2 (Juillet 2009) d'OCS 2007 R2, Microsoft a introduit un nouveau procédé de génération des deltas, appellé "Compact Deltas". Ces compacts deltas sont les fameux fichiers "C-xxx-yyy.labs" dont vous avez peut-être noté la présence dans votre répertoire (ou partage) où sont stockés les fichiers générés par le processus "ABServer.exe" (s'exécutant (par défaut à 1:30 du matin) sur un serveur frontal, une instance unique tournant à un instant T par Pool...).

Cela va de soit, vous devez avoir un client Communicator 2007 R2 à jour (mise à jour cumulative #2 (build 37) ou ultérieure) pour tirer parti des nouveaux compacts deltas. Mais il ne s'agit pas de la seule amélioration visant à réduire les effets (négatifs) du téléchargement du carnet d'adresses OCS 2007 R2...

Utilisation du service de transfert intelligent en tâche de fond (BITS - Background Intelligent Transfer Service)

Cette modification a été aussi introduite dans la mise à jour cumulative de Juillet 2009, et permet à MOC 2007 R2 (build 37 ou plus donc) d'utiliser BITS afin de 1) ne pas faire échouer le téléchargement lorsque les conditions réseau sont "difficiles" et 2) de s'auto-restreindre en cas de saturation du lien réseau.

L'utilisation de BITS ne s'applique (pour l'instant) qu'aux téléchargements du carnet d'adresses complet (fichiers F-xxxx.lsabs) et requiert d'être activé sur les clients (cf configuration des clients ci-après dans cet article).

Configuration des serveurs frontaux - Web Components dans IIS

Afin que les téléchargements BITS fonctionnent, il est nécessaire de forcer les Web Components IIS (le fameux "Handler") de l'Address Book afin d'envoyer un verbe HTTP "Redirect" (302) au client. Ce processus permet au client d'être directement réferré vers le chemin du fichier à télécharger, et autoriser le client BITS d'y accéder directement.

Pour configurer l'emission du Redirect au travers des Web Components IIS, il est nécessaire de modifier les fichiers "Web.Config" de chaque "Handler" (interne et externe) sur chaque serveur frontal OCS 2007 R2. Cette action n'est pas nécessaire sur les frontaux servant un Pool Directeur puisque ceux-ci ont (normalement) les services d'Address Book et IIS désactivés.

• Utiliser Notepad pour éditer %OCSInstallDir%\Web Components\Address Book Files\Int\Handler\Web.Config
• Changer la valeur dans la clef "redirect" de "false" à "true" (défaut: false);
• Enregistrer et fermer le fichier, et répéter l'opération avec %OCSInstallDir%\Web Components\Address Book Files\Ext\Handler\Web.Config
• Redémarrer les services IIS (iisreset /noforce) ou recycler l'application IIS associée.

Remplacez %OCSInstallDir% par le chemin d'installation des binaires OCS 2007 R2 (par défaut: %ProgramFiles%\Microsoft Office Communications Server 2007 R2).

Voici donc quelques captures:

Comportement avant changement du Handler (pas de REDIRECT)

Configuration du Handler

Comportement après configuration du Handler (avec REDIRECT)

Configuration des serveurs frontaux - Générateur de carnet d'adresses

Le générateur de carnet d'adresses (ABServer.exe) étant une application .NET, vous aurez probablement remarqué qu'il existe un fichier "ABServer.exe.config" au même emplacement que l'exécutable. Ce dernier permet en particulier de configurer la génération des "Compact Deltas":

• Clef "CompactDeltaOnly" (défaut: "false") - Passer à "true" afin d'éviter la génération des "anciens Deltas" (D-xxx-yyy.lsabs). Particulièrement utile pour libérer un espace disque non négligeable à condition de n'avoir que des clients MOC 2007 R2 build 37 ou plus;
• Clef "CompactDelta_ExcludedIfSipURI" (défaut: "title,physicalDeliveryOfficeName") - Permet d'exclure les attributs "title" (Titre) et "physicalDeliveryOfficeName" (Office) des entrées dans les compact deltas pour les contacts étant activés pour OCS. Les clients exécuteront des requêtes LDAP pour récupérer ces attributs s'ils n'ont jamais été récupérés auparavant;
• Clef "CompactDelta_AlwaysExclude" (défaut: "otherHomePhone,otherMobile,manager") - Permet purement et simplement d'ignorer ces attributs dans les compacts deltas.

Il est important que vous vérifiez que ces clefs sont bien présentes dans le fichier "ABServer.exe.config" de chaque serveur frontal participant à un Pool, et qu'elles soient bien sûr toutes en corrélation. Dans le cas contraire, vos Compact Deltas ne seront plus cohérents en fonction du serveur frontal qui sera en charge de la génération et vous risquez de compromettre leur intégrité, forçant ainsi les clients à ré-effectuer un téléchagement complet du carnet d'adresses.

Configuration du carnet d'adresses via ABSConfig.exe

ABSConfig.exe est un outil du Resource Kit permettant (comme son nom l'indique :)) de configurer la génération du carnet d'adresses sur les serveurs frontaux d'un Pool donné (il n'est donc utile de ne le faire qu'une fois par Pool, et non par serveur frontal).

Je passe la partie (certes importante mais hors sujet ici) sur la normalisation des numéros de téléphone... Le but est de s'intéresser ici aux optimisations qu'il est possible d'apporter lors de la génération du carnet d'adresses afin de réduire la taille de celui-ci.

La génération du carnet d'adresses considère qu'un objet Active Directory (et certains de ses attributs) doivent être transposés dans le carnet d'adresses OCS 2007 (R2) sous certaines conditions. Une de ces conditions, la plus fondamentale est la colonne "Is this Attribute Required?" qui peut être positionné à "Yes" (coché) ou "No" (décoché). Il s'agit donc d'une logique déterministique, à savoir que si l'un de ces attributs est présent (non vide) dans l'objet Active Directory, alors ce dernier est transposé dans la carnet d'adresses.

Par défaut, les attributs requis sont donc l'adresse SIP, et les champs de type téléphone. Ce filtre, très inclusif, a pour but d'autoriser les clients activés pour la téléphonie de "voir" et donc "appeler" les numéros de téléphones d'utilisateurs non activés pour OCS (qu'il s'agisse de fonctionnalités pures "Enterprise Voice" ou juste de type "PBX Integration" (comme le Remote Call Control par exemple)).

Cependant, un certain nombre de sociétés, donc certains de mes clients, n'intègrent pas (et n'intègreront malheureusement peut-être jamais) OCS avec de la téléphonie, et désirent donc n'inclure dans le carnet d'adresses OCS *que* les utilisateurs activés pour OCS.

Ainsi, les paramètres par défaut sont les suivants:

Et les paramètres permettant d'inclure *seulement* les utilisateurs activés pour OCS, ainsi que les groupes de distribution Exchange sont les suivants (en laissant les autres attributs configurés par défaut):

Afin d'alléger encore le carnet d'adresses, il est aussi possible de supprimer certains attributs en sélectionnant la ligne correspondant ceux-ci et en pressant la touche "Suppr" (ou "Del"). Evidemment, vous devez conserver l'attribut msRTCSIP-PrimaryUserAddress

Une fois les paramètres changés, effectuez une regénération complète des ressources utilisateurs (ABServer.exe -RegenUR), ce qui a pour effet de supprimer tous les carnet d'adresse jusqu'alors générés, et de repartir sur une nouvelle base. Le nouveau carnet d'adresses sera alors généré en prenant en compte la nouvelle configuration.

Cette configuration est à faire au plus tôt car elle va forcer les clients à télécharger un carnet d'adresses complet. D'ici là, la récupération des deltas échouera.

Configuration des clients

Réglage des téléchargements

Il existe essentiellement deux paremètres qui sont susceptibles de vous intéresser afin de régler les clients:

• Le premier permet de régler le délai initial de téléchargement du carnet d'adresses après démarrage du client. Par défaut, et depuis la mise à jour cumulative #2 (Juillet 2009, build 37), le client introduit un délai aléatoire avant de vérifier/télécharger les mises à jour du carnet d'adresses (cela peut aller jusqu'à 60 minutes).
• Ce changement permet de réduire les chances qu'un nombre exceptionnellement grand de clients téléchargent au même moment le carnet d'adresses (ce qui est fréquent le matin lors des pics de connexion...)
• Ce délai peut donc être soit désactivé (mis à 0) ou forcé à une valeur (exemple: 5) en *minutes*
• En toute objectivité, je recommande de conserver la configuration par défaut, sauf lors des phases de troubleshooting (avec Fiddler par exemple) et/ou pilote -- les seuls cas où l'on est "pressé" de recevoir les mises à jour rapidement.
• Le second a été introduit dans la mise à jour cumulative #3 (Octobre 2009, build 56) permet de régler le mode de téléchargement des Compact Deltas:
• Désactiver le téléchargement des Compact Deltas
• Activer le téléchargement des Compact Deltas (mode par défaut)
• Activer le téléchargement des Compact Deltas mais ne pas utiliser de requêtes LDAP

Activation de BITS

Une fois satisfaits avec le comportement du générateur d'Address Book et de votre client, il ne vous reste plus qu'à activer le téléchargement au travers du service BITS (Background Intelligent Transfert Service). N'oubliez pas que BITS est natif dans Windows et que BITS 2.0 est requis (Windows XP ou ultérieur il me semble).

Pour activer BITS, il suffit de mettre la stratégie HKCU\Software\Policies\Microsoft\EnableBitsForGalDownload (REG_DWORD) a 1 (un). Pour désactiver, mettre 0 (zéro) ou supprimer la valeur.

Template ADM pour stratégie de groupe (GPO)

Afin de faciliter la configuration de vos clients, votre serviteur (moi =°)) a donc mis à votre disposition un fichier Communicator.adm modifié (et donc non officiel) ici:

http://cid-21ad54fd70600673.skydrive.live.com/self.aspx/.Public/Communicator.zip

Pour conclure

Depuis les mises à jour cumulative #2 d'OCS 2007 R2 et de MOC 2007 R2 il est possible de réellement et considérablement réduire les impacts liés au téléchagement du carnet d'adresses.

Pour que ces améliorations soient optimales, il est nécessaire que les étapes suivantes soient effectuées:

• Maintenir une excellente corrélation entre les versions "serveur" et "client": Je dirai que les mises à jour cumulatives #2 sont un "must have", et je ne saurai que trop conseiller à minima les mises à jour cumulatives #3 [EDIT 16/04/2010 - le CU #5 est disponbile, cf mon article à ce sujet]
• Configurer les serveurs frontaux OCS 2007 R2 afin de configurer les "Handlers" internes et externes pour que BITS fonctionne - configurez ensuite les clients manuellement, ou par stratégie.
• Optionnellement, optimiser la taille de votre carnet d'adresses en n'incluant que les utilisateurs et/ou attributs donc vous avez besoin.

Un dernier petit conseil pour la route... TESTEZ toute modification dans un environnement de pré-production (avec un annuaire Active Directory peuplé et idéalement représentatif de la production). Cela permettra d'OBSERVER tout changement comportemental du serveur ou des clients, et de valider que ceux-ci réagissent comme attendu.