• Article

Administration du service de carnet d’adresses

 

Dernière rubrique modifiée : 2012-04-04

Dans le cadre du déploiement du serveur Enterprise Edition ou du serveur Standard EditionMicrosoft Lync Server 2010, le service de carnet d’adresses est installé par défaut. Les bases de données utilisées par le service de carnet d’adresses (RTCab et RTCab1) sont créées sur le serveur SQL Server (pour le serveur Enterprise Edition, il s’agit du serveur SQL Server principal, pour le serveur Standard Edition, du serveur SQL Server colocalisé).

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

Lync Server 2010 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, Lync 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. Lorsqu'un numéro de téléphone est utilisé depuis le carnet d’adresses et que la règle de normalisation est appliquée, les clients (par exemple, Microsoft Lync 2010, Microsoft Lync 2010 Phone Edition et Microsoft Lync 2010 Mobile) peuvent utiliser ces numéros normalisés.

Comme décrit dans les Nouvelles fonctionnalités de carnet d’adresses., les règles de normalisation utilisées dans les versions précédentes risquent de ne pas fonctionner correctement sans quelques ajustements. Du fait que les espaces et les caractères non obligatoires sont supprimés avant d’appliquer les règles de normalisation, si votre expression regex recherche spécifiquement un tiret ou tout autre caractère ayant été supprimé, votre règle de normalisation risque d’échouer. Vous devriez passer en revue vos règles de normalisation pour vous assurer qu’elles ne recherchent pas ces caractères non obligatoires, ou que la règle peut échouer normalement et se poursuivre au cas où le caractère soit absent et que la règle anticipe sa présence.

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 des services de domaine Active Directory (AD DS) pour chaque utilisateur, contact et groupe dans la table AbUserEntry dans 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 carnet d’adresses RTCab ou RTCab1. 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 des services de domaine Active Directory (AD DS) 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 Server 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 de Lync Server. Le tableau suivant présente ces valeurs actuelles.

ID Nom Indicateurs

1

givenName

0x01400000

2

Sn

0x02400000

3

displayName

0x03420000

4

Title

0x04000000

5

mailNickname

0x05400000

6

Company

0x06000000

7

physicalDeliveryOfficeName

0x07000000

8

msRTCSIP-PrimaryUserAddress

0x08520C00

9

telephoneNumber

0x09022800

10

homePhone

0x0A302800

11

Mobile

0x0B622800

12

otherTelephone

0x0C302000

13

ipPhone

0x0D302000

14

Mail

0x0E500000

15

groupType

0x0F010800

16

Department

0x10000000

17

Description

0x11000100

18

Manager

0x12040001

19

proxyAddress

0x00500105

20

msExchHideFromAddressLists

0xFF000003

99

entryID

0x99000000

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.

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 VRAI, empêche au réplicateur d’utilisateurs d’inclure ce contact dans la table AbUserEntry. Si sa valeur est FAUX, cela empêche le réplicateur d’utilisateurs d’inclure 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 du nom du compte d’utilisateur 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 CMS UseNormalizationRules a la valeur FAUX, 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 créés sur 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’indicateur 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 services de domaine Active Directory (AD DS) répertoriés dans la table AbAttribute. Parmi les attributs utilisés pour le filtrage figure l’attribut msExchangeHideFromAddressBook. Il s’agit d’un attribut utilisateur ajouté par le schéma Exchange. Si la valeur de cet attribut est VRAI, 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 VRAI, 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’indicateur 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.

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 créés sur 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, les contacts disposant de cet attribut sont ajoutés à la base de données.
noteRemarque :
Si les deux bits d’indicateur 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. Les informations de contact d’un utilisateur peuvent également être trouvées 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 Lync 2010 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 de la cmdlet Update-CsUserDatabase. 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 de la cmdlet UpdateCsAddressBook.

noteRemarque :
Le serveur frontal sur lequel est placé le serveur de carnet d’adresses n’est pas configurable administrativement. Un serveur est choisi au cours du déploiement, il s’agit généralement du premier serveur frontal déployé. En cas d’échec, le service de carnet d’adresses passe sur un autre serveur frontal, sans qu’aucune attention administrative ne soit nécessaire. Le service de carnet d’adresses comporte également deux bases de données : RTCab et RTCab1. Les bases de données sont mises à jour quotidiennement, mais en alternance. Si la base de données RTCab est en cours de mise à jour, des requêtes sont effectuées sur la base de données RTCab1 pendant la mise à jour. Le lendemain, la base de données RTCab1 est mise à jour et des requêtes sont effectuées sur la base de données RTCab pendant la mise à jour. Cela permet de garantir qu’au moins une des bases de données est disponible pour la recherche et la création du fichier de carnet d’adresses.
importantImportant :
Si vous avez renforcé ou modifié votre infrastructure à partir d’un déploiement multi-forêts ou d’un déploiement parent/enfant (par exemple en renforçant votre infrastructure avant de passer à Lync Server 2010), le téléchargement du service de carnet d’adresses et le service de requête Web du carnet d’adresses risquent d’échouer pour certains utilisateurs. Lorsqu’il se trouve dans un déploiement comportant plusieurs domaines ou forêts, l’attribut MsRTCSIP-OriginatorSid est renseigné sur les objets utilisateur qui exposent le problème. L’attribut MsRTCSIP-OriginatorSid doit être défini avec la valeur NULL sur ces objets pour résoudre le problème.