ABServer.exe generates two sets of files for use by 2 groups of clients. For clients that typically have sufficient local storage space, ABServer.exe generates a file containing the full address book that contains a large set of user and contact object attributes. To optimize download efficiency, it also generates up to 29 delta files that contain incremental updates containing the last one day, two days and up to 29 days worth of changes. These files have the *.lsabs file extension.

For clients that have limited local storage such as Microsoft Communicator Phone Experience, ABServer.exe generates a full address book file and up to 29 delta files that contain a restricted set of user and contact object attributes. These files have the *.dabs file extension (that is, device Address Book Server).

In Office Communications Server Standard Edition, the Address Book files are stored by default in <drive>:\%ProgramFiles%\Office Communications Server 2007 R2\Web Components\Address Book Files\Files. In Enterprise Edition, the Address Book file store is a shared NTFS folder that the administrator manually creates during setup. The data gathered by the Address Book Server is stored in a binary format in compressed files to minimize storage requirements. The number of days that the delta files are kept is set at the static value of 30 days, and this number cannot be changed. After 59 days (the first 29 days after a fresh start will contain fewer delta files), the Address Book Server reaches a steady state where a set of up to 1800 files, which contain up to 900 *.lsabs and 900* .dabs files, each of which includes 30 full files and up to 870 (that is, 30 days * 29 files/day) delta files.

Each time the Address Book Server starts, it determines whether there are data files in the output directory. If no data files are found, it will generate one full file. A delta file is not generated if there are no initial full files from previous days to compare against. The output files are written to the Address Book file store, a folder that can be assigned an access control list (ACL) by using the standard NTFS share permissions.

The following table shows how the full files and delta files are generated for both *.lsabs and *.dabs files.

Table 1. File Generation

By default (that is, without organizational unit (OU) partitioning), all data files are stored in one directory. File names for full files are of the form F-xxxx, where xxxx is the file creation date expressed as the hexadecimal 0-based number of days since January 1, 2001. Delta file names are of the form D-xxxx-yyyy.lsabs, where xxxx is the full file creation date, and yyyy is the delta file creation date. Files are also assigned the appropriate *.lsabs or *.dabs file extension. Files are created in memory and are written using a file handle that is created with no sharing allowed so that client applications cannot access a file before it has been completely written.

Note:
Exception:If a delta file size gets to beyond a certain percentage of the Full file size, a new Full file is generated instead of the incremental delta file. This percentage is specified by the server variable MaxDeltaFileSizePercentage. The default value for this is 1250, or 12.5%.

If this percentage is surpassed on the size of the server-side delta file, the server produces a full file instead of a delta file. In this case, the server generates fewer than 30 days of delta file information, which is an exception to its normal logic. If this number is set to a higher value, the chances of forcing a full download decreases. However, there is more client-side processing required to update its local database.

Additionally, any change to any attribute of an address book entry causes the entire record to be updated. For example, if the Mobile phone number changes, the entire user address book entry is updated.

It is possible to create different sets of address book files based on the Organizational Unit (OU) property in Active Directory. For example, Active Directory could leverage OUs to partition the Active Directory into two or more logical groups based on business unit (for example, Automotive, Marine) or business function (for example, Sales, Engineering, Manufacturing). By setting the MSFT_SIPAddressBookSetting:PartitionOutputByOUWMI property to True, ABServer.exe creates a number of sets of address book files in a tree of folder names that map to the OU. This setting is passed to clients, which in turn access the address files under the appropriate subdirectory as indicated by the user or contact object’s OU path setting.

PartitionOutputByOU can be leveraged in cases in large organizations where it is desirable to restrict the number of contacts or the size of the address book files that are accessed by groups of clients. It is also leveraged in Office Communications Server hosting environments where you need to partition users based on the company.

The Address Book URLs (that is, one internal and one external) are the paths that clients use to access the data files in the Address Book Server file store. These URLs are configured under the Address Booktab in the Web Components Propertiesfor the given Standard Edition server or Enterprise pool, and are retrieved through in-band provisioning (absInternalServerUrl and absExternalServerUrl) by the client when it logs on to its Standard Edition server or Enterprise pool. The clients can also have these URLs configured through Group Policy Objects.

Office Communicator needs to be configured to access the Address Book file store by using an URL defined in one of the following formats:

