Answered by:

The user does not exist or is not unique

Question

i have a Project Tasks list with an Assigned To column. I use the people picker to select the user that I want to assign a task to. I can find the user using People Picker, however, after adding the user I get the following
message:

"An error has occurred in the row. Click for more details". Followed by: "The user does not exist or is not unique"

Answers

i found that if I don't use the people picker and just type in the username as domain\username, it works. After entering domain\username, I click to the next field and it auto populates/syncs the name correctly.

We ended up calling Microsoft on this, and while we don't yet have a resolution, I believe we have a better idea of what may be causing this. The diplay name of the majority of our users is in the format "lastname, firstname"; well if the display name
did not have a comma we did not receive the error.

This is certainly not an ideal solution, but it seems like progress.

Microsoft has now informed us that they have received other reports of this, so this is a known issue. They have told me that they are working on a fix, but do not know when that will be released.

So in case anyone wants to know for reference.

There is an issue when using a list in the gantt view if you use the People Picker and the AD user has a comma in their display name. This will display "The User does not exist or is not unique"

Ok so I also contacted Microsoft on this issue and it is only an issue with users that have commas in their display name. They indicated this is a known issue, and it will not be fixed. Their provided workarounds are to use the user's alias
instead, or use the New Form option in the ribbon where applicable.

That is the issue. In a one-way trust scenario, the Global Catalog in your Resource Forest is unaware of the Display Name because that is not an attribute that is stored in a Foreign Security Principal.

Another issue I found in this type of setup is there is a registry key (HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure) that you need to provide the Application Pool account that is running the site with permission to. For some
reason it isn't done automatically.

My assumption is that you're in a DMZ setup, and SharePoint just doesn't do so well in that type of environment. You may be able to get around the specific issue you're seeing by using Claims Based Authentication instead of Classic Authentication (but
CBA has its own issues to contend with, I suggest you test it out).

That is the issue. In a one-way trust scenario, the Global Catalog in your Resource Forest is unaware of the Display Name because that is not an attribute that is stored in a Foreign Security Principal.

Another issue I found in this type of setup is there is a registry key (HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure) that you need to provide the Application Pool account that is running the site with permission to. For some
reason it isn't done automatically.

My assumption is that you're in a DMZ setup, and SharePoint just doesn't do so well in that type of environment. You may be able to get around the specific issue you're seeing by using Claims Based Authentication instead of Classic Authentication (but
CBA has its own issues to contend with, I suggest you test it out).

That is the issue. In a one-way trust scenario, the Global Catalog in your Resource Forest is unaware of the Display Name because that is not an attribute that is stored in a Foreign Security Principal.

Another issue I found in this type of setup is there is a registry key (HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\Secure) that you need to provide the Application Pool account that is running the site with permission to. For some
reason it isn't done automatically.

My assumption is that you're in a DMZ setup, and SharePoint just doesn't do so well in that type of environment. You may be able to get around the specific issue you're seeing by using Claims Based Authentication instead of Classic Authentication (but
CBA has its own issues to contend with, I suggest you test it out).

http://sharepoint.nauplius.net

I'll take a look at the registry setting that you mentioned. We are not using a DMZ setup; this is within our internal SharePoint site (Classic Auth; NTLM).

i found that if I don't use the people picker and just type in the username as domain\username, it works. After entering domain\username, I click to the next field and it auto populates/syncs the name correctly.

i found that if I don't use the people picker and just type in the username as domain\username, it works. After entering domain\username, I click to the next field and it auto populates/syncs the name correctly.

Did you ever find a resolution that doesn't require you to enter the username as domain\username?

Even entering the username as domain\username doesn't work for me. My scenario is similar in that the user is resolved but I can't save the list item having the Person column. However, it does work when the user IS a member of site.

i found that if I don't use the people picker and just type in the username as domain\username, it works. After entering domain\username, I click to the next field and it auto populates/syncs the name correctly.

Did you ever find a resolution that doesn't require you to enter the username as domain\username?

Even entering the username as domain\username doesn't work for me. My scenario is similar in that the user is resolved but I can't save the list item having the Person column. However, it does work when the user IS a member of site.

Unfortunately we could not fully resolve this so we just decided to use domain\username as a workaround.

