Microsoft Office Communicator is not syncing GAL changes on a daily basis. Communicator client is 3.5.6907.37 or 3.5.6907.56
Symptom
========
Microsoft Office Communicator has an exclamation sign. When the exclamation mark is clicked an error is displayed stating that "Communicator cannot synchronize with the corporate address book because corporate address book file appears to be damaged....". You look at your local GALContacts.DB and it has not been updated at least since last 7 days + Today.
Cause
=====
Check the Creation/Update date on your local GalContacts.DB file under %userprofile%\Appdata\Local\Microsoft\Communicator\<User SIP URI>\
Say for instance it was Thursday, ?December ?10, ?2009, ??9:24:02 PM.
Check to see if the manual procedure to update the ABS files or to test changes to ABS files is being executed on your server. Filter out following Event ID from your Front End Server Event Logs.
Say for instance you find:
Event 1:
Log Name: Office Communications Server
Source: OCS Address Book Server
Date: 12/10/2009 6:55:25 PM
Event ID: 21007
Task Category: (1008)
Level: Information
Keywords: Classic
User: N/A
Computer: XXX-OCS-001.YYY.COM
Description:
Synchronization pass completed successfully
\\XXXX\F-0cc2.lsabs with ZZ,000 contacts. (X,XXX,XXX bytes compressed to Y,YYY,YYY bytes)
Event 2:
Log Name: Office Communications Server
Source: OCS Address Book Server
Date: 12/11/2009 3:35:20 AM
Event ID: 21007
Task Category: (1008)
Level: Information
Keywords: Classic
User: N/A
Computer: XXX-OCS-001.YYY.COM
Description:
Synchronization pass completed successfully.
Files written:
\\XXXX\F-0cc2.lsabs with CC,000 contacts. (A,AAA,AAA bytes compressed to B,BBB,BBB bytes)
So looks like the same File (F-0cc2.lsabs) got updated twice within in a 24 hour period.
At 12/10/2009 6:55:25 PM, manual process of Regenerating the ABS files was invoked, and as a result Full files and Delta Files were created at that time.
The client than downloaded that file or a Delta File at 12/ ?10/?2009, ??9:24:02 PM and stored the File Hash says H1 in the GALCONTACTS.DB.
The Server is already configured to run and generate the files in the Address Book Server file store as configured by the MSFT_SIPAddressBookSetting::RunTime WMI setting, which by default runs at 01:30 local time each day
So at 12/11/2009 3:35:20 AM, manual process of Regenerating the ABS files was invoked, and as a result Full files and Delta Files were updated at that time and the File Hash H1 got modified to H2 at the Server but not at the client.
Now the client thinks the File Hash for the Full File should be H1 and the Server has modified it to H2, and so the client considers the Delta Files as corrupt and reports “Dates didnt match” and stops syncing any changes.
In the Communicator.ETL you will see:
1431 TRACE_LEVEL_ERROR [0]0104.0F50::12/28/2009-13:48:33.978 (GalpReadDeltaFile:GalImport_cpp2781)<O_TRC><ADR>0x00000000</ADR>Dates didnt match</O_TRC>
The behavior of the Communicator client has been changed in .37 and onwards, whereby Communicator downloads Full Files (F-... ABS files) ONLY if the local GalContacts.DB hasn’t been updated in last 7 days AND a newer delta file is not available. Thus if the server generates full files but no corresponding delta file for 7 consecutive days then ONLY the client will download a full file.
As a result the local GAL stops gets updated daily since the Delta Files exists, but the Hash stored in the Delta File (H2) does not match the Hash stored in local GAL (H1).
Resolution
========
Step 1: Stop running manual syncNow and regenUR all together as per https://technet.microsoft.com/en-us/library/ee323612(office.13).aspx.
Step 2: Allow a 24 hour period to elapse after performing Step 1.
Step 3: Delete the GalContacts.DB on every client machine for every user ONLY ONCE for the next logon.
Once the above steps are taken care of , the Full (F-..._) , Compact (C-...) and Delta Files (D-....) files will get generated every 1:30 AM local time and will be synced in by the clients as per:
https://technet.microsoft.com/en-us/library/ee323492(office.13).aspx
"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). "
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Important!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Below is a hotfix (Communicator R2 CU4) ready, which can address this issue partially by looking at bigger delta files i.e. OC handles the hash mismatch by downloading a bigger delta file (C-[local gal date -2 or 3 or 4]-[today].lsabs).
Comments
Anonymous
January 01, 2003
There is a bright side to all this, at least now it is stated somewhere to not run this process manually as previously it does not state the repercussion in any TechNet article I have found. I do have to thank Premal for his work as it was very frustrating to not understand the mysterious behavior behind the Address Book process and Communicator.Anonymous
January 01, 2003
So you are suggesting to stop running regenur and syncnow completely even after you have deleted the galcontacts.db from a user and everything is fixed? This is definitely not going to make our clients happy when you can't force an update to the user's Address Book Files. Sounds like you guys have some broken code and need to fix it and stop constantly making changes to the way the Address Book system works.Anonymous
January 01, 2003
We completely understand your concern and we are working on possible solutions, but wanted to put this out so there is some troubleshooting assistance.Anonymous
January 01, 2003
What about during a pilot when we are doing things like Enterprise Voic and Remote Call Control and have to constantly make modifications to the Address Book Normalization Files and have to force an update to the Address Book Information, delete GalContacts so the client gets the updated information? I think this is a major issue here since during a pilot, we don't have the time to wait every 24 hours before making a change and then delete the GalContacts.db. We need the ability to do a syncnow and regenur. What's the guidance for this type of situation?Anonymous
August 04, 2010
Another repeated question I have received: What text to look for in the Communicator ETL log for ABS/GAL related traces: The answer is the text "Galp"