• HTTPS Format.A secure HTTP (HTTPS) URL is the recommended methodology for accessing address book files. HTTP can also be used but is not secure. This method uses the Internet Information Services (IIS) HTTP server(s) which is the core component of the Web Components Server. If you require the file store to be accessible by remote users who are connecting outside the intranet (outside the firewall), the IIS server is required and you must configure HTTPS on your virtual server.
  
  
• File URL Format.The file URL (also called an UNC path) is the other method for accessing address book files. This approach is not recommended because you cannot use it for remote access. The file URL is a standard file URL in the format \\server\share. Standard share and NTFS permissions are applicable to this URL. The clients connect to the file store through the Server Message Block (SMB) protocol. There are two cases when a File URL cannot be used: when remote access is required and if the Office Communications Server pool is set to require encryption. In both of these cases, a HTTPS URL is required.
  
  

Note:

If your clients use an HTTPS URL to access the Address Book Server file store, verify that the client certificate is already trusted by Internet Explorer prior to an attempt by clients to access the Address Book URL. If the client certificate is not trusted, the download fails. The user is not prompted to check the certificate and to configure it as trusted. Consider using a certificate that is trusted by default on your client.

The type of authentication required for an Address Book URL varies depending on whether the URL is used for internal or external clients. The following table shows the supported authentication for each type of URL.

Table 2. Supported Authentication for Address Book URLs

The Address Book Client Provider is a module within Office Communicator that is responsible for synchronizing global address list (GAL) contacts with the Office Communicator contact database. Since all GAL contacts are read-only, this synchronization is a one-way process as follows:

1. Office Communicator logs on to the Enterprise pool or Standard Edition server using its logon logic.
   
   
2. Office Communicator accesses the internal and external address book shares by using the URLs provided either by the Group Policy Object (GPO) ABSInsideURL and ABSOutsideURL policy settings, or by retrieving them from the server during the logon process. These URLs are in either HTTPS, HTTP, or File URL format. The GPO settings take precedence over the settings retrieved from the server. If these GPOs are not set and depending on the setting of the AbsUseFallback Group Policy setting, the URLs are retrieved from either the Enterprise pool of the Standard Edition server. For details about these GPOs, see Deploying Communicatorin the Client Planning and Deployment documentation and the Microsoft Office Communications Server 2007 R2 Group Policy Settings documentation at http://go.microsoft.com/fwlink/?LinkID=140494 .
   
   
3. Office Communicator determines whether it is connecting from inside the intranet or connecting from outside through an Access Edge Server and then selects the appropriate URL for the connection.
   
   The logon credentials of the Office Communicator client are used to connect to the selected Address Book Server URL. Office Communicator uses the standard Internet Explorer application programming interface (API) to perform the URL authorization. If access is denied, one of the following occurs:
   
   
   • If the user is inside the intranet, the client displays an icon indicating an Address Book download failure. The user is not asked for credentials again.
     
     
   • If the user is outside the intranet, the user is prompted to enter proper URL credentials.
     
     

Note:
Office Communicator supports the use of a fallback URL for high availability. For details about configuring additional URL entries, see Using WMI to Configure Address Book Server Settingsin the Administering Office Communications Server 2007 R2 documentation.

If a client is accessing the URL for the first time and successfully connects, the client attempts to download the current full data file. On subsequent days, the client attempts to download a delta file based on the last full synchronization date. During daily client usage, this delta file is based on the previous day’s changes. If the client is offline for a day or more, it determines which delta file it must download to get up to date. For example, if the client is offline from Friday afternoon to Monday morning, it will attempt to download a delta file containing 3 days of changes. If the client is offline for more than 30 days, it is forced to attempt to download the full data file.

The client stores this information in the local GalContacts.db database. Storing this information in a local database reduces the time taken to synchronize information on the client computer with the latest information stored in Active Directory, thereby significantly improving the GAL search process. The client will also create an index to the database which is stored in the file GalContacts.db.idx.

In the event of a download failure because of network connectivity or other issues, the client retries in time intervals that doubles on each previous failure (that is, 1 minute, 2 minutes, 4 minutes, and so on, up to a maximum of 64 minutes, and then retries every 64 minutes). Any data that was downloaded before the failure is discarded, and the retry begins again at the beginning. If the failure persists for more than 24 hours, a warning is displayed, and an application event is added to the Event Log.

When the client logs on, it determines if it has been more than 24 hours since the last download. If so, then the current download occurs immediately. Otherwise, download is scheduled at 00:00 UTC (Universal Coordinated Time, also known as GMT).

The following exceptions apply:

