Configuring Enterprise Search in SharePoint 2010

We all have to agree that search plays an integral part of any successful SharePoint deployment and is an area that Microsoft continues to invest in with each new release of SharePoint. Microsoft went as far as acquiring FAST 2 years ago which it now offers as a separate add-on to SharePoint for those willing to invest in high end enterprise search.  In addition to FAST, SharePoint 2010 search comes in a number of flavors each offering their own feature set and capabilities which I have duplicated at the end of this article as an Appendix for convenience.
Today we will introduce SharePoint Server 2010 Search and eventually work our way up to Microsoft’s latest and greatest FAST Search Server in a near future article.  Before we deep dive into the step by step guide I will begin by listing some of the new features that you will come to expect from SharePoint Server 2010 Search.   These are as follows;

• Boolean query syntax has finally been introduced.  These include AND, OR and NOT operators in your search queries.
• Suggestions whilst typing and after running search queries, a feature that we have come to love with major search engines such as Google and Bing.
• Integrating SharePoint enterprise search with Windows 7, allowing end users to utilise the Windows 7 search box to locate SharePoint 2010 content.
• Results display has been refined to provide filters for search results such as document type, categories and managed properties.
• View in Browser capabilities, allows end users to view documents within their own browser utilising Office Web Apps and not having to rely on launching the necessary Microsoft Office Application, or even the need of having it installed on their local machine.  This is handy when browsing your SharePoint site via Kiosks and Internet Cafes that may not be running the Microsoft Office Suite.
• Last but not least, there have been a number of improvements to People Search, including phonetic name and nickname matching, and improved relevance and self search.

Now that we have a taste for what’s to come, let’s begin our configuration.
SharePoint Server Search is a service application which we have come to learn about over the past few articles that it is independent of other services and is no longer tied to the Shared Services Provider (SSP) that was introduced in SharePoint 2007.
SharePoint 2010 search architecture is made up of the Crawler, Indexing Engine, Query Engine and the User Interface and Query Object Model.  We now have greater flexibility and expandability with our search design in 2010 and can setup not only multiple Query Servers but can now scale out our Index server and add multiple instances.
Below is a logical overview of the components that will make up our SharePoint 2010 search configuration.

Configuring the Service Application
As always we begin our journey in Central Administration / Application Management / Manage Service Applications.
Click New / Search Service Application.
Name: Enter a name for your Service Application.
FAST Service Application: Select “None” (we will leave the configuration of FAST for a future article)
Search Service Account: Click on Register new managed account and ensure your domain account has already been provisioned in Active Directory.  I have created a separate search account; e.g. DOMAIN\sp_search

Application Pool for Search Admin Web Service: Create a new application pool for your search admin web service application.

Application Pool for Search Query and Site Settings Web Service: Create a new application pool for your search query web service application.

Click Create
The search service application will begin its configuration process.

You will eventually be presented with confirmation that the search service application was created successfully.
If we now navigate back to Application Management / Manage Service Applications, you will notice that 2 additional services have been added to our list.  These are;

1. Search Service Application (Typical Search Administration page which is similar to that in SharePoint 2007. From here we can create content crawl rules, reset indexes, setup content sources etc).
2. WSS_UsageApplication (This is a new service in SharePoint 2010 that specifically handles our Usage and Health Data Collection Service Application.  This service application handles web analytics such as usage, search query usage, rating usage etc  More on this in a future article).

Let’s now launch the Search Administration page by clicking on our Search Service Application.

Our Default content access account should be set to the account that we had specified at the time of provisioning the Search Service Application; i.e. DOMAIN\sp_search
Confirming Permissions
There are a couple of areas to note that we should check to ensure that our Default content access acount (sp_search) has been provided with the appropriate access permissions.  Let’s first begin by checking our User Profile Service Application by Navigating to Service Applications / User Profiles.  Just highlight the User Profiles and select Administrators from the ribbon.

Our newly provisioned sp_search account should have “Retrieve People Data for Search Crawlers” selected as a permission.

We will also confirm that our sp_search account has the necessary “Read” permissions against the Web Applications being crawled.
Navigate to Central Administration / Application Management / Manage Web Applications.  Again, highlight the Web Application in question and from the ribbon select User Policy.

Ensure that the Search Crawling Account is set to the sp_search domain account.

Content Sources
Let’s venture into our content sources listed in the Quick Launch navigation bar under Crawling.
As was the case with SharePoint 2007, our Local SharePoint sites will be detected by default, albeit without a crawl schedule.

