Tom commented on a post with the following problem, and I thought it merited a post.
“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”
It sounds like an interesting problem, but its difficult to answer without more information. Incidentally, the profiles comment, about being able to view user profiles, is rather a red herring. This is handled by an import process specified elsewhere in the SSP, and has nothing to do with the People Picker displaying users.
Lets discuss the stsadm command first. Without knowing the specific error message, I can’t say why the command is failing, but there are two probable outcomes. stsadm is not generally included in the default path for a windows installation, so if the error message is:
‘stsadm’ is not recognized as an internal or external command, operable program or batch file.
The problem is simply that you need to find the appropriate location first. The location is generally:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>
so simple change directory to that path, and run the STSADM again. It sounds obvious, but I must admit, I had a bit of a nightmare trying to find the stsadm path when I first started looking at SharePoint!
The other possibility is that the command has been run, but that the parameters haven’t been entered correctly. If so, you get the terribly helpful response of :
Command line error.
Followed by a complete syntax reference for the command, and it sounds much more likely that this is the cause of the problem, from the notes in the question. Unfortunately, this is quite a lot harder to discuss, as unsuprisingly people aren’t going to give the specific command line with all of their configuration details and passwords to be put onto a website, and the generic, censored versions are probably going to be correct, at least as far as it goes.
The best help I can give here is to put together a full hypothetical example, rather than just repeating the command syntax yet again.
Essentially, you first need to set an internal SharePoint encryption key, then tell the server what domains to add to the list, and what valid username and password to use to connect to the domain in order to pull back the list. Don’t use administrator, btw!!!
To set the initial encryption key, use:
stsadm.exe -o setapppassword -password <yourencryptionkey>
To set the actual domain link, use:
stsadm.exe -o setproperty -url http://domain1.example.com:80 -pn “peoplepicker-searchadforests” -pv “domain:domain1.example.com,domain1\LoginName, P@ssword; domain:domain2.example.com,domain2\LoginName, P@ssword; domain:domain3.example.com,domain3\LoginName, P@ssword“
Of course, with two way trusts a single user name and password could be used if you granted the appropriate rights.
What normally goes wrong putting this together? Normally it is either the encryption key hasn’t been set first, or that construction of the domain list has a syntax issue (or that the surrounding quotes have been missed off).
As a rule, though, if you get a command line error when running stsadm, you have got the format wrong. If the format is right, it won’t necessarily solve the problem (if your username or password is wrong, for example, it still can’t access the other domain information), but you’ll see the changes applied. A good way of checking is to run:
stsadm.exe -o getproperty -url http://domain1.example.com:80 -pn “peoplepicker-searchadforests”
And it will show the details you’ve set (with passwords asterisked out).
What makes the problem Tom is experiencing interesting is that apparently the People Picker has been working, and now isn’t. This, to me, implies that something has changed with the installation, or the Active Directory configuration.
Key things to check would be:
Has the system user context still got access rights to the domain that appears to be no longer accessible? A two way trust means that user rights can be assigned … by default they arent.
Have the active directory servers changed? If so, you may need to force DNS updates, otherwise resolution against the AD may be looking for defunct servers.
Has the stsadm command been run succesfully in the past, and the usernames and passwords have since changed (or expired)? This will obviouslly drop off the people pickers ability to query the domain.
Has a security patch been applied against the domain, or has permissions to the Active Directory been changed? By default, older systems allowed anyone to do a basic LDAP query against the Active Directory, but this was locked down. If this loophole was previously being used instead of setting correct access rights for the security context of the wep application, it’ll obviously start causing this issue.
I hope this helps – Tom, if you’ve solved the problem, please let me know the solution 
November 20th, 2009 at 9:31 pm
About the issues I posted, we found that some how the link between the sites and the ssp broke down, we have somewhat fixed the problem but we still have one webapp that will not find users that is in the ssp or the specific domain the other sites will find users and works just fine.
Ever seen this issue
Question 2
We also have a domain that we do not want any imports to come from yet we are pulliung them in and it is not specified in the profile import connections How can we keep the one from getting imported.
November 27th, 2009 at 4:00 pm
I’m not really able to answer your questions with the level of information available, I’m afraid. The PeoplePicker generally doesn’t look at the profiles imported in the SSP anyway. It sounds like an attempt to customise the people-picker on the webapp has been set up incorrectly, and thats blocking the response for any user. Just check the articles on customiseing the PeoplePicker results, and update it with a blank custom query to set it back to default behaviour. For question 2, do you mean the people picker is returning users from the other domain, or the ssp import is pulling in more users to the user directory than you want? Those are very different questions.
January 22nd, 2010 at 9:58 pm
We have not modified peoplepicker in anyway.
The tool only finds users in the site collections.
We have some users that can sign in and get access request page and then some that can actually sign in and see a page but still cannot be found in peoplepicker.
All trusts are correct.
Peoplepicker commands run
stsadm -o getproperty -url http://sitename -pn peoplepicker-onlysearchwithinsitecollection
stsadm -o setproperty -url http://sitename -pn “peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode” -pv no
We did get the AD commands to work yet we still cannot see users in peoplepicker unless they are already in the site.
This still only affects one domain and most can authenticate we just cannot add them to a site.
January 22nd, 2010 at 10:00 pm
Oh imports from the affected domain work perfectly still using the domain account given so its not a read right which is what peoplepicker should be doing.
February 8th, 2010 at 12:00 pm
Have you tried manually specifying the domain list in the people picker, with user names and passwords that have access to view the AD? You need to specify these via the command line otherwise it will use the account that the service is running under, and if that doesn’t have access, neither will the people picker.
The mix of users signing in is probably due to a group membership that has been set somewhere. If you specify authenticated users to have access to a site, they’ll log on. Incidentally, normally after logging on via a group, you’ll see them showing up in the People Picker index, whether or not the People Picker can see the AD details beforehand.
In the import via the SSP, you specify a domain account in the GUI – the people picker won’t use this. It runs in the context of the service or usernames and passwords specified via stsadm.
October 15th, 2010 at 1:10 am
Hi Rob,
First off great couple of articles on this. I found them really easy to follow. My question comes on the back of this article. We have a 2007 environment with multiple one-way trusts to about 4 other domains. All the setup has been done in the past and people picker was working great for all domains.
I was tasked with updating membership of a sharepoint group with a user in another domain, we’ll call it domain3 for now, that was added recently but I couldn’t find the user in the people picker. Other users from domain3 are able to resolve fine. We learned that the admin password for domain3 changed recently. I’m reasonably sure we were using that password for the peoplepicker connection. Is there a way to update just one out of the four domains user credentials using the stsadm command above or alternatively is there a way via the registry to update the username and password for that one domain? Any help would be great. Thanks in advance
October 19th, 2010 at 11:05 am
Hi Tim,
Tricky one! The People Picker is rather odd. It actually remembers users who have “hit” a site, in addition to doing a live lookup on the domain. For an established site, especially with low staff turnover, that means the link can fail, and not actually be a visible problem for some time.
I don’t believe there is an option to update just part of the property value, but there’s no reason not to rerun the command and update all of the links simultaneously, assuming you have valid passwords for each of the four domains … and if you don’t, then you shouldn’t have a live security link anyways!
The most important thing is making sure that the new property value is right, and a very good start is copying the original entry.
Running
stsadm.exe -o getproperty -url http://sharepoint.example.org/webapp -pn “peoplepicker-searchadforests”
will show you the current value of all the domain links (with passwords starred out, of course). Using this as the basis of the update command (with correct passwords), should keep all the existing links the same and fix the changed admin password for the problem domain.
Of course, it goes without saying that this is general advice on SharePoint, not specific guidance, without knowing specifics, and its always wise to test!
October 20th, 2010 at 12:16 am
Hi Rob
Thanks for your reply. After some testing I was able to get this resolved by re-entering and updating the domain credentials in question by using the stsadm.exe -o setproperty -url http://domain1.example.com:80 -pn “peoplepicker-searchadforests” -pv “domain:domain1.example.com,domain1\LoginName, P@ssword; domain:domain2.example.com,domain2\LoginName, P@ssword; domain:domain3.example.com,domain3\LoginName, P@ssword“
I had to modify the format of the command and place the url last but other then that it worked great. Its nice to have these little victories every now and again.
Keep up all the good work!
November 1st, 2010 at 6:14 pm
The instructions seem simple enough, I’ve seen a few variations on other sites but with all I’ve tried I must be missing a key ingredient.
I have one webserver (Server 2003) and 1 workstation (XP Pro running sqlexpress) in my MOSS 2007 development setup. To date it has been working with accounts from a single forest / domain, lets call it “first.domain.com” I added a second domain “second.com” on a 2008 server, added forwarders in each domain and created a 1-way external, non-transitive trust whereas second.com trusts first.domain.com.
Firewalls are currently off on the 2003 server and XP workstation.
From shared services, I setup the import connection to “second.com” and imported a few test profiles from “second.com”which display but cannot be accessed via. the peoplepicker.
In the second.com domain I created a user account (spaccess) and assigned the password (@spaccessPassword) This account is currently a domain admin in the “second.com” domain. Whether it needs to be or not is not clear to me.
I’ve run the 1st stsadm cmd on the front-end web server to set the encryption password (stsadm -o setapppassword -password MyPassword)
I’ve run several variations of the 2nd stsadm cmd on the front-end web server, resetting IIS after attempting each variation. The commands are received and the “Operation completed successfully” is returned.
The command that represents what I think is correct is: stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:first.domain.com;domain:second.com,second\spaccess,@spaccessPassword -url http://servername.first.domain.com
Note that http://servername is how internal users normally access this development site. http://servername.first.domain.com/………. is the URL I’ve been navigating to (after resetting IIS) to see if the command worked, allowing users from second.com to show in the peoplepicker. When I apply this to our production servers, I’ll be utilizing HTTPS.
if I run stsadm.exe -o getproperty -url http://servername.first.domain.com -pn “peoplepicker-searchadforests” it reports back
Any assistance would be greatly appreciated.
Dave
November 11th, 2010 at 4:14 pm
Hi Dave – it’s always difficult without knowing the exact commands and responses being used, but they have to be obfuscated for security on a public blog! Knowing what the getproperty reports back would be useful!
Your trust details seem a bit off. If second.com trusts first.com, then first.com users can be granted access to resources on second.com. If your sharepoint server is on first.com, then second.com users can’t access it.
You can import the details into shared services, as that doesn’t matter about trusts – just the user access rights on the account used to get the information.