I believe we are experiencing the same problem. The same error occurs when we try to add a user via People Picker in the Project Tasks view. If we enter the name directly in the form domain\username this works fine.

I checked the registry key in question and the application pool account has read access to this.

We have experienced this in our production environment which is running Sharepoint Server 2010 with the February 2011 Cumulative Update. We have also duplicated this in our development environment with the February 2011 Cumulative Update, the SP1 Update,
and the June 2011 Cumulative Updates.

In our development environment we have only tested with Classic Authentication, but in the production environment we have tested with both.

We ended up calling Microsoft on this, and while we don't yet have a resolution, I believe we have a better idea of what may be causing this. The diplay name of the majority of our users is in the format "lastname, firstname"; well if the display name
did not have a comma we did not receive the error.

We ended up calling Microsoft on this, and while we don't yet have a resolution, I believe we have a better idea of what may be causing this. The diplay name of the majority of our users is in the format "lastname, firstname"; well if the display name
did not have a comma we did not receive the error.

This is certainly not an ideal solution, but it seems like progress.

Microsoft has now informed us that they have received other reports of this, so this is a known issue. They have told me that they are working on a fix, but do not know when that will be released.

So in case anyone wants to know for reference.

There is an issue when using a list in the gantt view if you use the People Picker and the AD user has a comma in their display name. This will display "The User does not exist or is not unique"

We ended up calling Microsoft on this, and while we don't yet have a resolution, I believe we have a better idea of what may be causing this. The diplay name of the majority of our users is in the format "lastname, firstname"; well if the display name
did not have a comma we did not receive the error.

This is certainly not an ideal solution, but it seems like progress.

Microsoft has now informed us that they have received other reports of this, so this is a known issue. They have told me that they are working on a fix, but do not know when that will be released.

So in case anyone wants to know for reference.

There is an issue when using a list in the gantt view if you use the People Picker and the AD user has a comma in their display name. This will display "The User does not exist or is not unique"

I was facing the very same, when trying to sync my MS Project with SharePoint. On first sync between MSP and SP all the names I had assigned in the Project plan were not transferred to the SP list.

I tried to enter the names manually in the SP list (Current View: "Project Task"), but always got the message "The User does not exist or is not unique. Permissions to the SP site are ok and I tried users from different domains, all the same result.
When switching to the view "All Tasks" and edit the list item manually, it works w/o any issue. Not sure why, but at least a workaround for the 1st issue, even though one more step to add a user.

Now I added a few names which were not in my MSP plan before and syncing back did not work. Reason here is the differences of Regional settings. On SP name fields do apear e.g. like this: "Klick, Heiko ; Simpson, Bart". In MSP "Heiko Klick, Bart Simpson".
So in SP the field delimiter is ";" and per default in MSP ",". Once changing this in my local regional settings, the names are getting synced back.

The way you setup resources in MSP is important. When picking names from the Outlook Adress book they occur as e.g. "Bart Simpson" and I can not sync between MSP and SP. When picking the names from Active Directory they get added as "Simpson, Bart"
and everything works well.

Ok so I also contacted Microsoft on this issue and it is only an issue with users that have commas in their display name. They indicated this is a known issue, and it will not be fixed. Their provided workarounds are to use the user's alias
instead, or use the New Form option in the ribbon where applicable.

I had this issue on one of my farms. The issue is that SIDs are not resolving because of the AD Trust.

From SharePoint the error is:

"The user does not exist or is not unique"

I interpret this as the User could not be resolved. The odd thing is that it does resolve in PeoplePicker but will not stick. To verify this behavior I added the user to a file share on the SharePoint server. The user resolved, but when
I click OK it would turn into a SIDs. That is what I believe is happening in SharePoint. To fix the issue I had to troubleshoot the trust.

We received this error in our list too. We had infopath forms on our list and thought something wrong with infopath, did all the troubleshooting, nothing worked.

Finally doubted that may be we have too many lookup columns in our list.

So, we deleted a few of the lookup columns and then "editing" list items worked like a charm :)

But really not sure if that's what resolved this issue. And if Microsoft is accepting this issue and say there is no solution yet, then it is really upsetting. This issue was going to cause a great operational crisis in my project.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.