locked
AD contact does not show up in the address book

    Question

  • I have created a contact in AD for click-to-dial functionality and for caller-id reverse lookup. The contact does not have SIP or e-mail enabled. It only has a phone number and I would like this contact to show up in the address book for the Communicator. I have done abserver -regenurabserver -syncnow, and deleted and re-downloaded galcontacts.db but the contact still does not show up in the Communicator.

     

    What am I doing wrong?

     

    Any help would be appreciated.

     

    Thanks,

    AK

    Tuesday, December 09, 2008 9:55 PM

Answers

  • The .LSABS file gets locked by RTCCOMPONENT service and while it is in the locked state, the -syncnow process cannot oerwrite it. This happens quite often. The trick is to check the date/time stamp of the LSABS file after doing -syncnow. If it is what you expect, then it is fine but if it is an old date and time, the you must manually unlock the file from computer namagement and then try to do -syncnow. When and why the file gets locked, I do not know. I am planning to talk to Microsoft about it to see if they will acknowledge it as a bug and release a hotfix. If that ever happens, I will update this thread.
    • Marked as answer by Anupam Agarwal Saturday, December 13, 2008 1:14 AM
    Saturday, December 13, 2008 1:13 AM

All replies

  • Did you configure the contact with an E.164 number in AD?

    You should put a number similar to this one but then for your own country +3255555555

    So include a + symbol and the complete international phone number without leading zero's

     

    Then do a -Syncnow and delete the glocontacts.db on the local client to force AB download

    Tuesday, December 09, 2008 10:09 PM
  • Actually you should be able to see the phone numbers on the Contact in the Address Book in formats not matching E.164 assuming that numbers are correctly normalized by the Address Book service.

     

    I have a sample contact in my lab that is not SIP-enabled and contains three populated AD number attributes in these formats:

    telephoneNumber: (800) 555-1234
    homephone: 800 555-6789
    mobile: +18005554321

     

    And the Company_Phone_Number_Normalization_Rules.txt file includes this general translation pattern:

    ##
    ## Normalize all AD phone numbers to E.164
    ##

    \+?[\s()\-\./]*1?[\s()\-\./]*\(?\s*(\d\d\d)\s*\)?[\s()\-\./]*(\d\d\d)[\s()\-\./]*(\d\d\d\d)[\s]*
    +1$1$2$3

     

    And the resulting Galcontacts.db contains the following raw and normalized strings:

    Work Phone Display  (708) 878-4605 

    Work Phone Number  tel:+17088784605

     

    Home Phone Display  800-555-1212

    Home Phone Number  tel:+18005551212

     

    Cell Phone Display  18005551234

    Cell Phone Number  tel:+18005551234    

     

    The contact's numbers appear in OC using the display patterns above, which match the way the appear exactly as entered in AD.  But unless they are normalized into E.164 then the OC client typically does not display them at all.  There is some fuzziness to this behavior, but following the recommended usage of the ABS will take care of the problem with the least impact to current AD attributes.

    Wednesday, December 10, 2008 1:40 PM
    Moderator
  • Wednesday, December 10, 2008 2:19 PM
    Moderator
  • It seems to be a timing issue. regenur, syncow and galcontacts.db download did not show the contact yesterday after I added it but it appeared this morning after the address book was rebuilt last night. The address book generation is a frustratingly nebulous process where following the pricess does not always yield results but then things eventually settle down.

     

    Thanks for all the tips though. I have learned a lot about the address book in the last few days...thanks you you guys.

     

    AK

     

    Wednesday, December 10, 2008 3:43 PM
  • I've never had the manual process not work correctly, but you need to make sure you wait long enough between steps.

     

    When making a change to and AD attribute insure that you allow for AD repliaction to complete before running the -RegenUR parameter on the ABS.  After running that command check the OCS FE server's event log to verify that the regen process has completed, then fire off the -SyncNow.  That will take about 5-10 minutes to report anything in the event log.  After that completes then delete the galcontacts.db on the client and exit/restart OC.

    Wednesday, December 10, 2008 4:20 PM
    Moderator
  • I have been doing all of that. I am traking the event logs between commands to make sure everything is complete before proceeding to the next step. Here is something else I observed which appears to be a bug but may help shed some light on this address book anomaly I have been dealing with.

     

    According to the Microsoft article http://technet.microsoft.com/en-us/library/bb894616.aspx, there are 30 days worth full and delta files created before they are recycled. A full file is built each day and a delta file for the difference with each of the previous days' full files is built. So, after I perform regenur, it updates the SQL table with the updated binary data from AD however, syncnow only overwrites the DABS file (use by Communicator Phone Experience clients) and not the LSABS file (used by MOC clients). The event log reports that one new full file was written but does say specifically which one. When I check the date/time stamp, I see that the DABS file has the updated time stamp for when the syncnow was run but the LSABS file still has the old 1:30 AM time stamp. It works only if I delete the LSABS file and then perform syncnow. Deleting this file is also not easy becasue it is locked by some process. I have to force close the file from the computer management MMC and then delete it. I am wondering if the file locking has something to do with the new LSABS file not being created. Running syncnow does not create delta files becuase delta files for new changes in AD becuase thay can only be created for the difference between full files for the current day and each of the previous days. The problem is the overwriting of the new full file.

    Wednesday, December 10, 2008 6:07 PM
  • I have also verified the above scenario using the -dumpfile argument on ABSERVER. After running syncnow, the LSABS dump does not capture the changes made to AD but after deleting it and then runing syncnow, the LSABS file dump shows the AD changes.

     

    Wednesday, December 10, 2008 6:11 PM
  • The .LSABS file gets locked by RTCCOMPONENT service and while it is in the locked state, the -syncnow process cannot oerwrite it. This happens quite often. The trick is to check the date/time stamp of the LSABS file after doing -syncnow. If it is what you expect, then it is fine but if it is an old date and time, the you must manually unlock the file from computer namagement and then try to do -syncnow. When and why the file gets locked, I do not know. I am planning to talk to Microsoft about it to see if they will acknowledge it as a bug and release a hotfix. If that ever happens, I will update this thread.
    • Marked as answer by Anupam Agarwal Saturday, December 13, 2008 1:14 AM
    Saturday, December 13, 2008 1:13 AM