Updating keeps esea client unlimited, kiss
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 http://technet.microsoft.com/en-us/library/ee323492(v=office.13).aspx.
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-12d0–12d1.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.