Check to see that your Start Addresses are located within your content source via editing the content source from the drop down menu.  These includes all SharePoint Web Applications and the sps3 “User Profiles” address.

You can easily create your crawl schedule by clicking on Local SharePoint sites and scrolling down to Crawl Schedules.

Let’s initiate a Full Crawl by clicking on Start all Crawls from the Manage Content Sources page.
Once your crawl has completed, you should confirm that there were no errors encountered during the initial crawl.  Usually any errors noted are most likely due to incorrect permission assignments.
Creating a “Basic Search Center” Site
If you haven’t done so already, from your top level site, click on Site Actions / New Site.
Select “Basic Search Center”

Enter a Name and URL and click on Create.
This will provision the Search Center similar to the below.

Creating an “Enterprise Search Center” Site
Let’s also create an Enterprise Search Center for comparison.  The key difference here is that we are provided with two tabs for searching, one for Sites and the other for People.  The “Enterprise Search Center” will be the search site of choice for most organizations running SharePoint Server.
From Central Administration / Application Management / Site Collections, click on Create site collections.   Ensure you are creating the Site Collection below the relevant Web Application.
Enter your Title, Description etc and select the Enterprise Tab under Template selection.  Select the Enterprise Search Center, specify your site collection administrators and click OK.

This will provision the Enterprise Search Center similar to the below.

As we have already completed an initial Full crawl earlier, I can now test my new search centers by performing a couple of searches.
Searching Content

Searching People

Now I ran into an issue when trying to search for content located in My Sites.  The crawl log displayed the following warning;
“This item and all items under it will not be crawled because the owner has set the NoCrawl flag to prevent it from being searchable”
In order to fix this issue (and this is true for any Site Collection), is to navigate to your My Site host and click on Site Actions / Site Settings.
Click on “Search and offline availability” under Site Administration, and ensure that you have Indexing Site Content, Allow this site to appear in search results? set to “Yes”.

After enabling the indexing of My Sites, I was able to successfully perform My Site Content searches and the warning disappeared from the Crawl Log.
That’s all that is to it in setting up a search center in its most basic form.  From here you can expand your service applications over multiple servers providing you with redundancy, scalability and increased performance .  Until next time, happy searching 
References:
TechNet :: Getting Started with Enterprise Search in SharePoint 2010 Products

Appendix
SharePoint Versions Search Comparison

Feature	SharePoint Foundation 2010	Search Server 2010 Express	Search Server 2010	SharePoint Server 2010	FAST Search Server 2010 for SharePoint
Basic site search	Y	Y	Y	Y	Y
Best Bets		Y	Y	Y	Y
Visual Best Bets					Y
Similar Results					Y
Duplicate Results					Y
Search Scopes		Y	Y	Y	Y
Search Enhancement based on user context					Y
Crawled and Managed Properties		Y	Y	Y	Y*
Query Federation		Y	Y	Y	Y
Query Suggestions		Y	Y	Y	Y
Sort Results on Managed Properties or Rank Profiles					Y
Relevancy Tuning by Document or Site Promotions		Y	Y	Y	Y*
Shallow Results Refinement		Y	Y	Y	Y
Deep Results Refinement					Y
Document Preview					Y
Windows 7 Federation		Y	Y	Y	Y
People Search				Y	Y
Social Search				Y	Y
Taxonomy Integration				Y	Y
Multi-Tenant Hosting				Y	Y
Rich Web Indexing Support					Y

Share|

How To: Create, Configure, Consume SharePoint 2010 Secure Store in Business Connectivity Services

 I have seen quite a bit of confusion out there regarding how to use Secure Store Service for SharePoint 2010. While MSDN does have interesting articles, there has been no Alpha to Omega process that shows the relationship to the LOB System, Security Groups representive of the BCS Consumers, BCS Access Account representive of the Credential Owner [Impersonated User], and how to wire it up in SharePoint Designer 2010. This blog hopefully will dispel all fears about Secure Store and answer a MSDN Forum question while at it.
The Blog is broken up into sections

