The Lync address book process can be very vague about the locations it collects the information from and the priority it applies to conflicting information. When information is changed in AD it can be very frustrating for administrators when it is updated and shows the new information for some but not others. As of this writing it seems the information closest to the user takes the highest priority. A local Outlook Contact will override the local Lync Address Book. The local Lync Address Book will override information kept in the Lync Address Book Services Web Query (ABS-WQ).
During the course of resolving a Lync address book issue for Lync Server 2013 “CU2″ I gathered a list of common issues that can occur during the address book generation process. None of these were the fix for my issue and I’ll explain my resolution in detail later in this article. There is a similar fix included in the 2013 February CU, KB2798145, however this was applied and did not resolve the issue.
- Phone Numbers (Part 1) – When phone numbers are not updating it can be the format the number has been entered into AD. The easiest resolution could be the number corrected in AD. Additionally the normalization file, company_phone_number_normalization_rules.txt, may be required for deployments with a complex environment. This file does not exist in default deployments but can be created and stored in following location: LyncShare\#-WebServices-#\ABFiles. There are several other items that can affect this but these are two of the most common I have discovered. This information is usually displayed incorrectly for every user.
- Phone Numbers (Part 2) – old users SMTP proxyAddress was added to another user, such as their Manager. This will typically only show the display name and/or picture of the other user. This can be corrected by removing the other users SMTP proxyAddress from their account or editing the address book proxyAddress field with the ABSConfig tool and setting it to collect Tel Only instead of the default Tel or SMTP. This information is usually displayed incorrectly for every user.
- Local Lync Address Book – It seems the Delta files of the address book process does not include all of the fields as a full address book file. From my research the title is one of those fields at the time of writing. A client will download a full address book and then delta files based off of the KeepDuration (default 30 days) of the Address Book Configuration (Set-CsAddressBookConfiguration). It is possible after this period the changed information of a user, such as a new title, will change after this period ends. Additionally you can force a new address book to be downloaded by deleting the GalContacts.db and GalContacts.db.idx. These files are locked while the Lync client is running so exit the client before trying to delete them. The locations vary based on Windows version, the Lync client version and sip address. The locations are as follows:
- Windows XP with Lync 2010 – %userprofile%\Application Data\Local Settings\Microsoft\Communicator\sip_<sipusername>\
- Windows XP with Lync 2013 – %userprofile%\Application Data\Local Settings\Microsoft\Office\15.0\Lync\sip_<sipusername>\
- Windows 7 with Lync 2010 – %userprofile%\AppData\Local\Microsoft\Communicator\sip_<sipusername>\
- Windows 7 with Lync 2013 – %userprofile%\AppData\Local\Microsoft\Office\15.0\Lync\sip_<sipusername>\
- Outlook Contacts (Part 1) – Another occurrence I have seen is when an Outlook Contact exists for a Lync Contact, the information stored in Outlook will override the information displayed by Lync. Outlook has a process to update the contacts however If for some reason the old information is displaying over the new, it may need to be manually edited. This information is usually displayed incorrectly for an individual user.
- Outlook Contacts (Part 2) – A rather odd occurrence is if the user who’s information is not displaying correctly has an Outlook Contact of themselves. It seems this old information from the Outlook Contact or even their local Lync address book can be populated to the Lync Server and added to the information of the server Address Book. Additional sources are items configured by the user in the Lync client and also the Outlook Social Connector. This information is usually displayed incorrectly for every user.
- Address Book Customization – If there has ever been customization performed on the Address Book, probably by the ABS Configuration Tool (ABSConfig.exe) from the Lync ResKit, it is possible something was misconfigured or corrupted. These customizations may need to be changed back and in some cases the defaults restored by using the Restore Defaults function of the ABS Configuration Tool. This information is usually displayed incorrectly for every user.
- SharePoint – If integration has been configured with SharePoint this can also override information from AD. Check SharePoint and see if the affected users information has been updated correctly. This information is usually displayed incorrectly for every user.
- SQL – Most likely the information is not replicating correctly because of a service or permissions issue. A quick way to verify the information in SQL is correct is to add the user to an Outlook email, look at the Lync Contact Card of the affected user, if the correct information shows SQL has the correct information. This method is using the ABS-WQ and bypasses the local Lync Address Book. Additionally you could view the information using he SQL Server Management Studio, more on this later.
Remember when I said none of these were the fix to my issue? Well that is mostly correct, as it required 3 of the above resolutions in the correct order to resolve the issue. Can you guess which 3 and in what order?
To create the issue this seems to be the process of events.
- User was created with original information.
- User was enabled for Lync 2013.
- User was disabled and moved to a different OU in Active Directory.
- User was re-enabled in AD, information updated, and moved to another OU.
- User was re-enabled for Lync 2013.
The information that was updated for the user was the Title and Department fields in AD. Everyone saw the old entries however there were two behaviors based on Lync client version. Lync 2010 would almost always show the old information and Lync 2013 would sometimes show the old information and sometimes show the updated information.
I started the troubleshooting process as such:
- The time period for a Full address book file to be created had passed since the changes were made to AD.
- Opened AD Users and Computers and verified the information was updated. It was.
- Verified the updated information was correct in SQL. It was.
- I opened up my local copy of the Lync address book using notepad and could see where the user had the old information. At this point I knew it was something with the address book only, so I also looked at the full address book on the Lync server and verified it was in that file and it was.
This is a screenshot (edited) of the incorrect information in the GalContacts.db file:
Below is a screenshot (edited) of what the updated information should look like in the GalContacts.db file after the fixes, later in this article, are applied.
- No customization had been performed to the Address Book, but to be certain I used the ABSconfig tool to Restore Defaults and ran Update-CsAddressBook. No change.
- Checked to see if the affected user(s) had any Outlook Contacts or other customizations on their computer. Additionally I deleted their local address book; GalContacts.db and GalContacts.db.idx. I assumed there would be no change but still waiting for the new address book to be download by the user, then ran Update-CsAddressBook on the Server and deleted and downloaded the new address book for my client. No Change.
- Finally I decided to use the SQL Server Management Studio and see where it was pulling the user data from in AD. This was the first break through.
I opened up the RTCAB database and ran the following SQL command.
The user account was previously in the Disabled OU but has since been moved to the built-in User OU. I edited this entry directly in SQL using the command
set [AdDn] = ‘CN=username,CN=Users,DC=domain,DC=com’
where [AdDn] = ‘CN=username,OU=Disabled,DC=domain,DC=com';
If you have an error running the SQL statement, be sure you database selected is rtcab and not something different like Master. Additionally you may need to refresh the local cache or just close SMSS and reopen it.
I verified the entry had been updated by running the SQL select statement again.
Figuring this was the solution, I ran Update-CsUserDatabase waited for it to complete, ran Update-CsAddressbook, deleted the local address book file; GalContacts.db and GalContacts.db.idx. There was no affect on the newly downloaded address book.
My next step in the solution was the Restore Defaults on the ABSConfig.exe.
After performing this step, and waiting on the process to finish, I again ran Update-CsUserDatabase waited for it to complete, ran Update-CsAddressbook, deleted the local address book files; GalContacts.db and GalContacts.db.idx. Finally the edited user showed the updated information. This process required both of these steps as other users with the old information issue were still not corrected. After also editing their incorrect AD mapping and Restoring Defaults again, the remaining users were finally fixed after the new address was downloaded.
Were you able to guess the steps and order correctly? If not don’t feel bad this took several attempts to figure out. As it turns out the Update-CsUserDatabase is most likely not a required step. What tripped me up, and I have still not tracked down the answer on, is why did it require a Restore Defaults from the ABSConfig.exe tool to finally force the address book generation process to look at the updated AD entries?. My understanding is Update-CsUserDabase should have accomplished this step once I had edited SQL to point to the correct AD mapping.
Hope this helps clarify some of the randomness of the Lync 2010 and 2013 address book process.