Much has been written about Lync’s Address Book service. We know that Lync generates a Full address book file nightly at 1:30am by default, and also creates daily update files (Delta and Compact) that clients download daily in an incremental backup sorta way. (Here’s a good description of how ABS does what it does).
The Lync client doesn’t keep downloading Delta files forever though – every so often it discards its constructed mash of Full and Deltas and downloads a fresh Full file and the process restarts. The timing of this cycle is dictated by the Address Book’s “KeepDuration”:
PS C:\Lync2010-Updates\Scripts> Get-CsAddressBookConfiguration
Identity : Global
RunTimeOfDay : 1:30 AM
KeepDuration : 30
SynchronizePollingInterval : 00:05:00
MaxDeltaFileSizePercentage : 20
UseNormalizationRules : True
IgnoreGenericRules : True
EnableFileGeneration : True
Job Title Changes Aren’t in the Delta files
A weakness of the Delta process is that it fails to capture changes to job titles, so if someone scores a promotion, they’ll still have their old title hanging around in some people’s Address Books for up to a month (the default KeepDuration). The seemingly obvious fix (at least for those of us with ‘realistic-sized’ Full address books and/or small deployments) is to set the KeepDuration to 1. Lync simply won’t bother with Delta files, and everyone will download the latest Full file each day.
Changing KeepDuration Breaks ABS Downloads
So you:
Get-CsAddressBookConfiguration | Set-CsAddressBookConfiguration –KeepDuration 1
– and then the wheels fall off:
“Cannot synchronize with the corporate address book because the file could not be found. Contact your support team with this information”.
Unfortunately Lync Server doesn’t tell the clients you’ve done this, and for potentially the next month (or whatever your KeepDuration was previously), each day the clients will try to download the Delta files they’re expecting to be there. Lync’s of course no longer generating these files, so there are lots of 404s in the IIS logs (C:\inetpub\logs\LogFiles\W3SVC<blah>\) on the Front-End:
2012-12-22 06:24:38 192.168.1.3 GET /abs/handler/C-1110-1115.lsabs - 443 sip:username@contoso.net 192.168.1.2 OC/4.0.7577.4109+(Microsoft+Lync+2010) 404 0 0 31
The same is evident if you run the Lync Logger and capture the ABServerHttpHandler component:
(0000000003F6C062)File not found lync2010.contoso.local\LyncShare\3-WebServices-1\ABFiles\00000000-0000-0000-0000-000000000000\00000000-0000-0000-0000-000000000000\C-1110-1115.lsabs" Return 404 to client.
Oh, and of course their address book is STAGNANT now, bereft of Deltas or any updates! Brilliant!
What’s the fix?
I don’t have one, beyond the obvious of running Jeff Guillet’s batch file from his “Script to Force Download of the Lync 2010 Address Book” post – which isn’t a very enterprise-friendly solution. It certainly works though! (Any solution that will delete the users’ galcontacts.db and GalContacts.db.idx files will do the trick of course).
I tried faking up C and D files, just by copying and renaming the latest F file, but whilst the clients download it OK, they don’t recognise the format and discard it. And Lync trashes and refreshes the content of the folder overnight anyway, removing the pesky files you so diligently created .
If this is a REAL problem for you, I guess you can download the ABS file protocol and write your own utility that will take the content of the latest F and re-package it as a D file. Otherwise, if riding out the storm’s not for you, set KeepDuration back to what it was before, and then perhaps every Friday (assuming a Monday-Friday operation of course) drop it by 2 days… (I *think* that will work. Let me know if my logic’s flawed). [Nope: see below]
I’m still licking my wounds from this last one. Next install I do I’m going to start with a KeepDuration of 1. I’ve only just escalated it, and I’ll let you know if MS comes back with a solution.
Updated 18th Jan2013: Nope, the clients NEVER re-sync. Every week (based upon my original KeepDuration of 7) they pull a new Full file, and then go back to requesting Deltas. Microsoft has confirmed they can dupe this in the Lab, so it’s just a matter of waiting for the fix). Stay tuned.
Updated 30th Jan: They’re still looking into it.
Updated 11th June: We seem to have reached an impasse. It’s “design intent” and no amount of arguing on my case seems to be getting anywhere. :-(
G.
do you know what else is not changed in delta files? Ie, Job title doesn’t update until there is a full re-create. Is there any other fields that you know of which also are not updated?
That’s the only one I’m aware of Todd – although I see in the release notes for 2013 it says if you change their DN you’ll break all ABS updates for them altogether! (http://technet.microsoft.com/en-us/library/jj205120.aspx)
There’s a KB for that
http://support.microsoft.com/kb/2798145/en-us
Hi Greig
Thanks for your interesting and helpful blog.
I was just wondering where you found out that the title changes are not part of the delta files – did you simply open the delta file in notepad or is there a mystery MS document somewhere?
I’m running a lab at the moment with the keep duration set at 7 days to test the AD title change to confirm to a client that it will update at the keepduration timeframe. This is for a lync 2010 environment.
Hi Danie.
I don’t remember when we first became aware of this in Lync 2010, and I don’t recollect there being a KB for it, sorry.