SP2013 - Adding a new claim type encoding and its impact on Search

  • Article

Hi Search Enthusiasts

A quick heads up on some consequences on using custom claim type in SP2013.

There is an impact on Search when you had a new Claim Type encoding in SP2013 using the following cmdlet

New-SPClaimTypeEncoding

https://technet.microsoft.com/en-us/library/jj219605.aspx

 

The Search feature in SP2013 (unlike in SP2010) is also using the list of Claim Type Encoding to process the security information of each indexed document.

For a deep dive, "ClaimEncodingManager" is the object in the SharePoint Config DB / Table Objects containing all the Claim Type Encoding.

Whenever a change to the Claim Type encoding is implemented, it is necessary to restart the Content Processing components (net stop SPSearchHostController / net start SPSearchHostController) on the corresponding SP server (make sure you don't bring down your search functionality).

The content processing components (CPCs) are caching the farm Claim Type Encoding list upon startup. Unfortunately they (CPCs) aren’t aware when a change to that list occurs hence the restart necessity.

Unlike SP2010, Security information in SP2013 are stored in the Search index, meaning any addition of a claim type encoding, not only requires a restart of the Content Processing but also a complete full crawl.

For cross-farm deployment, for instance if your Search and Content Farm are separate, it is CRUCIAL that any change to Content farm Claim Type Encoding is reported to the Search farm as well.

If you have multiple Content farms, you need to make sure the claim type encodings aren't overlapping as they would need to be ported into the Search farm.

 

From a query perspective, It is also required to restart all Query Components (QPC) as they would be impacted as well of not knowing how to encode the incoming claims to build the security trimming filter.

 

Keep your Search up !