Guest Author: Joan Resnick Ehrlich

In my last article I left off ready to configure Search services, as specified by Configure Kerberos authentication (SharePoint Server 2010) in the SharePoint Server 2010 Beta Library on TechNet.  The documentation’s example scenario calls for the Index and Query services to be on dedicated servers. I had only my one SharePoint server and so adjusted the instructions accordingly.

I was first supposed to start the “SharePoint Foundation 2010 Search service”. Services can be reached via Central Admin, System Settings, Manage services on server. I did not see a service with that exact moniker but rather, a “SharePoint Foundation Help Search” service and so started it. I had not paid attention to Foundation Search in the first SharePoint go-round but had focused solely on the Server Search service application. I had assumed that Server Search replaced Foundation Search which, like WSS 3.0 Search, is limited in scope to the site collection level. To be honest, because of the name mismatch I was not sure Foundation Help Search was the same service as Foundation 2010 Search. (A perfect example of either literal thinking or thinking too much into something) A search on the former did not turn up useful information and a search on the latter was not much more helpful. I assumed the services were one and the same and continued with the configuration. Afterwards, I did a bit of investigating which I will explain later.

When starting the Foundation Help service I was presented with the configuration screen shown below. I used spssearch as the Search service account and a separate, dedicated domain account, spscrawl, for the Content Access Account, which I had not planned for and had to create on the spot. The Content Access Account (aka crawl account) is granted Read access to all SharePoint content. I left the defaults for the SQL server and Search database name. I also left the default indexing schedule, which I can adjust later.

Next up: Starting the SharePoint Server 2010 Search service, which is listed as “SharePoint Server Search" directly below the SharePoint Foundation Help Search:

Rather than opening the “subsequent page” described by the TechNet documentation, clicking Start merely produced the message shown below about needing to create a Search Service Application. I was not surprised at the apparent discrepancy between the 2010 Beta documentation and the Beta software. Certain parts of the documentation appear to be forklifted with little or no editing from MOSS documentation. But both the 2010 software and documentation are still being finalized; let’s wait to see the RTM.

I decided to manually create the Search service application (as the message describes to do) rather than use the Farm Configuration Wizard. [In Part 7 of this series I said I used the Wizard to create all service applications. This was the one exception I forgot to mention.] I wanted to configure dedicated web application pools and because I had not had the “Stopped” proxy issue with Search in the last go-round I felt confident I would not in this go-round. I decided to first register spssearch as a Managed Account, although I could have done so from the Create New Search Service Application page. I saw that configuring Foundation Help Search had already registered spssearch:

I continued with creating the service application, as shown in the screenshot below. I created separate, dedicated web application pools for the Search Admin Web Service and Search Query and Site Settings Web Service. I later came across TechNet: Deployment Scenarios: Multiple Servers for a Three-Tier farm: Create and Configure a New Search Service Application, which says to use the same application pool for both services. Does it matter? When I run into an issue that leads back to using separate application pools I’ll have my answer.

I used spssearch as the account for the Search Service and both web application pools. The TechNet documentation scenario calls for a separate crawl account. In the scenario the account name used is mosscrawl and it is a different account than for Foundation Search, which is named wsscrawl.  But the documentation never specifies where to use mosscrawl. As I found out by viewing the default settings on the Search Administration page after creation, the Search Service Account is by default used as the crawl account and as such, added to the Full Read policy of the Intranet and My Site web applications when these were created.

Thus, both spssearch and spscrawl were added to the Full Read policy for both web applications. Jumping ahead, here is a screenshot for the Intranet web application User Policy settings:

I do not see why two separate crawl accounts – one for Foundation Help and one for Server Search – are needed. I can see why the crawl account should be different than the Search Service account because the latter is used for web services. Oh well, another item for the RTM question list.

The Search Service application was created successfully. The application, its proxy, and the Server Search service all showed “Started”. The following databases were created in SQL:

And one database that resulted from starting and configuring Foundation Help Search service was also created:

I did not further configure the Search Service application, preferring to first complete the steps in the TechNet documentation.

As mentioned earlier, I did a bit of investigating into the name discrepancy between Foundation 2010 Search and Foundation Help Search. A look at the Services MMC snap-in (services.msc) shows a “SharePoint Foundation Search V4” service directly above SharePoint Server Search 14: (For the unfamiliar, V4 and 14 indicate the 2010 versions.)

I thought I would conduct an experiment by attempting to stop the Foundation Help service in Central Admin and see if Foundation Search V4 showed stopped in the Services MMC snap-in. But I got this message and decided against it:

I attempted the opposite: stopping the Foundation Search V4 service in the Services MMC snap-in. When I refreshed the Manage services on server page in Central Admin the Foundation Help Search service still appeared as “Started”. You would think I was onto something, but I then attempted the same experiment with Server Search. Attempting to stop Server Search in Central Admin produced this ominous message:

So I again did the opposite – stopped the Server Search 14 service in the Services MMC snap-in – with the same result: that service in Central Admin also still appeared as “Started”.

I then took a closer look at the service descriptions in the Services MMC snap-in. The description for the Server Search 14 service does state that it replaces Foundation Search for searching user content:

But here is the Foundation Search V4 service description:

Obsessively detail oriented that I am I noticed the description for Foundation Search also includes “help content” whereas Server Search does not. Either two different people wrote the descriptions or Foundation Search provides the help content for all SharePoint 2010 editions and perhaps that is how the service name in Central Admin came to be. I did find this TechNet document SharePoint Foundation 2010 Search is not running (SharePoint 2010 Products) in the Technical Reference, System Center Operations Manager knowledge articles section of the SharePoint Server 2010 Library as well as the SharePoint Foundation 2010 Library. The document’s location in both libraries seems to indicate the Foundation Search service is important in all SharePoint 2010 editions.

Both services use the mssearch.exe executable. Server Search 14 uses the one in the Program Files\Microsoft Office Servers\14.0\ Bin folder. Foundation Search V4 uses the one in the Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Bin folder.

Researching online brought me to an answer in a forum post, by MVP Mike Walsh (WSS FAQ sites:  WSS v3 FAQ and WSS v4 FAQ – great stuff) who explained the purpose of the WSS Search database in a MOSS system: http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/831bce3d-2fd0-484c-b827-a4c3b40980e1. The WSS Search database indexes Help content and MOSS Search indexes all other data. I also came across the K2Distillery article I cited in Part 7, which I reread and found the same applies for 2010. Information overload, when a human only has so many brain cells, leads to information being dropped from memory. But I have my answer and I have useful information I may otherwise not have known that might come in handy when troubleshooting.

Next up: Creating the Intranet and My Site web applications and site collections and testing Kerberos authentication connections.

Guest Author: Joan Resnick Ehrlich

Joan Resnick Ehrlich has been in the IT industry for 15 years and is Corporate IT Administrator for a mid-sized company on Long Island, NY. Prior to entering the industry Joan was a business researcher, and she enjoys combining her research skills with IT work. In addition to SharePoint, her primary responsibilities include Windows Server, Active Directory, Exchange Server, and SQL Server.