New in SharePoint 2013, Community Sites provide forums for people to ask and answer questions, post information, comment on posts, and be rewarded for their efforts in the form of points, earned badges, and gifted badges. Those familiar with the Microsoft forums should see many similarities. Much of the functionality in those forums has been built into the SharePoint Communities Sites. Additional components found in social networks, such as “liking” a post, are also included. This set of functionality can be extremely powerful in encouraging the sharing of knowledge and contributing of content. It’s also most effective when the forum aligns with real business goals; building a community site just for the sake of trying to encourage social computing doesn’t use communities effectively and will most likely fail.

You can add community features to an existing site, but a Community Site template is available. Discussion lists and the community features also have a bit of overlap. Therefore, SharePoint 2013 users have the following three options for community features:

The choice depends on the business needs, but if your organization needs a center of knowledge sharing, a community site is typically the way to go. If an existing site needs the Community Sites features, you can turn them on by following these steps:

Figure 2-1. Activating the Community Site feature

Enabling the Community Sites feature creates lists, creates pages, and shows Web Parts that work with the community features:

These items are available if the feature is turned on at the site level of an existing site or if a new site is created with the Community Site template. A community site has all the functionality of a normal SharePoint 2013 site, such as document management, versioning, permissions, auditing, and so on. The preceding items allow for an interactive forum experience, but some dependencies exist for an even more enhanced experience. The optional service applications of the SharePoint 2013 farm that provide additional functionality are as follows:

The types of members for a site can be broken down into four different types: owner, moderator, contributor, and visitor. Typically, forums are open for contributions from all members, but in some situations only a certain group of users can contribute to a forum but a larger audience can view the contributions. A specialized help desk might be an example of this, where only members of the technology team can contribute.

Moderators are the key set of users in a community site. They serve as the site’s shepherds. They can create and delete categories, edit and delete posts, mark replies as “best replies,” and configure reputation settings. They are also responsible for monitoring content, if that is enabled. (Of course, they can manually monitor it, but allowing the community to report offensive content is much more effective.) To enable monitoring of offensive content, follow these steps:

Now, all moderators receive email when a user identifies a post or reply as offensive. Having users report offensive content is considered a best practice because it minimizes the amount of time moderators have to keep an eye on the content.

On the same page as Enable Reporting Of Offensive Content is a setting called Established Date. This date is shown on the About Page and can be used for sites created before the Community Site template existed. With this setting, users can see how long content has been contributed.

Anyone who has created a blog site should be familiar with the categories, and the idea is the same with Community Sites. Part of the planning process should involve creating categories appropriate for the site. Correct categories help visitors find the information quickly and efficiently.

The My Sites feature has changed a lot between SharePoint 2010 and SharePoint 2013. The two most notable places of change are the look and feel as well as the addition of the SkyDrive, which has replaced the individual content area. The two main areas of My Sites are still the My Site host and the individual site collections. The interaction between Microsoft Office 2013 and the site collections (accessed by clicking SkyDrive from anywhere within SharePoint) will most likely lead to a much higher usage of the site collections and therefore require a greater degree of planning. Planning for the My Site host and for the SkyDrive locations should be done separately and is addressed that way in this section.

Social permissions are set in several places within the SharePoint environment. Proper planning helps enable those users who need the social components as well as keep those users who don’t (such as temporary employees or contractors, depending on the organization’s needs) from using the social components. Most social permissions are driven by political agendas instead of performance reasons, but you need to take some performance considerations into account.

Social data is stored and indexed for searching, which consumes resources. SkyDrive could also take up considerable resources and can be limited by allowing only the users that need it through permissions. Audiences also come under social permissions. Although they don’t prohibit users from accessing files, they can be used to change what is shown to users and to route them to their home My Site host.

Social permissions

Social components require that users have specific permissions. Three distinct permissions are controlled in the User Profile Service Application area. The following permissions are accessed under the Manage User Permissions link of the People section:

• Create Personal Site (required for personal storage, newsfeed, and followed content)

• Follow People and Edit Profile

• Use Tag and Notes

Users need all three permissions to be able to fully access all the social components of SharePoint 2013. Typically, the group of NT AuthorityAuthenticated Users is added by default. Permissions assigned in the Manage User Permissions dialog box are additive. For example, if a user doesn’t have the Use Tag and Notes permissions but Authenticated Users has the Use Tag and Notes permissions, they still have those rights. If you want to prohibit users from using the social features, the default user groups have to be removed, and the groups that need social permissions have to be added. In some situations, a social permission needs to be removed entirely; for example, if an organization decides that it doesn’t want users to be able to use tags and notes, it removes them in the Permissions For User Profile Service Application dialog box (see Figure 2-6).

Figure 2-6. Permissions for User Profile Service Application dialog box

By using these permission levels, you can limit social components to just the users that need them. You also can phase in social features as training and political concerns allow.

Some changes have been made in the permissions of user profile properties in SharePoint 2013. SharePoint 2010 had four levels of permissions for profile properties, but SharePoint 2013 has only two: Everyone and Just Me. The reduction in the number of options available was an effort to streamline the choices available to the end user. If a profile property has its permissions set to editable, users are limited to just two choices. With any social network, the easier something is for users to use, the more likely they are to use it. To modify the permissions for a user profile property, follow these steps:

1. Navigate to Central Administration and click Manage Service Applications under Application Management.

2. Click User Profile Service Application.

3. Click Manage User Properties under the People section.

4. Choose the property that needs to be modified and click it. From the drop-down list, select Edit.

5. In the Policy Setting section, set the Default Privacy Setting.

6. Click OK to save the changes.

Some properties, such as First Name, can’t be altered, but any added field can be changed. The choice of which properties are available to everyone is driven by the organization’s political concerns. For example, an employee ID might be brought in through Active Directory that should be visible only to the employee. This employee ID can then be used to populate fields and even be used for single sign-on (SSO) solutions based on such an ID.

User profiles are the crucial component for social components. Getting user profiles populated is one of the key components in setting up a SharePoint farm. Importing these user profiles from Active Directory (AD) is similar to the way SharePoint 2010 populated profiles. It’s still not a trivial task, however. For SharePoint to use profiles that it pulls from AD, the User Profile service needs to be started, a User Profile service application needs to be created, and then the User Profile Synchronization service needs to be started. When the User Profile service starts, you need to create a User Profile service application. Three databases associated with this service application are created when the User Profile service application is created:

You can use the Configuration Wizard to create the User Profile service application, but creating it manually or via a script is the better way to go. This way, you can name the databases rather than let SharePoint name them with a GUID. It also allows for greater control over the options, such as specifying a My Site host location, selecting which application pool to use, and identifying a failover database server.

Before creating the User Profile service application, you should create the My Site host. Doing so isn’t essential, but it does save some time by creating the managed path for you. Follow these steps:

