Solved

Office Communicator displaying incorrect job title.

Posted on 2011-03-04
21
8,231 Views
Last Modified: 2016-07-25
Hello,

Been a long time member, just found a reason to ask my first question.  

We are running MS OCE 2007 R2 and this was brought to our attention a few weeks ago for 1 specific user, but research yesterday shows it to be a wider-spread issue.  Starting around the first of February 2011, we have found if we change someones title under the organization tab of Active Directory (2003) it does not appear to update in the MOC.  Using my own machine as a test I have verified the local GalContacts.db does actually show the users proper job title, but not the client.

As a test, I deleted the GalContacts.db and GalContacts.db.idx on my local machine, completely exited the MOC, ran ABServer -syncnow on the front end servers, waited about 15 minutes, signed back in to MOC and then waited for the random sync to the server then verified the GalContacts.db does still indeed contain the proper job titles for the users, but MOC still does not show it.  However, if you open the contact properties of the user in the MOC, basically showing you their AD attributes, it is correct here.  Simply, the MOC does not want to cooperate.  :(

MOC Client version is:  3.5.6907.221

It appears to be less of a server issue and more of a client issue.  Isn't it supposed to be reading the local GalContacts.db...or am I incorrect in assuming that?

Let me know if you need any further information.  Thanks in advance.

Jdtuck
0
Comment
Question by:Jdtuck
  • 10
  • 4
  • 4
  • +1
21 Comments
 
LVL 15

Expert Comment

by:whoajack
ID: 35061850
one thing I would try to do is right-click the Communicator shortcut and try Run as Administrator, although that is just a quick guess. Perhaps some file permissions to the locally created databases?
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35061921
A further step, I uninstalled the MOC client today, on the 2 front-end servers ran both ABServer -regenUR and -syncnow, deleted all registry keys and associated folders on my laptop, then reinstalled the MOC client.  Funny thing to note, this started right around the beginning of February and after I installed the MOC there was an update to push out from 01/25/2011...not sure if that might have broken something or not.  After reinstalling the client it still did not work before I installed the patch or after.

I will try the Run as Administrator, can't hurt.  

Thanks!

Jdtuck
0
 
LVL 15

Expert Comment

by:whoajack
ID: 35061970
Also while this is not the official URL, you can set the client to refresh immediately upon login with some registry keys...
http://www.shudnow.net/2010/01/20/forcing-address-book-updates-in-communicator-2007-r2/
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35062039
whoajack, I have seen this article, as it states, hundreds of times, but that poses two questions.  

1.)  All of our workstations are Windows 7 Professional, most X86, so that registry key does not exist once you get down to Microsoft, there is no entry for Communicator.  Should I just go ahead and create the Communicator folder then insert the Dword.

2.)  The client itself does not seem to update, however, the GALContacts.db does update.  It seems like there is simply a break in communication between those 2 pieces, so is it necessary to force the update, when the update seems fine anyways?
0
 
LVL 15

Expert Comment

by:whoajack
ID: 35062094
I would manually create any keys that don't exist. Also refer to the Microsoft documentation that also confirms the proper paths...
http://technet.microsoft.com/en-us/library/dd441290(office.13).aspx

So you are confirming that the local .db files ARE updating, just not the workstation GUI itself. I would think that either the client for some reason is lacking permission to the files, or there is another preferred contact retrieval point such as Exchange Server which is possibly also not updated.

Can you confirm the contact updates are showing everywhere else?
0
 
LVL 15

Expert Comment

by:sharepointguru14
ID: 35062144
Jdtuck,

I have seen this problem before. For me the problem was that the server and client where not at the same patch levels. Can you confirm that the server and client are at the same patch level? If not (and it sounds like its the case) it seems like you may have updated your client and not the server. Apply the latest patches to both to get them at the same level and then the changes should be reflected.
I have seen it happen with phone number and title both times the client was updated and the server wasn't
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35062159
I will create the key manually and see what happens.

Yes, I can confirm that all of our Domain Controllers and all the Front-End Exchange (2007) servers show the appropriate AD properties.  I have tested deleting/recreating the GALContacts.db and idx files on several of our support engineers computers, and opening it in Notepad shows the proper job title.  

Not sure what permissions would have changed, is there a document somewhere that states the basic permissions needed?

It seems to be only on the client GUI that is having the troubles.  For example, we use Exclaimer on our mail servers for mandatory signatures, and those are correct.
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35062293
sharepointguru14,

Thanks, not sure why that never occurred to me, we usually only patch and reboot every quarter, so I will check over the next 2 nights and install any missing patches.  It is highly possible that OCS patches came out at the end of January that were not applied.  However, I do not recall seeing the notification that patches were missing on the 2 front-end servers, I will double check.

Jdtuck
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35084113
sharepointguru14,

You were partially correct, automatic updates were installed on the clients to update the MOC, and the 2 front-end servers and the database server were missing updates, so those have been applied and it was still showing improperly.

Last night I completely deleted her account from OCS, waited about an hour then recreated it.  Gets interesting now, immediately after recreating her OCS account, in my MOC and in our web-based IM her title displayed properly, however, come in this morning and it is back to being incorrect.

