I had a support ticket I dealt with today that I couldn’t find any useful information on via the web, so I’m here to spread the knowledge, if you’re reading this it likely means you’ve searched one of the keywords here and are hoping to get your Skype for Business Address Book Service sorted and your phone/web queries returning search results.
So here’s the process of how it started and what I found along the way:
Firstly, a customer raised a ticket with my company that they weren’t getting search results on the directory on their Polycom VVX device. I logged into the Web UI for the device and enabled syslogging as I personally find this much easier to work with. Once I aimed syslog at my syslog server (Audiocodes Syslog is an awesome tool if you need recommendations!), I then changed the logging settings of the Polycom device in question. Skype for Business Address Book Service has two core components in the Polycom world, Skype for Business ABS (obviously!) but also Web Ticket, this will become apparent shortly. I set both of these to debug as I wanted to see exactly what was going on.
The first response was surprising, ABS wasn’t reporting any faults, but when I reviewed the Web Ticket elements, I saw a response in the XML from the Front End “ContactDataCorruption”. Within the request that the Polycom sent to the front end was the link of the front end it was querying, which should be the front end the user is homed to, we’ll need this later.
So ABS wasn’t processing any results as the web ticket query failed. Next I set about running the following PowerShell commands:
Test-CsAddressBookService, I expected this to return success as I was getting as far as the Web Ticket section, but I just wanted to be sure, I gave it the FQDN of the front end that had returned the ContactDataCorruption message, and I got a success response. All good and healthy, so far!
Next up was Test-CsAddressBookWebQuery, when I ran this, I got an error “CorruptionEntryError”, no matter what combination of source and target users I placed within the query, as long as I was aiming at the FQDN of this front end server, I met the same response, in this scenario the customer had three front ends, running the same command with either of the other two front ends gave me a success result. So the corruption was clearly on this server in question.
Now the fix, nice and easy, I ran “Update-CsAddressBook”, this command doesn’t provide any form of progress, it just starts a background process you don’t get to witness. I informed the customer we should leave it up to 10 minutes just to ensure it has time to update. I then re-ran the same “Test-CsAddressBookWebQuery” command again with the troubled front end and I got a success message!
I then asked the customer to confirm the fault had cleared, I monitored syslog whilst they went to the phone in question, sure enough I could see ABS module returning attributes of the user that was being searched for.
The customer was happy, the ticket was closed and I got some material to inspire me to write a blog post! I hope this helps!