SharePoint, My Site and Tracking Colleagues in SharePoint 2007

Social Networking meets SharePoint! My Site is SharePoint’s answer to Web 2.0 social networking public sites like Facebook and LinkedIn specifically tailored for the corporate workplace. For any organisation especially those located across disparate locations it provides the ability to create synergy between those offices and users within offices. Today’s focus is on colleagues and the colleague tracker web part. Colleagues are those users that are part of your Workgroup plus those users you add manually that are not directly part of your Workgroup. Your Workgroup is automatically populated as part of the reporting hierarchy that can be set in each user’s Active Directory Profile which is then dynamically populated in the colleague tacker web part located under the My Home tab in My Site and the Organisation Hierarchy section under the My Profile tab in My Site.

Other colleagues can be manually added and grouped by each user individually. The role of the colleague tracker web part is to alert you of changes that have been made to your colleagues profiles and changes in user memberships. Other alerts include displaying your colleagues upcoming birthdays (if the colleague birth date profile field has been populated), when new blog posts have been added by your colleagues, out of office messages and upcoming anniversaries. You can modify what you want to be alerted on by modifying the properties of the web part. As you can see the colleague tracker web part located on the left is displaying new documents added across the SharePoint site from a particular colleague of mine and also an upcoming birthday for another colleague.

The below colleagues web part which is located by default under My Profile displays My Colleagues that are part of my Workgroup/Organisation Hierarchy from Active Directory and other colleagues that I have allocated against specific groups that have been created by me. Please note that after your My Site has been created you can choose as a user to remove the default colleagues.

As you can see, the colleague tracker web part becomes an invaluable tool in connecting colleagues highlighting any changes made by your peers. It assists in bringing people together throughout an organisation, and let’s face it we are living in a world surrounded by many social networking sites like those mentioned above. I will continue to delve further into My Site and how organisation’s of any size can really benefit from it in future posts.

People Picker, SharePoint and Forest Trusts in SharePoint 2007

Everything in my SharePoint Farm was working well until ….. I decided to install the recent February 2009 Uber packages from Microsoft, don’t ask me why but I have a habit of trying to keep up to date, even though Microsoft explicitly states when you download the hefty packages that you should only install them if you are experiencing one of the issues listed in the KB article and should wait till the next service pack. Have you ever sat down and read one of these Cumulative Update KB’s, they go on for pages and how am I suppose to know if I am actually a recipient of one of the hundred’s of known issues? So I decided to go ahead and install both WSS and MOSS packages a couple of weekends ago… Well, the result was it broke one of my workflow’s that I had designed in SharePoint Designer and I also wasn’t able to apply permissions to users outside the resource domain using the People Picker. I was scratching my head with regards to the latter, I recall I needed to do something special initially to get SharePoint to enumerate users from other forests so after a quick scavenge I realised I needed to re-run a couple of stsadm commands that I will share with you today.

In way of background, my SharePoint farm is serving users from the local resource domain and 2 other domains that are connected to our network through a one-way selective Active Directory Trust. Sounds complicated, but not too difficult once you get past the hurdles of connecting multi-vendor firewalls to create the tunnel. Once the tunnel has been established, all is needed is the setting up of DNS conditional forwarders and then the Forest Trust. Too easy, my Active Directory Admin can do that with his eyes closed, in my case I was the A.D man! Once you have the Forest Trust in place it’s a piece of cake to then import the A.D users from the other sites into SharePoint to pre-create the user profiles in SharePoint, Done! Here comes the tricky part, especially when you are trying to do this for the first time. You will need to run a couple of stsadm.exe commands in order to allow the people picker to search for users in other forests. Please note that users in the forest that the server is in (that is, a resource forest) are displayed automatically.

Okay, so let’s begin with the commands. By default, the People Picker will user the User Credentials against your Web Application Pool and in a one way trust this won’t work so we will need to run the following setapppassword command on each Web Front End Server in the farm.

Command 1 – To be run on each WFE.

stsadm.exe -o setapppassword -password <yourpassword>

<yourpassword> This could be any string to heart’s desire but must be identically run on each WFE.

