SharePoint Tips and TricksMore specifically the Error: “Cannot get the full name or e-mail  address of user ‘domain\user’”

Recently we came across an issue where some users display names were displaying as domain/username instead of first name last name.  It was odd that only some of the user display names showed up like this.  This environment was running SharePoint 2010 Server Enterprise and had a one-way AD trust setup back an internal domain where the user accounts were managed.   The user profile sync service was not configured in this environment, but might have solved the problem.

You can use this command to get a count of how many users have improper display names:

Get-SPUser –Web “” | Where-Object {$_.DisplayName –like “DomainName*”} | Measure-Object

This number is the number of users whose display name shows as DomainName\username.

We found a number of links that would allow you to sync the user’s display name and email address from active directory, but in our case it wasn’t working because of our user permissions running the command.

In his blog post, UserName showing up as DomainName\UserName instead of Full Name in SharePoint 2010Mukesh Parmar shows how to re-sync all the users’ display names and email address directly from AD in a given web application.

Get-SPUser –Web http://webappurl | Set-SPUser –SyncFromAD

This works great if your users are in the same domain as SharePoint, but, in our case, our users are authenticating over a one-way AD trust.  So we see the same error again.. “Cannot get the full name or-email address of user ‘domain\user’”.

"Cannot get the full name or e-mail address of user..." The error you receive when your user account does not have access to AD for the sync operation.

“Cannot get the full name or e-mail address of user…”    The error you receive when your user account does not have access to AD for the sync operation.

This error really is masking the actual problem and unfortunately the ULS and Event logs do not provide any more information.  I then went over to Windows Explorer and tried granting someone from the trusted domain NTFS file permissions on a folder.  I was prompted for credentials.  I entered the credentials used for the people picker account.  I see users in their domain…

This ruled out any network communication problems.

Then I considered this: what if I ran the PowerShell session as the people picker account and then tried to execute this command using an account with read permissions on the trusted domain objects?

First, there are some permission sets that this user needs:

  1. Admin rights on the Web App (through user policy in Central Administration)
  2. Local Admin rights on the SharePoint server
  3. DBO rights on the SharePoint Configuration and Content databases

I didn’t take time to figure out the least privileged rights required for this operation, but the above worked for me.

Now, hold down left shift and right click on PowerShell ISE or SharePoint 2010 Management Shell to execute the application in the context of another user than the one you are logged in as.

Run as a different SharePoint user

You will be prompted for credentials.

Enter the credentials of the people picker account that you just gave admin rights to.

If using PowerShell ISE type in the following:

Add-PSSnapIn Microsoft.SharePoint.Powershell

Get-SPUser –Web http://webappurl | Set-SPUser –SyncFromAD

If everything works as it should, you should see no output.  While the operation is running you can use the first snippet of PowerShell  in a separate session from this post to monitor the number of user names with DomainName it it.  Here it is again:

Get-SPUser –Web “” | Where-Object {$_.DisplayName –like “DomainName*”} | Measure-Object

In my case, I did see some more of the “Cannot get the full name…” errors because it is trying to import full names and email address for AD groups like “domain admins” which have been given permissions within SharePoint.  We don’t need to worry about these.

How did the names get screwed up in the first place?

I don’t know for sure, but I’m thinking the admin user who added these people to SharePoint was using an account in the local SP domain and not the trusted domain.  I’ve also heard that if the site’s URL is not in Internet Explorer’s trusted site list it can cause this issue, but I can’t say for sure.

This was an interesting problem and fair solution, and I’m happy we figured out a fix.  I didn’t see any articles out there which involve a one-way trust scenario like this one so I hope this has helped you!  If you have any ideas  on how to prevent this in the first place, please post to comments. Thanks for reading!