The second part of setting up user profiles involves importing profiles from a source such as Active Directory. You first need to start the User Profile Synchronization service, but before you do that, you need to make sure that the Forefront Identity Manager (FIM) services are correctly configured. Two FIM services are necessary for the User Profile service spplication to run:

Both services are disabled by default when SharePoint is installed. SharePoint enables them and configures the account associated with them when the User Profile Synchronization service is started.

Properly setting up the FIM service account is important. If the User Profile Synchronization service is started before the FIM services are configured, you might need to restart the computer before it can be provisioned correctly. The User Profile service also needs to be running. After the User Profile service and FIM services are configured, you can start the User Profile Synchronization service as follows:

After the User Profile Synchronization service starts, you need to configure a connection to pull in profiles from AD. Before you can do so, however, you need to choose or create an account that will be used to communicate with between SharePoint and AD. This account needs special privileges in AD—specifically, it needs the Replicating Directory Changes permission. If the account doesn’t have this level of permissions, the synchronization still starts, but changes in AD aren’t reflected in the user profiles. This permission must be granted on a domain controller using the Active Directory User and Computers tool under the Administrative Tools section of the Start menu.

If you need to export changes in a user’s profile to AD, the synchronization account also needs Grant Create Child Objects and Write permissions to the organizational unit (OU) being synchronized with user profiles. One of the most common examples of when this would be needed is when My Site photos are used to populate Outlook and Lync via the thumbnailPhoto field in AD. That way, a single source of photos can be used for all three programs, plus any other program that can pull data from AD. Planning for the synchronization is discussed later in the Planning connections section.

SharePoint 2013 has several items that can appear in the Activity Feed. Users can follow users, tags, sites, and conversations. Users can also post on a user’s site or mention them in posts, which causes an item to appear in their activity feed. Two significant changes reflect the influence of social networks on SharePoint. The first is the mention. You can put an “at” sign (@) in front of a person’s name to make the post appear in the person’s newsfeed. The second one is the hash tag (#), which a user can put in front of a word in a post. Putting the hash sign in front creates a tag that users can follow. If a user is following that word, the post appears in that person’s newsfeed. For example, if a user posts something about SharePoint and another user is following the keyword SharePoint, they see that on their newsfeed, as shown in Figure 2-8.

Figure 2-8. Using a hash tag to indicate a keyword and the option to follow the keyword

Following keywords is made even easier by a link that appears at the top of a conversation with the keyword associated with the word Follow. Because following keywords is so easy, you can expect a large increase in the number of tags followed. Tags are indexed and can be searched on. All this activity increases the load on the SharePoint server and needs to be taken into account when designing the farm.

The Outlook Social connector also shows the activity for individuals. These feeds are pulled from SharePoint periodically and stored in Outlook, requiring both memory and CPU resources. The number of people using the Outlook Social connector will vary depending on the organization, but this should factor into preparing for the load on the SharePoint server.

The number of profile properties that can be followed and therefore appear in the activity feed affect the resources required and need to be planned out. Also, some properties are excluded from the activity feed for political reasons. For example, in certain organizations, the title of a person can reflect their salary; as a result, an organization might decide that changes in a person’s title only promotes gossip and distracts people from their jobs. Users might also benefit from some profile properties that aren’t set up to be followed. To change whether a profile property appears in the SharePoint 2010-compatible newsfeed, follow these steps:

The number of items that a user follows and the frequency of change in these items determine the load on the activity feed. Although the frequency of change is determined by usage and can’t be easily controlled, you can limit the number of items followed. Users can follow three main items and have their changes appear in their activity feeds:

You can limit each of these items. Changing the number of items that can be followed is a farm-level change and affects all users. Organizations with a large number of users and/or a large farm with many documents and sites might want to limit the number of items that can be followed, as follows:

These limits are fairly high (and already at the maximum) for most people. You can’t increase them, but you might want to lower them to increase the performance of the SharePoint server.

You can access feed information on a user’s My Site. SharePoint 2013 offers several feeds, each with a different set of overall feed data that you can filter so that users can see the most appropriate data:

Distributed Cache allows for fast retrieval of activity-related items across all the components of SharePoint by caching recently accessed items. In fact, Distributed Cache has a dedicated cache referred to as the Feed Cache, whose sole purpose is to store activities and conversations for use by feeds on My Sites. Distributed Cache comes in two modes: Dedicated and Collocated.

Dedicated mode is recommended for the best performance, but it requires a server solely dedicated to being a Distributed Cache server. Collocated is when one or more SharePoint servers are running the Distributed Cache service as well as other services. A server running Distributed Cache in Collocated mode should stop all non-essential services to reduce the competition for memory resources.

Starting the Distributed Cache service on a SharePoint server is fairly straightforward:

Unlike SharePoint 2010, SharePoint Server 2013 can use Distributed Cache to cache the login token. This means that if Network Load Balancing (NLB) is being used, a user won’t lose his login information if he goes from one Web Front End (WFE) to another. In SharePoint 2010, the NLB servers had to be set up to have affinity (where a user would go back to the same WFE). Although this would work, it wasn’t true load balancing. With the login token cache, any WFE that receives a request for resources can access the security token, validate the user, and provide him with the resources requested (assuming that that user has permissions).

The Distributed Cache service is built on Windows Server AppFabric, which implements the AppFabric Caching service. This service must be installed on the Windows Server running SharePoint before it can be used. Luckily, Windows Server AppFabric is one of the prerequisites that must be installed before the SharePoint installation.

After the User Profile service application is created and the User Profile Synchronization service starts, you can use the selected account with sufficient permissions to create synchronization connection to a directory service. This connection needs to pull in just the users who are supposed to have profiles. This means that inactive users, test users, non-human users, and/or non-full-time employees might need to be filtered out.

Every user who needs a profile must have an identity in a directory service. A unique identifier needs to exist that identifies the user (such as the account name in AD) so that the user can be synchronized as a unique person. A directory service doesn’t have to be Active Directory, although this is the most common. Directory services come in three different types:

Claims-based or forms-based authentication requires that a trusted provider be used; with Windows-based authentication, no trusted provider is needed. Several different types of connections can be made to directory services, including these built into SharePoint Server 2013:

Such a varied set of directory services exists in case SharePoint runs in a non-Windows environment or users come from a third-party source. SharePoint Server 2013 is an enterprise solution that needs to work in a wide variety of environments. For purposes of illustration, you need to see how to create a Synchronization Connection with AD as the directory service:

When a synchronization connection is created successfully, you can apply filters. You can use a filter to exclude certain users, such as contractors or temporary employees. Filters can also be used to narrowly define a set of users for a particular connection. For example, if only a subset of users from a specific office location needed profiles, a filter could limit the number of users imported. Most often filters are used to filter out inactive users. Not deleting users from AD in case they return is often a policy, so they can be given the same account that they previously had.

Filters are based on the attributes imported in the synchronization. The set of attributes will vary from organization to organization. To better understand how filters are used, follow these steps to create one:

Now, the only thing left is to create a synchronization schedule. You first need to perform a full import and validate that the correct number of users are returned and that the mapped fields are populated correctly. Typically, a full synchronization isn’t required, but it’s necessary when the connection is first created. To synchronize a profile, follow these steps:

The process might not start immediately, but should start within a minute. The process could take a long time to complete, depending on the number of users and the performance of the server doing the profile synchronization. Full synchronization is a resource-intensive operation and should be done only when absolutely necessary.

After the process completes (check the Profile Synchronization Status on the Manage Profiles Service page to see whether it says Idle), look at the number of user profiles to ensure that they match the expected number.

You can determine a profile synchronization schedule based on business requirements and the capabilities of the SharePoint server running the profile synchronization service. An incremental profile synch isn’t overly taxing on the system and can be run quite often. You might want to consider an incremental synch if changes in Active Directory need to be reflected in SharePoint within a certain time frame.

You can set up an incremental profile synchronization after the connection is verified. Changes can’t be made while the User Profile service is being synchronized; you must wait until the current synchronization process finishes. Incremental synchronization is handled with a timer job created in the SharePoint environment, which you can set up as follows:

Now the profiles should be synchronized with AD regularly. Periodically, you should check individual users to ensure that changes are being replicated.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

Search is at the very core of SharePoint. Users type terms in the search box and expect relevant results to be returned. Although SharePoint does a great job at indexing and querying those results, it still needs some human interaction to help it determine the most relevant results.

Many factors can be used to help determine what results are the most relevant. SharePoint takes into consideration the item that’s searched on and what users click to refine the results that seem the most relevant, but many other factors can be configured so that certain results can be pushed to the top. The following items can be configured to help improve search relevancy:

You can use each of these items to help end users find the results they need as quickly as possible so that they can spend more time doing their job and less time searching for the data. This section covers how to configure and plan for increasing search result relevance using the items in the preceding list.

Key,Synonym,Language
SharePoint 2013, SharePoint Server 2013, en
SharePoint 2013, SP2013, en

Key, Display form
Expert, Contoso Expert
Contoso, Contoso Expert

Whenever a document is added, it doesn’t appear in the search results until it’s crawled and indexed. The same is true with document changes: They don’t appear until the content source is crawled. The more often a content source is crawled, the more up to date the results will be. SharePoint 2013 now includes an option to continuously crawl a content source. Of course, crawling continuously is a resource-intensive task, and the server or servers doing the crawling need to be up to the task.

Continuous crawling is started at 15 minute intervals by default. This interval can be changed using PowerShell. Before continuous crawling can be used, it must be enabled according to content-source level (applicable only to the SharePoint sites’ content-source type). To enable continuous crawling, follow these steps:

Enabling continuous crawling means that search results can appear before a crawl is completed because adding a document starts a new crawl that might finish before the first crawl. A user can add a document and have it appear in the search results within seconds of it being added, which can greatly improve the end-user experience and help users find the most current information as soon as possible. The only thing to consider is the amount of resources consumed by the search server. For large content source and limited search server resources, enabling continuous crawling might not be an option. After continuous crawling is enabled, the server should be monitored to see how memory and CPU resources are affected.

Result sources help limit crawls to subsets of the SharePoint farm. They have replaced the scopes used in previous SharePoint versions. Correctly configuring the result sources can help maximize the efficiency of the search servers.

SharePoint’s default result source is Local SharePoint Results, which is set up for you when you create the Search service application. Whenever a Search Driven Content Web Part is added to a page, it uses the default result source. If business rules specify that a specific result source is used, you can change the default at the Search service application level, the site collection level, and the site level. To change the default result source at the Search service application level, follow these steps, using an administrator account for the Search service application:

You can create result sources at the farm, site collection, and site levels, but this book focuses only on the farm level. To create or modify result sources at the site collection level, navigate to the site collection settings and click Result Sources in the Site Collection Settings section. To modify or create result sources at the site level, navigate to the site setting and click Result Sources under the Site Settings section.

To create a new result source at the farm level, follow these steps, using an administrator account for the Search service application:

Result sources enable you to bring a variety of different search results into the SharePoint search experience, so that users can use SharePoint as a single source for all their search needs. However, you still need to plan out the result sources.

Gone is the ability to create scopes and have them appear in the drop-down list next to the search box (although migrated scopes will still be usable). Users now click the result scope they want to use. The result scopes shown on a search page are configured on the page from the result scopes that have been made available. For example, on the Enterprise Search results page, the default result sources of Everything, People, Conversations, and Videos are listed below the search box (see Figure 2-10).

Figure 2-10. Result types shown right below the search box on the Enterprise Search Center results page

The result sources are listed in a Search Navigation Web Part (the result types shown under the search box are actually just links to pages configured to display a particular result source by changing the query values of the Search Results Web Part). Clicking one of the result types changes what appears in the search results box connected to the Search Navigation Web Part. The displayed result sources are determined by the search settings, not by the Search Navigation Web Part. To modify the result sources, follow these steps:

Figure 2-11. Configure Search Navigation section of Search Settings

Before adding new links, you have to create the pages. The Search Results Web Part is where you choose the result source, but you can configure many other query options. You don’t need to know how to configure each of these options for the test, but you should have a general understanding of the options available. Some options that you can configure (by clicking Change Query in the Search Results Web Part settings) are as follows:

As you can tell by the number of options, the ability to configure the search results has been greatly expanded. A high degree of customization can mean the results will take a while to be fully returned. In such cases, asynchronous loading would provide a more user-friendly experience.

SharePoint 2013 has completely revamped the way search results appear. In SharePoint 2010, designers had to work with a huge XSLT file to modify the results. Now designers can target individual types of items and have them display differently, with specific metadata displayed and HTML that can be modified to show links and/or graphics in addition to the content. You can modify each item type in distinct files rather than modify the whole XSLT file. This way, multiple developers can work independently, potentially speeding up development as a result. SharePoint 2013 also uses query rules to alter the results being returned. This can be used to promote certain content or to change the result set based on the query entered.

You can use all these items together to provide a richer and better targeted search experience. They can even be used to provide a different result set for different individuals. For example, engineers could have different search result experiences than contractors.

This section covers how to use query rules, display templates, and result types to configure the search experience (result sources were covered in the previous section). Going through each of these, even if you aren’t the person having the search experience, will help you both on the exam and in understanding the architecture behind them.

Query rules

Query rules are used to change what’s returned in a search result set. You can use query rules to promote certain results, show additional results, and fine-tune rankings. A query rule is made up of conditions, actions, and publishing. These three components combine to make a rule that determines the content of the search results for a specified amount of time.

To get a better understanding of query results, you should start by creating one. You can set query results at the Search service application level, the site collection level, and the site level. At the Search service application level, you can add or modify query rules as follows:

1. In Central Administration, click Manage Service Applications in the Application Management section.

2. Click the Search service application to open the Search Administration page (or click the list of Search service applications).

3. In the Queries And Results section, click Query Rules to open the Manage Query Rules page (see Figure 2-12).

Figure 2-12. The Manage Query Rules page in Search Administration

The first step in building a query rule is to determine what the conditions are. Not enough room is available to go over all of them, but here are some examples of possible conditions. First, look at some of the possible results sources:

• All Sources

• Wiki

• Documents

• Pages

• Local People Results

After you choose a result source, you need to select a user segment and a topic category. Then you can create a query rule for the context by clicking New Query Rule. You can then configure the rule by following these steps:

1. Type a name for the rule in the Rule Name text box (the context will show under the box).

2. In the Context section, choose one of the following possible query conditions from the drop-down list:

   • Query Matches Keyword Exactly

   • Query Contains Action Term

   • Query Matches Dictionary Exactly

   • Query More Common in Source

   • Result Type Commonly Clicked

   • Advanced Query Text Match

3. Depending on which query condition is chosen, you can fill in options, such as providing the text for Query Matches Keyword Exactly.

4. Continue adding conditions by clicking Add Alternate Condition, if you want.

5. Choose which action to take:

   • Add Promoted Result

   • Add Result Block

   • Change ranked results by changing the query

6. In the Publishing section, choose when to make the query rule active or inactive by selecting a Start Date and End Date. You also can choose to review the rule on a certain date by setting the Review Date and entering a Contact.

7. Click Save to save the changes.

Back on the Manage Query Rules page, you can test a query by typing some text in the Find Rules That Fire For A Query text box. You can also sort the queries by different types, such as inactive rules, thus simplifying the task of finding and modifying the query rules. Adding a query rule doesn’t make it take effect right away, but you can still test it immediately. You can use the same steps at the site collection and at the site level for targeted query results.

A search schema is composed of managed property mappings and managed property settings. Managed properties determine what’s indexed and therefore available in the search results and for refiners. The content and metadata of a document or a list item is referred to as crawled properties. For crawled properties to be included in the search index, you must map the crawled property to a managed property. Only managed properties are written to the index and therefore available to be searched on.

You can map multiple crawled properties to a managed property. For example, you can map both Office and Location to the managed property Office. Therefore, when a user types Office:Seattle, it returns results for documents or lists with either the Office or Location property populated with the word Seattle. If a document or list item contains the Office and Location properties, the first property that the Search service encounters is used to populate the Office managed property. A crawled property can also be mapped to more than one managed property.

Some crawled property types generate a new managed property and mapping between the crawled and managed property. Whenever a site column is generated on a list or document library, a crawled property, a managed property, and the mapping between the two is automatically generated. Search application administrators can change the default mappings or create new ones. However, any changes to the default mappings require a full crawl of the content to take effect.

Multiple search schemas can exist. The main search schema is maintained in Central Administration in the Search service application. However, you can modify search schemas at the site collection and tenant levels. This means that site collection owners can manage the search experience at the site collection level by modifying the search schema. Site owners can view the search schema but can’t modify it.

The search index is composed of a set of files in a set of folders on the search servers that have the index component on them. The content processing component processes crawled properties and stores the mapping information in the index. A variety of indexes can be queried. Whenever an item is changed, it must be reindexed after it’s crawled. To reduce the reindexing load, SharePoint 2013 has introduced new index update groups:

The default full-text index contains the contents of the managed properties. All searchable text is saved into the index. The full-text index is divided into weight groups that determine the importance of a managed property. The relevance ranking model determines what content is the most important and therefore appears higher in the search results. Two main full-text indexes exist (other than the default full-text index): one for SharePoint content and one for people-related content.

Because all the data that exists in the indexes is based on managed properties and how a crawled property is mapped to a managed property, you should go over how these are added to the Search service application. To add a managed property, follow these steps, using an account with administrative rights to the Search service application:

If you want to change the mappings, you can edit managed properties in the same area they are created. If you want to change the name, you can create a new one and, if necessary, delete the old one (if it’s not in use, it can be changed safely).

Use caution when deleting a managed property. Users can no longer run queries using the property, any query rules based on that property will no longer work, and it will break any custom search applications or Web Parts that use the property. If you’re not sure whether it’s used, don’t delete it until you can find out.

Now that you’ve created a managed property, you can attach crawled properties to it. Again, just because a property is crawled doesn’t mean it’s searchable. It must be mapped to a managed property and/or included in the full-text index. To map this property, follow these steps, using an account with administrative rights:

Each crawled property has a category. Categories help organize the crawled properties so that they’re easier to find and group, but they also provide a way to modify all the crawled properties in a category at the same time. For example, all the crawled properties in the Basic category could be set to Searchable. To view or edit property categories, follow these steps, using an account with administrative rights:

Changes made to a category affect all the crawled properties in that category. Therefore, choose these settings carefully because they can have unintended consequences on items in the search index.

Search analytics are important because they let users know how Search is being used and therefore how it can be modified to help users find what they want more efficiently. The analytics processing component analyzes crawled items and how users interact with Search. This is referred to as search analytics, which you can use to determine which items are searched on most often, how many times no results appear, and what users end up clicking. The analytics architecture consists of three main parts:

The Analytic Processing Component runs two different types of analyses: search analytics, which analyzes how content is crawled and added to the search index, and usage analytics, which analyzes user actions such as clicked or viewed items.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

Channels are part of the publishing infrastructure of SharePoint 2013 and are configured for particular device types. For example, you might have a channel for laptops, one for tablets, and one for mobile devices. SharePoint 2013 uses user agent strings that the browser provides to determine which channel to use. Depending on the channel, SharePoint can provide different master pages and CSS files designed specifically for the device being used. This allows web content providers to provide content that crosses a variety of different devices. (However, this doesn’t mean that content doesn’t have to be tested on the target devices.)

To create a channel within a site collection, click the Device Channels link in the Look And Feel section of the Site Settings page. Optionally, you can use the Design Manager. A default channel is already part of the site collection; if a browser doesn’t meet any specific channels, it will use the default one. A channel is defined by five properties:

Each site is limited to 10 channels (for on-premises installations). The order in which these channels occur can affect what channel is applied to what device. The more specific rules need to be above the general ones because the rules are processed in the order that they occur. For example, if a channel for a Windows 7.0 Phone operating system was below a channel for all Windows Phones, the Windows 7.0 Phone operating system channel would never be used. You can order device channels by following these steps:

After you create a channel, you need to associate a master page with it via the Site Master Page Settings. You can use the same master page for multiple channels. Channels can use a master page only if an approved version of the master page is available.

You can use device panels to display specific content on a particular device channel or set of channels. Doing so is particularly useful for trimming content for smaller devices such as mobile phones. Rather than use Cascading Style Sheets (CSS) to hide or alter content, you can use the device panels to prevent any rending of content, thus saving on resources, which can be of particular interest for users with limited bandwidth or bandwidth quotas. Typically, content that requires many resources—memory, CPU, bandwidth—is constrained to desktops and/or tablets.

SharePoint 2013 allows for any library or list to be designated as a catalog. This way, the list or library can be reused among publishing sites. Creating a catalog is easier by first creating a product catalog site collection via the Product Catalog template, which is part of the Publishing group. The Product Catalog templates aids in the creation of catalog items and topic pages (pages automatically created for catalog items). This site collection is created just like any other site collection in Central Administration. After it’s created, you need to customize it for it to be a useful catalog. The Product Catalog template is part of SharePoint 2013 Enterprise Edition and isn’t available in the Standard edition.

Product catalogs

After you create the site collection, you can find several options that can help guide you through creating a product catalog. The welcome page shown in Figure 2-14 lists the steps basically in order.

Figure 2-14. Home page of a product catalog site collection

Creating site columns

You first create site columns. You can use existing site columns, but you probably want to create some additional that are specific to the products in the catalog (such as make and model columns, if the products are cars). After all the site columns that describe the product are created, you can add them to the Product content type. (You can always add or remove site columns, but getting the catalog as close to final as possible is best because additional site columns can affect how the product is displayed.)

Managing site content types

The second step is to modify the Product content type. Click Manage Site Content Types on the welcome page and scroll down to Product on the Site Content Types page. You can also make the changes directly by clicking the Product link in the Manage Site Content Types section. From here, you will add the product-specific site columns as follows:

1. Click the word Product under the Product Catalog Content Types heading.

2. Click Add From Existing Site Columns.

3. Choose the product-specific site columns from the Available Columns drop-down list and then click Add.

4. In the Update List And Site Content Types section, leave Yes selected so that the site columns are added to the product list and the Product with Image content type.

5. Click OK to save.

Important: Modifying the Product content type

The Products list on the product catalog site actually uses the Product with Image content type by default. The Product with Image content type inherits from the Product content type, so you always want to update all content types inheriting from the Product content type to see the changes in the Products list.

Managing Item Hierarchy in Term Store

The third step is to create the product hierarchy. Click the Manage Item Hierarchy In Term Store link (or by going through the site settings). The one you want to modify is under the Site Collection heading, followed by the site name and site catalog). This should have one term set called Product Hierarchy. Under the Product Hierarchy, you can enter an item that’s all inclusive of the products (for example, if the products are cars and trucks, the highest level would be vehicles). Then you enter term sets and subterm sets as applicable. Figure 2-15 shows an example.

Figure 2-15. Example of a Product Hierarchy for a product catalog

Note: Term Store Locations

Rather than use a term store located within the site collection, you should use a term store located at the farm level (one created by going to the Metadata service application in Central Administration rather than the Term Store link under Site Settings). This way, consumers of the product catalog (like with other site collections) don’t need rights to the term store within the product catalog site collection.

Adding Catalog Items

After the categories are entered, they can be chosen when a user adds an item. Items are added by clicking the Products link on the welcome page and then clicking the new item or the plus arrow. The list can also be reached by clicking Add Catalog Items or the Products List link. The Products list has Product with Image as its default content type, but you don’t have to insert an image if one isn’t available. To add an item category, you can click the metadata icon next to the Item Category, or just start typing into the Item Category text box and have SharePoint provide suggestions. By default, the categories term set is closed and it doesn’t allow unknown terms to be entered.

Important: Approval of product list items

By default, items entered into the Products list require approval. Until they are approved, they aren’t visible to end users, aren’t indexed, and don’t appear in the search results.

Modifying Search Properties

The final step listed on the welcome page is the Modify Search Properties section. This reminds the creator(s) of the product catalog that the newly created site columns need to be added to the managed properties within the search schema so that they can be searched on. After this step and a full crawl of the content are performed, the product catalog is ready to be used or consumed. It can be used in the site collection that it exists or it can be consumed by other sites or site collections.

The settings for how the product catalog is to be consumed don’t appear on the welcome page, but they can be found in the Library settings of the list itself. Several settings can be applied to a product catalog and should be planned out ahead of time, depending on how the product catalog will be used, how it will be searched on, and who can edit the items. To modify these settings, follow these steps:

1. Click Products on the welcome page.

2. Click List Settings on the List tab.

3. Click the Catalog Settings link.

4. Choose to enable or disable search indexing by clicking Advanced Settings Page in the Reindex list section (or trigger a full reindexing).

5. Choose whether to share the catalog among other sites and site collections by selecting the Enable This Library As A Catalog check box.

6. Select Enable Anonymous Access if you want users to have anonymous access to the product catalog.

7. Choose which fields will identify the catalog items (unique field or fields that identify unique items) and add them in the Catalog Item URL Fields section.

8. In the Navigation Hierarchy section, choose the column to use for navigation (typically, the Item Categories field).

9. Click OK to save changes.

Note: Catalog properties

If the library isn’t enabled as a catalog, the options for anonymous access, catalog item URL fields, and navigation hierarchy won’t be available.

Using the Catalog

Assuming that you chose to share the product catalog with other sites and site collections, the product catalog can be consumed and displayed. The site collection that contains the product catalog needs to be crawled fully before it can be consumed. This might take a bit of time depending on how the crawl was set up. When the crawl is finished, the product catalog can be consumed. This is done within the site that’s using the product catalog:

1. Navigate to the Site Settings page and click Manage Catalog Connections in the Site Administration section.

2. Click Connect To A Catalog on the Manage Catalog Connections page.

3. Choose or search for the product catalog. When you find it, click Connect.

4. Several options are on the next page, but the only ones that need to be filled in are in the Navigation Hierarchy section. Select the navigation field (for example, Item Category) and then choose the root term. You also want to choose the navigation level (Vehicles in this example), because you can’t choose the Product Hierarchy level.

5. Click OK to save changes.

After a connection is established, SharePoint creates pages on which the catalog can be displayed and the navigation hierarchy used to navigate the product catalog. Several options could have been configured during the connection. Of note is the Catalog Item URL Behavior option, which you can use to make the catalog seem as though it’s part of the consuming site. This is done by making the URLs relative to the consuming site. You also have the option of continuing to point to the source catalog. You even have the option to choose different master pages for the product catalog, but generally you want to use the master page of the consuming site so that it appears that it’s actually one site. Catalog items can be used with variants as well. The language tag is part of the Product content type and can be used to filter product catalog items so that only items that match the browsers language are shown.

Exam Tip

As a new component in the WCM abilities of SharePoint, product catalogs will likely be a source of at least one question on the exam. Key concepts are the use of term store data for navigation and that a product catalog can be consumed by another site or site collection.

Topic pages

You can use topic pages—category pages and catalog item pages—to display content from a metadata-driven term store (like the term store from the product catalog) without having to create a new page for each category or category item. This also allows for automatically created user-friendly URLs (unless that option is turned off). For example, if you used the example product catalog and had it consumed by a site called http://contoso, http://contoso/trucks and http://contoso/trucks/Long-bed would be category pages and http://contoso/trucks/long-bed/2 (a Dodge Ram truck is the second item in the catalog) would be a catalog item page. (Notice the absence of .aspx or .html extensions on the page names.) These pages are created automatically and are based on page layouts that are also created for you. To get to these newly created pages, use the navigation provided by the metadata, which replaces the structural navigation (see Figure 2-16).

Figure 2-16. Example of metadata-driven managed navigation being pulled from a product catalog

You can set up managed navigation without using a product catalog and use it with any term store.

More Info: Managed navigation

See http://msdn.microsoft.com/en-us/library/jj163978(v=office.15).aspx for more information about managed navigation in SharePoint 2013.

Before any data actually appears on the topic pages, the pages must be published. Open the Site Settings page and click Master Pages And Page Layouts in the Web Designer Galleries section. On the Master Page Gallery page, look for the following two pages and publish a major version of them:

• CategoryItem-<Top level Term Store Name>.html

• Category-<Top level Term Store Name>.html

For the example, the files would be CategoryItem-Vehicle.html and Category-Vehicle.html, respectively. If you plan to change these layouts, edit the HTML pages. They are meant to be customized for your product catalog branding needs. If for some reason you want to edit the .aspx page directly, delete the HTML page layouts.

The category page is meant to help users find the products they are looking for. It has a Content Search web part that limits the results to the category and displays links to the catalog items. The catalog item page is meant to display one item as well as display the picture at the top with properties below it. With the navigation and the topic pages created, you are well on your way to designing a complete product catalog suitable for public consumption.

More Info: Cross-site publishing

See http://technet.microsoft.com/en-us/library/jj635883.aspx for an overview on cross-site publishing in SharePoint Server 2013.

Content deployment is broadly defined, but in the context of WCM, this section focuses on cross-site publication, a new feature in SharePoint 2013, and Web Parts such as the Content Search Web Part that you can use to show content from the search index. Cross-site content deployment allows for publishing of site content across sites, site collections, and even farms. This varies from content deployment in SharePoint 2010 in which the entire site had to be deployed using the built-in SharePoint 2010 functionality.

The Content Search Web Part (CSWP) can show content from the search index, allowing content to be shown from other locations within the context of the site on which it’s located. This is much different than using the Content Query Web Part in SharePoint 2010 in that it was confined to the site collection in which it was contained. The CSWP is configured to use a result source, either built-in or created. It can also be used to show results from a published catalog. Some of the default result sources are as follows:

After you choose the result source, you can restrict the returned items to the current site, the current site collection, or a URL, or you can leave it unrestricted, in which case it brings back everything from that result source. If no result source matches your needs, you can build a query from scratch. This is very similar to creating a result source. Considering this, you have a great amount of flexibility in the results that can be pulled back from the search results. An additional property of the CSWP allows for the search results to be further refined by tags. The following options are related to tags:

Restricting by tags can provide many options, such as putting on a page that shows a particular wiki item. The CSWP could show videos related to the tag across a number of site collections and even different farms.

The CSWP also uses display templates, allowing for customization of how the results are displayed. The display templates are configured similarly across the SharePoint environment. This is essentially modifying HTML and JavaScript.

Traditional content deployment is still supported and is similar in function to the way it was in SharePoint 2010. The improvements in SharePoint 2013 involve a feature that determines whether a site collection can be deployed. Certain features must be removed before a site collection can be deployed via the built-in content deployment. If you try to deploy a site collection, you probably can’t see any site collections to deploy by default because a feature at the site collection level needs to be activated. To prepare a site collection for deployment, follow these steps:

When the Content Deployment Source Feature is activated, you can check whether the site collection is ready for content deployment. SharePoint 2013 lists items that prevent a site collection from being deployed. To find this list, follow these steps:

By default, a normal publishing site requires that quite a few features be deactivated before it can be deployed. Some of these can be deactivated by clicking the Deactivate link on the Content Deployment Source Status page. Some features are hidden and need to be deactivated by using PowerShell. The list might be very long and require that a lot of features be turned off. Some site templates, such as the Community Site, aren’t even supported. The PowerShell command for deactivating features is as follows:

Disable-SPFeature –Identity <name of feature> –url <URL of site collection or site>

When the unsupported features are disabled, the site is ready for deployment. However, the farm receiving the content must be configured to receive content. By default, a SharePoint 2013 farm is set up to reject any incoming content deployment jobs. To receive content deployment jobs, the SharePoint farm can be configured as follows:

After the receiving SharePoint farm is configured to accept content deployment jobs from the deploying SharePoint farm, you can configure content deployment paths in Central Administration. The process involves creating a path for the content to be deployed and a job that determines how often the content will be deployed. To create a content deployment path, follow these steps:

After the path is established, you can set up a job that runs on a specified schedule or on demand. The Manage Content Deployment Path And Jobs page shows the newly created path. Hovering over the name of the path and clicking it reveals options to Test Job, Run Now, and edit the Quick Deploy Settings. Follow these steps to configure the Quick Deploy Job settings after you choose the Quick Deploy Settings for the content deployment path:

The content deployment job is now configured. To test the job to ensure that it works, choose Test Job in the content deployment path. The first time you deploy the job, choose Run Now. The first deployment can potentially take a while, depending on the size of the site collection. After the initial deployment, only changes are deployed, greatly increasing the speed of deployment.

Variations are used to target a person’s preferred language based on their browser settings. For example, with variations, SharePoint can target a page for English speakers, another one for French speakers, and a third one for Japanese speakers. SharePoint would automatically route a person to the preferred page based on the preferred language of the browser being used. SharePoint 2013 also can do machine translation, using an external service to automatically translate content. This is a powerful new feature but, as with any translation service, reviewing the finished product is necessary to ensure accuracy.

Setting up variations is done at the site collection level. After variations are configured and labels are created, content is copied selectively from the source site to the language-specific sites. For variations to be used, you should start by configuring the variation settings:

After setting the variation settings, you can configure the labels. Labels represent individual variations (languages) that will be created. Labels typically represent individual languages, such as French, German, Chinese, Japanese, and so on. Language packs can be used with variations but aren’t required. Language packs provide translations for the SharePoint menu and ribbon items but don’t translate the user-provided content.

You can add language packs at any time, but because they require some downtime of the SharePoint server, installing them at the beginning is best. Adding language packs also gives users an interface in the language they prefer, encouraging use and contribution.

