Availability microsoft communicator not updating god, she's gorgeous
Sometimes we will find that even we changed user's properties in AD such as department, title, phone number etc., it's contact card still remain old info seen by other users. Recently I also faced several issues from my customers and I would like post a collected summary here for this scenario.
When Communicator client access the contact card, it will retrieve the title info from Static Publications, which is aggregated by OCS server. For the details, when a user subscribes to a presentity’s presence, the user can receive multiple instances of the presentity’s contact card. One of these is published by Office Communications Server when the data is from Active Directory. Others are published by Office Communicator when the presentity signs in, and they can be from in-band provisioning, the Address Book Service file, or user input. The data from the different instances can conflict with each other. It is up to the client application to interpret and reconcile the conflicting data. Office Communicator does the reconciliation for some properties, but not all of them. Office Communicator Service does not do any reconciliation, except publishing the Office Communicator Server instance of the contact card if it is missing or accidentally overwritten by client publication.
Please note that if one communicator failed to retrieve the latest values will overwrite the Static Publications with the outdated data available to it. Therefore, we not only need make sure the OCS generated correct address book file and subscriber’s communicator download the correct GalContact.db, but also need make sure the presentity’s communicator (the user in the contact card) also downloaded the correct GalContact.db and published the latest data to Static Publications.
OC Presence: Category Instances
Base on above theory, the troubleshooting steps are as follows:
1. Make sure the address book files in sever side generated successfully:
The address book data is retrieved from Active Directory, stored in the RTC database, extracted from the RTC database, and then placed in files and the RTCAb database for use by various clients. The following steps are performed:
• User Replicator (UR) reads the new or modified (that is, added, deleted, changed) user and contact object information from Active Directory and writes it into the RTC database. This process runs every 60 seconds.
• ABServer.exe reads the address book information from the RTC database and generates two sets of full and delta (that is, contains only the changes) address book files for use by Office Communicator (that is, with the file extension *.lsabs) and Office Communicator Phone Edition (that is, with the file extension *.dabs). These files are placed in a NTFS directory. ABServer.exe also creates a full database (that is, RTCAb) that is used by the Address Book Web Query Service. By default, ABServer runs on a daily basis at 01:30. Also all phone numbers that cannot be normalized are placed into a .txt file in the same NTFS folder.
• Office Communicator, Office Communicator Phone Edition, and other related clients download either the full or delta file on a daily basis. They are access either through a file URL (also called a UNC path) to the NTFS folder or through a HTTPS URL (or HTTP if configured). The address book entries are then stored locally in the GalContacts.db and potentially in GalContactsDelta.db.
• Office Communicator Mobile clients leverage the Address Book Web Query Service, which leverages the latest daily updates in the RTCAb database.
Data Flow in Address Book Server
1). Deleted files out of the ABS share in OCS server.
2). Ran the abserver –regenUR
3). Ran the abserver –syncnow
4). Both commands returned with the usual “completed successfully. You may need to wait 5 minutes.
5). Go to OCS server side’s address book files folder, run the command below to check each file one by one, such as Abserver /dumpfile F-0e6d.lsabs , check the output file to see if the target contact in these files contain old value or new value.
Managing the Address Book Server from the Command Line
2. After verifying the server side address book generated succcessfully with correct info, then we can make sure communicator client download the file sucessfully.
1). Delete all the communicator’s address book files under AppData\Local\Microsoft\Communicator\SIPAccount\
2). (Optional) After client side GalContacts.db files regenerated, we can double cofirm if the department, title, phone number etc. in contact card has been updated or not. Use some tool such as UltraEdit, open the GalContacts.db, search the department, title, phone number etc. to see if it is the new value or old value for this user.
Note: We can also let Office Communicator (.37 or later) downloads the GAL immediately after start-up:
3. Now we can wait for some time. Let communicator user publish its latest contact info from downloaded GalContacts.db to Static Publications via SIP. Then check it again.