Command 2 – To be run on one WFE.

stsadm -o setproperty -url http://SharePointSite:85 -pn peoplepicker-searchadforests –pv “domain1.com”,<loginname1>,<password1>;”domain2.com”,<loginname2>,<password2>

Now the trick with this command is to ensure you include all your forests in the one command. Running the command twice in my case for connecting 2 other forests did not work, you will need to include them in the single command.

Please also ensure you run command 2 for each Web Application in your farm including My Site.

Below are some reference links to Microsoft’s TechNet site and Joel Oleson’s Blog – SharePoint Land explaining the above commands and usage in a lot more detail. Until then, Happy People Picking!!

Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server)

Cross Forest, Multi Forest Configuration and Additional Info

Data View Web Part in SharePoint 2007

I have been doing a lot of work lately with SharePoint 2007 and came across 2 scenarios where I needed to utilise the Data View Web Part (DVWP) available from within SharePoint Designer (SPD). I honestly think that this is one of the many under utilised tools from within SharePoint.

Scenario 1

The request was to be able to display a subset of an existing SharePoint list from one sub site and display it on another sub site.

Scenario 2

The request was to be able to have items within a list highlighted (different colour for instance) based on a condition, a.k.a conditional formatting.

In both of these scenarios I was able to utilise the DVWP to tackle these two requests quite easily. Firstly we need to launch SPD as this is where all the action occurs. We then need to checkout the page where you would like to insert the DVWP. After the page is checked out for editing, we add the DVWP by selecting Insert from the toolbar menu within SPD and then selecting SharePoint Controls / Data View.

The Data Source Library appears on the right providing us with the ability to select a SharePoint List from the current site or you could connect to another library from other sites in the site collection.

Click on the required list and then select Show Data. Finally click on Insert Selected Fields as and then select Multiple item view. As you can see from the Common Data View Tasks you can easily create filters, sort, add or remove columns and in my case I was also able to apply Conditional Formatting.

Using the Managed Metadata Service in your SharePoint 2010 Sites-Part 3

We come to the conclusion of our 3 part series in configuring the Managed Metadata Service Application in SharePoint 2010 and today is where all the hard work comes into play. We shift our focus away from Central Administration and I will be providing you with examples on how we can utilise our managed metadata within our SharePoint sites.

If you have happened to miss out on the first two articles in this series, click on the links below for some light catch up reading;

1. How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1
2. How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2

I mentioned way back in How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1 of this series that the Managed Metadata’s primary purpose is to provide you with a central location to store your metadata that can be later utilised in ANY SharePoint site. Notice that the word “any” is in caps! This flexibility is one step ahead of what we referred to as Content Types and Site Columns in SharePoint 2007 where it wasn’t as straight forward.

Adding Managed Metadata to a SharePoint List or Library

Let’s navigate to a List in which we would like to add our Managed Metadata as a column. Navigate to the List or Library in question and click on List under List Tools in the Ribbon and then click on Create Column.

Enter a name for your Column. In my example I will call it State as I will be using the State Term Set which we created in How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2 and select Managed Metadata as your column type.

Set your “Display format” so it either displays just the term label or the entire path.

Under Term Set Settings, select your Term Set. You can also utilise the search facility in the event you have a large number of Term Sets.

Finally select whether you want to Allow Fill-in, which is only available if your Term Set was set to allow it. This is handled by the Submission Policy set to Open, (discussed in How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2 ).

Click OK once done.

I will now proceed to add a new item in my fairly bland Custom List via Add new item.

You have the option to click on the browse button on the right or you can begin typing in which it will provide you with Suggestions. In the above screen capture I began typing in one of the “other labels” or commonly referred to as synonyms which we discussed in detail in How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2. The end result will be the actual “Default Label” Term listed in the Taxonomy Term Store in Central Administration. E.G. I was typing in “New South Wales” and the default label in the Term Store was set to “NSW”.

One thing to note is the “Send Feedback” link, which is visible if you click on the browse button beside your metadata field. This allows users to provide feedback if an email address was specified under “Contact” in the properties of the Term via the Term Store Management Tool.

