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.

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

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!

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!

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

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.

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.

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.