Part 1 Access Denied for Local Administrator

You have successfully configured Winrm and CredSSP on your server and enabled Credential delegation on your client. Your account is a local administrator on the target server. Normally you should be all set to start a new remote session. But in some cases you will see this:

How can that be? Access denied for a local admin?

In this case the next thing to check is the output of Get-PSSessionConfiguration on your target server. Normally this is what you will see (the exact output will vary slightly by OS/PowerShell version):

If instead you see this:

You have found the problem. Access has been disabled in the session configuration. This could be the result of Disable-PSSessionConfiguration or manually removing permissions. To fix it you will need to re-enable access with Set-PSSessionConfiguration. In most cases you will run it like this:

Set-PSSessionConfiguration -Name "microsoft.powershell" -ShowSecurityDescriptorUI

You will need to specify a different name if you are trying to connect to a named session you have setup. This command will bring up a new window that will allow you to add the permissions to local administrators. Select 'Y' to restart the service to make the change live.

Now running Get-PSSessionConfiguration will return the default output and you will be able to connect without seeing access denied.

If you search on an exact url within Path, then you will find the document with that URL

The problems arise when you would like to search for just a part of the URL within 'Path' or search for part of the URL in the full text index. This does not work in the out of the box setup.

This is because Path is set as "Complete Matching"

The reasoning for this configuration is mentioned here: Changes from SharePoint 2010 to SharePoint 2013

Many customers are willing to trade off some additional space in the index and tokenization processing to be able to search on parts of the URL. This is how you set it up. First off, it is a  good policy never to change the default managed properties if you can avoid it. So, we'll create a new Managed Property called 'newpath'. You can create the property as normal using the GUI, but we'll need to handle mapping crawled properties in PowerShell. We want to use the exact same crawled property mapping that Path uses. First create the new managed property.

We will leave Complete Matching unchecked

We will also add Searchable, so we can search against the full text index.

Leave the crawled property mapping empty.

Next is the crawled property mapping. Start by getting the Path managed property and displaying the mapping.

Now create the same mapping for newpath. We use PowerShell since that allows us to easily select the exact same propset and name that Path is mapped to.

Now you'll see the mapping in the GUI

After a full crawl of your content source. Testing searching on the newpath managed property:

Testing against the default full text index with a subset of the URL. This will not work out of the box

Searching for the same subset of the url against path. This is what you'll get with an out of the box full text search.

I stated looking into the User Segmentation feature in SharePoint 2013. The idea is that you create query rules based off of a category of users and then change the search experience to better suit them. Some examples would be adjusting results based on the users language / location, providing different best bets based on a user's title, etc. The first step is to define the names of the segments. These are just entries in the Managed Metadata Service term store.

Here is an example from my test case. I just created two terms: English and French.

This is where most examples would ask you to create a custom web part. Here are two examples I looked at: Adaptive experiences in a Product Catalog in SharePoint 2013 using Facebook location data and User segmentation in SharePoint 2013

That web part will do a few things:

1. Look for a property to compare against user segments.

2. Check the term store to see if there is a match for the property.

3. Grab the guid of the matching term

4. Add the guid to a special query parameter

Step 1 is not really SharePoint specific. Steps 2 and 3 are fairly straight forward. So, I wanted to focus on part 4. How can you add a user segment to your query without adding a custom web part? What if you are using the REST API directly?

The key is how can you specify "UserSegmentTerms"

(dataProvider.Properties["UserSegmentTerms"] = userSegmentTerms.ToArray();)

in your query. UserSegmentTerms is not a property that you can just add as a part of the get request. UserSegmentTerms needs to be passed a part of KeywordQueryProperties. 

To pass the KeywordQueryProperties, we're going to use a post request and send a JSON object. I found Nadeem's blog a great place to get started here: How-To: PostQuery in SharePoint 2013 Search REST API and Tip - Handling HTTP 403 Forbidden when querying the Search REST Service using the PostQuery method .

Once we have our basic JSON post query working, we want to specify the KeywordQueryProperties. This is done by specifying "properties". There are some good examples here SharePoint Search REST API overview . If you scroll down to "Properties", you'll see an example of how to specify the KeyworkQueryProperties.

Now, what we need to do is to create the same property that would be submitted by dataProvider.Properties["UserSegmentTerms"] = userSegmentTerms.ToArray();). So, the Name will be UserSegmentTerms, the type will be a string array and the value will be a one element array with the guid of the term that defines our user segment.

Here is what my query look like if I want to specify the "French" user segment.

3c2375ab-d09a-4f9a-9089-3ec0084192a9","3c2375ab-d09a-4f9a-9089-3ec0084192a9 is the guid of my French term in the term store. You can see the guid in my first screen shot.

All that's left is to create Query Rules that will fire off of the user segment.

Baseline:

Looking only at the component counter, we can see it gets up to about 3,500. This is over the limit mentioned as guidance. But, that is just a rough guideline.

With 1 additional Content Processing Component from part 2:

Now we see a dramatic increase in  Search Flow Statistics\Input Queue Full Time, up to a combined 20,000. This is way over the guideline of 1,000. We shouldn't expect to gain anymore speed in our crawl by adding additional Content Processing Components at this time.

To demonstrate further that adding another Content Processing Component wont help. I modified the topology and added a third Content Processing Component. My crawl still takes the exact same time as with only two CPCs. You can also see that the total Search Flow Statistics\Input Queue Full Time doesn't change, we are pushing more content than the indexer can keep up with.

In part 4 we'll keep tuning to speed up the crawl.

We'll now rerun the same full crawl test we performed in part 1 and collect counters from both servers.

Our transactions waiting is still increasing, so we still see that the bottleneck is downstream of the crawler. 

The Content Processing Component still looks like our bottleneck, but there is slightly less load now that is spread over two CPCs. Here is the Search Flow Statistics\Input Queue Full Time to compare against part 1.

Now, the most important metric: did we improve our crawl time? By adding this single component to our search topology, we were able to cut our time for a full crawl nearly in half. Going from 85 minutes to 45 minutes. This dramatic improvement in performance shows how valuable tuning your search infrastructure can be.

In future installments we'll take a look at what to do when other components are the bottleneck. See part 3

The environment I will use for testing is a single virtual machine running all of the farm components. It hosts SQL Server, all the SharePoint components, as well as a custom content enrichment web service. The content source I am crawling is a SQL database connected through BCS. The sql table has around 150,000 rows and a full crawl takes about 80 minutes. The VM has the following specs:

Ram: 16GM

CPU: 5 virtual cpus

Disk: Single VHD hosted on a local disk

The VM runs on a server that hosts other VMs and services and the disk is shared. So, like most real world environments, the hardware performance is dependent on how the resources are being shared. This is the reality for many environments and we still need to tune them.

My tuning requirements are simple: make it go faster. This is often as detailed a tuning requirement that you will get.

The first step is to capture a performance baseline, so we can compare the effects of any changes that we make. We first need to defined the counters to collect. Then we will run a full crawl and capture those counters during the crawl. It may not be possible to run a full crawl, using an incremental that picks up enough content will work fine as well. In that case you will need to track progress by looking at the throughput rate and not necessarily the crawl time.

For my baseline test, I started up a full crawl and captured counters for 10 minutes. I have attached the counters.txt file to this blog post. For the initial baseline I will used the counters and steps I outlined previously (SharePoint 2013 Monitor and Tune Content Feed) There are some good details on using powershell to pull the counter data on Mark Sullivan's Blog . I ran the following command to capture the output as a blg:

get-counter -counter (get-content counters.txt) -MaxSamples 10 -sampleinterval 60 -ComputerName ksesearch | Export-counter -Force -Path perfbaseline.blg

Here you can see my transactions waiting backing up. More and more transaction are waiting as the crawl progresses. This Indicates an issue downstream, showing that the crawler is pushing data faster than we can handle it.

The next step is to look at Search Flow Statistics\Input Queue Full Time to determine if indexing or content process is the bottleneck component. You only need to be concerned about the content processing instances of this counter.

Our run shows nothing over 100, which is well under the guideline of 1000. So, our next step will be to add an additional content processing component. The entire crawl took 85 minutes at a feeding rate of 29 documents per second. We'll look to improve that with the tuning. We will discuss the details in part 2.

For reference, here is the raw performance capture:

perfbaseline.blg

counters.txt

Define InProperty to be the name of the managed property you would like to extract from and OutProperty to be the Managed property that will hold the extracted data.

using System;

using System.Collections.Generic;

using System.IO;

using Microsoft.Office.Server.Search.ContentProcessingEnrichment;

using Microsoft.Office.Server.Search.ContentProcessingEnrichment.PropertyTypes;

using System.Text.RegularExpressions;

namespace RegExContentProcessingEnrichmentService

{

public class RegExContentProcessingEnrichmentService : IContentProcessingEnrichmentService

    {

 // Defines the error code for managed properties with an unexpected type. 

privateconstint UnexpectedType = 1;      

// Defines the error code for encountering unexpected exceptions.

privateconstint UnexpectedError = 2;

//  out is the managed property we will write the extracted data to 

private const string OutProperty = "out";

//  in contains the text we will match our pattern against

private const string InProperty = "in";

private readonly ProcessedItem processedItemHolder = new ProcessedItem

        {

            ItemProperties = new List<AbstractProperty>()

        };

 public ProcessedItem ProcessItem(Item item)