There are a couple of neat navigation enhancements made available out of the box in SharePoint 2010 which tightly integrates with our Metadata. Commonly referred to as Metadata Navigation, these options are listed under our List Settings.

Navigate to List Settings / General Settings / Metadata navigation settings.

Within this screen we can specify which fields we want to utilise and incorporate in our Navigation Hierarchies and or Key Filters which are both displayed below the Quick Launch. Both allow for enhanced and easy drill down when filtering your list. I have gone ahead and added our “State” Metadata field to both Navigation Hierarchies and Key Filters as examples.

Example of a Navigation Hierarchy.

Example of Key Filters.

Well, that’s just about it on the Managed Metadata service application. I hope you have enjoyed this 3 part series in which you can now take away and utilise within your own deployments. Taxonomy in SharePoint 2010 has definitely come along way, easily allowing you to create and maintain your metadata in an organised fashion.

Until next time.. Happy SharePointing!

Articles in this series

1. How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1
2. How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2

How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 2

In previous How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1, I introduced you to the Managed Metadata Service in SharePoint 2010 and discussed some of the key concepts, before delving into the setup and configuration of the Managed Metadata Service Application. Today we continue our journey and venture into creating Groups, Term Sets and Terms utilising the Term Store Management Tool. I will then demonstrate how we can utilise our managed metadata within our SharePoint sites in the next and final article in this series.

Let’s begin by venturing back into the Term Store Management Tool which we first introduced in How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1.

Navigate to Central Administration / Application Management / Manage Service Applications. Highlight the Managed Metadata Service and click on Manage.

This launches the Term Store Management Tool which we briefly introduced in Part 1 of this series.

Let’s begin by creating a new group. You can do so by clicking on the Management Metadata Service node (or whatever you called it) and selecting New Group.

In my example I will create a group labeled “Office Locations”. I have entered a description to help others identify the purpose of this group and added the Group Managers and Contributors, so what’s the difference between the two levels of permissions?

Group Managers have the privilege to add items to the group and also have the ability to add users to the Contributors group.

Contributors have the privilege to only add and edit terms and set term hierarchies within the group.

After adding the above details, click on Save.

Our new Group will now be listed as per the below.

I will now create 2 Term Sets which will sit under “Office Locations”. They will be, “State” and “City”.

You can do so by clicking on the Group Name and selecting New Term Set.

I will label my first Term Set as “State”.

Here I will identify the owner of this Term set, optionally specify an email address for “term suggestion” and list the Stakeholders who are notified before major changes are made to the term set.

We can also set the Submission Policy which dictates whether we allow users to contribute to the Term Set (commonly referred to folksonomy) or restrict it to only metadata managers (Taxonomy).

Our last option determines whether we will allow our end users to utilise the term set for tagging.

Once you have specified your options, click Save. I will now proceed to create a second Term Set labeled City as per the above instructions. Once finalised, our Term Sets will be listed under our Group as per the below screen capture.

I will now proceed to create our Terms below our Term Sets. I’ll begin by selecting the first Term Set “State” and then selecting Create Term.

I will create my first Term, “NSW” which is an Australian State. You will then be greeted with the below screen;

Here we can specify whether the Term is available for Tagging, add a Description to assist users and add “Other Labels” in which we can enter synonyms and abbreviations relating to the Term. This might come in handy when adding Terms and in my example, I have added “New South Wales” as an additional Label to the abbreviated “NSW” Term.

Click Save once you have completed the modifications. I will proceed to create a Term for each State and City following the above steps and you should have something similar to the below once you have finished.

Note, we can expedite the creation of Term Sets by using the Import method

As an example, I have utilised the sample Import File provided by Microsoft and imported the contents within our Managed Metadata Service.

Now that we have a thorough understanding of the creation of Groups, Term Sets and Terms we will continue our journey in the next and final part of this series where we will utilise our Metadata within our SharePoint Sites.

Articles in this Series

How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1.

How to Configuration the Managed Metadata Service Application in SharePoint 2010-Part 1

