Serveur de carnet d’adresses : fonctionnalités avancées du carnet d’adresses

Article
03/23/2012

Dernière rubrique modifiée : 2011-04-29

Cette rubrique aborde les fonctionnalités de serveur de carnet d’adresses, telles que la normalisation du numéro de téléphone, le réplicateur d’utilisateurs et le filtrage.

Normalisation des numéros de téléphone du serveur de carnet d’adresses

Office Communicator nécessite des numéros de téléphone au standard RFC 3966/E.164. Pour utiliser des numéros de téléphone non structurés ou formatés de manière incohérente, Office Communications Server s’appuie sur le serveur de carnet d’adresses pour prétraiter les numéros de téléphone avant qu’ils ne soient transmis aux règles de normalisation. Si la propriété WMI UseNormalizationRules a la valeur TRUE, ABServer.exe lit les numéros de téléphone à partir de la base de données RTC, les normalise (si nécessaire), puis écrit les valeurs normalisées dans les fichiers (c’est-à-dire, de téléchargement) du carnet d’adresses et la base de données RTCAb de requête sur le Web du carnet d’adresses. Les clients, tels qu’Office Communicator et Communicator Mobile, peuvent utiliser ces numéros normalisés.

Vous pouvez appliquer deux types de règles aux numéros de téléphone : l’un correspond à l’ensemble de règles génériques qui sont automatiquement effectuées par le serveur. L’autre correspond à un ensemble de règles d’une société exemple qui peut être modifié et qui est inclus dans le dossier d’installation avec ABServer.exe. Les règles de la société exemple incluent un commentaire au début du fichier indiquant aux administrateurs qu’ils doivent, s’ils souhaitent utiliser des règles spécifiques pour leur société, copier ce fichier exemple à l’emplacement de sortie du pool et modifier le nom en Company_Phone_Number_Normalization_Rules.txt, en vue de l’utiliser lors d’actions de synchronisation futures.

Si l’indicateur WMI UseNormalizationRules a la valeur TRUE, les règles sont appliquées aux attributs Active Directory avec une valeur de bit 0x2000 définie dans la colonne Indicateurs. Si la valeur de bit 0x1000 a été définie dans la colonne Indicateurs, la valeur d’attribut Active Directory associée est toujours normalisée.

Sample_Company_Phone_Number_Normalization_Rules.txt est le fichier exemple dans lequel vous configurez les règles spécifiques aux exigences de votre société. Pour l’utiliser, créez une copie Company_Phone_Number_Normalization_Rules.txt. Sinon, le serveur de carnet d’adresses utilisera uniquement les règles génériques configurées par défaut sur le serveur.

Remarque :
Lorsque vous supprimez le serveur de carnet d’adresses, Company_Phone_Number_Normalization_Rules.txt n’est pas supprimé. Si vous souhaitez supprimer ce fichier, vous devez le modifier manuellement.

Réplicateur d’utilisateurs et serveur de carnet d’adresses

Le serveur de carnet d’adresses utilise les données fournies par le réplicateur d’utilisateurs pour mettre à jour les informations obtenues initialement de la liste d’adresses globale. Le réplicateur d’utilisateurs écrit les attributs Active Directory pour chaque utilisateur, contact et groupe dans la table AbUserEntry de la base de données, le serveur de carnet d’adresses synchronise les données utilisateur à partir de la base de données dans les fichiers du magasin de fichiers du serveur de carnet d’adresses, puis dans la base de données de requête sur le Web du carnet d’adresses RTCab. Le schéma pour la table AbUserEntry utilise deux colonnes : Guid utilisateur et Données utilisateur. Guid utilisateur représente la colonne d’index et contient le GUID sur 16 octets de l’objet Active Directory. Données utilisateur est une colonne image qui contient tous les attributs Active Directory mentionnés précédemment pour ce contact.