        {

            processedItemHolder.ErrorCode = 0;

            processedItemHolder.ItemProperties.Clear();

        try        {

          // placeholder for output.

          // We have defined the Managed Property as multi-valued, so we want to output a list

          Property<List<String>> output =new Property<List<String>>();

                 // store the input string

                String input=null;

               // loop through each property

                  // http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2013/06/19/advanced-content-enrichment-in-sharepoint-2013-search.aspx

                  // presents a more elegant method of selecting the desired properties

         foreach (var property in item.ItemProperties)

                {

            // Check if this is the input property.

            if (property.Name.Equals(InProperty, StringComparison.Ordinal))

                    {

                        // I had some issues getting the value via the example method. This seems to work fine

                        input= (String)property.ObjectValue;

                    }

                }

         if (input!= null)

                {

                 // regex to find in the input

                 string pattern = "Value=\"([^\"]*)\"";

                 MatchCollection matches = Regex.Matches(input, pattern, RegexOptions.Singleline);

                // initialize the output

                output.Value = new List<String>();

                output.Name = OutProperty;

               foreach (Match match in matches)

                    {

                        // add the value of the matching group to the output managed property

                        output.Value.Add(match.Groups[1].Value);

                    }

                    processedItemHolder.ItemProperties.Add(output);

                }

        }

   catch (Exception)

            {

                processedItemHolder.ErrorCode = UnexpectedError;

            }

return processedItemHolder;

        }

    }

}

Note: some of the thresholds are a rough estimate and may be replaced by more formal product documentation or field experience in the future.

The main components in the feeding chain are:

• Crawl Database

• Crawl Component

• Content Processing Component

• Index Component

Here are some useful counters to monitor for each component.

When we begin content tuning we need to isolate the bottleneck in the feeding chain. I find it useful to approach this as a two step process. First we want to determine if the bottleneck occurs prior to the search subsystem (Upstream) or after hitting the search subsystem (Downstream). You could also look at these two pieces as content acquisition and content processing.

Content Acquisition consists of:

• Content Source (SharePoint site, web site, BCS connection, etc)

• Crawl Component 

• Crawl Database

Content Processing consists of:

• Content Processing Component

• Index Component

A good first counter to look at is Search Gatherer Projects - SharePointServerSearch\Transactions Waiting for all of the Crawl Components. If this counter is low (less than a few thousand), content processing is keeping up with content acquisition. If the counter is high and/or consistently rising, then we are pushing more data than Content Processing can keep up with. This is also visable in the Crawl Health report by viewing the queue length.

In the case where Content Processing is slow, we have two possibilities: the Content Processing Components are the bottleneck or the Index Components are the bottleneck. Both Search Submission Service\# Pending Items and Search Flow Statistics\# Items Queued For Processing will be high (greater than a few hundred).

1. If Content Processing Components are the bottleneck

1. Processor utilization will be high on servers running Content Processing Components

2. Search Flow Statistics\Input Queue Full Time will be low (less than about 1000)

2. If Index Components are the bottleneck

1. There will be high disk I/O and/or latency on servers running Index Components

2.  Search Flow Statistics\Input Queue Full Time will be high (greater than about 1000)

When Content Acquisition is slow, there are three possible bottlenecks: Content Source, Crawl Database, Crawl Component

1.  If Crawl Database is the bottleneck

1. Search Gatherer Projects - SharePointServerSearch\Transactions Completed will be high (greater than a few hundred)

2. There will be high disk queue length / disk latency on Crawl DB

2. If Crawl Component is the bottleneck (not common)

1. There will be high processor utilization on Crawl Component servers

2. There will be no disk latency issue on Crawl DB

3. If Content Source is the bottleneck

1. Search Gatherer - SharePointServerSearch\Threads Accessing Network will be close to Search Gatherer - SharePointServerSearch\Threads Filtering

2. There will be low processor utilization on Crawl Component servers

3. There will be no disk latency issues on Crawl DB

Here is the error you'll see if you try to activate an new topology in this state:

PS C:\Users\SPFarm> Set-SPEnterpriseSearchTopology -Identity $newTopology
Set-SPEnterpriseSearchTopology : Topology activation failed. Management called failed with System.InvalidOperationException: 'Unable to change topology when Generation controller is not active' at    at Microsoft.Ceres.SearchCore.IndexController.IndexController.IsEmptyIndex(String indexSystemName)
   at Microsoft.Ceres.SearchCore.IndexController.IndexControllerManagementAgent.WrapCall[T](Func`2 original)
At line:1 char:1
+ Set-SPEnterpriseSearchTopology -Identity $newTopology
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.Offic...tSearchTopology:SetSearchTopology) [Set-SPEnterpriseSearchTopology], SearchTopologyActivationException
    + FullyQualifiedErrorId : Microsoft.Office.Server.Search.Cmdlet.SetSearchTopology

This is current as of the March 2013 Public Update. This appears to be yet another reason to assure your active topology is fault-tolerant and not to rely on adding additional components in the event of a failure.