Office Communicator 2007 R2 July 2009 update (3.5.6907.37+) and newer - Stale GAL content problem (galcontacts.db)

I have seen sporadic reports of stale GAL (Global Address List/Book) reports from time to time from end users and on user forums.

9 times out of 10, a simple deletion of the galcontacts.db and galcontacts.db.idx located in %userprofile%\Appdata\Local\Microsoft\Communicator\\ would solve the problem.

It was noted that the RTM version of Communicator 2007 R2 client (6.5.6907.0) had less reports of the issue. I chalked it up as a bit of a fluke because there didn't seem to be a common pattern other than stale info and a possible bug/change in behavior in post-RTM updates.

Using my workstation as an example path for the galcontact[.db/.idx], under Vista, Windows 2008 R1/R2, and Windows 7:
C:\Users\atiensivu\AppData\Local\Microsoft\Communicator\sip_aaron@tiensivu.com\GalContacts.db
C:\Users\atiensivu\AppData\Local\Microsoft\Communicator\sip_aaron@tiensivu.com\GalContacts.db.idx
For earlier versions of Windows, the path would be:
C:\Documents and Settings\atiensivu\Local Settings\Application Data\Microsoft\Communicator\sip_aaron@tiensivu.com\GalContacts.db
C:\Documents and Settings\atiensivu\Local Settings\Application Data\Microsoft\Communicator\sip_aaron@tiensivu.com\GalContacts.db.idx

Now, however, we have an answer for the stale GAL problem with this OCS escalation scenario documented here. I really appreciated that they posted all the technical details.

Most notably:
The behavior of the Communicator client has been changed in .37+, whereby Communicator downloads Full 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

#1 Stop running manual absserver -syncNow and absserver -regenUR all together as per http://technet.microsoft.com/en-us/library/ee323612(office.13).aspx. (Most standard installs do not do this to begin with - you would have to set up a scheduled task manually to do this)

#2 Allow a 24 hour period to elapse after performing Step 1.
#3 Delete the GalContacts.DB on every client machine for every user ONLY ONCE for the next logon.

I'm hoping a future Communicator update fixes up this logic change but in the meantime, it can be worked around.

Unfortunately, with the logic change in 3.5.6907.37+, the behavior is now dependent on various patch levels of the OCS client, which is something that was problematic with a few of the Communicator 2007 R1 updates. I'm hoping TechNet is either updated or the behavior is refined a bit.

However, I doubt most installations will have seen this overall.

I figured I'd add my on-site/consultant perspective and get the word out a bit more since the July 2009 updates and newer patches have been offered on Microsoft Update and my standard mode of operation for almost all installations is to use the latest MOC client available.

I have some time off this week from work so I am finishing up a few more things to post here. Mainly OCS, Exchange 2010 and Windows 7/2008 R2 related. Good stuff!

BTW: New Year's Resolution - 1920x1200x32bit - bad joke, I know.