Le réplicateur d’utilisateurs détermine quels attributs Active Directory écrire en lisant une table de configuration située dans la même instance SQL que la table AbUserEntry. La table AbAttribute contient trois colonnes : ID, Nom et Indicateurs. La table est créée pendant la configuration de la base de données. Si la table AbAttribute est vide, le réplicateur d’utilisateurs ignore la logique de traitement de sa table AbUserEntry. Les attributs du serveur de carnet d’adresses sont dynamiques et récupérés à partir de la table AbAttribute, qui est créée initialement par le serveur de carnet d’adresses à l’activation de ce dernier.

L’activation du serveur de carnet d’adresses renseigne la table AbAttribute avec les valeurs requises pour la prise en charge d’Office Communicator 2007 R2. Le tableau suivant présente ces valeurs actuelles.

Tableau 1. Valeurs de la table AbAttribute

ID	Nom	Indicateurs
1	msExchHideFromAddressLists	0xFF000003
2	givenName	0x01000000
3	Sn	0x02000000
4	displayName	0x03020000
5	Title	0x04000000
6	mailNickname	0x05000400
7	Company	0x06000000
8	physicalDeliveryOfficeName	0x07000000
9	msRTCSIP-PrimaryUserAddress	0x08020800
10	telephoneNumber	0x09022800
11	homeNumber	0x0A002800
12	otherHomeNumber	0x0A002000
13	Mobile	0x0B022800
14	otherMobile	0x0B002000
15	otherTelephone	0x0C002000
16	ipPhone	0x0D002000
17	Mail	0x0E000000
18	proxyAddresses	0x00000105
19	groupType	0x0F010800
20	ManagerouPathId	0x10000000
21		0x11000800

Les numéros dans la colonne ID doivent être uniques et ne jamais être réutilisés. Le fait de garder des valeurs d’ID inférieures à 256 permet également d’économiser de l’espace dans les fichiers de sortie créés par le serveur de carnet d’adresses. Toutefois, la valeur d’ID maximale est de 65 535. La colonne Nom correspond au nom de l’attribut Active Directory que le réplicateur d’utilisateurs doit ajouter dans la table AbUserEntry pour chaque contact. La valeur dans la colonne Indicateurs sert à définir le type d’attribut. Les types d’attributs de serveur de carnet d’adresses suivants sont reconnus par le réplicateur d’utilisateurs, indiqué par l’octet bas de la valeur dans la colonne Indicateurs.

Tableau 2. Attributs du serveur de carnet d’adresses reconnus par le réplicateur d’utilisateurs

