Topic Last Modified: 2011-04-12

As a part of the deployment of Microsoft Lync Server 2010 Enterprise Edition server or Standard Edition server, the Address Book Service is installed by default. The databases used by the Address Book Service – RTCab and RTCab1 – are created on the SQL Server (for Enterprise Edition server, this is the back end SQL Server, for Standard Edition server, the collocated SQL Server).

Address Book Server Phone Number Normalization

Lync Server 2010 requires standardized RFC 3966/E.164 phone numbers. To use phone numbers that are unstructured or inconsistently formatted, Lync Server relies on the Address Book Server to preprocess phone numbers before they are handed off to the normalization rules. When a phone number is used from the address book and the normalization rule is applied, clients, such as Microsoft Lync 2010, Microsoft Lync 2010 Phone Edition and Microsoft Lync 2010 Mobile, can use these normalized numbers.

As discussed in the New Address Book Features, the normalization rules that were used in previous versions may not work properly without some adjustments. Because the white space and non-mandatory characters are removed prior to the normalization rules, if your regex expression is specifically looking for a dash or other character that was removed, your normalization rule might fail. You should review your normalization rules to ensure that either they are not looking for these non-mandatory characters, or that the rule can fail gracefully and continue in the event that the character is not present where the rule anticipates it will be.

User Replicator and Address Book Server

The Address Book Server uses data provided by User Replicator to update the information that it initially obtains from the global address list (GAL). User Replicator writes the Active Directory Domain Services (AD DS) attributes for each user, contact, and group into the AbUserEntry table in the database and the Address Book Server syncs the user data from the database into files in the Address Book Server file store and into the Address Book database RTCab or RTCab1. The schema for the AbUserEntry table uses two columns, UserGuid and UserData. UserGuid is the index column and contains the 16-byte GUID of the Active Directory object. UserData is an image column which contains all of the previously mentioned Active Directory Domain Services (AD DS) attributes for that contact.

User Replicator determines which Active Directory attributes to write by reading a configuration table located in the same SQL Server-based instance as the AbUserEntry table. The AbAttribute table contains three columns, ID, Name and Flags. The table is created during database setup. If the AbAttribute table is empty, User Replicator skips its AbUserEntry table processing logic. Address Book Server attributes are dynamic and are retrieved from the AbAttribute table, which is initially written by the Address Book Server when the Address Book Server is activated.

Address Book Server activation populates the AbAttribute table with the values needed to support Lync Server. The following table shows those current values.

ID Name Flags

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

The numbers in the ID column must be unique and should never be reused. Also, keeping the ID values under 256 saves space in the output files written by the Address Book Server. However, the maximum ID value is 65535. The Name column corresponds to the Active Directory attribute name that User Replicator should put in the AbUserEntry table for each contact. The value in the Flags column is used to define the type of attribute. The following types of Address Book Server attributes are recognized by User Replicator, indicated by the low byte of the value in the Flags column.

Attribute Description

0x0

A string attribute. User Replicator converts this type to UTF-8 before storing it in the AbUserEntry table.

0x1

A binary attribute. User Replicator stores this in the blob without any conversion.

0x2

A string attribute, but is included only if the attribute value begins with "tel:". This is primarily for multi-valued string attributes, specifically proxyAddresses. In this case, Address Book Server is interested only in proxyAddresses entries that begin with "tel:". Therefore, in the interest of saving space, User Replicator stores only the entries that begin with "tel:".

0x3

A Boolean string attribute, which if TRUE causes User Replicator to not include this contact in the AbUserEntry table. If FALSE, it causes User Replicator to include the attributes for this contact in the AbUserEntry table, but not the particular attribute with this flag. This is another special case type that is primarily for the msExchHideFromAddressLists attribute.

0x4

A string attribute, but is included only if the attribute value begins with "smtp:" and includes the "@" symbol.

0x5

A string attribute, but is included only if the attribute value begins with either "tel:" or "smtp:" and includes the "@" symbol.

0x100

If set, this is a multi-valued attribute that can appear more than once for each contact.

0x400

If set, this identifies the email user account name attribute for a contact. Address Book Server uses this flag to identify which attribute value to show in the phone normalization event log entry.

0x800

If set, this identifies a required attribute for a contact. Address Book Server includes a user in the AbUserEntry table only if there is a value for this attribute in Active Directory. If there is more than one required attribute, only one of them is required to have a value to include the user in the AbUserEntry table.

0x1000

If set, Address Book Server always normalizes the value of this attribute.

0x2000

If set, Address Book Server uses the normalized number from proxyAddresses, if the UseNormalizationRules CMS setting is FALSE; otherwise it behaves the same as when the flag bit is 0x1000.

0x4000

If set, Address Book Server does not include objects in the AbUserEntry table that have this value for the specified attribute. For example, if the msRTCSIP-PrimaryUserAddress attribute has this flag bit set, then contacts that have this attribute are not written to the database.

