Tweedle Dee & Tweedle Dum - SharePoint 2010

As the XRM story unfolds, Microsoft Dynamics CRM and Microsoft SharePoint will hopefully continue to grow closer together and indeed better together.  CRM 5.0 already includes SharePoint document library integration out the box.  This of course makes sense; easily 80% of the CRM deployments we work on include SharePoint as part of the solution... so it is natural for Microsoft to make this easier in the next wave.

However, like CRM, SharePoint has its little quirks.  One of them has to do with search results not showing up for users.  This can be very frustrating and hard to debug, but if you have a cross-domain SharePoint 2010 environment you might find that users from the domain where SharePoint is not installed can not find any records when they do a search.  Read on to learn more.

The issue had to do with my environment and the fact that my system was stand-alone in one domain, but my users were from another USERACCOUNT domain.  First some context.  This is what happens when you perform a search (simplified):

1. User logs into the site and enters their query
2. The query is passed to the search service for processing:
   http://[SERVERNAME]:[PORT]/[GUID]/SearchService.svc
3. The user is redirected to the “results” page
4. The results page calls the search service again to get the results
   
   fd52ef63-dfa8-4518-be93-d92a270a27b9: Query completed 0 ms, detailed time:  Query stage execution ms times: 0 0 0 0 0 0 0 0   Query stage cpu ms times: 0 0 0 0 0 0 0 0   Query stage hit counts: 1 1 1 7 1 0 1 1   Cursor count: 206  Mapped page count: 266  Total index count: 14    [srequest.cxx:5526]
   
   
5. The results are then filtered based on the requesting users permissions
6. If all goes well, the results are provided to the results page which transforms them and presents them to the user.

In my case, the problem was with Step #5.  The log showed I was getting this error:

AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user's Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user.

The root cause of the problem is that the Service Account that is being used by the Search Service AppPool did not have access to user requesting the search’s domain.  In this example, the AppPool was NETWORK SERVICE on the Customer1 machine; but the user was coming from USERACCOUNT domain.  In my search for the fix, the following blog posts were “helpful” but not entirely complete.

• http://mattstratton.com/tech-tips/configuring-sharepoint-2010-search-in-a-one-way-trust-scenario
• http://blogs.technet.com/b/wbaer/archive/2010/04/11/managed-accounts.aspx

To get around this issue, I had to do the following:

1. Add a new “Managed Account” from the USERACCOUNT domain
2. Configure the SharePoint Service AppPool account to use this account

You have to do this via PowerShell, because the “Register New Managed Account” won’t work for similar reasons as above.  The procedure is as follows:

1. Load the SharePoint 2010 PowerShell environment
2. Run:  new-spmanagedaccount -Credential USERACCOUNTDOMAIN\USERNAME
3. Load SharePoint Central Administrator
4. Go to:  Security | Configure Service Accounts
5. Select: Service Application Pool – SharePoint Web Services Default
6. Set the account to the one you just created in Step #2
   
   
   Note: This account must have appropriate elevated privileges within SharePoint and the server to run the service account under.
   
   
   
   
7. Click OK
   

Before you embark on this fix, you should make sure that everything is configured correctly and working.  You should also consider enabling Diagnostic Logging and find the error message I noted above to make sure that this is indeed why you are not getting results.

Some general tips for searches not getting results:

• Verify that the index is both crawling and indexing the expected items.
• This is done via Central Administrator, under General Application Settings | Search |  Farm Search Administration | Search Service Application
• From here you can use the Crawl Log to see if the items you want indexed are indexing.  You can also verify that your content is within the scope of Content Sources
• Verify that the Crawler Service has permission to read the items you want indexed
• Verify that the Site / Site Collection has the “Allow this site to appear in search results” enabled
• Verify that the List you want indexed has “Allow items to appear in search results” enabled.
• Verify that the SharePoint Server 14 Search Service is running

Cheers,

This posting is provided "AS IS" with no warranties, and confers no rights.