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).

https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d