The Managed metadata service application is a welcome addition to SharePoint 2010 and is one of my favorite Enterprise Content Management features within this release. In this three part series I plan to delve into the configuration of the Metadata Service Application and then finish off with real life examples on utilizing our metadata throughout our SharePoint sites. So what is the Managed Metadata Service Application all about and what value does it bring over what we had in SharePoint 2007?

The Managed Metadata’s primary purpose is to provide you with a central location to store metadata (commonly defined as data about data) that can be utilised throughout any site within your SharePoint farm. This is definitely one step ahead of what we referred to as Content Types and Site Columns in SharePoint 2007 where it was cumbersome to deploy to more than one site collection. I touched upon the Managed Metadata Service Application in my article in How to Configuration the User Profile Service in SharePoint 2010 as this was a prerequisite for the User Profile Service Application.

Primer on the Managed Metadata Service in SharePoint 2010

Managed Metadata and the word Taxonomy go hand in hand, and as mentioned previously, the Managed metadata service application allows us to formalize our Taxonomy or metadata which will be utilized across the entire farm.

There are a number of concepts that you will need to familiarize yourself with before we embark on the configuration.

Term Store This is the database in which our managed metadata is stored in.

Term is a word or a phrase that can be associated with an item in SharePoint Server 2010.

Term set is a collection of related terms.

There are two types of Terms available within SharePoint 2010. These are “Managed Terms” and “Enterprise Keywords”.

“Managed terms, commonly referred to as “Taxonomy” are predefined words or phrases that can only be created by users with the appropriate permissions. We can refer to this special group of users as “Metadata Content Managers”.

“Enterprise keywords, commonly referred to as “Folksonomy” are words or phrases that have been added by the end user.

Now that we have a better understanding on some of the key concepts, let’s deep dive into our setup and configuration of the Managed Metadata Service Application.

Setup the Managed Metadata Service

To setup our Managed Metadata Service, navigate to Central Administration / Application Management / Manage Service Applications.

Click New and select “Managed Metadata Service”

Enter the follow details;

Name: Managed Metadata Service

Database Server: <server_name>

Database Name: Managed Metadata DB

I will utilize the sp_farm account for the Application Pool Identity.

Click Create.

Lastly, navigate to Central Administration / System Settings / Manage services on server and start the Managed Metadata Web Service.

Now that we have successfully setup our Managed Metadata Service, let’s venture into the Term Store Management Tool. You can do so by navigating to Central Administration / Manage Service Applications and clicking on the newly created Managed Metadata Service.

Note, You can achieve the same by highlighting the service application and clicking on the Manage icon located in the ribbon.

This will launch the below screen which is referred to as the Term Store Management Tool.

Let’s quickly highlight what is made available on this screen.

Available Service Applications: If the farm has been setup with multiple Managed Metadata service applications you can easily navigate and configure each one from the single interface.

Sample Import: Here, Microsoft is providing your designated Metadata Managers with a template import file. This template can be used as a base of creating your own which can then be later imported.

Term Store Administrators: This is where you would add the designated users which will provide them with the ability to create new term set groups. By doing so, they will in turn be able to provide the necessary permissions to the group manager role. Note, users added here have full control of the specified term store. In the above screen capture, I have gone ahead and added Administrator and myself as Term Store Administrators.

Default Language: This one is self explanatory

Working Languages: In addition to the Default Language, you can also specify additional languages available for translation purposes.

That’s it for now. Stay tuned for my next article in which I will venture into creating Groups, Term Sets and Terms and demonstrate how we can utilize our managed metadata within our SharePoint sites.

References

