Bugra Postaci's Blog

PeoplePicker – Double Users and Diacritic issue

Well, it is an another well know issue by Microsoft.
Here you can find some definitions:

* Experiencing inconsistencies with some user profiles where the user Account name attribute is observed to vary between e.g. Domain\aloş and Domain\alos . This is observed in SharePoint Central Administration > User Profile Service Application > Manage User Profiles and Edit User Profile sections and therefore impacting approval workflows where they are using InfoPath Forms .

*Connecting local domain to Sharepoint server, in domain are login with diacritics, in sharepoint there are login of users with diacritics – wrongly displayed .Also when search for the user in people picker we get two users account one with account name with diacritics and second without it.
In UPA profile contains correct account name (without diacritics)

Issue Reproduce:
Add a user in Active Directory. In example we are adding TESTMOSS2010T\Berkc user.

For first time login the SharePoint as a Site collection administrator (which should be different that our test account)
And try to grant permission the user but use diacritic as berkç (use ‘ç’ instead of ‘c’)

When you check and verify the user, move and keep Mouse over the validated user text , that will Show us the account
As you can see it is “TESTMOSS2010T\berkç” . Well so far so good . SharePoint accept it without any problem when you click the OK.

If you search from user it will Show you just one with “berkç”

If we try without diacritics like “berkc” it is also accepted .

But wait a minute , If you keep Mouse over the validated user text , that still show us the account as
“TESTMOSS2010T\berkç” .

Hmm , thats looks strange . (Well actually SharePoint has already saved the data in UserInfo table & UserInformation List as ‘berkç’) and SharePoint is clever enough to understand this is same user.
(because they have same SID) PS: If the SIDs are different well it is tottally different problem and out of scope for this article 🙂

You can see in UserInfo table

And User Information List

Well , I dont want to use it like this. This user should be “TESTMOSS2010T\berkc” so how can i change it .
Move-SPUser will helps here.

$user = get-spuser -Identity “TESTMOSS2010T\berkç” – web <web Url>
Move-SPUser -identity $user -NewAlias “TESTMOSS2010T\berkc” -IgnoreSID
(In some scenarios it doesn’t work , so in that condition you may need to delete user from SharePoint and add again )
After i changed that user account , hmm i can see now 2 account if i search from people-picker .

Why ? The reason is LSA cache . Because very first time we make a query to AD as “berkç” and AD accepted it (Well the configuration of AD user resolution for diacritics is a different issue so i don’t mention here) and Server LSA cache has stored as “berkç” . So PeoplePicker has uses both SharePoint DBs and AD Resources to Show results . In that condition SharePoint DB (User Information List) returns “berkc” and AD query bypassed by LSA – Show us “berkç”

The LSA maintains a SID cache on domain member computers. This cache stores mappings between SIDs and user names. If the SID information exists in the local cache, the LSA returns the cached user name information instead of checking whether the user name has changed.
The local SID cache helps reduce domain controller workload and network traffic. However, inconsistency may occur between the local cache and the domain controllers.

If you want to get rid-off this behavour ; disable LSA cache: http://support.microsoft.com/kb/946358.

To work around this issue, disable the local SID cache on the domain member computer. To do this, follow these steps:

1. Open Registry Editor.To do this in Windows XP or in Windows Server 2003, click Start, click Run, type regedit, and then click OK.

   To do this in Windows Vista and newer, Click Start, type regedit in the Start Search box, and then press ENTER.

2. Locate and then right-click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Point to New, and then click DWORD Value.
4. Type LsaLookupCacheMaxSize, and then press ENTER.
5. Right-click LsaLookupCacheMaxSize, and then click Modify.
6. In the Value data box, type 0, and then click OK.
7. Exit Registry Editor.

Note The LsaLookupCacheMaxSize registry entry sets the maximum number of cached mappings that can be saved in the local SID cache. The default maximum number is 128. When the LsaLookupCacheMaxSize registry entry is set to 0, the local SID cache is disabled.

Unfortunately there is no other resolution for this design.