After installing SharePoint, and importing all the User Profiles, you’ll find if you are using the People Picker, you’ll only see users from the trusted domain that have successfully logged on the SharePoint 2007 server, rather than all of them. This is rather bizarre, as you’ve imported all the profiles, and can see them!
You actually need to configure the PeoplePicker to do a lookup to the Domain Controllers, as its here the People looks, NOT the SharePoint user profile store. It seems unusual, but true! It’s quite a complex task.
Before you do anything else, work out a list of all of the domains the PeoplePicker needs to look at, INCLUDING the domain SharePoint is installed on. If SharePoint is on Domain1 and you want to see all the Domain1 users and all the users from the trusted domain Domain2, you’re going to need to list them both, something most of the guides online don’t make clear. You’ll also need the fully qualified domain names – doing use the older NetBIOS name. If your domain is exampledomain.local, don’t just use “exampledomain” – we’ll need the full thing.
Next, make sure you have a valid Active Directory user account on each of the domains you want to look at. You don’t need to worry about the domain the SharePoint server is on – the accounts SharePoint should be running under will already have access.
Now, we first need to set up an encryption key, so SharePoint can securely store the usernames and passwords for the other domains. Use the following command on every server in the farm – if you don’t, the other SharePoint servers won’t be able to decrypt the stored user names and passwords:
stsadm –o setapppassword –password MyPassword
Replace MyPassword with your chosen encryption key, of course!
Next, we need to tell each Web Front End server, which domains to use. I always list the current domain SharePoint is a member of first, for ease of reference. Normally, I’d expect at least two entries – the current domain and the trusted domain (or domains) – if there isn’t a trusted domain, why are you doing this???. We’ll need to separate the entries in the domain list with semi-colons.
stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:domain1.com;domain:domain2.com,domain2\user,password –url https://sharepoint.domain1.com
Here, the url should be replaced by that of your web application – don’t forget to use https if you’ve set the application up to use SSL. Domain names should obviously be replaced with your own, and you should use the usernames and passwords from each domain that you either created or ensured were available earlier. A more realistic looking example might be:
stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:technet.microsoft.com;domain:kb.microsoft.com,kb\AD_Lookup,LookUp2009 –url https://sharepoint.technet.microsoft.com
Please note this is an entirely hypothetical example, so don’t think of trying the links or usernames!
Fianlly, though this generally isn’t mentioned in most of the other guides, you need to reset IIS before SharePoint will pick up the changes. As always, I prefer the noforce option, just in case.
issreset -noforce
You should now see all of the available people from the domains you’ve selected in the people picker!
May 22nd, 2009 at 6:16 am
Hi ,
When i login with external user in to the sharepoint site i am not able to see all AD users but when log in with AD user then i am able to see all the users from the domain in people picker.
we are using ECTS to add External user.
Please help me solve this issue its very critical.
Thanks in advance
July 23rd, 2009 at 3:56 am
Hi,
This is exactly what I am looking for. I am currently setting up an extranet at my work. Qustion. How do you incorporate filter strings to the above example? For example, I want to return only accounts that are active.
Thanks
October 23rd, 2009 at 8:34 pm
Few details first
We have a MOSS 2007 FARM AND 3 DOMAINS all have a two way trust.
We have over 78 sites all of which stopped with no known reason from being able to find users that are in one of the domains we can find the users in the view profiles yet we can no longer find users using peoplepicker for any users from the one domain.
We have tried this command you have provided and they come back with commandline error
stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:full domain name,-userlogin domain\username password –url http://webapp url
Any help would be great we have been stumped for over a week,
October 26th, 2009 at 1:40 pm
Hi Tom – hopefully the new post on More People Picker Issues will be helpful – http://kipper.org.uk/index.php/2009/10/more-people-picker-issues/
January 22nd, 2010 at 9:48 pm
We have the exact problem accept we have a two way trust and peoplepicker is only finding users inside their own sites.
We have verified that the property is not set it states “NO”
We have run almost in not all STSADM commands available no affect.
Reuilt the SSP’s and all WFE’S No affect.
Some users can sign in but have no access just get read only and some get request access page.
If they get request access page I can then add them.
Very weird scenario and have no clues this issue has been happening now for like 2 months and no body seems to have a clue not even Microsoft
January 22nd, 2010 at 9:50 pm
Also we have multple domains as well, all are two way and verified no issues.
only one domain has this issue default and another have no issues I can find those accounts.
October 15th, 2010 at 3:00 pm
Hi there,
We have just setup a multi-tenancy SP 2010 environment, where the User domain is separate from the Resource (Server) domain.
I have setup a hostname based site collection for a test company and everything seems to be working correctly, including the User Profile Application correctly retrieving their profiles from the User domain (when you specify the OU of the company with the Set-SPSiteSubscriptionConfig cmdlet + in conjunction have a Sync Connection setup to retrieve the accounts from the other domain)
But the People picker just isn’t playing ball.
I am running the command:
stsadm -o setproperty -url “http://app01″ -pn “peoplepicker-searchadforests” -pv “domain:domainname.co.uk,DOMAIN\ADUserAccess,xxxxx”
as I thought maybe this was required in addition. But then the result of the Get command to check is that the property doesn’t exist:
stsadm.exe -o getproperty -url http://app01 -pn “peoplepicker-searchadforests”
Any ideas!?
Thanks
Gavin
October 19th, 2010 at 10:55 am
I’m more experienced with 2007, rather than 2010, but my understanding is that the same steps are needed to overcome domain trust issues.
You didn’t mentioning running the step:
stsadm –o setapppassword –password MyPassword
If you didn’t first set the encryption key, you can’t store the domain password to access the other domains. This could cause the failure to store the value highlighted by the use of the getproperty command.
You also don’t mention the nature of the trusts, so it’s difficult to give much advice. 2010 is much more strict than 2007 out of the box – only the local domain will be searched now, unlike 2007. Of course, there is another potential issue with trust relationships over domains – the ports need to be opened. Depending on the nature of the “resource” domain, they may well be safeguarded over the network. Off the top of my head, you need at least 88, 139 and 445 open. You also need to make sure that DNS is set correctly – if domain resolution on your local domain doesn’t point you to the correct remote domain servers, the resolution won’t work.
Other possibilities include slightly incorrect syntax in your instruction. First, you need to make sure you are specifiying the specific top level web application, not the server. If your web application path is http://exampledomain.org/sites/ then specifying
stsadm -o setproperty -url http://exampledomain.org -pn “peoplepicker-searchadforests” -pv “domain:domainname.co.uk,DOMAIN\ADUserAccess,xxxxx”
won’t work – it has to be the full web application URL.
Next, specifying the domain is rather a pain too. you need to specify all the domains involved, which will include the local domain, not just the remote user domain. You need to make sure you specify the AD domain name, which isn’t necessarily the same as the email address or usernames, depending on the config – many use abstract *.local domain names. putting it together from these examples, you’d need something like:
stsadm –o setapppassword –password MyPassword
followed by:
stsadm -o setproperty -url http://exampledomain.org/sites/ -pn “peoplepicker-searchadforests” -pv “domain:resourcedomain.local;domain:userdomain.local,USERDOMAIN\ADUserAccess,xxxxx”
October 21st, 2010 at 11:17 am
Rob, thanks so much for all that info. It really helped me clarify my thoughts. I had done the apppassword and all the rest pretty much.
Checked the DNS settings and all, but at the same time the User Profile Sync Connection to the same domain was working with that account and returning user accounts.
Eventually, though I would create a standard web application on another port to see if I still had issues. Went as Farm Admin to the web applications, and the ‘New’ was greyed out. Strange… Logged in as Domain Admin and had the permissions to create the Web App.
So then tried to run the script as Domain Admin rather than Farm Admin, and hey presto the property got created (validated with Get-Property), on both the new web app, and the existing one.
Now the new web app is correctly searching the User Domain, as is the root site collection of the existing web app. However the tenant site collection created under that is giving another error now:
Claims Search call failed. Error Message: Object reference not set to an instance of an object. Callstack: at Microsoft.SharePoint.WebControls.PeopleQueryControl.IssueClaimsQuery(String searchPattern, String providerID, String hierarchyNodeID, Int32 pageSize, SPProviderHierarchyTree spgroupTree).
I’m going to try delete the site collection for the tenant and recreate it all as Domain Admin and see if it works then!
Cheers
Gavin
November 11th, 2010 at 4:16 pm
Did recreating the site collection work, Gavin? Glad I was of some help