0x8000

If set, Address Book Server does not include objects in the AbUserEntry table that do not have this value for the specified attribute. If both the 0x4000 and 0x8000 flag bits are set on an object, the attribute with the flag bit value set to 0x4000 takes precedence, and the object is excluded from the AbUserEntry table.

0x10000

If set, this represents a group object. User Replicator uses this flag bit to include contacts with the groupType attribute whose presence indicates a group (for example, a distribution list or security group).

0x20000

If set, User Replicator uses this flag bit to include this attribute in device-specific Address Book Server files (that is, files with a .dabs extension).

Filtering the Address Book

The users populated in the Address Book Server files can be controlled based on certain Active Directory Domain Services (AD DS) attributes listed in the AbAttribute table. One such attribute used for filtering is the msExchangeHideFromAddressBook attribute. This is a user attribute added by the Exchange schema. If the value of this attribute is TRUE, Exchange Server uses this attribute to hide the contact from the Outlook Global Address List (GAL). Similarly, if the value of this attribute is TRUE, User Replicator does include that user in the AbUserEntry table and this user will not be in the Address Book Server files.

You can use some flag bits to define a filter to use on Address Book Server attributes. For example, the presence of certain flag bits can identify an attribute as an include attribute or an exclude attribute. User Replicator filters out contacts that contain an exclude attribute and filters out contains that do not contain an include attribute.

Currently, there are three different filters. The following table lists these filters.

Attribute Description

0x800

If set, this identifies a required attribute for a contact. User Replicator uses this flag bit to filter out contacts that do not contain at least one required attribute. The OuPathId is a required attribute, which is always set. So at least one of other required attributes should be set. Otherwise, contact (that is, with value of required attribute OuPathId) will still not be written to database. For example, if telephoneNumber and homePhone are defined as required attributes, only the contacts that have at least one of these attributes are written to the database.

0x4000

If set, this identifies an exclude attribute. User Replicator uses this flag bit to filter out contacts that contain this attribute. For example, if msRTCSIP-PrimaryUserAddress is defined as an exclude attribute, contacts that have this attribute are not written to the database.

0x8000

If set, this identifies an include attribute. User Replicator uses this flag bit to filter out contacts that do not contain this attribute. For example, if msRTCSIP-PrimaryUserAddress is defined as an include attribute, only the contacts that have this attribute are written to the database.

Note:
If both the 0x4000 (exclude attribute) and 0x8000 (include attribute) flag bits are set, the 0x4000 bit overrides the 0x8000 bit and the contact is excluded.

Although you can filter the Address Book to include only certain users, limiting entries does not limit other users' ability to contact the filtered users or to see their presence status. Users can always find, manually send instant messages, or manually initiate calls to users not in the Address Book by entering a user's complete sign-in name. Also, contact information for a user could also be found in Outlook or the Windows Address Book.

While having full contact records in the Address Book files enables you to use Lync 2010 to initiate email, telephone, or Enterprise Voice calls (that is, if Enterprise Voice is enabled on the server) with users that are not configured for Session Initiation Protocol (SIP), some organizations prefer to include only SIP-enabled users in their Address Book Server entries. You can filter the Address Book to include only SIP-enabled users by clearing the 0x800 bit in the Flags column of the following required attributes: mailNickname, telephoneNumber, homePhone, and mobile. You can also filter the Address Book to include only SIP-enabled users by setting the 0x8000 (include attribute) in the Flags column of the msRTCSIP-PrimaryUserAddress attribute. This also helps to exclude service accounts from the Address Book files.

After you modify the AbAttribute table, you can refresh the data in the AbUserEntry table by running the cmdlet Update-CsUserDatabase command. After UR replication completes, you can update the file in the Address Book Server file store by manually running the cmdlet UpdateCsAddressBook command.

Note:
The Front End that the Address Book Server is placed is not administratively configurable. One is chosen during deployment – typically the first Front End deployed. In the event of failure, the Address Book Service will move to another Front End, and requires no administrative attention. Also, there are two databases for the Address Book Service – RTCab and RTCab1. The databases are updated daily, but alternate which database is updated. If the RTCab database is being updated, queries are preformed against the RTCab1 database while the update is in progress. The next day, RTCab1 is updated and queries are preformed against RTCab while the update is in progress. This ensures that at least one of the databases will be available for query and Address Book file creation.
Important:
If you have consolidated or otherwise modified your infrastructure from a multi-forest deployment or a parent/child deployment (such as consolidating your infrastructure before moving to Lync Server 2010), you may find that the Address Book service download and the Address Book Web Query fails for some users. When in a deployment that had multiple domains or forests, the attribute MsRTCSIP-OriginatorSid is populated on the user objects that are exhibiting the problem. The MsRTCSIP-OriginatorSid attribute must be set to NULL on these objects to resolve the problem.