This project has moved and is read-only. For the latest updates, please go here.

Quick Edit cant resolve User

Nov 27, 2014 at 11:41 AM
Hi There,

we have one problem: If a user fillout a username or email within the quick edit dialog, the user cannot be resolved by sharepoint.
Only if I type "i:05.t|adfs|email(at)" the user will be resolved.

In the "normal" NewForm.aspx everything works great.
If I start typing email or display name - it doesent matter - sharepoint will find the users.

in the claim mapping table there is only one mapping defined:


Atribute to display
What is wrong?

Thanks and greetings
Nov 27, 2014 at 12:33 PM
indeed I reproduce the same behavior, and SharePoint logs record this error:
11/27/2014 13:29:51.54 w3wp.exe (0x03B0) 0x146C SharePoint Foundation General 8kh7 High The user does not exist or is not unique.<nativehr>0x81020054</nativehr><nativestack></nativestack> 7736d09c-015b-e055-882e-6725d254657f
This is very likely because you also have Windows authentication enabled, and it also resolves the user, so SharePoint ends up with 2 users, doesn't know which one to choose, which causes the error in the quick edit form.
Dec 1, 2014 at 9:10 AM
Edited Dec 1, 2014 at 9:11 AM
Hi Yvand,

thank you for your answer.

in this zone (default zone) there is only ADFS enabled.
Dec 1, 2014 at 12:26 PM
Hello, ok, but just in order to test, can you make sure to have only ADFS enabled in all the zones and try again?
I'm pretty sure that this error occurs because user is also resolved by Windows internal claims provider.
Dec 4, 2014 at 1:14 AM
Hi Yvand,

I have also seen this but had not looked into it yet. The problem here is that turning off Windows Auth will cause the Search engine to stop crawling the content. I currently have both Auth types on the one "Default" zone for two reasons:

Search must always be setup with Windows Auto and be on the default zone
If you move users to a different zone then invitation emails etc. go out with the wrong URL's

I know this is an area Microsoft have been talking about changes but begin able to move the search provider to a different zone or make sure emails go out with the correct URL's would help allot of these issues that spring up.
Dec 30, 2014 at 5:30 PM
Just FYI,
We are able to verify that if you are using your default zone as your crawl zone with Windows Authentication it will error.

We are in the processes of opening a ticket with Microsoft and get a real solution.
Jan 2, 2015 at 7:23 PM
We have not been able to reproduce this in Quick Edit mode. All seems to be working just fine. Do you have the latest version of LDAPCP? SharePoint 2013? We are running on the September 2014 CU at the moment. Additionally, we ran the following script to hide the "AD" option.

$cpm = Get-SPClaimProviderManager
$ad = get-spclaimprovider -identity "AD"
$ad.IsVisible = $false
Jan 18, 2015 at 9:05 PM
Hi chlorinecoach,

Can you confirm how you have your zones setup and auth types? also is search functioning as well and outgoing emails for alerts etc? if it was not for these then this would be an easy fix but if you have found a way I know of allot of installs that would be great full.
Jan 23, 2015 at 9:09 AM
Hi there:

default Zone -> LDAPCP -> ADFS
intranet zone -> NTLM -> For Crawler

the powershellscript:

$cpm = Get-SPClaimProviderManager
$ad = get-spclaimprovider -identity "AD"
$ad.IsVisible = $false

doesent work..

I cant test a ADFS only zone, because this is on production and I have no idea, what the result can be, if I disable the intranet zone :/ (never touch a running system)
Jan 26, 2015 at 10:06 PM
Hi dmarx,

this is how I had our system until I realised that search results were returning the wrong URL. If you do a search for some content then look at the URL of the links returned (actual URL not the displayed URL) you should find that they are the intranet ones not the default zone ones unless you have found a way around it that I couldn't find.

e.g. when I have mine setup I had:

Default -> <- for users via ADFS & LDAPCP
intranet -> <- for search crawler via NTML

I then had a URL rewrite rule setup in the search settings to change the search URL to the user URL.

When performing a search everything looked ok but if I hovered over a link in the search results I noticed that the actual URL in the status bar was pointing to the search zone with NTLM thus users couldn't click on results as the site was not shared with their NTLM account only their ADFS account. This also caused internet people to not get results as the search URL only exists internally.

Do you get this?
Jan 27, 2015 at 9:20 AM
Hi Terafirma,

try to search not for a document... can you confirm, that a "non office (word, excel, powerpoint)" result show the right url - like a page or a list or something else?
Jan 27, 2015 at 9:15 PM
Hi dmarx,

from memory it was both but as we have now moved to a single zone with both auth types enabled I can no longer test. This works for me but I am yet to confirm the quick edit mode on a column type of person in a list.

It's down the list of bugs to check and fix. I was however intrigued to see if you had found a way around the multi-zone issue.
Feb 2, 2015 at 2:30 PM
Hi Terafirma,

Sorry for the late response. We are crawling and using SAML all on our default zone, as search won't crawl outside of the default zone. We are using Windows auth with NTLM for search.

We don't have any issues. Quick edit mode works as expected on person/group columns.
Feb 4, 2015 at 12:16 AM
Hi Chlorinecoach,

Do you also have ADFS setup on the default zone or do your users browse from a different zone than default where NTLM is configured?
Feb 12, 2015 at 2:17 PM
We are not using ADFS, we are using PingFederate. However, it's the same difference. We have both SAML and Search on our default zone. Users browse on the default zone where both are configured.