Live Communications Server 2005 Address Book Service FAQ & Troubleshooting

  • Article

FAQ

Question - Is there a way to control the users that are populated in the ABS file or is there a way to filter the address book based on an AD Attribute?

Answer - The users populated in the ABS files can be controlled based on certain AD Attributes listed in the ABAttribute table.

One such attribute used for filtering is the msExchangeHideFromAddressBook. This is a User attribute added by the Exchange schema. Exchange uses this to hide the contact from Outlook Global Address List, if the value is equal to True. In the same way if the value on this attribute is True, UR does not include that user in the ABUserEntry table and hence this user will not be in the ABS files.

There are 5 other attributes - mailNickname, msRTCSIP-PrimaryUserAddress, telephoneNumber, homePhone and mobile that can be used for filtering users. A user has to have a value for at least one of these attributes to appear in AB files. For example, if you do not want service accounts to appear in AB, you might try deleting these 5 attributes from service accounts.

Question - How can you filter ABS entries to only include SIP enabled users?

Answer - ABS entries can be filter for only SIP enabled users, but changing the value in the Flags column for the 5 required attributes -

· mailNickname,

· msRTCSIP-PrimaryUserAddress,

· telephoneNumber,

· homePhone

· mobile

a) Among the 5 required attributes, clear the 0x800 bit in the Flags column of AbAttribute table for all of them, except the msRTCSIP-PrimaryUserAddress attribute. This way the only entries that will appear in the address book files are those that are SIP enabled.

b) After modifying the AbAttribute table, start a UR regeneration process, by setting the RegenerateCookiesNow of the MSFT_SIPUserReplicatorSetting WMI class to TRUE. This will refresh the data in AbUserEntry table.

c) Next step is to start a manual -syncNow operation. The generated ABS file will now have only SIP enabled users.

Even if you filter the address book, this does not prevent end users from interacting with users excluded from it (SIP enabled or otherwise). They can still find, add as contacts, or manually make calls to users by entering their complete user name (test.user@contoso.com) into the find field. Also, any entries in the user’s PIM (Outlook, or Windows Address Book) can be found/addressed.

Limiting entries in the address book does NOT limit people's ability contact them, or see their presence (assuming they are SIP enabled).

Furthermore, the address book file allows people to use OC to initiate e-mail, or contact other users via telephone or VoIP call (if RCC and/or PC2Phone are enabled) that are NOT SIP enabled. Incoming phone calls (TO SIP enabled users, from NON SIP enabled users in the address book) will also be correctly identified by name (as opposed to just displaying a phone number) when the address book file contains a record for the calling user.

Limiting access to this kind of information can dramatically lower the overall value of OC/LCS to an end user or a company as a whole. If a customer wants to limit the records in the address book file, it may be worth a discussion to determine what their concerns and goals are, and to identify the value these other records can provide. If the goal is to limit communication across organizational boundaries, this is not the appropriate means; limiting the records in the address book file does not adequately perform this kind of separation, though it can be useful in conjunction with other techniques.

 

Question - Does any changes made to AbAttribute table impact future upgrades/service packs/etc.?

Answer - While upgrading if one chooses not to replace the database option, then the changes to AbAttribute table will not be impacted, otherwise they will get replaced.

 

Question - Are there ways to have ABS look only in a specified OU or OUs or is OU based filtering supported?

Answer - There is currently no way to have ABS look only in a specified OU or OUs.

 

Question - How are ABS and UR related?

Answer - ABS relies on User Replicator (UR) to sync the users that are in the AD to the database. ABS then syncs the user data from database to ABS files.

Question - What is the best practice for locating the Address Book data files for internal and external access?

Answer - The best practice is to have a dedicated machine for the ABS files, as documented.

 

Question - Will there be any issues with installing IIS on a Standard Edition Director server and locating the address book data files, for internal and external access, on the Director?

Answer - This should work fine and would not be an issue.

 

Question - Are there ways to customize phone numbers in AD?

Answer - Phone numbers in AD can be pre-normalized using a utility in the Live Communication Server 2005 SP1 resource kit. Please see the Communicator_Phone_Normalization_Scripts_Guide.doc, which is installed in the PhoneNormalization folder of the reskit. Administrators should also review the Office Communicator 2005 Telephony Planning and Deployment Guide when considering how to address phone number normalization in their deployments.

In addition to pre-normalization in AD, phone numbers can be customized in the OC client by turning on Normalization (is turned on by default) in the Address book service, using the Generic and Custom phone normalization rules files. This can either replace or compliment pre-normalizing numbers in AD, and details can be found in the Live Communications Server 2005 Document: Address Book Service Planning and Deployment Guide.

 

Question - Does ABS directly modify AD, while applying normalization rules to phone numbers?

Answer - No, ABS does not directly modify AD with normalized phone numbers.

