Address Book Server: Address Book Web Query Service
Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
The Address Book Web Query Server queries are passed by the client to the Address Book Web Query server by HTTPs (or HTTP if configured). The internal and external URLs are configured on the server under which are leveraged for both Address Book Web Query Server and Distribution List Expansion. These URLs are then passed to the clients through the dlxInternalUrl and dlxExternalUrl in-band provisioning settings.
Queries are sent to the Address Book Web Query Server by using HTTPS (or HTTP if configured through the URL). The ASP.net first pre-processes the query and forms an SQL query, which is executed by the SQL Server (or SQL Server Express for SE) using the RTCAb database. Next, post-processing of the results occurs (that is, constructing the information to be sent to the client). The query results are then returned to the client.
Following are sample URLs for internal and external Address Book Web Server queries. The specific search attributes are not included.
https://server.contoso.com/GroupExpansion/int/service.asmx?op=QueryAbContacts
https://server.contoso.com/GroupExpansion/ext/service.asmx?op=QueryAbContacts
The following table lists the RTCAb database fields that are extracted from the RTC database by ABServer.exe.
Table 1. RTCAb Database Fields
| Name | Active Directory name | Attribute ID | Example |
|---|---|---|---|
Display Name |
displayName |
4 |
“Sara Davis”, “Dan G Fennell” |
Office Number |
telephoneNumber |
10 |
1.425.555.0101 |
Mobile Number |
Mobile |
13 |
1.425.555.0198 |
SIP Address |
msRTCSIP_PrimaryUserAddress |
9 |
sarad@contoso.com |
Primary email address |
proxyAddress |
18 |
sarad@contoso.com , sara.davis@contoso.com |
The RTCAb database is designed so that additional search fields can be easily added to the database (adding additional fields is currently not supported). The example in the following table shows sample data in the AbAttributeValue table, which is the primary table in the RTCAb database that is used for queries. The UserID column maps to an address book entry (for example, a user or contact object). The AttrID column identifies the attribute (see the previous table), the Value column is the alpha-numeric value of the attribute (for example, “Bill Malone”), and the DTMF column encodes the string value in a numeric format for predictive text dial pad.
Table 2. Sample AbAttributeValue Table
| Ptrn | UserId | AttrId | Value | DTMF (dial pad index) |
|---|---|---|---|---|
1 |
365649 |
10 |
+1 (425) 5550198 X50198 |
1*425*5550198*50198 |
1 |
365649 |
10 |
14255550198 |
14255550198 |
1 |
365649 |
10 |
4255550198 |
4255550198 |
1 |
365649 |
10 |
5550198 |
5550198 |
1 |
365649 |
10 |
0198 |
0198 |
1 |
365649 |
4 |
Bill Malone |
2455*42837 |
1 |
365649 |
9 |
Billm |
24556 |
1 |
365649 |
9 |
billm@contoso.com |
24556126686761266 |
1 |
365649 |
17 |
billm@contoso.com |
24556126686761266 |
1 |
365649 |
18 |
billm@contoso.com |
24556126686761266 |
1 |
365649 |
18 |
billm@msg.Contoso.com |
245561674126686761266 |
1 |
365649 |
18 |
billm@titanium.contoso.com |
24556184826486126686761266 |
1 |
365649 |
18 |
billmcontoso.com |
2455626686761266 |
1 |
365649 |
18 |
2455626686761266 |
24556674126686761266 |
1 |
365649 |
18 |
billmtitanium.contoso.com |
2455684826486126686761266 |
Note
The digit 1 in the dual-tone multifrequency (DTMF) interface is used for various characters (for example, !, @, ., -) and the digits 0 and 1. The symbol * is used to represent a space or other separators.
Office Communicator Address Book Queries
Currently, Office Communicator is the only client that leverages the Address Book Web Query Service. The Address Book Web Query Service supports a wide set of query options.
The following table contains the parameters and default values that can be processed by the Address Book Web Query Service. Although it is not possible for users or administrators to modify this query, this table helps demonstrate how Address Book Query works and how queries may differ for future clients that may leverage this service.
Table 3. Parameters and Default Values
| Parameter | Type | Default | Notes |
|---|---|---|---|
QueryString |
String |
Expression for the query |
|
Dial |
Boolean |
True |
Determines whether a predictive search query is performed (for example, dial pad queries that leverage the DTMF index) |
PrefixQueryAttributes |
String |
displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile |
Attributes where a SQL LIKE comparison operator is used (for example, “Cam” matches “Cameron) |
ExactQueryAttributes |
String |
displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile |
Attributes where a SQL = comparison operator is used (for example, “Cam” does NOT match “Cameron”) |
RequestTimeout |
Query timeout |
||
MaxResult |
Int |
50 |
Maximum results to return |
ReturnAttributes |
String |
givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager |
Default set of attributes to be returned to the user. Many of these attributes cannot be used in the query string expression |
The following table lists parameters that Communicator Mobile uses. These are hardwired into Communicator Mobile and cannot be changed.
Table 4. Communicator Mobile Parameters
| Parameter | Type | Default | Notes |
|---|---|---|---|
QueryString |
String |
Expression for the query |
|
Dial |
Boolean |
False |
Does not support dial pad queries |
PrefixQueryAttributes |
String |
displayName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, mobile |
Uses prefix match (SQL LIKE) |
ExactQueryAttributes |
String |
||
RequestTimeout |
Query timeout |
||
MaxResult |
Int |
20 |
Saves network bandwidth |
ReturnAttributes |
String |
givenName, sn, displayName, mailNickName, physicalDeliveryOfficeName, msRTCSIP-PrimaryUserAddress, proxyAddress, telephoneNumber, homePhone, otherHomePhone, mobile, otherMobile, otherTelephone, ipPhone, mail, manager |
Default set of attributes to be returned to the user. Many of these attributes cannot be used in the query string expression |
Queries on Display Name
Currently the Address Book Server only supports name-based queries based on display name. It does not support queries based on the Active Directory entries for last name (that is, SN), first name (that is, givenName), and so on. It may also match the user part of the Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) or e-mail address. To support names typed in different orders (for example, “Sara Davis”, “Davis, Sara”, and “Davis Sara”) and users with multiple first or last names (for example, “Pablo Rovira Diez”), multiple entries are placed into the AbAttributeValue table for the display name. For example, the following entries are placed in the table for Pablo Rovira Diez:
Pablo Rovira Diez
Diez Pablo Rovira
Diez, Pablo Rovira
Rovira Diez Pablo
Rovira Diez, Pablo
Since the Address Book Web Query Service leverages the SQL LIKE string matching expression, all of the following strings will match at least one of the table entries, and will return “Diez Pablo Rovira” as a match (in addition to other possible matches).
Pa
Pablo
Pablo Rovira
Diez Pablo
Diez, P
Rovira
Rovira Diez P
Rovira Diez, P
However the following strings will not create a match:
Rovira Pablo
Pablo Diez
The general case for display name index generation is as follows:
Simple Case
DisplayName = "A B" will support
A B
B a (Inversed)
B,A (Inversed with Comma)
Generates 3 indices
Complex Case
Display Name = “A B C D E” will support
A B C D E
D E A B C (Last 2 words)
D,E A B C (Last 2 words with Comma)
E A B C D (Last word)
E, A B C D (Last word with Comma)
Generates 5 indices (no more, no less)
In the case where there are more than two words in the last name, the index based on the display name will most likely need to be leveraged to obtain the desired match.
Queries on Phone Numbers
To support practical queries based on phone numbers, a number of indices are created. By leveraging the SQL LIKE expression (that is, partial match), you can use a number of useful options for searching phone numbers.
The RFC 3966/E.164 phone number “+1.425.555.0101” will get entries with the following indexes:
+1.425.555.0101
4255550101
5550101
0101
14255550101
Tel:+14255550101
14255550101
The RFC 3966/E.164 phone number “+01 (23) 456789 x01” will get entries with the following indexes:
+01.23.456789.01
012345678901
2345678901
45678901
01
0123456789
Tel:+0123456789;ext=01
Address Book Web Query also pre-processes queries to remove any extraneous symbols. For example, the string +1(425) 555-0101 would be translated to 14255550101 before running the query.
Sorting Query Results
Currently, Communicator Mobile only retrieves for the first 20 matches for a given query. The Address Book Query Server searches for the first 100 matches for any query, of which only the first 20 entries in the result set are passed back to the client (that is, based on the actual query sent by the client). For performance reasons the Address Book Query Server does not attempt to process more than 100 matches. For example, if a user tries to query “Bo”, only the first 100 matches that SQL Server finds are returned. In cases where there are more than 100 potential matches, the query does not fetch every attribute that begins with a “Bo” (for example, every user with a first name or last name that begins with a “Bo”, a SIP URI that begins with a “Bo”, and so on) and sort them, as this would take up significant database cycles. Although this is not optimal, it achieves a decent tradeoff between functionality and performance. In general, most users refine their query and re-submit it rather than scrolling through pages of query results.
There are a few issues when a user attempts to search for a common name. For example, if a user searched for “Daniel” and there were more than 100 “Daniels” in the address book, 100 random matches would be returned and subsequently sorted. The user may see “Daniel Park” and “Daniel Taylor” sequentially and assume that “Daniel Roman” (that is, alphabetically between Park and Taylor) is not in the address book. However, this is not necessarily the case because “Daniel Roman” may not have been in the set of 100 entries returned and would not be presented in the list. In this case the user would be expected to enter a more refined query.
Predictive Text Queries
The AbAttributeValue database table also has a column for DTMF queries. This is a special index created to support predictive text queries where telephone dial pads are used to enter queries. For example, the digit 2 could represent an “A”, “B” or “C”. Thus if a user keyed in “226”, it would match any existing entries that start with “226” in the DTMF column (for example, “Cam”, “Cameron”, “Candice”, “Bam”, etc.). Although this query is supported by the Address Book Web Query Server, there are no clients that currently leverage this interface.
Note
Communicator Mobile performs numeric matches on office and mobile phone numbers and any SIP or e-mail address that leverages digits. However these queries do not leverage the predictive text query algorithms.
Address Book Web Query Database
The Address Book Web Query RTCAb database is collocated as a separate SQL Server instance on the same SQL Server as the RTC database for the given pool. The database leverages the same high availability features as the RTC database. The database should also be included in any backup plan, although historical copies are not relevant and the database can be regenerated by using the ABServer –syncnow command.
The database is implemented by using two database partitions, where each partition contains a complete copy of the address book. At any given point in time, one partition is active, which means it is being used by Address Book Web Query Server for handling queries from clients. The other partition is then available to the ABServer.exe process for the next nightly update. After the update process is finished (that is, committed to the database), this new partition becomes active. This technique helps enable optimal performance as there are no locking contention issues in the database (that is, all queries are read-only).
The size of the RTCAb is modest and is dependent on the number of contacts in the address book and the number of fields populated. SQL Server also reserves significant space for the creation and maintenance of the database and various indices.
Address Book Web Query Database Language Support
The Address Book Web Query RTCAb database currently uses the Latin1_General_CI_AI (that is, Case Insensitive, Accent Insensitive) database collation. In SQL Server, collations control various language-specific rules for how comparisons (that is, SQL = and LIKE) and sorts (that is, SQL ORDER BY) behave. The Latin1_General collation supports various Latin-based languages that have the same superset of order and sorting rules, including Dutch, English, German, Italian, and Portuguese/ Brazilian.
There are languages where the general rules of Latin largely apply to (for example, Modern Spanish and French) but may have some subtle issues around comparison and sorting (for example, certain ligatures may not be correctly sorted). For other languages, such as Japanese and Simplified Chinese, where the rules of Latin have no influence, sorting and comparison are dictated by the underlying characteristics of Unicode. In languages with a large number of characters, users often rely on exact match and not necessarily matches based on a partial letter match. Not having correct alphabetical ordering may not be as much of an issue as it is with languages like English.
Address Book Web Query Server Performance
The Address Book Web Query Server and RTCAb database generally only have a minimal impact on performance the Web Components Server (typically running on the Front-End servers) and the back-end server. Currently, only the Communicator Mobile clients use Address Book Web Query Server and queries on this device are explicitly controlled by the user when they use the Search function, as opposed to being performed automatically as a user types in a name or phone number.
The Address Book Web Query ASP.net process is relatively lightweight and the back-end database processing is all read-only queries on a database that is updated once per day. The Address Book Query service does not pose any significant performance bottleneck, and whatever impact it has can be resolved by general performance tuning on the front-end and back-end servers.