Lync 2013 Server Fails to Update Address Book on Lync Clients

Ran into an interesting problem today and worked with Premier support to get it resolved.  What we found was even though our Client Policy is web and download, Lync clients would ONLY download the full Address Book the first time (i.e. new SIP profile on a computer) and never get updated after.

Lync 2013 Enterprise on 2008r2 servers with the latest CU.  All Lync clients are fully up to date.

So what does this mean?  Well it means that whenever my client first downloaded the GAL, that was the ONLY time it was given information about users in my Lync environment.  Notice in the print screen below that my GalContacts.db file was last modified on March 1st 2014 (note this was also the created day) however today’s date is March 11th 2014, thus my Lync client is ~ 10 days out of sync.

What’s supposed to happen?  Essentially if a Lync client is online then every 24 hours the Lync client will pull down a “delta” address book file.  While this link is very old, the retry logic still applies

Why wasn’t the client pulling down the “delta” files?  We started looking at the address book share and here’s what we saw.  In short, there weren’t any.

As you can see the Lync abserver.exe was doing it’s job and was creating full address book files.  I uploaded my client etl log to the support engineer (I’m told there’s no way for a non Microsoft person to open these logs) and what he found was my Lync client was trying to find c-12d0-12d1.lsabs which just wasn’t there.

Why was my Lync 2013 client only looking for that file and not pulling down the latest full address book?  The answer is the Lync client is hard coded to pull down C-*.lsabs files after it’s pulled down a full file.

So, why wasn’t there any C-*.lsabs files in our file share?  To get to this we need to look at the MaxDeltaFileSizePercentage value

As you can see our policy states if the delta is larger than 20% of the Full, go ahead and just create another full.  If you look at the earlier print screen you’ll see Lync was doing just that.  It was ONLY creating Fulls.  This presents an interesting problem for clients who are hard-coded to pull down files beginning with C-*.lsabs.

How do you get around this problem?  You set the MaxDeltaFileSizePercentage to 100 (thus telling Lync to create the delta file regardless of file size).  Once we set that and ran a update-csaddressbook the delta files were created.

You will notice that the delta files (ones beginning with C*) are much larger than the full (ones beginning with F*).  Ironically enough the C is for compressed and the F is for Full.  This is a known bug with the Lync 2013 server environment and a fix time is unknown.

Once the C*.lsabs were created, my Lync 2013 client picked up the Delta file and I could query for updated information.

While taking with the premier engineer I asked why as my Lync client looking for  c-12d0-12d1.lsabs and not any other?  Here’s why.  The Lync client will look for the two most last Full Files F-12d0.lsabs and F-12d1.lsabs and will pull down the c-12d012d1.lsabs (I’ve highlighted the important parts).  So tomorrow the delta file should be c-12d1-12d2.lsabs.

Also interestingly enough, these file names are the same among Lync pools (we have 4 pools in my environment).  This is good in the event you fail a pool over or move uses between pools.

One last side note *.lsabs is for Lync clients and *.dabs are for Lync devices.

Hope this helps someone else running into this problem.

3 thoughts on “Lync 2013 Server Fails to Update Address Book on Lync Clients

  1. Hi,

    Have been troubleshooting a similar issue and stumbled across your post and thought I’d share my findings.

    The Lync client determines the delta it needs from Last Modified date-stamp of the GalContactsDelta.db (or the GalContactsDelta.db if that exists – typically created in your larger environments) file in the sip profile. It calculates the number of days since 01/01/2001 (the same as the Address Book Service – – which is why the filenames are consistent across pools) and generates the delta filename it needs as C-xxxx-yyyy.lsabs and then requests this from the Address Book Service (e.g. https://lyncwebserverfqdn/abs/handler/C-xxxx-yyyy.lsabs) where:

    xxxx = Difference in days (01/01/2001 & Last Modified Date) as hex value
    yyyy = Difference in days (01/01/2001 & Todays Date) as hex value

    E.g. For a client with an a week old address book the last modified date would be 15/02/2015 and todays date is 22/02/2015 then:

    xxxx = 5158 days = 1426(hex)
    yyyy = 5165 days = 142d(hex)
    delta needed = C-1426-142d.lsabs

    The default Address Book Service configuration allows for generation 30 days of deltas (Get-CsAddressBookConfiguration > KeepDuration) meaning that the client should be able to find and request deltas from the Address Book Service using the above calculation as long the last modified date is less than 30 days old.

    So what happens when the last modified date than 30 days old? The general consensus is that the client should download a Full Address Book (F-xxxx.lsabs) based on the current date. This is where I am seeing issues as the Lync client simply takes the last modified date, calculates the delta filename and makes the request, with complete disregard for how old the last modified date-stamp actually is. Since it is more than 30 days old the Lync client makes a request for a file that doesn’t exist and we see HTTP 404 errors being recorded in IIS logs on the FE servers. What this also means is that if the GalContactsDelta.db (or the GalContactsDelta.db) ever becomes older than the Keep Duration value, your Lync clients’ address book will always be out of date unless the GalContactsDelta.db and GalContactsDelta.idx files are deleted forcing the the download of a Full Address Book.

    To make the situation worse, the Lync client will keep attempting to download this non-existent delta every 0 – 60 mins after the last attempt, generating yet more 404’s. So not ideal behaviour, generates unnecessary traffic, disk I/O, bigger IIS log files etc. In an ideal world I would expect the Lync client to have a threshold age value (linked with the Get-CsAddressBookConfiguration > KeepDuration value – there’s an idea MS and delivered using SIP in-band provisioning?) after which the Full Address book is downloaded.

    At least that’s the situation in the environment I am troubleshooting which has a large user base and behaviour is ubiquitous across a number of Lync client versions (list below), your mileage may vary. Quite straight-forward to test the above – just replace the GalContactsDelta.db/.idx files with those that have a different Last Modified date-stamp in the SIP profile and monitor HTTPS requests (Fiddler is your friend) to compare the different deltas being requested.

    Apologies for the rather large posting – got bigger than I thought (don’t have a blog, no time for it generally) – but hoping this adds to your already excellent presentation and helps the client side troubleshooting for this.

    Affected Client Software (in my environment):


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s