Attribut	Description
0x0	Attribut de chaîne. Le réplicateur d’utilisateurs convertit ce type en UTF-8 avant de le stocker dans la table AbUserEntry.
0x1	Attribut binaire. Le réplicateur d’utilisateurs stocke cet attribut dans le blob sans aucune conversion.
0x2	Attribut de chaîne inclus uniquement si la valeur d’attribut commence par « Tél. : ». Cela concerne principalement les attributs de chaîne à plusieurs valeurs, notamment les adresses proxy. Dans ce cas, le serveur de carnet d’adresses s’intéresse seulement aux entrées d’adresses proxy qui commencent par « Tél. : ». Par conséquent, afin de gagner de la place, le réplicateur d’utilisateurs stocke uniquement les entrées qui commencent par « Tél. : ».
0x3	Attribut de chaîne booléen qui, s’il a la valeur TRUE, empêche le réplicateur d’utilisateurs d’inclure ce contact dans la table AbUserEntry. Si sa valeur est FALSE, le réplicateur d’utilisateurs inclura les attributs de ce contact dans la table AbUserEntry, mais pas l’attribut spécifique comportant cet indicateur. Il s’agit d’un autre cas spécifique qui concerne principalement l’attribut msExchHideFromAddressLists.
0x4	Attribut de chaîne inclus uniquement si la valeur d’attribut commence par « smtp : » et inclut le symbole « @ ».
0x5	Attribut de chaîne inclus uniquement si la valeur d’attribut commence par « Tél. : » ou « smtp : » et inclut le symbole « @ ».
0x100	S’il est défini, cet attribut à plusieurs valeurs peut apparaître plusieurs fois pour chaque contact.
0x400	S’il est défini, cela permet d’identifier l’attribut de l’alias de messagerie pour un contact. Le serveur de carnet d’adresses utilise cet indicateur pour identifier la valeur d’attribut à afficher dans l’entrée du journal des événements de normalisation téléphonique.
0x800	S’il est défini, cela permet d’identifier un attribut requis pour un contact. Le serveur de carnet d’adresses ajoute un utilisateur dans la table AbUserEntry seulement si une valeur existe pour cet attribut dans Active Directory. S’il existe plusieurs attributs requis, seul l’un d’entre eux est nécessaire pour disposer d’une valeur afin d’inclure l’utilisateur dans la table AbUserEntry.
0x1000	S’il est défini, le serveur de carnet d’adresses normalise toujours la valeur de cet attribut.
0x2000	S’il est défini, le serveur de carnet d’adresses utilise le numéro normalisé des adresses proxy, si le paramètres WMI UseNormalizationRules a la valeur FALSE, sinon il se comporte comme si le bit d’indicateur était 0x1000.
0x4000	S’il est défini, le serveur de carnet d’adresses n’inclut pas d’objets dans la table AbUserEntry qui contiennent cette valeur pour l’attribut spécifié. Par exemple, si l’attribut msRTCSIP-PrimaryUserAddress a ce bit d’indicateur défini, les contacts disposant de cet attribut ne sont alors pas écrits dans la base de données.
0x8000	S’il est défini, le serveur de carnet d’adresses n’inclut pas d’objets dans la table AbUserEntry qui ne contiennent pas cette valeur pour l’attribut spécifié. Si les deux bits d’indicateurs 0x4000 et 0x8000 sont définis sur un objet, l’attribut avec la valeur de bit d’indicateur définie sur 0x4000 est prioritaire et l’objet est exclu de la table AbUserEntry.
0x10000	Représente un objet de groupe s’il est défini. Le réplicateur d’utilisateurs utilise ce bit d’indicateur pour inclure les contacts avec l’attribut groupType dont la présence indique un groupe (par exemple, une liste de distribution ou un groupe de sécurité).
0x20000	S’il est défini, le réplicateur d’utilisateurs utilise ce bit d’indicateur pour inclure cet attribut dans les fichiers du serveur de carnet d’adresses propres au périphérique (c’est-à-dire les fichiers avec l’extension .dabs).

Filtrage du carnet d’adresses

Les utilisateurs renseignés dans les fichiers du serveur de carnet d’adresses peuvent être contrôlés en fonction de certains attributs Active Directory répertoriés dans la table AbAttribute. Parmi les attributs utilisés pour le filtrage figure l’attribut msExchHideFromAddressLists. Il s’agit d’un attribut utilisateur ajouté par le schéma Exchange. Si la valeur de cet attribut est TRUE, le serveur Exchange Server utilise cet attribut pour masquer le contact dans la liste d’adresses globale d’Outlook. De même, si la valeur de cet attribut est TRUE, le réplicateur d’utilisateurs n’inclut pas cet utilisateur dans la table AbUserEntry qui sera également absent des fichiers du serveur de carnet d’adresses.

Vous pouvez utiliser certains bits d’indicateurs pour définir un filtre à utiliser sur les attributs du serveur de carnet d’adresses. Par exemple, la présence de certains bits d’indicateurs peut identifier un attribut comme étant un attribut à inclure ou à exclure. Le réplicateur d’utilisateurs filtre les contacts contenant un attribut à exclure et ceux ne contenant pas d’attribut à inclure.

Il existe actuellement trois filtres différents. Le tableau suivant les répertorie.

