Add domain to people picker in Foundations 2010 and 2013

Hello everyone,

Recently I ran across a scenario where I needed to add in a new domain full of new users to my SharePoint Foundations farm.

Originally in my test setup we were dealing with a one way domain trust between my original dev forest and the newly created forest, so I went to searching and found the following article:

http://jantjesworld.blogspot.com/2013/06/configuring-peoplepicker-in-sharepoint.html

So I went in and followed the steps in his article and everything seemed to work just fine. That is until we went to production with this same scenario and discovered that we weren’t using a one way trust, but a two way trust.

After many hours of research and even a support ticket with Microsoft, we finally found our answer. And so far from the research I have done, there are many people who have figured out the one way trust issue, but no one has specifically noted what to do in a two way trust. That’s what I’m here for. 🙂

In a one way trust your PowerShell should include accounts that have permissions in the domain or forest so they can cross properly. In my case though with a two way trust the login information is not needed. Also with a two way trust, I did not need to set an encryption key.

For the new two way trust, all I had to enter was:

Stsadm -o setproperty -pn peoplepicker-searchadforests -pv “forest:Contoso.com; domain:Fabrikam.com” -url http://myintranet

I’m not sure if it was necessary, but after running this I did reset my web servers just for good measure and then, viola! I am now able to see my existing domain users as well as the new domain users in my people picker settings in SharePoint Foundations.

I have also tested this on both 2010 and 2013 versions of the product and it worked like a charm. My last bit of advice in this scenario is to make sure that you work closely with your Active Directory admin on this and ask many detailed questions…

It will go far and save you many headaches and possibly even a support call with Microsoft.

Thanks,

BJ

Advertisements

Login issues with Host Named Site Collections

 

Greetings SharePointers!

Recently we created our first set of SharePoint 2013 sites using Host Named Site Collections. To get a quick refresher on this you should really read the following article by Kirk Evans (@kevans) to get a bit up to speed. You can find it here.

We had an interesting after effect for our users once we did this that I thought I would let everyone else know about.

Originally we had our SharePoint 2010 sites setup under path based site collections with the structure of http://webapp/sitecollection. This has been working out great for us so far, but many of our sites that we first created as sub sites in a site collection have grown to a size where we really needed to separate them out onto their own site collection and content database since they showed signs of only getting larger (like bigger than 50GB).

Since this is a bit trickier than simply doing a backup-spsite because since these were subsites, we had to use export-spweb to break them out of the site collection and then use import-spweb to move them into a new Host Named Site Collection (HNSC) named http://sitecollection.webapp.

Once we created our HNSC through PowerShell and finished the import-spweb to bring the sub site into the new site collection, we started getting calls from users about not being able to log into the new site. Once I logged into a user’s machine to see what the issue was I saw what was happening.

When the user went to the new HSNC 2013 site for the first time, they were being prompted to log in with a username like this:

“sitecollection.webapp\username”

Normally the users were used to seeing:

“Domain\username”

Once I corrected their login back to domain\username, then the prompt would go away and they could get into the site and they would not see the prompt any longer. Since this new naming was different from our standard domain I had to go into the user’s browser and make sure the new site was under their local intranet settings in their browser so the credentials could be passed properly.

Our long term fix for this was to roll out a group policy object to all the users of the site that added this new url to their local intranet section of their browser so their credentials would pass properly. Since implementing this GPO, we haven’t seen users having issues getting to the new site.

I hope this post helps anyone else who runs into this issue going forward.

Thanks,

BJ