Phone numbers in AD can be pre-normalized using a utility in the Live Communication Server 2005 SP1 resource kit. Please see the Communicator_Phone_Normalization_Scripts_Guide.doc, which is installed in the PhoneNormalization folder of the reskit. Administrators should also review the Office Communicator 2005 Telephony Planning and Deployment Guide when considering how to address phone number normalization in their deployments.

 

Question - By default, a full address book file is generated if the diff file exceeds 1/8th of the total. Is there a way to change this behavior?

Answer - Currently there is no way to control or change this behavior. The next release will provide ways to configure this.

 

Question - Is there a way to control when an ABS file will be generated?

Answer - ABS file generation time on the server is currently configurable through WMI property MSFT_SIPAddressBookSetting::RunTime.

 

Question - How can we safely uninstall the Address Book Service and the User Replicator?

Answer - Since ABS for LCS 2005 SP1 is a separate service, it can be safely be uninstalled from Add/Remove Programs. There are no ways to uninstall UR as it is part of the server itself.

 

 

Troubleshooting

When manually running syncNow, an empty ABS file was created, or only users who had been updated in the AD appeared in the ABS file.

If ABS is installed on a separate server, a manual UR regenerate has to be done for users to be updated in the ABS files.

Why do I see entries for users who are not enabled for LCS in the ABS files?

This is by design. Some users who are not enabled for LCS may have telephone numbers. If an entry has a phone number, but not an IM address, that user can be called from OC, but cannot receive IMs.

ABS information is also used for Reverse Number Lookup on inbound calls to OC users. This enables call notifications, missed and forwarded call e-mails, and conversation window entries to reflect the user associated with a phone number, even if they are not SIP enabled.

When I try to call using an ad-hoc dialed number, I notice that the number is not normalized as I expected, even though I was able to verify that the normalization worked on that number using the -testPhoneNumber switch.

First, verify that Communicator successfully downloads the Address book (GalContacts.db) file, which contains the normalization rules used by Communicator for ad-hoc dialed calls. This file can be found in the “%userprofile%\ Local Settings\Application Data\Microsoft\Communicator\" folder. If this file does not exist, verify that the ABS service has been run at least once, that the files are output correctly, and that the user has access to the IIS server and share in the ABS config.

You may be affected by the issue described in KB article 913092 (A custom telephone number normalization rule is not applied by the Live Communications Server 2005 SP1 version of the Address Book Service). That article contains a link to a hotfix that addresses this and other issues.

Finally, the -testPhoneNumber switch uses both the Generic and the Company normalization rules to verify the number specified. However, Communicator uses only the Generic rules for ad-hoc dialed numbers.

A workaround for this would be to add some (or all) of the Company rules to the beginning of the Generic rules file. Since this file is generally set to read only, you will need to change the permissions on first. For clarity, you may wish to ensure that a normalization rule only exists in one or the other of the normalization rules files, or to rename the Company Specific rules file once you have added the appropriate rules to the Generic rules file.

Once the Generic rules file is updated, you can generate a new set of ABS files via a manual -syncNow operation. Since these files will have the same names as the set generated automatically that same day, Communicator may not automatically download the new files the next time it attempts to sync the Address book files. Communicator will get the changes the next time it tries to sync AND the files it currently has were generated on a different day than the new files. You can force Communicator to immediately download the new files by exiting Communicator, manually deleting the GalContacts.db file, and restarting Communicator.

 

 When I verify my phone number using -testPhoneNumber switch everything appears to be okay. But, a -dumpFile shows that the number has not been modified as expected.

You may be affected by the issue described in KB article 913092 (A custom telephone number normalization rule is not applied by the Live Communications Server 2005 SP1 version of the Address Book Service). That article contains a link to a hotfix that addresses this and other issues.

This KB describes a bug in LCS 2005 SP1 AB Server where AB Server applies a built in E164 normalization rule BEFORE any rules from the Company or Generic rules files. The -testPhoneNumber command line switch does NOT apply the built in E164 normalization rule when performing the test normalization. Your numbers may not be normalized as expected, because the built in rule supersedes your custom rules.

 When I did a manual command line -syncNow, I did not see any delta files created. Instead, another full file got created. Is this expected behavior?

Yes. If the size of the Delta file is going to be greater than 1/8 the size of the full file, only a full file will be generated. An event log entry will also be found showing why the delta file did not get created.

What happens when a client doesn't logout for several days (which is a common scenario for some of our users)? Do users get address book updates without signing out and back in?

If a Communicator client stays online and never signs out, new updates (probably delta download files, but possibly full files) are downloaded. It happens at 12am UTC time, if the local database on the client is outdated (yesterday’s date) and the delta has been generated by ABS. If the delta hasn’t been generated by ABS, the client will keep trying (using an exponential back-off between tries) until it maxes out. At that point an error will be shown at the bottom of the main UI.

-Kripa Seetharam

SDET Unified Communications Group