Configuring SharePoint 2010 Search in a one-way trust scenario

Let me just start out by saying that I think that SharePoint 2010 is pretty darn awesome. The user experience is three billion times better than previous versions, and the list of amazing features is miles long.

That being said, I’m starting to think that Microsoft didn’t really do a lot of testing of this product in a multi-domain, one-way trust scenario. Let us assume the scenario below:

In this scenario, the domain SERVER trust ACCOUNT, but not vice-versa

My SharePoint 2010 farm is in Server, but all user accounts are in ACCOUNT. This is a one-way trust, and a fairly common corporate scenario.

The Search Symptom

After configuring SharePoint Search and successfully crawling some content sources, I was never able to return any search results. People results would show up, but no content from the SharePoint sites. Additionally, when I looked at my Scopes in Central Admin, they showed no items…but the crawl log showed all the results.

For Admin Eyes Only!

After spending hours trying to debug this (going so far as to even completely delete the Search Service application and recreate it), I came across this post on MSDN:

At first, I thought this didn’t apply to me, as I was connecting at ACCOUNT\USER, who was a farm admin as well as a site collection admin. But then I came across another post:

I wasn’t seeing that exact error, but it made a bit of a lightbulb go off for me. On a whim I tried logging in as SERVER\ADMIN…and voila! Search results appeared!

So now what?

This was all well and good, but it didn’t solve my problem. I needed ACCOUNT users to get search results too. The issue seemed to be that the app pool for the Search query component was running as a service account in the SERVER domain…and that account didn’t have any rights in ACCOUNT to determine the security trimming for the user doing the search. Long story short, I needed that app pool to run as an ACCOUNT account.

That being said, when I went to register the ACCOUNT account as a managed account, it wouldn’t take it. Because, you know, the farm account (I suppose) didn’t have rights in ACCOUNT to pull up any properties about this user:

PowerShell to the rescue!

The GUI wasn’t going to let me add this managed account…but would PowerShell save the day? Turns out that yes, yes it would. Following the insight from Bill Baer’s blog post, I was able to add an ACCOUNT service account using PowerShell…which I could then select as the app pool identity for the Search query component. And after doing so…voila! Search results worked like a charm.

Where do we go from here?

This is just one of the several issues I’ve encountered in our one-way trust scenario with SharePoint 2010. The maddening thing is that all of these issues worked FINE in MOSS 2007…but it seems that with all of the infrastructure changes that happened with 2010…a lot of this stuff got lost along the way.