(For more resources on Microsoft Sharepoint, see here.)
Site Directory options
There are two main approaches to providing a Site Directory feature:
- A central list that has to be maintained
- Using a search-based tool that can provide the information dynamically
List-based Site Directory
With a list-based Site Directory, a list is provisioned in a central site collection, such as the root of a portal or intranet. Like all lists, site columns can be defined to help describe the site’s metadata. Since it is stored in a central list, the information can easily be queried, which can make it easy to show a listing of all sites and perform filtering, sorting, and grouping, like all SharePoint lists.
It is important to consider the overall site topology within the farm. If everything of relevance is stored within a single site collection, a list-based Site Directory, accessible throughout that site collection, may be easy to implement. But as soon as you have a large number of site collections or web applications, you will no longer be able to easily use that Site Directory without creating custom solutions that can access the central content and display it on those other sites. In addition, you will need to ensure that all users have access to read from that central site and list.
Another downside to this approach is that the list-based Site Directory has to be maintained to be effective, and in many cases it is very difficult to keep up with this. It is possible to add new sites to the directory programmatically, using an event receiver, or as part of a process that automates the site creation. However, through the site’s life cycle, changes will inevitably have to be made, and in many cases sites will be retired, archived, or deleted.
While this approach tends to work well in small, centrally controlled environments, it does not work well at all in most of the large, distributed environments where the number of sites is expected to be larger and the rate of change is typically more frequent.
Search-based site discovery
An alternative to the list-based Site Directory is a completely dynamic site discovery based on the search system. In this case the content is completely dynamic and requires no specific maintenance. As sites are created, updated, or removed, the changes will be updated in the index as the scheduled crawls complete. For environments with a large number of sites, with a high frequency of new sites being created, this is the preferred approach.
The content can also be accessed throughout the environment without having to worry about site collection boundaries, and can also be leveraged using out of the box features.
The downside to this approach is that there will be a limit to the metadata you can associate with the site. Standard metadata that will be related to the site include the site’s name, description, URL, and to a lesser extent, the managed path used to configure the site collection. From these items you can infer keyword relevance, but there is no support for extended properties that can help correlate the site with categories, divisions, or other specific attributes.
How to leverage search
Most users are familiar with how to use the Search features to find content, but are not familiar with some of the capabilities that can help them pinpoint specific content or specific types of content. This section will provide an overview on how to leverage search to provide features that help support users finding results that are only related to sites.
SharePoint Search includes an object classification system that can be used to identify specific types of items as shown in the next table. It is stored in the index as a property of the item, making it available for all queries.
Site Collection objects
List objects where [templatename] is the name of the template such as Announcements or DocumentLibrary.
List Item objects where [templatename] is the name of the template such as Announcements or DocumentLibrary.
User Profile objects (requires a User Profile Service Application)
The contentclass property can be included as part of an ad hoc search performed by a user, included in the search query within a customization, or as we will see in the next section, used to provide a filter to a Search Scope.
Search Scopes provide a way to filter down the entire search index. As the index grows and is filled with potentially similar information, it can be helpful to define Search Scopes to put specific set of rules in place to reduce the initial index that the search query is executed against. This allows you to execute a search within a specific context. The rules can be set based on the specific location, specific property values, or the crawl source of the content.
The Search Scopes can be either defined centrally within the Search service application by an administrator or within a given Site Collection by a Site Collection administrator. If the scope is going to be used in multiple Site Collections, it should be defined in the Search service application. Once defined, it is available in the Search Scopes dropdown box for any ad hoc queries, within the custom code, or within the Search Web Parts.
Defining the Site Directory Search Scope
To support dynamic discovery of the sites, we will configure a Search Scope that will look at just site collections and subsites. As we saw above, this will enable us to separate out the site objects from the rest of the content in the search index. This Search Scope will serve as the foundation for all of the solutions in this article.
To create a custom Search Scope:
- Navigate to the Search Service Application.
- Click on the Search Scopes link on the QuickLaunch menu under the Queries and Results heading.
- Set the Title field to Site Directory.
- Provide a Description.
- Click on the OK button as shown in the following screenshot:
- From the View Scopes page, click on the Add Rules link next to the new Search Scope.
- For the Scope Rule Type select the Property Query option.
- For the Property Query select the contentclass option.
- Set the property value to STS_Site.
- For the Behaviorsection, select the Include option.
- From the Scope Properties page, select the New Rule link.
- For the Scope Rule Type section, select the Property Query option./li>
- For the Property Query select the contentclass option.
- Set the property value to STS_Web.
- For the Behavior section, select the Include option.
The end result will be a Search Scope that will include all Site Collection and subsite entries. There will be no user generated content included in the search results of this scope.
After finishing the configuration for the rules there will be a short delay before the scope is available for use. A scheduled job will need to compile the search scope changes.
Once compiled, the View Scopes page will list out the currently configured search scopes, their status, and how many items in the index match the rules within the search scopes.
Enabling the Search Scope on a Site Collection
Once a Search Scope has been defined you can then associate it with the Site Collection(s) you would like to use it from. Associating the Search Scope to the Site Collection will allow the scope to be selected from within the Scopes dropdown on applicable search forms. This can be done by a Site Collection administrator one Site Collection at a time or it can be set via a PowerShell script on all Site Collections.
To associate the search scope manually:
- Navigate to the Site Settings page.
- Under the Site Collection Administration section, click on the Search Scopes link.
- In the menu, select the Display Groups action.
- Select the Search Dropdown item.
- You can now select the Sites Scope for display and adjust its position within the list.
- Click on the OK button when complete.
Testing the Site Directory Search Scope
Once the scope has been associated with the Site Collection’s search settings, you will be able to select the Site Directory scope and perform a search, as shown in the following screenshot:
Any matching Site Collections or subsites will be displayed. As we can see from the results shown in the next screenshot, the ERP Upgrade project site collection comes back as well as the Project Blog subsite.