[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 818
  • Last Modified:

User name display inconsistency in MOSS 2007 meeting attendee list

I have a problem with the Microsoft Office SharePoint Server 2007 attendee web part on a meeting site.

When I add names to the attendee list I get one participant whose name never displays correctly (same one every time).  Normally (and what I want) the meeting attendee web part displays each participants “Preferred Name” (like John Doe) in the name column, however with this one account it displays our domain name, back slash, the users AD logon account name (like COMPANY\jdoe).  I don’t know why this is happening, or how to fix it.

I’ve checked the active directory information and it’s all correct.  From the SharePoint Central Administration site I’ve checked the user profile, and it imported correctly and completely, and you can even type in the preferred name in the search box when adding accounts to the attendee list and it works properly, but as soon as you view the meeting site you get the wrong name shown.

Anyone know why this is happening?
0
skdax
Asked:
skdax
  • 4
  • 3
4 Solutions
 
M_K_ACommented:
Hi skdax,

Is it possible that there is a duplicate profile that is incomplete. I would expect the described behaviour if the meeting attendee web part finds an incomplete profile based on whatever search criteria it uses, but when you search using the preferred name, it finds the correct profile (because the duplicate does not contain the preferred name)

Apologies, I know that this is answering a question with a question ...
M_K_A
0
 
AtisCommented:
In short - (WSS) sites have their own user list. Even if you import/synchronize profiles (from AD) every day that bogous account in site collection won't be changed. Try changing user in that particular site not through SharedServices.
0
 
skdaxAuthor Commented:
M_K_A, Atis - Thanks for the suggestions, both were useful and I think pointed me to what the problem was, now I just have to figure out how best to fix it.  It appears this one problem user account is NOT being ported over from AD, so it's not really a matter of an incomplete profile, but rather no profile at all.
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
AtisCommented:
On second thought ...let's see if your farm is OK.
(replication to sites (WSS part) should still occur. Two timer jobs do that: Profile Synchronization and Quick Profile Synchronization (try to see their status through CA->Opeartions.
To skip error log checking let's do a basic task first.
With admin account run following command: stsadm -o sync -listolddatabases 3 (last parameter is days). If you have such databases do the following: stsadm -o sync -deleteolddatabases 3 (same parameter). Do not worry - this command won't delete content databases.
Then we have to fire up those thasks. Easiest would be to restart the server. You could also change timer job schedule by running the following: stsadm -o sync -synctiming m:60 (every 60 minutes).
Good luck!
0
 
skdaxAuthor Commented:
Atis - Our farm is pretty simple, a single server running MOSS 2007 and SQL Server 2008, so efforts along those lines should be straightforward.  Using stsadm I went back 7 days, and no databases show up.  I've also checked the timer jobs from within Central Administration and both seem to be working just fine, and both say the last time they ran was shortly before I wrote this.  I didn't run the "deleteolddatabases" command since it didn't appear to be necessary, but if you think just the act of running it might solve the problem, I'm game.

Although I haven't gone through all our OUs yet, I did discover that so far the problem appears to be isolated to a single OU, not just a single user account.  There are actually two users in this OU, and neither is importing, although they have no problem using SharePoint.  I added a test user to this problem OU, and forced SharePoint to do a full import, and the new user was NOT imported.  I've checked the security settings on this OU and the accounts within it, and they are exactly as they should be, nothing extra, nothing missing.  Maybe this will help narrow down the problem.
0
 
AtisCommented:
Interesting ...
Could you do the same select/query (you use in import configuration) in Active Directory Users and Computers tool (preferably on the same server logged in as a user you use for import task) and see if you get all users needed/expected. If not - try changing query (and/or recheck permissions for selected user) till you get what you need.
0
 
skdaxAuthor Commented:
OK, so here's the latest regarding this issue.

Before I was able to try the next suggestion provided by Atis it was time for another meeting, and now both users in my problem OU show up exactly as expected in the meeting attendee list.  They still don't show up in the overall list of users that can access the SharePoint site, and my previous meeting site is still showing "domain\username" rather than their preferred name, but aside from that things appear to be working correctly.  I still don't know why they don't show up in the overall list of users, but it doesn't seem to matter, so I suppose I can live with that.  And perhaps there is some glitch with my older meeting site causing this behavior.

I've plugged these two users into other meeting attendee lists and each time everything works correctly.  I hate these one-off problems that magically seem to fix themselves, but right now that's where I'm at.

Unless this latest development causes any light bulbs to turn on, it appears that the problem has been resolved, even if it hasn't been solved.
0
 
skdaxAuthor Commented:
Thank you M_K_A and Atis for your assistance on this issue.  It appears that the problem is isolated to a single meeting site, and has never occurred again.
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now