Published: May 31, 2012 06:05 AM by
We have come a long way during this journey to craft a functional and useful targeted search solution that began with the deconstruction of a previous 2007 version of the solution to the reconstruction of that same solution in 2010. Surprisingly, there was much more involved in the recreation of this solution as many of the out of the box configurations were already set with the Collaboration Portal in 2007. However, after working through the configuration changes and details, we have finally arrived at the experience for the user, where we can now complete our solution here in SharePoint 2010.
Implementing a Search Site
There are many moving parts involved with SharePoint, often a configuration or service set up in the back-end while an interface displays and allows users to interact with that service in the front-end, and Enterprise Search is no different. While the setup of the Search Service Application and Content Sources provided us the back-end we need to surface our targeted search results, we required the additional Site Collection configurations to ensure that search queries and search results would be input and returned through an application used by SharePoint. Furthermore, to focus the search query, we needed a Search Scope created and configured to act as the conduit for the queries, as well as establish a landing place for our search results from that targeted query. And although we had already constructed the logical architecture to support an Enterprise Search Center, the site is yet too generic to provide us a funneled, specific view. Thus we need one final element in the Search Center Site itself to both submit and display the search properly, which resides in the Web Parts, Lists and Libraries in the Search Center itself.
The Enterprise Search Center, regardless of customizability, requires that the Publishing Infrastructure be activated as the Enterprise Search Center itself is a Publishing Site by construction. The Enterprise Search Center uses two main web pages, a search page and a results page, to accept and return search queries for the Web Front-End to handle, which are both stored in a Pages Library in the Site. However, the benefit of the Enterprise Search Center is a tabular control that displays multiple pages through an identical interface and thus allows Web Pages to be connected to each Tab that is displayed in the Enterprise Search Center. These tabs are controlled by two lists, one for Search Pages, one for Search Results. This blends the query and results experiences into an identical form yet allowing for queries and result sets to be configured and even customized differently, yet still seem as if the very page accepting the query is the one that is rendered with the search results. Furthermore, changes can also go through review and approval processes, just like any other Publishing Site.
The Enterprise Search Center also includes additional Web Pages, including an Advanced Search page as well as a query and results page for People Search. Essentially, multiple Web Pages aligned with a List Tab can be presented on the landing page of the Enterprise Search Center for any sort of Enterprise Search customization as needed. This is further customized by various Search Web Parts that are included in the Enterprise Search Center’s Site Definition, that controls how search queries are accepted and results sets returned. And, with the Minimal.master page it uses, it keeps the search experience as simple and clean as possible, but also allowing for customization through Web Parts and other means to make the search more useful. Only an analysis of the URL would betray the difference in pages, although even the URL with additional parameters also helps in focusing the result sets in the page, such as when describing the Search Scope. To make a truly interesting application, implementing a Search Center also requires some degree of customization to enhance the user experience for Enterprise Search.
The process is deceptively simple: a standard search page presents a Web Part that displays a Search Box, which accepts the query and sends it through to the Query Processor for processing. The Site Collection is configured to return results in either an out of box default system page, or in a page customized by the Search Administrator for additional functionality or simply better formatting for the view of the results. When the Query Processor completes its task and returns the results to be rendered, it uses the Site Collection Search Results configuration to populate Search Results Web Parts, and the Web Front-End renders the results in the browser. However, this simple process also prevents our targeted search solution from working for two reasons. First, it prevents the user from submitting a search to only be queried against specific content, and second it prevents a targeted results set from rendering in an identical page and thus creating a possibly confusion experience.
To solve this issue and bring the entire configuration full circle, we need to perform a few additional configurations in the Enterprise Search Center:
1) Create additional Web Pages for both a targeted query and the associated search results
These web pages are created to allow a search query to be run against our targeted content and return results in a dedicated page that seems to be identical to the page where the query was submitted.
Note that the page names must be different since they are stored in the same Pages Library.
2) Create Tabs to represent the Search and Results pages used in the targeted query
To coincide with the previously created Web Pages, for the Enterprise Search Center to display either page correctly and without confusion, a Tab connecting the Web Pages for both the search and results phase of the search also needs to be created.
Since the Page names need to be different, yet the pages need to show with the same Tab, a Tab for each page will also connect the correct Page with the correct Tab view when rendered in the browser. Additionally, a Tooltip can be input to provide some hover text when the mouse pointer is positioned over it.
3) Configure the Search Box Web Part to use the correct Search Scope
The main function needed to leverage the Search Scope we created that focuses the query only on the Document Center site containing the targeted content is to configure the Search Box Web Part to use the specific Display Group. The default Search Scope, which will be the only Search Scope in the Document Center Display Group, will be used by default.
The search Web Page is used for this configuration, to focus Display Group on our custom Search Scope. By using the Dropdown Mode of “Show, do not include contextual scopes” allows our custom Search Scope to be leveraged instead, and prevents the contextual Search Scopes from being used. This configuration will allow a user to click the Store Only tab if they only wish to search within the Document Center Site and thus limit their search results to only content from that site. Note that this configuration is for the Enterprise Search Center specifically.
4) Configure the Search Box Web Part to use the custom Display Group
In the Miscellaneous section of the Search Box Web Part, we can configure the Document Center Display Group created when creating our custom Search Scope. This was necessary to configure which Display Group would be used in the Scopes Dropdown box. However, because we eliminated other contextual Search Scopes from being used, by setting our custom Display Group, this limits what the user can change or configure. This was configured to focus the search using the Tab separation to make the searches more readily intuitive.
Additionally, we want to be sure that the search results return and are rendered in our custom Web Page, and thus the Target search results page URL is also configured to use the local Web Page created earlier. This could also have been created in a different URL, but as this Enterprise Search Center has been configured for the Site Collection as a whole, using the local Pages Library was adequate for this scenario.
5) Test the targeted Search Scope and Web Page
By running a specified query against known content, we can now determine if the application is working. A simple keyword search for content should reveal search results in only the Document Center Site.
Note that the results sets are very limited, and only show content from the Document Center Site as desired. In contrast, a standard All Sites search query through the Enterprise Search Center yielded not only different results by also more and with different relevance.
Additionally, although the majority of the results from the general All Sites Search Scope search yielded results from our File Share Content Source, a quick refiner in the Refinement Panel by Sites shows that our News Site also yielded results.
A successful test bears out that despite a possible skewing of results and relevance due to various additional sources, the targeted solution remained focused and much more relevant.
Furthermore, this configuration for the Enterprise Search Center became necessary as the default Search Scope options, which would include our custom Search Scope, would still be needed to target content on the Enterprise Search Center Site. However, because we included the Search Scope in the All Sites Scopes as well, this targeted search can be performed from anywhere in the Site Collection, again because the Search Settings configured the use of the custom Search Scopes and their result sets.
Through some front-end content configuration involving Web Pages, Tabs Lists, and Web Parts, a successful targeted solution could be applied through the Portal Site Collection and thus properly emulates the 2007 solution despite all the changes between versions. And here, even the proper configuration of Web Parts and Site Collections Settings were necessary to work through to reach our solution goal.
Overall, the solution was re-creatable despite all the changes and shifts in configurations and options, but works just as well as the original, while taking advantage of even some newer features to make the Enterprise Search Experience that much more useful. At this point, although one last phase of this series was to examine the improvements that SharePoint 2010 could have on this 2007 solution, the length of this process brings us to a conclusion that our comparison and improvement analysis will need to be held in a different post.
This brings our targeted search solution series to a close. For now, our next post will return us to our never-ending quest to Solve for Y.
Published: April 30, 2012 22:04 PM by
Up until this point, we have been working to recreate a solution that was partially out of the box with limited additional configuration needed so that we could reach the point of creating a specific solution for our Enterprise Search experience. And while it is true that the setup and configuration of Enterprise Search still needs to be performed in SharePoint 2010, the nature of setting up Enterprise Search through a Search Service Application (SSA) is not too far from the SSP setup that would have included the Search service in the first place. The only things we needed to do additionally, which were also identical to SharePoint 2007, was the creation and configuration of the Content Sources as detailed in my previous post. Now that we have arrived at the same starting point as the Collaboration Portal from SharePoint 2007, we can examine the additional customization needed to create our targeted Search solution.
As we have seen with SharePoint Foundation Search, Search is limited to only the Site Collections in which they are performed, allowing a search query to run in relation to any content within that Site Collection from the Site and below where the search is performed. In some ways, Enterprise Search in the previous version out of the box worked like this, since Context Search was added at that time. However, Context Search does not go beyond the Site Collection and thus cannot be considered Enterprise since it cannot touch other Site Collections, much less content not included in a SharePoint Site.
To achieve a more global search set, the inclusion of an indexing service and associated content sources is required to allow SharePoint to communicate with any content and thus return truly Enterprise Search results. Thus by default, a search query returns results from any crawled content, and is displayed through several possible interfaces, which include the Search Center Sites. In this regard, a Site Collection must be configured to determine which Search Center Site will display results as well as submit the queries. Since this is not configured in most Site Templates in SharePoint 2010, this must be set or the result sets will never return content outside of the Site Collection. This sums up what we have achieved thus far in our solution.
However, Enterprise Search is not limited to specific content like it is with Context Search, so long as the content is crawled by SharePoint. This means that more specific relevance may not have much impact on the search results if perhaps we were only looking for content in a specific repository, such as a specific Site or File Share. To configure this, we need to create a Search Scope. In essence, a Search Scope is a logical division of a Search Content Database configured to perform queries against less than the entire corpus of the searchable content.
Site Collection Search Scopes
There are, in effect, two configurable levels of Search Scope: Global and Local. Global refers to all Sites in a Farm (or connected Farm), while Local refers to a specific Site Collection. Although Search Scopes can be configured at either level – one through Central Administration or one through Site Collection Administration respectively – both scopes are managed by the SSA as far as publishing, rules, updating and availability. Global Search Scopes are useful when a particular logical division, such as by a specific type of content, is required or applicable across all Site Collections in the Farm, but the more granular nature of a Local Search Scope allows the Site Collection Administrator control over how that group of Sites will use a logical limitation that may only apply to that group of Sites. If this were a business unit, a branch location or even an internal only type of function, the ability to choose availability of Search Scopes can be beneficial.
One of the main reasons why the Search Scope is valuable, however, is inherent in the purpose of the Search Scope, which is to limit what will be searched within the arrangement of the available content. Search Scopes allow this limitation through several configuration options, all aimed at tightening the view of the content that will be searched. The most common is by Content Source, but this can also be configured to the URL level and thus as broad as an entire host or domain to a specific site or folder. This configuration, called a Scope Rule, allows for a specific, almost topic- or area-related scope to be applied to search queries. In our example, by configuring a Search scope with a Scope Rule that only searches the specific Document Center where the promotional data is located, we can pinpoint where the search will be run against without having to touch other content sources.
The key differences between a standard Contextual Search and a Search Scope allows the granularity of focusing only on a specific data source rather than the Site Collection as a whole. This also produces a targeted effect anywhere a search needs to be run, regardless of the Site in the Site Collection. This feature is applicable to our solution as a Site Collection Search Scope however, because it limits the availability to our targeted Portal rather than being a globally available limit. If the solution called for a specific targeting type not limited to a group of Sites, using a global Search Scope would be appropriate, but as this Site Collection was used specifically for the purpose of housing and accessing this specific data, the Site Collection level works best.
We need to complete several steps to configure our Search Scope for our Organizational Portal to target the Document Center where all the location-specific data will be searched.
1) Create the Search Scope
Through the Site Collection Administration page we create the Search Scope by simply naming the Scope, then configuring a few additional areas.
Aside from a Title, we also need a Display Group and a Target Results Page. The Display Group organizes Search Scopes by a type that shows in the drop-down options depending on where the Search Scope is logically grouped. A Search Scope grouped into a set can be used when configuring how search queries will be run by selecting the Scope for the type of search that is expected to be performed. In most cases, the Search Dropdown will be the most likely group as it is the default, but others can be created for additional targeting limitations, such as certain types of content only within certain branches or divisions. Display Groups can only be configured through the Site Collection Administration page governing the Search Scopes, ensuring that these groupings apply within a Site Collection.
As a Display Group is created, or a new Search Scope is created if the Display Group already exists, the Search scope can be paired with the proper Display Group by either means. A Display Group can further define which Search Scope will act as the default scope, but all Search Scopes within a Display Group can be giving a position, indicating its important, relevance or focus based on how far from the top the Search Scope is available. A Search Scope can be paired with more than one Display Group, if it applied. At times, with reasons such as types of content or location of content, a Search Scope could have a many-to-many relationship as well as a one-to-many relationship, although these types of configurations need to be logically organized to make sense to the user or it will lose its application and perhaps even confuse the user further.
We will discuss the Target Results Page at a later time.
2) Define the Display Group
By either method – Creating a New Display Group or Creating a New Search Scope if the Display Group is available – we can choose which drop-down will be tied to the Search Scope. Since we want to perform standard Enterprise Searches but also use a targeted search, a Display Group indicating where the Search Scope will be used will be created to indicate how that search will run. By creating a one-to-one relationship between Display Group and Search Scope, we can eliminate confusion over how the Search Scope will work. Note that at least one Display Group must be chosen for the Search Scope to surface and be usable.
Search Scope Rules
3) Create the Search Scope Rule
Once the Search Scope is created, a single or multiple set of Rules needs to be created for the Search Scope to be properly limited. The Search Scope will not be available until Rules are added, although only one Rule is necessary.
Each of the types of Rules focus on how the content will be divided, such as by Web Address or by Property. However, from within a Site Collection, one Rule type that focuses on Content Source cannot be chosen, although this can be configured through Central Administration. In our scenario, the Web Address Rule will apply as we want our Search Scope to be limited to only the Document Center within our Portal. Since the Web Address options are very specific, we need the Folder level to indicate our Document Center Subsite in our Portal Site Collection. Also, the ability to Include, Exclude or Require is also important, as each type indicates an OR, AND or AND NOT operator Rule respectively. This allows for multiple rules to be properly joined or excluded as needed. Since we do not need to configure additional Rules, the default of Include will suffice.
Once a Rule type is chosen it cannot be changed, although it can be deleted and recreated.
4) Publish the Search Scope
Rules can be changed, removed or added at any stage, but each change, including creation of the Search Scope with at least one Rule, requires that the Search Scope be processed by the SSA upon completion. This process typically takes about 14 minutes but can be processed sooner through Central Administration.
Once the Search Scope has been properly configured, it can now be bound to a Search Center through the use of Web Parts, Targeted Pages, and Search Settings.
Because this behavior of grouping and logically limiting search queries is not automatic behavior, there are several steps involved with configuring a working, usable targeting system that will allow for the right level of focus as well as application. By creating a Search Scope with a single rule to focus only a the Document Center, and then grouping that Search Scope into a single Display Group, all search queries that run through that Search Scope Display Group will only yield results from our targeted location, effectively creating and focusing the targeting requirement of our solution. And while this particular solution did not require it, some thought and planning should go into the creation of Search Scopes, Search Scope Rules, and Display Groups, to optimize the Enterprise Search experience and not confuse or detract from the Search Application.
One last customization needs our attention, however, which is how the Search Center, the Search Settings, the Content Source, and the Search Scope all come together. This will be the topic of the next blog post.
Published: March 31, 2012 00:03 AM by
In my previous post, we began a configuration process to reproduce a simple targeted Search solution in SharePoint 2010 that was once configured in SharePoint 2007. The array of differences in the configuration were much more plentiful than I expected, and thus required a little more work than the original setup. However, the process can still bring us to the solution despite the changes that made the recreation more complex.
We began with setting up the simple content architecture with a Web Application and a four-Site Site Collection, and proceeded to create the Search Service Application (SSA) needed to meet our Search Service requirement. At this point, the configuration of the Content Sources, the Scope for the target and the custom Web Pages in the Search Center still need to be completed, all of which we will continue with here in this post.
Content Sources Overview
In order for any content to be discovered through a Search query, a Content Source must be created and configured. This Content Source defines what network endpoint SharePoint will identify as a location of stored content and uses Hosts, also known as Start Addresses, to define what points in that network source SharePoint will crawl. Additionally, file types must be defined for SharePoint to identify, by a simple file extension, what is considered content by both the user and by SharePoint. Furthermore, SharePoint requires a special interpreter called an Index Filter (or iFilter) to open and understand how to read the content in the designated content node so it can create the entries in the Index Partition and other databases. Thus the Content Source is heavily used by the Crawl Component to find and index content for search usage.
Content Sources in SharePoint 2010 are similar to SharePoint 2007, but now a new Content Source communication system has been included. Previously, all Content Sources used Protocol Handlers to communicate with a network endpoint and traverse the system to identify content in that system, referred to as Content Nodes. Now, some Content Sources, such as the ones that connect to third-party content system databases such as Lotus Notes or Documentum, use the newer system of the Connector Framework. This Indexing Connector is built upon Business Data Connectivity Services, and allows SharePoint to crawl, enumerate, and create local indexes of the targeted database content. The Indexing Connector, regardless of being Protocol Handler or Connector Framework, is required for the Crawl Component to use the configured Content Source, but by picking the type of Content Source, the proper Indexing Connector is chosen as well. Thus content can essentially be grouped by its native Indexing Connector, such as File Shares or Exchange Public Folders.
When building a Content Source, once the Indexing Connector type has been chosen (again by choosing the Content Source type), the host addresses that will be crawled must also be determined. These addresses, also known as Start Addresses, include the entry point for the Index Connector via the URL, UNC, or other method used by an Indexing Connector (such as a Business Data Connectivity Model) and a crawl depth configuration specific to Indexing Connector type that allows SharePoint to crawl subfolders, other servers, and the like. And while the software boundary of a Content Source is 500 Start Addresses, the recommended threshold is 100. This means planning the starting points for the crawls should be high enough in the target system to crawl everything expected to be indexed from that system.
Also, each Content Source can have and should have a Crawling Schedule, to allow the Crawl Component to regularly visit the target system to update indexes and to keep the source of content queries as fresh as the organization is comfortable to have. The key tradeoffs reside in how much processing from the Crawl Component and the target system can be borne and still be acceptable for daily working performance from either system and the amount of content expected to be crawled. This planning point usually results in multiple Content Sources to reduce resource consumption by creating differing and staggered scheduling when performing crawls. Scheduling options include Full Crawls and Incremental Crawls. Full Crawls are usually required at the onset of the SSA’s deployment, and subsequently when configurations change or corrupted indexes need to be repaired, among other reasons. However, SharePoint will not perform any crawls unless triggered either manually or by schedule.
In Enterprise Search, SharePoint has always had a self-awareness of content that it managed regarding indexing. A standard, automatically created Content Source called Local SharePoint Sites is created when a new SSA is built, and it includes all Start Addresses for each Web Application associated with the SSA. This automatic configuration makes crawling SharePoint-native content much easier, and new Web Applications added are automatically updated as a host address as needed. For our scenario, since the SSA did not exist before creating the Web Application, we do not need to set up this host address. However, to insure that our targeted application is focused on the particular content in question, a different location of duplicate content will be created using the File Shares Content Source.
1) Create a Share
First, a file share named Workspace Content will be created that will host the same content as our Web Application. Again, this is only to verify that our targeted solution is actually looking at the source we are expecting, which will be the SharePoint Site-based content.
2) Create a File Share Content Source
Next, we build a Content Source based on the File Shares Indexing Connector and set the appropriate Start Address by using the UNC of the file share
3) A Full Crawl of the Content Source is needed to be sure we have the File Share content Crawled.
4) Content for the Document Center Subsite of the Web Application is added.
The Document Center Site Template now includes an Upload a Document button, which triggers the single document upload dialog box and also allows for multiple content uploads. The same content stored in the Workspace Content File Share is also stored here. Also, the Document Center has only one Document Library by default called Documents, which will suffice for our scenario, but could include additional Document Libraries, Folders, and even Picture Libraries as it did in the original solution. In this case, we do not need to flesh out that level of organization to test the solution.
5) Create web page-only content for the Web Application
To insure that the targeted solution is also only looking at the Document Center Site, an additional Site was created to emulate the News Site from the previous version of SharePoint. You may notice that the Workspace Content File Share also includes HTML pages that would be used in web pages for the News Site, and thus after the Publishing Site was created as a Subsite, web pages for the Site content was also generated here. The purpose of this is to test how keywords in Search may show results from either the Document Center, the Publishing Site, or the File Share, since the point of the targeted solution is to focus on only the Document Center Site.
6) Perform a Full Crawl for the Local SharePoint Sites Content
Since we need the content of both sites, the Document Center and the Publishing Site, included in our results set as this would be a standard expectation of an Enterprise Search, a Full Crawl against the Web Application needs to be run. Going forward, Incremental Crawls will be adequate, but for testing purposes we will update our index to be as fresh as possible.
Once our configuration for Site content and crawled content has been completed, we can test that Enterprise Search is providing an accurate view of our content. This is important because SharePoint 2010 continues to support Context Search (sometimes referred to as SharePoint Foundation Search), which automatically indexes a Site Collection for its content and allows a user to search only within that Site Collection. By adding the File Share Content Source and creating the Enterprise Search Site, we have created an Enterprise Search that will go beyond the Site Collection and will behave as a standard Enterprise Search application should.
In the first screenshot, we see that content has come from both the Document Center Site and the File Share. We are also alerted to the presence of duplicate entries, as denoted by the View Duplicates link that shows under some of the results. In the second screenshot, one of the duplicate entries is expanded to show that content from the Publishing Site is also being displayed in results separately from the File Share. Thus we have an expected and very standard approach to an Enterprise Search application, emulating what would have occurred with less configuration from SharePoint 2007. Now that we have the groundwork set, we can create the targeted application solution.
Similarities between versions of SharePoint does not always mean quick and easy configurations going from previous version to next. Although many additional enhancements have been made to improve many portions of the experience and functionality, there are still additional tasks and planning points that need to be considered and performed to meet the need of a functional solution. And while some things, such as Context Search, provides a quick and touchless solution for simple search, when expanding to deeper or broader levels there needs to be more completed to service even something that may have been considered standard from the previous version.
In our scenario, taking Enterprise Search from scratch required many additional steps and planning options, and to reach the point where the custom solution was originally crafted, there was still plenty of work to be performed to reach that point. There are reasons why this approach can be useful, especially when considering a more centralized Enterprise Search experience, but it also means some processes from previous configurations may need to be well documented and thought out a bit more to move into the new format and structure.
At this point our scenario brings us to the customization of the solution, and considerations for the present system of Enterprise Search still need to be considered. These topics will be examined in upcoming posts.
Published: February 28, 2012 23:02 PM by
If there is one thing I have learned about SharePoint over the years, it is the constant fluctuation of features and configurations coming and going to the point where it is difficult to predict what exactly has changed since a previous version until you attempt it. And while some things are exactly the same, some things are just different enough to make you have to think through an issue or two a bit further. In our case, recreating the targeted Search solution created in the 2007 version was not as turnkey as it would have seemed. However, due to a number of very beneficial changes to the platform, sometimes these changes can be accepted but not necessarily welcomed.
In my previous post, I spoke about a simple single Site Collection with multiple sites providing a focused Search solution targeted to a Document Center, and our goal was to recreate this solution. Several changes make recreating such a solution a bit more challenging, including:
- The discontinuation of the Collaboration Portal
- Changes to the Search Center Site template
- Changes to the Search settings for a Site Collection
- Available Features activated in a Site Collection
- Changes to the Search Architecture
However, the solution is not completely lost, simply mired in a few more configurations and changes that happened automatically in 2007. We will walk through building of the content Sites and the Search structure in this post.
Setup and Configuration
Our solution begins with a simple single Web Application and a single Site Collection. This Site Collection will serve as the root of the Web Application, and will contain four sites to emulate the missing Collaboration Portal Portal Definition that would have contained all of these sites. The Site Collection will begin with a Team Site as the Top-Level Site, with the Enterprise Search Center, Document Center and Publishing Site with Workflow as immediate Subsites. There were other sites in the original solution, but these three will provide us enough variance to create and test the solution. After the Web Application, Site Collection and Subsites are created, we need to activate a few Features, including:
- Publishing Infrastructure (Site Collection): This is to support the Search Center since it uses Publishing Features
- Publishing Workflow (Site Collection): This is for the Publishing Site with Workflows for publishing news articles
Without the Publishing Infrastructure activated, the Enterprise Search Center cannot be created although the Site Template will not be hidden from the template choices.
To support the full functionality of the Document Center, the Publishing Infrastructure and Document ID features were also necessary, although for the initial solution these are not vital to its completion. The Publishing Workflow is for the Publishing Site to recreate the News Site publishing.
We could have used the Publishing Portal for our solution, since this would have included a Basic Search Center, a Press Release Publishing Site and a Publishing Top-Level Site, but several reasons make the Team Site solution here preferred. First, the Basic Search Center will not meet our requirements as it is not very customizable. Second, the Publishing Portal Top-Level Site is not as Collaboration-friendly as the Collaboration Portal Home Site. Third, the nightandday.master used in the Publishing Portal is pre-branded and would not make a good generic or specific company portal. However, the Basic Search Center is the main issue.
Search Site Changes
There are three available Search Center Site Templates available for use: Basic Search Center, Enterprise Search Center, and FAST Search Center. These replace the Search Center and Search Center with Tabs Site Templates that were available in the past. A quick evaluation of each will help us analyze the usefulness of each one.
Search Center Template
Basic Search Center
Similar to Team Site, may have Tabs lists for query page and results page if Publishing activated
Simple Search, beyond SPF Search but limited to single page
Limited customization, will not work for targeted solution
Enterprise Search Center
Similar to Publishing site, will have Tabs lists for query page and results page
Customizable Search, supports tabular control for customized Search pages and Results Pages
Requires additional configuration to build an adequate targeted solution
FAST Search Center
Similar to Enterprise Search Center
As Enterprise Search but used with FAST Search Server
Requires FAST Search Server
The Basic Search Center is targeted for a simple customizable interface since it can only use the single page provided at the root of the Site. Much like a Team Site, the Basic Search Center does not use Publishing and thus does not use a Pages Library to store and manage Search Pages. Even if Publishing is activated on the Basic Search Center, the custom Web Pages are not used, although two lists, Tabs in Search Pages and Tabs in Search Results, will become available. However, these cannot be used to create a Search Center with Tabs solution as it functioned in 2007.
The FAST Search Center, while as customizable as the Enterprise Search Center, works with FAST Search Server and cannot be used outside of FAST being available and configured. Since we are not configuring FAST in our environment, the FAST Search Center cannot be used, and since the Basic Search Center is very limited, we cannot use this either. Thus, we will focus our efforts on the Enterprise Search Center.
The Enterprise Search Center supports a key function to provide our targeted solution: the tabular control. This control allows a designer or administrator to create a web page and link an in-browser tab to the page, forming the tabs as choices in the web page for both a customized Search page as well as a customized Results page that are attached to the tabs. This becomes important later as the ability to create a customized Search and Results page allows us to focus the search to the Document Center as well as display the results just for the Document Center.
A Site Collection also normally uses SharePoint Foundation Search and uses the OSSSearchResults.aspx page for Search results, which also means that to use the Search Center, the Site Collection must be configured to support Search. In 2007, this was automatically configured for the local Search Center in the Collaboration Portal, but because the Collaboration Portal is not used in 2010, configuring the Search Center and the Search Results page must also be done for the Search Center to be used.
This configuration, however, is identical to the 2007 configuration, and thus a custom, specific Search Center can be created outside the Site Collection if desired. Once we have our Search Center configured, the Search Search Application can be configured.
Search Service Application Overview
Search, amongst other advanced services offered in SharePoint 2007, was once a component of the Shared Service Provider, which allowed one or more Web Applications to be associated with it to consume and take advantage of all services configured for the Shared Service Provider (SSP). However, only one SSP could be assigned to one Web Application, and thus a subset of services, such as Search and User Profiles only, or a grouping of similar services, such as two Search services indexing different content, could not be configured. However, with the uncoupling of Services from the SSP, all Services now can be associated with multiple Web Applications, as well as have duplicate Services associated with the same Web Application. This allows for scenarios mentioned previously to create a better offering of services. The Service Application architecture allows the administrator to decide which Services, as well as how many of the same type, can be deployed and associated with one or more Web Applications in the Farm. Additionally, some services, such as Search, can be published across Farms and thus be provided to other Farms. Because of this architectural change, the setup and configuration for the Search Service Application (SSA) has also become more complex.
An SSA requires the two key server-based components that have been true for Search since the first iteration of SharePoint: an Indexing Server and a Search Server. In 2010, as the Indexing server no longer contains the Index but actually propagates it to the Query Server, it is now a Crawl Component, which links the physical server to a Crawl Database as one component of the Search architecture. The Search Server stores the Index in partitions, and also connects to a Property Store, and thus becomes a Query Component. Both components are necessary to implement Enterprise Search at a minimum. In our scenario, the physical architecture is not as vital as the SSA or the Search Center, and thus we will keep the discussion related to deployment of Crawl and Query Components to a minimum, implementing what is necessary to get the Crawl component to build the Index Partition and allow the Query Component to run queries and display results.
Following good practice, the SSA has not been constructed since it would require running the Farm Configuration Wizard, which limits the control over the Application Pools and Content Databases for the administrator. Thus, setting up the SSA requires a few steps before we can begin crawling and querying content.
1) Start the Search Services
We will need two Search-based Services started: the SharePoint Search Service and the Search Query and Site Settings Service.
These two services will provide the crawling functions and the querying and administration functions.
2) Create the Search Service Application
When creating the SSA, aside from the basics of the name and if FAST will be used, three specific options need to be configured:
- The Search Service Account – This account will be used in the Application Pool ID for network services and will default as the Default Content Access Account
- The Search Admin Web Service – This will create the Application Pool used to managed the Administrative Web Service for managing the crawling of the Search component
- The Search Query and Site Settings Web Service – This will create the Application Pool used to managing the querying and load balancing of the Search component
In general, the Default Content Access Account is usually different from the Search Service Account as it accesses content during the crawling process, and can be changed after the SSA is created. Once the configuration for the SSA is in place, the SSA will be built.
3) The Topology is constructed
As the SSA is configured and created, the initial Topology for the SSA will also be generated, including the two main components for Search.
The Crawl Component will have its Crawl Database created and will associate the initial Server as the Crawl Server. Additional Crawl Databases and Crawl Servers may be created and configured as needed. A temporary location for storing the building and updating of the Index Partition will also be configured.
The Query Component will have the Property Database created and will associate the initial Server as the Query Server. The Index Partition will also be generated at this time.
Additionally, the Administration Component, which will host the SSA Administration interface, will also be generated and will be displayed when the administrator clicks links to manage the SSA. A database to store content for this Site will also be created and connected to the Administration Component.
The SSA infrastructure is now complete. This will be used to crawl and query our content structure that was also created previously. However, we have additional configurations on both the back-end and front-end yet to complete.
Many things have changed for both the collaboration structure and the Search Service and Components. Because of the deprecation of some features and technologies, coupled with newer features and functions, recreating this solution was actually more difficult than it would have seemed. However, there is much more that needs to be completed, including Content Sources and configuration of the Search Center itself. This will be covered in an upcoming post.
Published: January 30, 2012 23:01 PM by
Awhile ago I met a nice fellow at a SPUG meeting who was profoundly interested in improving his organization with technology, and SharePoint was one of the key tools he implemented. He was interested in building a useful, fairly intuitive environment for managers and other users alike, and had a challenge with Enterprise Search. I should say his challenge was not with getting Search up and running, but how to focus it in ways that would be useful for targeted, specific content search and display. During time before the SPUG meeting I worked out with him what he would need to do, and I always found it a very eye-opening experience as to how far Search could actually go in SharePoint. In 2001 and 2003 Search was pretty limited, but beginning in 2007 there was a greater number of configuration and change points that made customizing Search a workable application reality.
That was 2007, but here in SharePoint 2010, Search has become so much more. In the interest of plumbing the depths of SharePoint Search in 2010, I wanted to see if was possible to not only recreate this application but also to see if SharePoint 2010 had additional things that could be done or added to make that search experience even better.
The specific example we will use in our scenario came from a need for this IT Pro to create a targeted application for a very specific group of content focused around limited release products and services as well as a changing base product catalog that needed to be referenced on occasion when building other new limited releases and new product catalogs. The concern was that out of the box Search would index everything and thus a targeted search for this particular body of content would display everything. He wanted to have specific results returned from only that group of focused content. He already had a Search Center in his Collaboration Portal so he wanted to modify what was already existing into something more focused.
To recreate and possibly improve upon that, we need to construct a similar architecture while examining the limitations of SharePoint 2007 with what we can reconstruct and improve upon in SharePoint 2010. With the removal of the Collaboration Portal from SharePoint 2010, the Search Center must be included in any Site Collection to resemble what the previous Portal Template would have had. However, there are limitations for using Site Collection-specific Search Centers, including the limitation of Keywords and Best Bets to that Site Collection. Thus, if any Keyword/Best Bet would be useful in the Enterprise, that would have to be recreated in each Site Collection. The Keyword/Best Bet configuration is but one limitation of the Site Collection-bound Search Center as a Subsite. The challenge here will not be so focused on the limitations but how we constructed the solution and, after recreating the solution, attempt to improve upon it with newer practices and SharePoint 2010.
The lack of a Collaboration Portal does not limit what we can configure, in fact to recreate this we simply need a Site Collection with a Search Center Subsite. Since our only choice for multiple sites in a Site Collection from a Top-Level Site template is the Publishing Portal, we could begin with that, but since most Administrators would likely use Team Sites as a Top-Level Site instead, we will begin our reconstruction from there. Also, the Collaboration Portal also held a News, Site Directory and Document Center set of Subsites, but in our scenario the Document Center was actually the main storage area for this special focus content. Thus we will also build a Document Center in our recreation. The Site Directory is not as useful in this scenario, but the News Site could also be included to differentiate content from other Subsites that should not show in the content search, so we will create a simple Publishing Subsite for the News Subsite.
In 2007, the Shared Service Provider (SSP) that was created to host the Search component has now been replaced by the Search Service Application (SSA), so this will also suffice in creating our crawl and query components to run our content searches. Already the benefit of creating a separate SA for Search has its advantages over the SSP, but this also means we can look to other possibilities for improvements that perhaps we could not achieve in 2007. Additionally, the Search Center Site template has changed with additional Web Parts and may become even more configurable now. Regarding the 2007 Document Center, whatever Document Management features were available at that time were configured and set in the Document Center template, and the new version of the Document Center template takes advantage of several additional new features that can make the Document Center an even more useful Library-based Site. Thus even the Document Center should be examined to discover any additional benefits here in 2010.
Enterprise Search – Revised, Revitalized
Enterprise Search has been growing and changing since the first version of SharePoint and of course, since its roots in Site Server even before SharePoint became the business standard. Thanks to the acquisition of FAST, Enterprise Search has reached even more new levels and becomes increasingly more robust in larger enterprise environments, as well as much more customizable in any environment. Yet the core functionality has remained stable and useful: create and configure a Search Application, target Content Sources and provide a searchable Catalog to present result sets through a customizable interface. Even with all the architectural changes in SharePoint 2010, Enterprise Search still provides that familiar structure so Administrators can focus on how content gets indexed and how result sets get displayed.
As previously mentioned, with the breakup of the SSP and the implementation of Service Applications (SAs), Enterprise Search can be implemented as a single Search Service but also as multiple, different purposed services. This may provide a benefit in our feature enhanced scenario. But the SA architecture alone provides a configuration option the SSP could not meet: purposed and assigned search content. By creating a Search Service Application (SSA), an Administrator may still focus on indexing content from many of the same familiar sources in the past, including File Shares, Web Sites, Exchange Public Folders, the People Database and even Business Data Connectivity Applications. However, the key benefit of the SA architecture is the uncoupling of the Index itself from the single instance of the Index Server. Now referred to as the Crawl Component, the indexing server has an associated Crawl Database and propagates the Index as an Index Partition to a somewhat familiar module, the Query Component. Once referred to as the Search or Query Server, the Index exists as partitions on one or more servers, which can also be mirrored. The Query Component also keeps its own Property Database. For the Crawl Component, the ability to add additional components releases Administrators from being shackled to a single instance for crawling.
Additionally, Enterprise Search has changed in additional other ways to the benefit of the user experience as well. Because of the Federation Object Model, querying against different search engines and at least displaying results not dependent on the native SharePoint Search Engine is native, customizable and can even be merged. The inclusion of the Connector Framework allows for connections and crawling into new and different content sources and even becomes the new method for leveraging Business Connectivity Services. And on the front-end, new Search Site Templates with more Web Parts that are also extendable provides richer context in which new Search Applications can be made. All of this bearing huge potential for new and more innovative and useful patterns in Enterprise Search.
Document Management – Revisited
Because part of our scenario requires the use of the Document Center, although many of the basic features can easily be reconfigured from a standard Team Site Template, an examination of the Document Center and its general features is also beneficial to determining what can possibly improve our scenario. Although many features of SharePoint have focused on standard management tools such as Check in/out, Versioning and Content Approval, the inclusion of Workflows, Content Types and Information Management Policies extended the capabilities of SharePoint in 2010, along with additional features such as Document ID, Document Sets, and Content Organizer. However, the Document Center Site Template takes advantage of what was available in 2007 and adds additional support for these features in 2010. This site template continues to be useful and applicable, and even hosts a new home page with additional Web Parts for better Document Management by user. Thus while the Document Center does not impact the back end quite as much as Enterprise Search, for our scenario there can be plenty of additional benefits to be examined and possibly applied.
The initial part of this scenario will require nothing more than a single Web Application with one Site Collection with a Team site Top-Level Site and three Subsites: News, Documents, and Search. We will take our limited availability content and build our Search architecture, leveraging the Search Center and other Search configurations to achieve our goal. Following this, we will examine several other permutations of this scenario and see how far we can improve upon the targeted Search experience as well as what we can use to improve that experience, if at all.
Interestingly enough, the original solution required some work since the specifics were being applied in ways I understood at the time but needed to be configured and tested to discover the operational aspect of such a solution. However, it is the recreation and improvement of this solution which brings us to the gist of the scenario and the focus of the upcoming posts centered on fashioning a 2010 solution.
In my next blog post, we will implement the recreated solution and analyze differences and changes as well as look into the specific configurations needed to achieve our goal.
Published: January 12, 2012 05:01 AM by
As a start of a new year of blog posts and informational sharing, I will begin a new aspect of my posts I will call Word Problems, which will focus on one-off issues, concerns, questions or challenges I have encountered related to SharePoint. At this point the plan is to slip these in between my more serial posts, but as they say, even the best laid plans and whatnot…
A very recent question that was brought up was related to the availability of terms from the Managed Metadata Service to its subscribers, in particular, what terms from the Managed Metadata Service are available for a user to see. For example, if Zoe is only allowed to see certain terms from a Managed Metadata Service, how can the Site Owner or SharePoint Administrator restrict his viewing and using of such terms? This is the gist of the scenario, but not the complete description, as we need more information before we can proceed.
Terms Management Overview
To understand the scenario a bit better, a quick review of how Terms are stored and managed is necessary. I have previously discussed this with a bit more depth in my discussion about Choice Term Sets, but to keep in focus for this discussion, we will review this at a very simple level.
Managed Terms are stored in the MMS (Managed Metadata Service Application) and are organized at two levels: Term Groups, which provide a layer of management security, and Term Sets, which organize a group of terms into a hierarchy. The Term Groups are necessary to have Term Sets, and will define who can control the editing of any Term Sets in that Group. The Term Sets only define the hierarchy of terms, including the root term of the grouping, but can be used to open a set of terms for editing if necessary. This latter part is important for allowing users to define a managed set.
The entire scenario looks like this: There are two Term Groups, Marketing and Sales. The Metadata in Marketing should be restricted to only users of the Marketing Term Group, and thus should not be seen or accessed by the users of the Sales Term Group. Now, if Zoe is setting up a a local Site Content Type in the Sales Site Collection, and she applies a new Managed Metadata Column to the Site Content Type, when she goes to select which Term Set to use for the column, can she see and use the Term Sets from both the Marketing Term Group and the Sales Term Group? And, depending on the answer, how can we control this, if it is possible?
Terms Availability Basics
According to this Technet Article about planning for Terms and Term Sets, specifically when planning for Term Groups, when separating Term Sets for visibility purposes, a Term Store Manager should create different Term Groups and create the specific Term Sets into the proper groups. However, when we do this, such as creating a Marketing and Sales Term Groups, we find that a Site Owner can create a Managed Metadata Column using either of the Term Sets from either Term Group:
Thus we see that Zoe can still access the Marketing Term Group and associated Term Sets despite the separation of Term Groups. This is not unexpected, but as limiting as it could be. There are several possible solutions that can help to control both management and visibility, and each one requires some consideration when planning to implement them.
It is important to remember that all users are provided the ability to apply or tag metadata through the Managed Metadata Column if they have Edit access to a List or Library, so visibility and access can begin with simply ensuring that the Site Owner creating a Managed Metadata Column only select the Term Set or Term they wish to be applied to a List or Library. This will prevent suggestions from other Term Sets automatically.
Solution #1 – Separate Term Stores
The most obvious conclusion for a SharePoint Administrator when deciding on how to separate Term Sets from availability is to create multiple Term Stores (via MMS) and thus limiting which Web Application will subscribe from the proper Term Store. In application, this would mean that two Managed Metadata Service Applications, such as MMS-Marketing and MMS-Sales would need to be created, and two Web Applications, such as Marketing and Sales, would also need to be created and associated with the correct MMS. In this case, the Marketing Web Application could be associated with both MMS Applications while the Sales Web Application would only be associated with the Sales MMS. The major limitation is in the architecture, as this would complicate matters tremendously and would not scale well at all. And while this can have application in some scenarios, in a single Web Application, single MMS, this would not apply.
Solution #2 – Local Term Sets
When working with Term Sets, a SharePoint Administrator will work with Global Term Sets, which are Term Sets that are made available to all associated Web Applications. A Local Term Set is a Site Collection-bound Term Set, in that it is created from the Site Collection and only visible and available to that Site Collection. A Local Term Set is generated when a Managed Metadata Column is created; instead of applying an available Term Set from the associated Term Store, the Site Owner can customize options by creating their own Term Set. This in effect will create a specialized Term Group for that Site Collection and will automatically limit visibility of that Term Set to prevent others from viewing that content.
When generating a new Managed Metadata Column, the name of the column automatically becomes the name of the Term Set, logically associating the new Term Set with the column. Once a Local Term Set is generated, it can be managed and accessed like any other Term Set in the Term Store for any other Managed Metadata Column, but only for that Site Collection. The Term Group will be named after the URL of the Site Collection with a Site Collection label as a prefix, but this can be changed as well.
In order for this to work, two important configuration on the MMS must be set: first, the MMS must be set to be the default location for column-specific sets, as configured on the Proxy Service Connection properties of the MMS, and second, there can only be one default store for one MMS associated with one Web Applications, similarly to how Enterprise Keywords are associated with one MMS to one Web Application. In fact, the Local Term Sets appear beneath the System Terms (where the Enterprise Keywords and Orphaned Terms are stored) in a similar fashion.
Thus we find an effective method for creating secured Term Sets per Site Collection, and thus limiting other Site Collections from seeing and accessing these terms. Additionally, these Terms and Term Sets can be copied, moved and reused like other terms, although the Term Store Manager cannot access them except through the Site Collection Term Store Management Tool directly.
Our only issue now is that if we have users in the same Site Collection, we cannot limit the visibility of specific Term Sets using this method, as the Local Term Sets are still available throughout the Site Collection as the Global Term Sets are.
Solution #3 – Unavailable for Tagging
Another possible solution, with limited application, can be configured using the Term Set configuration for Tagging. By default, all terms in a Term Set are available to be applied or tagged to items in List and Libraries as needed, but this can be changed either at the Term Set level or at an individual Term level by the Available for Tagging checkbox. By deselecting this checkbox, a Term or entire Term Set will be unavailable for choice in a Managed Metadata Column and thus cannot be applied at all. This can be useful if certain terms should be completely managed by a limited body but not available to the general public.
To further limit access to restricted terms, a Local Term Set could be generated first, and then a specific Term Set could be marked as unavailable for tagging as well, to create, at least at this point, the most granular level of visibility limitation we can configure at this point.
The major limitation is that the Term or Term Set must be toggled to make it available to be applied and then retoggled to remove its availability for tagging. Thus a very limited application would ensue, one that would require some, if not significant, administrative overhead to manage.
Managed Metadata in SharePoint 2010 can be quite fantastic, but there are still many interesting limitations and shortcomings that may need to be addressed before it can be flexible enough for a complete metadata management system. However, even at this stage, using Local Term Stores and possibly even using Tagging limitations can provide a degree of control expected in an organization's metadata management governance. Until then, some careful or thoughtful (or both) planning should be made when determining how to apply term availability through Term Sets.
Thank you for joining me in this interesting challenge, and we will examine another Word Problem in a future post.
Published: December 30, 2011 13:12 PM by
This post will represent the culmination of a series of posts based on the scenario of creating and publishing an organizational manual using Wiki-based technology and Web Content Management. The combination of the two provides a simple yet effective content creation and publishing system that requires little development overhead with plenty of collaboration tools already available out of the box.
Up until this point, we have been analyzing the Wiki-based technologies found in SharePoint 2010 and how they have matured into an interesting mix of collaboration and web publishing. By leveraging both document management features such as libraries, content approval and publishing, while also taking advantage of the newer publishing features for Wiki Pages such as page layouts, web parts and bookmark links, we have found a useful process inherent in SharePoint. The last additional component we will examine is Content Deployment to determine if it can be applied to this scenario.
Content Deployment allows a SharePoint Administrator to configure a connection between two Site Collections to move content from a source and make it available in a destination. While these Site Collections are usually in separate Farms, this can be configured to run on the same Web Application if needed. The main purpose of configuring a Content Deployment infrastructure is to create at least two separate environments representing, minimally, authoring and publishing. In some cases, it may be necessary to create a third environment somewhere between or around the authoring and publishing ones to represent additional business requirements such as compliance or testing, although the exact deployment chain can be represented in a number of ways.
To configure a relationship between a source and destination Site Collection, two connections need to be established: a Path and a Job. The Path represents the direction of the deployment, which is always one-way and goes from the source to the destination. Authentication to apply deployment permission to the destination Site Collection is configured using the Central Administration site and credentials on the destination server. The Web Application and Site Collection must be named to make this connection. The Job represents the schedule of deployment using a specified Path. The Job can also determine which sites within the source Site Collection will be deployed. In SharePoint 2010, the ability to generate and use SQL Snapshots for the source Site Collection is configurable and requires SQL 2008 Enterprise Edition to generate the snapshots. This feature prevents content updates during a deployment since the snapshot is created before the deployment begins.
There are three types of Content Deployment jobs: Full, Incremental and Quick Deploy. To maintain proper synchronization between the two Site Collections, content GUIDs, modification dates, and flags are used to add, replace or delete content.
- Incremental: Deploys new, changed or deleted content from source to destination, using GUIDs, dates and flags
- Full: Deploys all content, including content previously deployed, which means no checks for previous content are done
- Quick Deploy: Allows content authors to deploy a Web Page only, which runs every 15 minutes rather than by schedule
Each of these deployment options offers a specific solution to control how content will be deployed and maintained on the destination Site Collection and can certainly be used in combination. Additional factors, such as security on the destination, where the exported and imported content will be stored temporarily, and which objects from the source will be deployed, also need to be taken into consideration. Some planning should go into arranging this infrastructure since configuration will lock in the Paths and make it difficult if not impossible to change later. Additionally, for Incremental Jobs, if a Full Deployment had not occurred previously, the Incremental Job will perform a Full Deployment first. The option to choose a Full Deployment over an Incremental Deployment is no longer available.
Configure Content Deployment
For this scenario, we will configure a Content Deployment infrastructure to support an authoring and publishing environment to represent a Web Application containing the source Site Collections where the main content authoring will be handled and a Web Application for the destination published content for general consumption for the organization.
1) Configure Deployment Environment
In Central Administration, we configure the Content Deployment settings to accept incoming deployment jobs. We then configure which Import and Export servers to use, which must have Central Administration installed on them. This also allows us to configure which servers can be used for dedication if necessary.
By default, the Content Deployment process will require encryption between the two servers, although it is not necessary, but may be required especially if the servers are separated by a firewall or other security measures such as in a DMZ. Also, the location of temporary files should be specified and enough space to store that content should be available on this location.
2) Configure a Deployment Path
Once the two servers for deployment are configured, a Path needs to be configured between the source and destination site collections. Since the source has already been configured, we require a new Web Application and at least two Site Collections—one for the main Organizational Manual site and one for the Human Resources Manuals in our example—that must also be empty at the initial configuration. This will allow the Incremental updates to properly update content using the GUIDs, modified dates and flags as mentioned earlier. Creating empty Site Collections can be handled through the command-line or by creating the Site Collection using the Select Template Later Site Template option for the Top-Level Site.
After the destination Site Collection has been arranged, then the Path can be created. Name the path and choose the Source Web Application and Source Site Collection.
Configure the destination Central Administration site by its URL, and apply the account that will be used as the service account for the deployment. Next, indicate the Destination Web Application and Site Collection.
The last configuration concerns Security. If the names of the authors should be deployed with the content, be sure to check the Deploy User Names checkbox, otherwise the system will use the System Account as the author. Also, if security from the source Site Collection needs to be handled differently from the destination Site Collection, one of three choices that can be configured:
- All: All security information from the Source will mirror security in the Destination, including roles and specific users
- Role Definitions Only: Only the SharePoint Groups, Permission Levels and Access Control Lists will be deployed to the Destination, but the users from the Source will not be included
- None: No security from the source will be applied to the Destination, and security must be managed by the Administrator on the Destination Site Collection
This security configuration allows different security to be managed on the Destination as needed, such as controlling Destination security to not allow the original content editors from editing content on the published Destination.
3) Configure the Deployment Job
With a configured Job, content will not deploy. A Job is configured on a Path, and while more than one Job may exists for the same Path, it is not recommended to process two Jobs on the same Path at the same time. After choosing which Path to use, create the Job and choose if SQL Snapshots will be used as well as which portion, if not all of, the source Site Collection will be deployed to the destination.
Also, if content will be deployed on a regular schedule, this can also be configured as needed. The default is once a day. Jobs are also dependent on the Change Log settings, which defaults to 60 days, so any content that is not deployed within this timeframe will not update the destination properly, so this may have to be adjusted appropriately.
4) Test and run the Deployment
Once the Job has been created, it can be tested or run in full. Testing will only verify if a connection can be made but will not check an actual deployment. Thus a run of the job will be necessary to ensure that content will be deployed to the destination.
After the content successfully reaches its destination, notice that Content Deployment also rewrote the links for Wiki Pages as well as the inserted links to represent the new URLs of the Destination Web Application. Also, although Content Deployment does not send assemblies and other code through the Job, Web Parts that are supported on the destination, such as the Content Query and Content Editor Web Parts, will deploy to the Destination.
Content Deployment can be applied to our scenario in creating, publishing and deploying our Employee Handbook, although it was not entirely necessary but took advantage of the Publishing features available in the Wiki Sites. Along with working with supportable content such as out of the box Web Parts, the content moved to the Destination for use and security can now be configured to manage this separately from the collaboration Web Application handled internally. Additionally, the use of the SQL Snapshots provides an additional layer of content integrity to ensure that content ready to deploy will not be altered during deployment.
For our Wiki-based solution, we also determined that the new features for a SharePoint 2010 Wiki also supports Web Publishing enough to provide easy content creation and publishing, and with some additional configurations, an even more robust solution for developing and deploying our Employee Handbook.
Overall, a functional solution that can easily be enhanced by many other technologies, but for the purposes of our scenario, an effective solution at this point, and thus brings our examination to a conclusion.
Thanks also to the additional resources mentioned in this article!
In the next post, we will examine a new challenge and solution in our never-ending quest of Solving for Y.
Published: December 19, 2011 11:12 AM by
One of the interesting changes to Wiki Pages and related technologies in SharePoint 2010 is how much more like a Publishing Page Wiki Pages have become. In fact, in SharePoint 2010 they take on more characteristics and features of a Publishing Page since their inception in SharePoint from the previous version. However, they continue to maintain the simple, ad hoc nature of easy web page creation, editing and publishing that they had when they were first created. The growth of a Wiki Page into a Publishing Page, while not entire, has become a benefit for content authors who may still prefer working in simpler, more familiar client environments such as a Business Productivity application. Additionally, content authors can take advantage of the improvements made to make Web Page collaboration another tool in their content generation belt.
Up until this post, we have been examining how we can take the Wiki-based technologies and create a web-based organizational manual that continues to take advantage of collaboration, document management and web publishing. Once our Wiki-based infrastructure was created and put in place, the real work of creating and managing Wiki Pages began. At this point, many of the Web Content Management pieces related to publishing web pages can now be leveraged to enhance the already useful collaboration features we have configured for this scenario. We have discussed the generalities up until this point, and now we can engage in the particulars of the effort.
Creating the Employee Handbook
Once the Subsite has been created, the process for making the manual follows with each library, web page and the content itself:
1) Create the Handbook Structure
Each Wiki Library will store the pages of each Chapter, with each page being a separate Section. Once the Libraries are created, additional configurations such as Required Check Out, Content Approval, and Comprehensive Versioning should be configured to support the drafting and publishing of each page. Additional features such as a Publishing or Approval workflow could be added as well.
The first page of the Library, which is Home.aspx, will become the Chapter Table of Contents that will be written first. Because Wiki Pages use a simple Wiki Link feature that allows the content author to create additional Wiki Pages on click, each Section page will be created by the double bracket method surrounding the Section name. A broken underline will indicate that a page does not exist yet, but upon clicking it a page will be generated. Additionally, by separating the page name and the page title with a simple bar (“|”), the page will automatically be named by the text to the left of the bar, while the link text will be the text to the right of the bar. If there is no need to separate the page name from the page title, such as a simple single word page title, the bar will be unnecessary.
Each Section page can thus be easily generated from the Chapter Table of Contents and quickly create the content needed to populate the Library. Each Chapter Library can generate the base content pages in this similar manner. Once the pages are created, they can be populated with content. Then the standard drafting and approval can manage the content.
2) Create the Section Pages
Now that the Sections Pages are created, additional configurations can be applied to the page, in particular, hyperlinks to create a simple navigation experience for the reader. First, we can configure bookmark links for each Section heading for quick navigation. We can configure this by inserting a normal hyperlink but adding text into the Bookmark field in the Format tab of the Link Tools Ribbon tab. When referencing this bookmark, we need only to add a #bookmarkname tag at the end of the page URL in the Link Tools tab of the Ribbon.
Additional hyperlinks for navigation will be placed at the bottom of the page to provide previous/next navigation, as well as links back to the top of the page and back to the Table of Contents for the Chapter. The links for the previous/next section navigation as well as the navigation to the Table of Contents can be done using Wiki Links, but because we require the precision to return to the top of the page, we need to configure a bookmark link at the top of the Section page. The Wiki Linking technology automatically presents available Wiki Pages in the Site and also allows browsing through other Wiki Libraries to locate specific Wiki Pages as well.
Furthermore, the Table of Contents for the Employee Handbook can also use the Wiki Links to create links for each page once the entire set of Wiki Pages are created.
3) Configure Web Parts
Several Web Parts particular to Web Content Management can be useful here in the Wiki Pages for each Section and Chapter page. In particular, the Content Editor Web Part, the Content Query Web Part, and the Summary Links Web Part.
Content Editor Web Part
One of the benefits of a Wiki Library is a special Quick Launch section called Recently Modified, which displays links to the last five edited pages at the top of the page over the Quick Launch. Unfortunately, the presence of the Recently Modified view disrupts the Chapter Navigation created through modifying the Quick Launch navigation, as well as displays the Page Names rather than the Page Titles. This is a known issue and is easily solved through a small bit of code linked to a Content Query Web Part to hide the Recently Modified view. The specifics can be reviewed here, and the code can be placed in a text file and stored in the Style Library of the Top-Level Site and linked to the Content Editor Web Part. Because this issue will repeat itself on every Wiki Page, we can export a configured Content Editor Web Part and add it to the Site Collection Web Part Gallery, making the adding of the Web Part per page easier.
Content Query Web Part
The function of the Content Query Web Part allows content from various locations throughout a Site Collection to be viewed and thus present the content in an aggregate view. The Web Part can be configured through the browser to focus on a specific level in the Site Hierarchy as well as configure how the content will be presented through the Web Part. To display a navigation scheme for each Chapter and Section, Site Columns for both Chapter and Section as well as Chapter Name and Section Name will be attached to the Chapter Libraries. The Query is adjusted to focus only on the Employee Handbook Subsite, but the Filter is configured to show only the items in a specific Chapter and grouped by Section. The Presentation is configured as preferred.
Summary Links Web Part
The Summary Links Web Part provides a contained group of hyperlinks that are not bound to a source list like a Links List. Many of the Presentation configurations found through other Web Content Management publishing features are also found in this Web Part as well. This Web Part can be configured to link to Chapters, Sections or, in the Top-Level Site of the HR Site, it can act as a link highlight for manuals and other important resources.
As we see here, the content authoring process can be enhanced to complete our organizational manual scenario. Along with the Web Content Management publishing features, such as the three mentioned Web Parts, the Wiki Libraries create the foundation for the Employee Handbook building process. This simple collaborative structure joined with web publishing provides a functional system for developing the content and thus our content development system has everything it needs to be simple, functional and useful.
Because we can take advantage of Web Publishing with Wiki Sites as well, in the last post in this series we will examine how Content Deployment can be leveraged for an authoring and publishing infrastructure.
Published: December 08, 2011 20:12 PM by
We are in the middle of an examination of using Wiki-based collaboration features to create a functional organization manual. In this scenario, we are creating an Employee Handbook for Human Resources entirely in a Wiki-based solution. In my first post, we examined Wiki-based features such as Sites, Libraries and Pages, as well as comparing and contrasting Wiki Pages from other types of SharePoint web pages. In my second post, we examined the logical structure that would be assembled and configured to support our manual, as well as specific uses applied to each Site Collection, Site, Library and Page. Here in the third post, we will continue this discussion, focusing on how the structures within the Web Application can enhance the Wiki-based manual and other related sites.
Content: Top-Level Site of Department
In our Employee Handbook scenario, we placed the manual under the HR Site Collection and had the Employee Handbook created as its own subsite, populated with Wiki Libraries representing the chapters of the manual. The Top-Level Site, however, would not be the storage location for any of the manuals in Wiki format. The main reason we separated the manual in its own site was:
- To take advantage of automatic and controlled navigation
- To managed each chapter as a separate set of documents
- To separate security control per manual
- To separate collaboration work from other manuals
The benefits would create a simple package while still taking advantage of several areas, including:
- Site Collection features useful for the Wiki-based publishing
- Workflows, Content Types and Web Parts
- Automatic security isolation from other departments
- Centralized collaboration work and tools
- Centralized navigation for other manuals in the department
- SharePoint context-level search for the Site Collection manuals
The above reasons are generally the application of the Top-Level Site architecture used here, so that other, less manual-specific tools and functions can be separated from the manual collaboration and viewing itself. Thus, to enhance our department-driven Site Collection collaboration, we would create in the Top-Level Site:
- A Wiki Library for an FAQ as well as general guidelines and tips for collaboration
- A discussion board for a departmental forum for ideas and changes
- A commentary page for the departmental information
- Navigation tools for all manuals in the department
- A centralized Style Library, Document Library and Image Library
- A master forms and printing manual library for printing the entire manual and forms related to the manual
- A change update announcements list to broadcast important changes
- A help and guidance guide for specific manuals and how to access, use, search and print documentation
Interactive sections, such as an update and announcements summary page, as well as a simple comment wall for exchanges and feedback, can also provide additional functionality for the site.
We can construct this Top-Level Site as an application focused on making access to these manuals much simpler, more streamlined and consistent, and still provide additional tools and resources for the manual creators to generate, update and publish the manuals as needed.
Configurations for Top-Level Site:
- Controlling Global Navigation to hide all manual subsites to prevent overcrowding
- Controlling Current Navigation to display important libraries such as forms, how-to’s and references
- Creating Site Columns for Chapter and Section metadata on the content Wiki pages
- Activating the Publishing Infrastructure feature to take advantage of Look and Feel controls
- Limiting the Site Template and Page Layout templates for manual subsites
- SharePoint Groups to represent Manual Creators either by manual or by role
- Navigation tool for viewing and accessing manual content subsites
Content: Top-Level Site of Documentation Site Collections
For the Top-Level Site of the entire Wiki Documentation Web Application, the Site acts more like a resource center as well as a navigation tool for accessing individual department Site Collections, or specific Manuals of high interest. While there may be additional subsites beneath the Top-Level site to control resources, a single site holding all the necessary content in Document and Asset Libraries would suffice for our need. Since the majority of the content will be outside of this Site Collection, many of the external hyperlink references will be done using standard hyperlink inserts instead of Wiki Links.
Standard Resources may include:
- An Organization Style Guide for specifics when creating documentation
- Legal information to be included or considered when developing content
- Organizational Chart and Job Role or Job Description Information
- Master Templates and Forms used for the organization
- Employee Directory and other contact information
Configurations for Root Top-Level Site:
- Modify Current Navigation to represent key resources and content
- Use content targeting to control access to Resources
- Define centralized libraries for organizational guides and tools
- Define centralized libraries for templates and masters
- Provide access matrix, legal information and other organizational references
The two Top-Level Sites – the Root Site Collection and the Departmental Site Collection – offers many communication and collaboration options that can grow from simply being Enterprise Wikis, but can also be used as Team Sites. However, the Root Top-Level Site requires much less configuration and dependency on the Enterprise Wiki while the Departmental Site Collection benefits from Wikis for additional FAQ and Guidance documentation while limiting the need for a complete Team Site in this scenario. Thus it would seem that using Enterprise Wikis can still be a great benefit and also provide the degree and flexibility of control needed to complete our organizational manuals.
Now that our infrastructure is in place, the specific work on the Wiki Pages can be handled. In my next post, we will examine how the Wiki Pages and Web Content can come together to provide a sensible and useful content generation tool.
Published: November 27, 2011 18:11 PM by
In my previous post, we discussed the Wiki as a method of creating documentation, such as organizational manuals, for functional and simple content collaboration and creation through the web-based features already built into SharePoint. We also examined how Wiki Pages, as opposed to Web Part Pages or Publishing Pages, would provide the optimal mix of publishing and collaboration that would meet the needs of creating content through web pages and in turn making that content available to the organization as a whole. Our goal is to create a publishing Wiki system relying on the Wiki-based features and possibly leveraging other related technologies. In this post, we will examine how we can deploy Sites and Site Collections to support our Wiki-based publishing infrastructure.
It is not the logical infrastructure – the Web Applications, Site Collections and Sites – that complicates the solution, as the creation and configuration of these objects are not where the challenges lie, but rather the features and limitations of the Wiki Sites, Libraries and Pages to meet the need of the goal. Therefore, discussion of those particulars will be limited.
Our infrastructure will be simple to begin: one Web Application hosting at least two Site Collections, one Site Collection for the specific department and related manual, and one Site Collection for general information, navigation, and other resources. We will begin our focus on the departmental Site Collection and the individual manual site. Within the manual site, a default Table of Contents page will be created and each chapter will be isolated to a Wiki Library.
Creating the Structure
1) Create the Wiki Web Application
Nothing of particular challenge in this stage; we choose the host header name and set DNS entries, then create at least one Content Database for either the entirety of the Wiki content or different databases for each Site Collection. This would provide support for restoring the Wiki-based content separate from other content, as well as support individual manuals by department if each divisional Site Collection has been placed in its own database. It would also be a good idea to generate a wildcard inclusion managed path to separate the naming for the content as well.
2) Create the Wiki Site Collections
We create at least two Site Collections, one at the root and additional ones under our wildcard inclusion managed path, such as /dept in case additional needs may arise that will create other manuals for different reasons. The root Site Collection will act as the main navigation point and hold collected resources and tools for everyone generating content within the Wiki Site Collections. This will not contain any of the Wiki-based manuals.
The additional Site Collections will represent different departments generating the content, although they could easily be divided up into purposes, locations or any organizational division appropriate to the business. The key decision will be who should control access for publishing and reading the content, and represent that control appropriately. The Top-Level site of the specific Site Collection will provide navigation, resources and other tools for all related manuals in this particular Site Collection.
Regardless of organizational divisions, every Site Collection Top-Level Site will use the Enterprise Wiki Site Template.
3) Create the Wiki Subsites
Since we will be building an Employee Manual, we will place this site within an HR Site Collection as a subsite as this manual is typically generated by HR. By separating the entire manual into its own site, we can control individual chapters by Wiki Libraries and each section will be a Wiki Page within the appropriate chapter Wiki Library. This will provide a quick and simple navigation control for our sections within the chapter, and also for each chapter for the manual.
When the subsite for our manual is created from the Enterprise Wiki Site Template, a default library called Pages will be created. This Library, although associated with the default Wiki Pages normally generated when a Wiki Library is created, is actually a publishing page library with the Enterprise Wiki Page Publishing Page attached to it as well as a Project Page and Redirect Page. This default library will be used to hold the Table of Contents page for the entire manual, plus additional pages such as a How-To-Use guide and other tools and information.
Because we created separate Site Collections to divide management for the manuals, as we create new manuals we can create additional subsites to represent each manual. This also allows manual-specific control over the content through Site-Based security, and if the security requires such, a manual-based Site that is shared by more than one department can be made in a different Site Collection to represent this control.
Additional resource libraries, such as storage for forms, printable documents, collaboration resources and tools, will be generated either at the subsite level or at the Top-Level site, depending on how globally available these resources need to be.
4) Create the Wiki Libraries
For each chapter, we create a Wiki Library. This will automatically generate the Home.aspx and "How To Use This Wiki".aspx pages. The Home.aspx page automatically created will become the Chapter Table of Contents, and each section will be created as a Wiki Page as needed. We should keep the How To page for additional reference and instruction on collaborating through Wikis, although this information may also be consolidated into a User Guide for the manual.
There is no need to create additional Wiki Libraries in subsites beyond the required chapter, but the Top-Level Site in the Site Collection may have additional Wiki Libraries, including ones related to using and navigating content.
Naming Conventions for each Library should represent the organization naming, but the Title properties can reflect the individual chapter titles as well. This will provide a fast and easy way to generate navigation in the Quick Launch bar based on the chapters, but the generation of the Table of Contents will be handled differently.
5) Create the Wiki Pages
Since each Wiki Library will be a chapter, each Wiki Page in the Wiki Library will represent sections. This structure will also support multi-tiered structures that have many subsections per section but keep all related section information on the same page. Navigation within a section page presents additional configuration requirements.
Naming Conventions should also be applied as they are for the chapter libraries. Page names will be simpler and use text/HTML in the document itself to represent the complex naming, such as the section and subsection divisions and names. Unlike the chapter Libraries however, the order of pages will be controlled by views in some cases for navigation.
We find that our logical infrastructure is quite simple and no additional configurations per Site Collection, Site, Library or Page has been discussed. However, the need to configure our infrastructure further is certainly evident, as such things as navigation, version control, content approval and other web content management features. Also, the focus thus far has been on the Employee Manual subsite and its content, but attention to the divisional/departmental Top-Level Site and the root Site Collection must also be given to create a more usable structure since this will not be an additional Site Collection attached to the standard collaboration Web Application.
Object in the Architecture
Purpose for Division
Site Collection by Department/Division
Separates Ownership of Content by natural boundaries
Creates Shareable Ownership of Content
Supports individual backup/restore for Content
Top-Level Site of Site Collection Department/Division
Creates central navigation for all manuals in Site Collection
Provides centralized tools for all manual subsites
Contains additional, non-Wiki content (forms, tracking, discussions)
Controls shared resources (templates, web parts)
Pages Library in Manual Subsite
Controls Table of Contents for All Manuals
Subsite in Department/Division Site Collection
Represents each different manual for separated management
Organizes sections of manual into simpler groups
Creates simple navigation management for content
Library in Manual Subsite
Separates Manual Chapters
Creates automatic navigation
Separates Management of individual Chapters
Pages Library in Manual Subsite
Controls Table of Contents for Manual Chapters
Provides additional content related to manual (how-to's)
Pages in Chapter Libraries
Separates Chapter Sections
Supports Subsections in each Section
Within the manual subsite there will be additional configurations that will be set to take advantage of the collaboration features along with the Wiki features for SharePoint. Wiki Libraries normally use Simple Versioning since the changes to the Wiki pages would all be major ones. However, for drafting and approval control, the Wiki Libraries will have additional settings, including:
- Enforced Check-Out for editing control
- Comprehensive Versioning for drafting
- Draft Item Security set for Approve to limit change visibility
- Content Approval to control publishing
- Custom metadata to indicate Chapter and Section
- Custom Views to sort and show content based on Chapters, Sections, or other metadata
Wiki Libraries also suffer from some specific limitations to make using the collaboration features a bit simpler, such as not using folders, not allowing list templates and not allowing the attaching of or displaying content types. With SharePoint 2010, such limitations also include limiting custom columns from being displayed on the web page. However, the custom columns can be used in other ways, as we will discuss later.
Also, changes made to the navigation displays such as through the Quick Launch or Wiki Pages will also need to be configured.
Understandably, there is a higher level of complexity that simply creating an Enterprise Wiki site with numerous Wiki Libraries. Most of these additional configurations do not have to be applied although they will support a publishing system for the Wiki Pages. For the Employee Handbook manual subsite, the logical architecture along with the collaboration settings and Wiki-based features would be enough. But to continue to make the infrastructure useful, additional roles related to the Site Collections and Top-Level Sites also need to be defined.
In my next post, we will discuss the roles they play and how they can augment what we have already built.