Tableau 3. Filtres

Attribut	Description
0x800	S’il est défini, cela permet d’identifier un attribut requis pour un contact. Le réplicateur d’utilisateurs utilise ce bit d’indicateur pour filtrer les contacts qui ne contiennent pas au moins un attribut obligatoire. OuPathId est un attribut obligatoire qui est toujours défini. Au moins un des autres attributs obligatoires doit donc être défini. Sinon, le contact (c’est-à-dire avec la valeur de l’attribut obligatoire OuPathId) ne sera toujours pas ajouté à la base de données. Par exemple, si telephoneNumber et homePhone sont définis comme attributs obligatoires, seuls les contacts contenant au moins un de ces attributs sont ajoutés à la base de données.
0x4000	Identifie un attribut à exclure s’il est défini. Le réplicateur d’utilisateurs utilise ce bit d’indicateur pour filtrer les contacts qui contiennent cet attribut. Par exemple, si msRTCSIP-PrimaryUserAddress est défini en tant qu’attribut à exclure, les contacts disposant de cet attribut ne sont pas écrits dans la base de données.
0x8000	Identifie un attribut à inclure s’il est défini. Le réplicateur d’utilisateurs utilise ce bit d’indicateur pour filtrer les contacts qui ne contiennent pas cet attribut. Par exemple, si msRTCSIP-PrimaryUserAddress est défini en tant qu’attribut à inclure, seuls les contacts disposant de cet attribut sont ajoutés à la base de données.

Remarque :
Si les deux bits d’indicateurs 0x4000 (attribut à exclure) et 0x8000 (attribut à inclure) sont définis, le bit 0x4000 remplace le bit 0x8000 et le contact est exclu.

Même si vous pouvez filtrer le carnet d’adresses afin de n’inclure que certains utilisateurs, la limitation des entrées n’empêche pas les autres utilisateurs de contacter les utilisateurs filtrés ou d’afficher leur statut de présence. Les utilisateurs peuvent toujours rechercher, envoyer des messages instantanés ou initier manuellement des appels pour les utilisateurs absents du carnet d’adresses en entrant le nom de connexion complet d’un utilisateur. Office Communicator 2007 R2 peut aussi utiliser les informations de contact d’un utilisateur dans Outlook ou le carnet d’adresses Windows.

Bien que le fait de disposer d’enregistrements de contacts complets dans les fichiers du carnet d’adresses vous permettent d’utiliser Office Communicator 2007 R2 pour initier des appels par courrier électronique, téléphone ou Voix Entreprise (si Voix Entreprise est activé sur le serveur, évidemment) avec des utilisateurs non configurés pour le protocole SIP, certaines organisations préfèrent inclure uniquement les utilisateurs activés pour SIP dans les entrées de leur serveur de carnet d’adresses. Vous pouvez filtrer le carnet d’adresses de manière à inclure uniquement les utilisateurs activés pour SIP en effaçant le bit 0x800 dans la colonne Indicateurs des attributs obligatoires suivants : mailNickname, telephoneNumber, homePhone et mobile. Vous pouvez également filtrer le carnet d’adresses de manière à inclure uniquement les utilisateurs activés pour SIP en définissant le bit 0x8000 (attribut à inclure) dans la colonne Indicateurs de l’attribut msRTCSIP-PrimaryUserAddress. Cela permet également d’exclure les comptes de service des fichiers du carnet d’adresses.

Après avoir modifié la table AbAttribute, vous pouvez actualiser les données de la table AbUserEntry en exécutant la commande abserver.exe –regenUR. Une fois que la réplication du réplicateur d’utilisateurs est terminée, vous pouvez mettre à jour le fichier dans le magasin de fichiers du serveur de carnet d’adresses en exécutant manuellement la commande abserver.exe –syncNow.

Voir aussi

Concepts

Address Book Server Drilldown

Partager via