Plan managed metadata (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ee530389.aspx

How to Install Office Web Apps for SharePoint 2010

We continue our journey in configuring our SharePoint 2010 farm and today we shift our focus to one of the many exciting new inclusions in SharePoint 2010, “Office Web Apps”. Office Web Apps was first introduced with SharePoint 2010 and soon after released to the public integrating with Windows Live SkyDrive (currently in beta form) to compete with Google Docs. Office Web Apps is an online version of Microsoft Word, Excel, PowerPoint and OneNote allowing users to access these applications and their respective documents from any Internet connection and most notable web browsers. For those running SharePoint 2010, you can deploy Office Web Apps onto your SharePoint farm providing your users with the same functionality as the online version of Office Web Apps. Deploying Office Web Apps on your SharePoint farms will add the following service applications;

• Word Viewing Service Application
• Excel Calculation Service
• PowerPoint Service Application

Today I will be extending my step by step SharePoint 2010 configuration articles and by the end of this post you will be able to open and edit Office documents from within your web browser without the requirement of having Microsoft Office installed locally. This is a huge productivity gain for those that might be accessing their SharePoint sites from an Airport Kiosk where Office is usually not available.

Installation

You will need to download Office Web Apps from the Microsoft Download Site. This download is available to Volume licensing customers or those with TechNet and MSDN subscriptions. Let’s begin by launching the setup.exe and entering our product key;

Accept the licensing terms.

Click Continue

Choose a file location for installation. Ensure you select a drive with adequate free space for your Data partition which stores the Office Web Apps search index files.

Click Install Now

Upon successful installation, you will be greeted with the “Run Configuration Wizard” window. We will immediately run the configuration wizard by leaving the checkbox ticked and clicking close. You can also achieve the same by running PSConfig. Both methods will register the Office Web Apps services.

Click Close to Run the SharePoint Configuration Wizard.

Click Next and click Yes to acknowledging the restart of the IIS, SharePoint Administration and Timer Services.

Click Next

Click Finish to acknowledge the successful configuration.

You will then receive the below Central Administration screen regarding configuring your SharePoint farm. Because we have been configuring each service application one by one as needed (best practice) we will click cancel and proceed to activate the Office Web Apps services individually.

Provisioning the Office Web Apps Service Applications

Let’s begin by starting the relevant Office Web Apps services located under Central Administration / System Settings / Manage services on server.

Scroll down until you locate all of the Office Web Apps specific services, namely Excel Calculation Services, PowerPoint Service and Word Viewing Service. Click Start for each respective service.

Let’s now navigate to Central Administration / Application Management / Manage service applications.

Click on New / Word View Service

Enter the following details to complete the creation of the Word Viewing Service Application. Ensure that you select “SharePoint Web Services System” from the Use existing application pool option.

Click OK

Your service application will then proceed with the creation process and will be listed with our previously provisioned service applications.

You can now further provision the “Excel Services Application” and “PowerPoint Service Application” in the same manner following the above steps. Please note that there isn’t a separate service application for OneNote.

Activating Office Web Apps

Depending on where you want the feature activated, you will venture to your Site Collection(s) and activate each one individually or you can utilise PowerShell to activate multiple site collections at once within a single script.

From within your SharePoint Site, click on Site Actions / Site Settings.

Under Site Collection Administration, click on Site Collection Features.

Navigate down the page until you find Office Web Apps and click on Activate.

You should now be able to open a Microsoft Word document from a document library on your SharePoint site and it should launch within the browser by default.

To ensure the best experience possible for your end users, you should install Silverlight. The below warning will be will be displayed if Silverlight is not detected.

By default, your browser will open the document in view mode and it’s only until you click on Edit in Browser that you will receive the Office Web Apps editing toolbar.

Things to note

• Silverlight installed on client computers will enhance the end user experience for Word and PowerPoint Web App and improve speed with regards to page loading. There’s no benefits for Excel or OneNote Web App.
• Installing Office Web Apps will change the default behaviour when opening documents from open in client application to open in browser.
• There is no service application for OneNote.
• Service Application Proxies are utilised to provide location information of a service instance within a farm.
• You can load balance and install Office Web Apps on multiple servers to optimise performance.
• When installing on a SharePoint farm (i.e not a standalone installation), you will need to install Office Web Apps on every server.
• Current list of supported browsers include Internet Explorer 7 and 8, Firefox 3.X, Google Chrome and Safari 4.X.

Resources

Office Web Apps (Installed on SharePoint 2010 Products) – TechNet http://technet.microsoft.com/en-us/library/ee855124.aspx

How to Configuration 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