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.

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.

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.

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.

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.