• Prep Work
• Active Directory Users in Play
• The Service Account I am selecting as the Impersonated User (Credential Owner)
• The Security Group where all the people that will consume BCS Data will reside
• SQL Server Security
• Who has Access to What
• Setup
• Creating & Configuring the Secure Store Object
• Creating & Configuring the External Content Type in SharePoint Designer 2010
• Creating External Connection with Secure Store
• Creating the External Content Type
• Reviewing the External Content Type (ECT)
• Reviewing the Security on the ECT
• Test & Validation
• Creating an External List derived from the ECT
• Logging on as a User from the Security Group AND Secured in the permission setting of the EC
• 
  
• Logging on as a User from the Security Group NOT Secured in the permission setting of the ECT

Part 1: Setup

Above: This represents the AD Account [appBCSUser] which I will use as the Impersonated User i.e. the Broker if you will that will connect to the LOB system on behalf of the Group of people who should have access to the data but DOES NOT have access to the database. This is something your DBA will love because he doesn’t have a flurry of people having accounts on his/her DB. Above: This represents the AD Security Group [SecureStoreBCSUsers] that have access or should have access to LOB Systems. You can of-course have multiple of these for any number of LOB Systems. Note here that Fabian and Hardeep are in this list, we will be the test users later on. Above: Lets look into CA now and set up our environment Above: Click Applications Management then Manage Service Applications Above: We are interested in the Secure Store Service so we click it Above: We already have some there from previous Labs, but we will create a new one… click New Above: We create a Target Application ID [note this cant be changed once committed], Display Name which can be the Same App ID, and so on. Above: I populate the fields and choose “Group” as my Target Application Type. MSDN has a good explanation as to why you want to do that over other options. the Long and Short is that it allows me in this example to tie an AD Group FabianLab\SecureStoreBCSUsers to a single set of credentials i.e. the FabianLab\appBCSUser account. Ill show a few other options below Above: By default it wants to know how you will collect the credential of the Impersonated User in my case it is a Windows Account so this works. Above: I change it around a bit for kicks by adding the word Testing infront of the default text Above: Here are a few other options that you can use. SSS is a Claims Aware SSO solution and can take in just about any Authentication Mechanism Above: So here because I only log on to CA with the Farm Admin Account, I set that as the target App Admin, however here is where we start to make the App Work for our design. In Members, you can see that i have my AD Group Account earlier. This means that I dont have to meddle with the SSS App anymore, just add and subtract from the AD Security Group. Above: It processes once i click OK Above: Now i have a NEW SSS App, but wait you may ask… what about the Impersonated User.. we are coming to that… Above: We click on the custom actions available and select SET CREDENTIALS to set the Mapping for the Impersonated Users to the Group that we will Manage of “Allowed Users”… Above: Our trusty Silverlight App shows the progress of us opening a Dialog Pane Above: The default look of the Credential Mapping Above: I populated the values with my User Account previously mentioned in the AD Step

Part 2: Validation and Testing

Above: So in SQL Sever you can clearly see that the only account that has Access to the Database “FabianPlayPen” is the AD User mentioned above right… Above: We create a new External Content Type by defining the name and Selecting External system to define our Connectivity Above: We choose SQL from the list of choices Above: We define our SSO connection. One note here though in full disclosure, I had tried a few times to make this work and did a typo, so I re-did my SSS App and called it FabianLABSSSMSDNForumQ from what i had it last but the steps are the same. Above: Here you may or may not get challenged for credentials when you click OK. The credentials you put here are or should be your own; assuming that you are in that Security Group that will be mapped to the Impersonated User. If not, then you need an account in that Security Group List. Above: Once completed you will be able to connect to your LOB System, expand it and perform any operation allowable to you Above: In our instance lets just create a FULL CRUD operation Above: Validation that it is complete Above: Click the “Save” button to push the ECT up to the BDC Metadata Store. Above: Now we can check a place where alot of Gotchas happen. Now one may assume that because they have access to the LOB system via the impersonated user and Group Mapping you are done… You’d be wrong, now you NEED to have permission to use the ECT and I already have mine set up by default under “Set Store Permission” to add myself, the search account, and my service account by default. You may need to put your security group here to make it seamless, but because i am doing demos and want it to break depending on my use case, i leave it fluid. Above: to do that, click the custom actions and select “Set Permissions” Above: Do your business here by adding the users you want to have access. Here note that Hardeep doesnt have access while he IS a member of the Security Group. Above: Once done, now we can create our External List by choosing our ETC recently created. Above: Commit to the System and cross your fingers…. Voilla!

Part 3: UAT

Above: Logged on as Me…

reference: http://fabiangwilliams.wordpress.com/category/sharepoint-designer-2010/: