** Updated below **
If you, like me, have changed the default values of the address book with the resource kit
ABSconfig. You might want to read this post, and check out your own deployment.
I know the resource tools are what they are, and not fully supported when things turn out wrong, but I know plenty who have used this tool to manipulate the content of the address book. And as I showed in a previous post, I used it to manipulate how the Lync clients connect to exchange (
Read the post here).
This has been working like a charm for long time, and still does, for internal clients. But somwhere down the road, it seems there has been released a patch that changes the behavior of the web services for address book searches
I'll explain in brief. in my environment, I have made the address book populate the email address from a different field than the default. I have selected the "info" property of the AD user, an not "mail" as the default. When the address book is generated, and downloaded by a client, it looks just fine, with the intended result.
The internal clients all see their correct e-mail address, and the outlook client integration works like a charm.
However, when I searched the same username from a federated account, this is what I got in response.
As you can see, the web search module seems to be reading from the default/original property and not the property I set with ABSconfig.. And it really looks bad.
I have not tested every single property change, but if one property behaves like this, chances are other properties might behave in the same way.
If I find a solution to this, I will make sue to update this post. (And before you ask, this was tested with the newest available version: 7577.172)
** Update 1 march 13th **
Someone was kind enough to remind me the current CU is CU5, not CU4.
I have now updated affected system to CU5, and it did not help.
** Update 2 march 13th **
I wanted to give Thomas's comment some though, and ran the abserver -dumpfile command. Sadly, this only proved my suspicion. The web search must be getting it's populated values from somewhere else. This is the information in the lsabs file:
The info property is listed as it should, with the proper value. The bogus email address that was written in the "mail" property of this user is no where to be found. Still, the bogus email address is the one shown to federated users, or internal user that have not downloaded their local db file yet.
** Update 3 April 10th **
I recently discovered the error might not be on the web search module, but might have something to do with the Edge server component.
I can see the wrong e-mail address beeing populated through a "INFO :: SIP/2.0 200 OK" message:
------------------------------------------------------------------------------------
Content-Transfer-Encoding: binary
Content-Type: application/msrtc-event-categories+xml
Test
Test@company.com.fake
------------------------------------------------------------------------------------
Comments
with address book value problems it is often actually a client issue.
I recommend you to do the following:
1. Create a dump file from the most current address book full file with abserver.exe on the command-line.
2. Search the dump text file for one of the attributes that has shown different values in your tests. What does it say for that user in the ABS file? If the value is correct there, your address book configuration works as expected.
3. Now go to the client of the user that is "producing" those different values. Open galcontacts.db in a text editor and search for the same value/attribute combination. Chances are high that you still got the old/wrong value there. In that case delete the galcontacts.db file on the client machine (exit the Lync client before). Start Lync again and let it re-sync the ABS file into galcontacts.db and verify the value again with the same procedure.
There may be new values on the address book, but the information a client may publish to Lync Server takes precedence in almost any cases I can think of at the moment. Due to how the publishing/enhanced presence update/subscription mechanism works, such a client will make not yet udpated information on the client available to anybody subscribing to his information. And that's actually a very common reason, why you would see information conflicts like this.
Hope that helps.
Regards,
Thomas
@lyncall_de
Thank you for your reply.
Only problem is: The offline/downloaded address book is correct, it does show the correct values. I have regenerated the address book (deleted all files first), deleted the local cached copy of the client, and downloaded the new.
Whenever I use the downloaded db file. The output is the correct output. But when I do the search using Web services, the out put is the wrong output.
Federated users can't use the locally cached one. And that is why I created this post.
I can reproduce the same error on any Lync installation running CU4. I have tried 4 so far. They are all the same.
Kind regards
Lasse
have you also verified the second part of my comment?
That problem usually occurs, because a client publishes old information back to Lync Server. Because published information for the client takes precedence over address book data, those information is sent out to users subscribing to your status, such as federation users.
So you have to check the client(s) of the affected user as described above - the user, for which wrong information is shown.
Give it a try. Had that problem several times in various environments and was always able to solve it with the procedure above.
Kind regards,
Thomas
Every time I have regenerate the address book, I have also deleted any local files on the test client machine (local and federated partner).
If I search for a user which is offline (i get the wrong result), If I search a user which is online, still get the same result.
I might not have been to clear about this. But this was not an issue prior to the installation of CU4. (It used to be correct, but isn't any more. :)
Kind regards,
Lasse
- Thanks!
When downloading the addressbook all is present but when using webquery it isn't visible.