• If the address book contains over 50K entries, the client maintains a separate delta database GalContactsDelta.db and index GalContactsDelta.db.idx for GAL contacts, and periodically merges updates into its main database GalContacts.db. This helps reduce the processing required on a daily basis on the client machine in very large environments.
  
  
• There are conditions when the server will not generate some of all of the delta files on the server. This happens when the MaxDeltaFileSizePercentage is exceeded. In this case the client will be forced to download the full address book file. This effectively causes the GalCaontacts.db to be completely replaced. Whenever a full download occurs in the case where there are over 50K entries, the GalContactsDelta.db database will be emptied (as there are no deltas).
  
  
• An additional client-side case is when the client cannot access the relevant delta file (that is, possibly locked, access denied, or not created due to time zones and file download time). In this case the client attempts to access relevant older delta files (that is, up to 2 additional days back). For example, after logging on at 09:00, the client cannot access a delta file containing 4 days of changes on Wednesday (after the files have been generated at 01:30). The client tries to access the delta file generated on Tuesday containing 3 days of changes, and if that cannot be accessed, it tries to access the delta file generated on Monday with 2 days of changes. After successfully accessing one of these older delta files, the client does not try to access additional files until the next day. Although the client does not obtain the latest changes, it will likely get some previous changes, which in turn minimizes the amount of deltas it needs to process the following day.
  
  

Because Office Communicator uses the standard Internet Explorer API to perform the URL authorization, it depends on the following Internet Explorer settings:

• Security Settings, including the intranet URL settings.For example, if you are using an Internet (that is, external) type of URL, such as http://server.com/share, for intranet (that is, internal) users instead of an intranet URL, such as http://server/share, unless this URL is configured explicitly as an intranet URL in Internet Explorer, Office Communicator ignores this entry. We recommend that you use an intranet URL for internal users. If you have a specific need to use an Internet URL, you must manually configure this URL as an intranet URL in Internet Explorer, or you must use an Active Directory group policy to configure the URL.
  
  
• Proxy Settings.If you use an HTTP proxy to manage your Web traffic and the Address Book data flows through this proxy, the client cannot access these URLs if the proxy becomes unavailable or if authorization problems occur with the proxy.
  
  

As a best practice, store Address Book data files on separate storage. The storage can be any of the many types, for example a direct access storage device (DASD) or a storage area network (SAN). The storage needs specific to the Address Book Server are very minimal and are expected to be in the range of 20 MB to 5 GB, depending on the number of users in the forest. The size of the full data files depends on the number of users and contacts stored in your Active Directory. The size of the delta files increases with the number of daily changes that occur to users and contacts in Active Directory. A large number of changes increases the delta file size and the time it takes to generate the delta files.

On average the *.dabs files are about 25% of the size of the *.lsabs files. This depends on the number of fields that are typically populated.

Office Communicator 2007 R2 stores the local address book database and in the directory:

<drive>:\%LOCALAPPDATA%\Microsoft\Communicator\ <user>\

The following table shows sample address book files for an organization with approximately 250,000 address book entries (that is, users, contact objects). The file sizes vary depending on various factors such as the number of address book fields that are populated.

Table 3. Sample Address Book Files

The file download process on the Office Communicator Phone Edition (IP Phones) and related devices is similar to on the process for Office Communicator, with the main difference being that it downloads the smaller *.dabs files. These files contain a limited set of attributes, specifically displayName, msRTCSIP_PrimaryUserAddress, telephoneNumber (that is, office), and mobile (that is, telephone number). Although this search experience is not as robust as that of Office Communicator, it is fairly effective. Additionally many users do not use the text search capability on IP Phones because it is not as easy to use as using a keyboard with Office Communicator. Additionally predictive text searches may seem to return unexpected results, match phone numbers and names, and have a limited screen for showing result sets.

The IP Phones locally implement a method of doing predictive search, enabling a user to query address book text names by using dial pad digits. For example, the digit 2 could map to an “A”, “B” or “C” and 6 could map to “M”, “N” or “O”. Thus, the digit sequence “226” would match address book entries with the name “Cam”, “Bam”, “Can”, and so on.

In enterprise environments, Address Book files can get too large to be reasonably downloadable by mobile clients, such as Communicator Mobile (2007 R2 release). To better target the needs of mobile clients, Office Communications Server 2007 R2 introduces a parallel path for Mobile Address Book data: The Address Book Web Query Service, which leverages the RTCAb database to provide on-demand address book queries for mobile clients.