The next step in using variations is to create labels. Labels—also created at the site collection level—determine the sites created by SharePoint. Sites created based on label are created beneath the source site automatically. The first label to be created is the source variation label from which other variations receive published content based on the individual label settings selected. To create labels after the initial label, follow these steps, using an account that has site collection administrator permissions:

You can continue to create labels for all the variations that you want. After you finish creating them, return to the Variation Labels page and click Create Hierarchies. The variations won’t be available right away; they are created with timer jobs and will be ready to use soon, depending on the resources available. You can check the status on the Variations Labels page. This page shows other information—such as locale, language, and whether it’s the source—about all the labels created and allows them to be edited.

One great new function of SharePoint 2013 is the ability to support the automatic translation of content. Referred to as Machine Translation, it’s configured in Central Administration similarly to other service applications. The Machine Translation service application requires a connection to the service providing the translation. After the Machine Translation service application is created, it needs to be configured, as follows:

You need to consider many options when configuring machine translation. Depending on the amount of translation required, specifying a server (or two) as the designated translation server might be beneficial. Only those servers with the Machine Translation service started on them can process translation requests.

Translation services have come a long way in a short time, but that doesn’t preclude checking the translated data for accuracy. Another way to address this is to set up a link for end users to report errors in translation.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

eDiscovery is generally referred to how litigators and records managers discover content in an electronic format. This involves searching through documents, emails, and websites across a wide variety of sources so that the content can meet the criteria for a legal case. SharePoint 2010 introduced the concept of putting a hold on an item such as a document, list item, or page so that no further modifications could be placed on it (nor could the item be deleted). Exchange 2010 also introduced a way to put legal holds on mailboxes so that a thorough search could be made on them without any content being modified or deleted. SharePoint 2013 works with Microsoft Exchange to establish an eDiscovery solution. The tasks involved with setting up eDiscovery in SharePoint 2013 involve the following:

If content is to be discovered in Exchange using a SharePoint eDiscovery center, Exchange Server 2013 must be running. To discover content in the Exchange Server instance, make sure the following steps have been performed:

Content can be discoverable only if it’s crawled and indexed by the Search service application associated with the eDiscovery center. If Exchange content is to be searched, it must be crawled as part of result source. Also, all sites and libraries within the sites must be made searchable for the eDiscovery center to be able to discover them.

Everything that needs to be searched must be accessible by the users involved in the eDiscovery. The recommended way to provide permissions is to create a security group of all concerned individuals and then grant permissions at the web application level. This is done by creating a user policy with full read (because you don’t want the records modified) for each web application involved in the discovery process. Changing or adding a policy at the web application level starts a recrawl of the content contained with the web application, precluding the need to manually start a new crawl. Finally, the security group needs permissions to view the search crawl log. This is done using PowerShell.

After permissions are established and any Exchange Server permissions and crawls are set up, an eDiscovery center needs to be created. This center is a site collection that allows user to create and manage eDiscovery cases. The eDiscovery template requires that claims be used in the web application in which the center resides. It’s created similarly to other site collections in Central Administration, using the eDiscovery template that resides in the Enterprise section.

After an eDiscovery site is created, you need to create a new case before you can start eDiscovery. Follow these steps:

The site that’s created has two major sections: one for Identify and Hold and one for Search and Export. The exam doesn’t cover the end-user experience, so this book won’t cover how to use these functions in detail, but seeing how these functions work is a worthwhile exercise to get a better understanding of how to plan for an eDiscovery site.

The ability to do in-place holds is a new feature in SharePoint Server 2013 that deserves some attention. It allows for items in SharePoint and Exchange Server to stay in place so that users can continue to work with them, but a copy of the content at the time the hold is placed is kept. This is in contrast to SharePoint 2010, which wouldn’t allow content that had a hold on it to be modified or deleted. Now, an end user doesn’t even have to know that the content is being held. An in-place hold occurs at the site level, and a preservation hold library is created that stores copies of any content modified or deleted after the hold is placed. If multiple in-place holds are established, the content could appear more than once in the preservation library.

SharePoint Server 2013 includes a powerful set of features for managing records. Because of the very nature of records, setting up a record-management solution requires a considerable amount of planning. A record is generally considered a piece of evidence that an organization performed an activity or transaction. In SharePoint, a record is considered active until it’s declared a record and can then be modified only if it meets certain policy requirements. You can make an item go from active to record in several ways:

Records generally have some sort of legal and/or archival nature to them, which means that as soon as an item becomes a record, it shouldn’t be altered (or if it is, the alteration is recorded) and should have a retention period as part of it. The retention period determines how long the record should remain with the record management system. When planning for a record-management system, you need to consider the following:

Record management typically isn’t a single solution for most organizations. Various types of records could exist, such as print, audio, video, and even physical items such as art. Although the exam focuses on SharePoint-specific solutions, including these other types in your overall plan is a beneficial exercise. You would first categorize the types of records that you need to manage and the details associated with them, such as kind of record, category, description, media, retention period, disposition, and a contact of the person(s) who oversees the records.

SharePoint 2013 has all the record-management features that existed in SharePoint 2010, plus the following additional capabilities:

Site retention is where the entire site is essentially treated as a record. In SharePoint 2013, a site can be “closed,” which means that it’s ignored by navigation and search crawls but can still be accessed via its URL. Closure of a site doesn’t prevent its use; closure just makes the site harder to get to. Closure of a site collection, however, can make the site collection and all subsites read-only depending on the policy chosen.

Site closure is enabled via Site Policy, a site collection feature that must be enabled before site collection policies can be implemented. After you activate this feature, you can implement a site collection closure policy by following these steps:

After the policy is created, you can apply it at the site or site collection level for deletion policies and at the site collection level for closure policies. To apply site policies, click Site Closure And Deletion in the Site Administration section on the Site Settings page. You also can choose to close the site immediately if manual closure is desired.

Site mailboxes are integrated between Exchange Server 2013 and SharePoint Server 2013. In the past, documents and emails were usually kept into two distinct repositories. Site mailboxes use shared storage in both the Exchange and SharePoint spaces to provide end users a single place to access emails and related documents. Now emails can be dragged directly from Microsoft Outlook into SharePoint and can be treated as records, just like regular documents residing in SharePoint. Configuration of site mailboxes is required on both the Exchange Server side as well as the SharePoint side. Knowing how to set up site mailboxes in detail isn’t required for the exam, but general knowledge of what is required might be. The following items are required in addition to SharePoint Server 2013:

Site mailboxes should be configured and maintained on the SharePoint side. The lifecycle application can be used to automatically close and delete site mailboxes, giving users the chance to keep them open if needed. When a site mailbox is closed by the lifecycle application, it’s retained for a period of time specified by the lifecycle policy. You should delete mailboxes only via the SharePoint interface, because deleting them on the Exchange Server instance causes orphans on the SharePoint server. On the Exchange Server side, only the mailbox size and the maximum size of an individual email can be set. These are set with PowerShell commands on the Exchange Server node.

