Working with Premier Support today (on a seemingly unrelated issue) I stumbled upon some very interesting functionality which seems to have alleviated some pretty serious SharePoint People Picker problems. Imagine yourself in a scenario with a lot of user domains and WINS not working 100% like it should. When WINS fails, SharePoint tries to do a NetBios broadcast which doesn’t make it outside the subnet. So what you’ll find is SharePoint’s People Picker craps out, and not in a good way.

For awhile there we tried the searchadforests command which in a lot of ways didn’t make sense because we already had 2-way trusts with all the domains we were trying to communicate with. We limped along with people picker taking 60-90 seconds to resolve users. It was faster at resolving Domain\User therefore that was the guidance we provided to most site collection admins.

Previous attempts at gaining help from Microsoft resulted in a recommendation to perform domain consolidation, which in a large organization isn’t helpful.

Ironically enough, the SharePoint August 2012 CU includes some new functionality outlined below. As  a point of reference, our people picker is now humming between 5-15 seconds. I really wish I knew about this fix back in October when we rolled the August 2012 CU out to our environment.

======== Outline of issue documented in August 2012 CU ==========

The issue is caused when you click ok, People Picker makes a NetBIOS call to try to resolve the domain name.  Since the customer does not have WINS set up, a NetBIOS broadcast is done.  This fails to find the trusted domains because broadcasts are not allowed outside of the subnet.

This issue has been resolved and is included in any Cumulative Update after the August 2012 CU

http://support.microsoft.com/kb/2687339/EN-US

After you install the CU, you must run some PowerShell to enable the fix:

In order to use people picker without NETBIOS or WINS enabled you have to specify the domains you want to resolve users from using PowerShell explicitly on every web application.

After you installed the hotfix there is a new property which contains the NetBIOS name of a domain which you need to specify for the people picker settings for each web application.

This means that you have to list each of your trusted domains in the people picker settings, you cannot just specify a forest and have SharePoint resolve all domains from it.

Using PowerShell you can set the domain properties based on this sample.  The places where you need to enter your own values are in bold.

Add-PSSnapin Microsoft.SharePoint.PowerShell

# enable the global setting in the farm.  You only need to do this part once.
$farm = get-spfarm
$farm.Properties
$farm.Properties[“disable-netbios-dc-resolve”] = $true
$farm.Properties
$farm.Update()
# Handle one webapplication
$wa = Get-SPWebApplication http://yourwebapplicationurl
# Display current settings
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains
# Save current settings to text file
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains | out-file pp_settings_before.txt
# Clear the list
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Clear()

# You need to repeat the following block for all the domains you want People Picker to work for on this particular web app
# ——————————————————————————————————————————
$newdomain = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain
$newdomain.DomainName =‘oneDomain.corp.contoso.com’;  # specify the fqdn
$newdomain.ShortDomainName =’oneDomain‘; # specify the netbios name

# =====================================
# This section is only required if there is a one-way trust to the domain and the application pool account does not have access

# First you have to run setapppassword on every server in the farm.
# This sets the encryption key used with the password you enter for the account you specify for $newdomain.loginname
stsadm -o setapppassword -password <password>
# Where <password> is any string you want to use as an encryption key.
# This needs to be run on every server using the same value for <password>

$newdomain.loginname = ‘oneDomain\userName’ # Specify an account that has access to the remote domain
# Do not change anything in the next two lines, it will prompt you to enter the password.
[System.Security.SecureString]$secureStringValue = Read-Host “Enter the account password: ” -AsSecureString
$newdomain.setpassword($secureStringValue)
# =====================================

$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain)
# Repeat end
# ——————————————————————————————————————————-

# Finally save settings for the web app
$wa.update()

You have to do this for each web application individually to enable the fix.

Workaround

If you can’t install the August 2012 CU right away, this workaround can be applied.  It essentially caches domain resolution info for the NetBIOS domain name in the Netlogon service and makes Nltest /dsgetdc:<DomainShortName> work.  If you get that to work, People Picker should also work.

1.  Create a batch file that contains the following commands for each external domain:
Nltest /dsgetdc:ExternalDomainName.FQDN
Nltest /dsgetdc:ExternalDomainName

Example:
Nltest /dsgetdc:Global
Nltest /dsgetdc:Global.Contoso.com
…and so on for each domain…

2. Run this batch file as a scheduled task every 15 minutes on each WFE.  This should keep the Netlogon cache populated, and should prevent the error from occurring.