Is it possible the SQL DB on the backend is not updating properly.  I thought I would look at the RTC tables, but everything is hashed so I see no way of finding out what AD attributes are in the tables for these people.

Anyone know a SQL query that will show this?  

Jdtuck
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 15

Expert Comment

by:whoajack
ID: 35084423
Well the thing is, you mentioned that the workstation-side database files were showing the updated information so I would focus on what sharepointguru14 pointed out, related to server components matching client components. Perhaps after applying any missing builds, stopping/starting all OCS services and/or rebooting the systems?

Do you have current build version for the server components? Or KB numbers for which updates are currently applied?
0
 
LVL 15

Expert Comment

by:sharepointguru14
ID: 35086583
JDtuck,

Yes it is important that client and server side builds are in sync. Can you confirm that they are? If so what build number are you on for each?

When this user logs in do they see the same thing as you? Are there any sync issues, outlook warning, ! signs?

Do you have these users in your local outlook contacts?
Is your communicator client set to show friendly names? (view -> show friendly names)
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35086637
Yes, the servers and the client are all in sync after updates were applied and servers rebooted.  The build is 3.5.6907.0, servers are 3.5.6907.196 and client is 3.5.6907.221.

When the user logs in they see the same info as everyone else and the Friendly names are enabled.  As I mentioned, what is weird was after deleting the account last night and recreating, it temporarily showed correctly.  Then it reverted back sometime between last night and this AM when I came in.

I do not have the user in local outlook contacts.
0
 
LVL 15

Expert Comment

by:sharepointguru14
ID: 35090584
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35095147
These have already been applied to both server(s) and clients.  I have verified all relevant file details match the patch levels.
0
 
LVL 8

Accepted Solution

by:
Jdtuck earned 0 total points
ID: 35100541
All,

I truly appreciate everyone's help, as I spent about a week researching this before I broke today and called Microsoft.  I would like to share what I learned as this is not anywhere on the Internet that Google could connect me with.

Basically, the servers configurations are fine, and all the testing I did on my laptop was a complete waste of time.  Here is why:

By default, every night at 1:30AM the new address book is updated and at some random time within the first hour of logging in each day the local workstation downloads updates from the day before that are included in the compact delta file.  In my opinion this next part is a design flaw, there are 2 AD attributes that are NOT included in the compact delta file, "office" and "title", I was told MS programmers did not think this would change often enough to warrant including it in the code, nor will it ever be.  I work in a company of roughly 1200 employee who change departments and get promotions all the time, so that is a negative for us...other downside is HR has the ability to change these titles so we are never informed.

The full and legacy delta files continue to include these attributes.  The legacy and full delta files are only downloaded when a NEW galcontacts.db file is downloaded to the workstation.  Another snafu in the programming is, even though my local galcontacts.db file displays the correct attributes, it will NOT reflect in MOC unless the user who's title, or whatever, changed has them as well.  So with that being said, for it to be represented company-wide you have to manually delete these files from the end-user in question so that they can download the Full and Legacy files at which point it gets reflected to everyone.  Even the engineer I worked with thought it was weird, but it is what it is.

For the changes to be represented you have to remove the 2 files from any client that has changes in office locale or title.  We are thinking of creating a login script to delete these daily, because we have multiple office locations and DC's so it will not impact the network performance being that authentication is staggered, and add the registry key that forces your MOC to download the GalContacts.db as soon as it is opened.  Hopefully making it seamless.

I hope that all makes sense, I have a copy of the MS diagram that explains how it all works and is solely based on the end-user having the correct files I will try to upload in case anyone ever needs it.

Thanks again!

Jdtuck
0
 
LVL 8

Author Comment

by:Jdtuck
ID: 35109461
Here is the diagram I was provided with that shows how the update process works from AD to SQL to MOC. OCS AB OCS AB
0
 
LVL 15

Expert Comment

by:sharepointguru14
ID: 35112517
jdtuck,

thanks for the post and the info. seems like there is a missing piece in this process, somehow I haven't come across it to this point. I'll be sure to follow up on it as I'm curious as to why its designed that way and it will remain that way.

Again sorry we couldn't help and thanks for sharing the solution.
0
 
LVL 8

Author Closing Comment

by:Jdtuck
ID: 35145510
I ended up calling MS to get resolution.
0
 

Expert Comment

by:Member_2_7969327
ID: 41728824
Finally I got Solution here... This worked .. Thanks a lot...

http://www.techittricks.com/2016/07/lync-ocs-skype-for-business-shows-wrong.html
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

As with any other System Center product, the installation for the Authoring Tool can be quite a pain sometimes. This article serves to help you avoid making these mistakes and hopefully save you a ton of time on troubleshooting :)  Step 1: Make sur…
Messaging apps are amazing tools with the power to do a lot of good, but the truth is the process of collaborating with coworkers requires relationships established through meaningful communication - the kind of communication that only happens face-…
Viewers will learn how to turn a Live Set into a compressed Live Pack file, and how to install Live Packs. Make: File > Collect All And Save: File > Manage Files: Click Manage Project: Click Create Pack: Select save location: Install: Doub…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now