A record center is a site that you can create anywhere inside a SharePoint environment by using the Records Center template. The key components of the record center are the Drop Off Library and the Record Library. Documents sent to the Drop Off Library (via routing or uploading or code) are processed and then sent to the proper record folder (such as the Record Library or similar library) depending on the document’s properties. This is known as document routing. Drop Off Libraries don’t just exist in record centers, but in other site templates as well, and they can be used to route documents. The Drop Off Library requires the site level feature Content Organizer to be activated (the default in a record center). This enables the two site settings pages located under the following Site Collection Administration settings, which need to be configured before document routing can occur:

You need to consider a number of settings when planning for a record center or for sites using the Content Organizer:

Another available option enables you to email role managers if a submission doesn’t match a rule and/or when content has been left in the Drop Off Library. This allows for unattended monitoring of record activity. Also, a submission point enables other sites or email-messaging software to send content to this site (it’s always the site URL followed by /_vti_bin/OfficialFile.asmx).

Modifying the content organizer settings gets you ready to create rules. Content organizer rules route documents to the appropriate locations based on content types and property rules. To create a rule, follow these steps, using an account that has Full control:

After an item is declared a record, you need to consider how long to retain it and how to dispose of it after it’s no longer required for business or legal reasons. (The term “dispose of” is used here because it might not actually be deleted.) Retention plans are typically centered on the business and legal requirements for keeping documents around. The two main factors involved are disk space requirements and disaster recovery concerns.

Disposition involves several options. The most efficient is automatic deletion. For example, if a record has been around for seven years, it’s deleted automatically. In this case, it would happen without user interaction and if, for some reason, a record was declared accidentally, it would be deleted without notice. Another method of disposition is to have automatic deletion with holds. In this case, a record would be deleted automatically unless a hold had been placed on it. The hold would be extended past the time for automatic deletion for a predefined period of time. Also, records might require human interaction and review before they are deleted. This disposition method is the safest (that is, least risky) but requires the most time and effort.

Site retention policies were discussed in the preceding section. A site itself can now have a deletion as well as a closure schedule. The policies associated with items within a site collection are defined at the site content level by default. To define a policy for site content, follow these steps:

You can override content type retention policies at the document library and list level. Overriding requires that the site collection level’s Library and Folder–based retention is activated. After this is done, go to the library or list settings and then click Information Management Policy Settings. On the Information Management Policy Settings page, click the content type if more than one is associated with the list/library. On the Edit Policy page, enable retention as you would for a content type and then enter the appropriate retention schedule.

With record management and eDiscovery, you need to plan for large document repositories. The definition of “large” is subject to debate, but you can take some steps to ensure that your SharePoint environment is responsive. The best way to determine the system’s capabilities is to do some load testing, which helps determine the number and type of servers necessary to achieve the capabilities demanded by your business needs. Some of the tests that you can perform are as follows:

After you come up with a test that represents what the end user will experience and the load that will be placed on the servers, you can load the servers with test data to see whether the performance is what you expect. As with any test scenario, representing the load presented by real-life situations is difficult, but it can at least help you determine the hardware requirements.

One item that can decrease performance is the number of items in an individual document library or list. Although SharePoint can support lists/libraries containing tens of millions of items, performance degradation occurs, especially for the SQL Server node that contains the items. You need to test performance on the individual hardware and software that you expect to use, but CPU usage and memory are two items that need to be monitored.

The number of documents contained within a content database can also affect document uploading performance. A large part of this degradation can be mitigated with proper database maintenance. Most databases are set up to grow by a percentage so that when a 100 GB database, for example, needs to grow 10 percent, it must grow by 10 GB, but when it’s a terabyte in size, it must grow by 100 GB. Obviously, growing a database by 10 GB would require a lot less time than growing it by 100 GB. Other maintenance tasks, such as keeping the index up to date as well as keeping a fresh set of statistics, helps improve performance.

Because most of the work involved with large document repositories is placed on the SQL Server nodes, you can achieve only a certain amount of performance increase by adding more WFEs. Each situation is different, but generally after two WFEs, the performance gain is minimal. Even during bulk uploads, the SQL Server node becomes the bottleneck. Data being sent to the SQL Server instance needs to be written to disk, and the speed at which this occurs depends on the input/output speed of the disks more than any other factor.

SharePoint sites tend to continue to grow, and planning for space to contain all this growth comes under capacity planning. Although document libraries and lists can contain millions of items, you might not want all that data in a single content database. Extremely large databases require a long time to back up and even longer to restore if something happens to them. Most organizations strive to find an effective setup that minimizes the number of databases and maximizes performance. Such a setup depends on a multitude of variables, including hardware, software, number of servers, network performance, and the business needs. You need to take care of capacity planning early on to handle the growth of large repositories so that the budget, space, and technical expertise can be available to meet the demand.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

In this thought experiment, you were presented with two main questions: How many content databases are required for My Sites? What is the best way to increase performance for the activity feeds?

You can answer the first question with some simple math, based on an assumption that no content database should be larger than 200 GB. Because each user is allowed 1 GB of space, you can assume 200 users per content database. This means 25 content databases for the My Sites, thus allowing for users to fully use their allotted space without moving site collections from one database to another.

The second question is concerned with activity feed performance. The best way to increase activity feed performance is to have a dedicated Distributed Cache server, a SharePoint 2013 server that runs only the Distributed Cache service. The other option is to have collated servers running the Distributed Cache service with every non-essential SharePoint service turned off. This gives the Distributed Cache service as much memory as possible, allowing for the fastest retrieval of activity feed data.

In this scenario, you were asked how you would customize the search results for when a user entered the name of the CEO in the people results search box. This requires three steps:

These three steps enable you to display the required results in the desired format.

In this scenario, you were presented with a single main question: What is the best solution for providing consistent list content across multiple sites and site collection, both internally and externally? The answer is a product catalog site collection that enables a product catalog to be published across sites, site collections, and even SharePoint farms.

Because the content is to be shared internally and externally (meaning the Internet), a product catalog makes the most sense. A product catalog enables the consuming of content from a wide variety of sites and site collections, enabling editing of content in one location and publishing that content to every source that consumes it. Product catalogs are new in SharePoint 2013 and represent a new way to distribute content across multiple sites, site collections, and even SharePoint farms.

In this scenario, you were told to come up with a solution for an eDiscovery project that would cause minimal disruption to the end users allowing them to work undisturbed. You would start by creating a security group, an eDiscovery site collection, and a new case site:

After the new case site is created, content can be identified and held. An in-place hold would cause the least amount of disruption to the end users enabling them to continue to work on their documents and lists without disruption. After items are identified and held, a search and export can make a copy of all identified items (including mailbox items, if that was configured during the identify process).