SharePoint 2013: The item has been truncated in the index because it exceeds the maximum size

Problem

During routine system checks, you discover numerous instances of the following warning occurring in the Search subsystem crawl log:

The item has been truncated in the index because it exceeds the maximum size. ( Item truncated. Field=body, Occurrences=121961, Chars=524290; ; SearchID = [ID string] )

Troubleshooting

1. Checked MaxCharactersInPropertyStoreForRetrieval property: executed this commandlet

   (Get-SPEnterpriseSearchMetadataManagedProperty -Identity body -SearchApplication (Get-SPEnterpriseSearchServiceApplication)).MaxCharactersInPropertyStoreForRetrieval

   This returned 2097152, which is greater than the Chars count in the warning.  This value is in bytes.
2. Checked MaxCharactersInPropertyStoreIndex property: executed this commandlet:

   (Get-SPEnterpriseSearchMetadataManagedProperty -Identity body -SearchApplication (Get-SPEnterpriseSearchServiceApplication)).MaxCharactersInPropertyStoreIndex

   This returned 0. This value is in bytes.
3. Increased MaxCharactersInPropertyStoreIndex property:  executed this script

   $prop=Get-SPEnterpriseSearchMetadataManagedProperty -Identity body -SearchApplication (Get-SPEnterpriseSearchServiceApplication)
   $prop.MaxCharactersInPropertyStoreIndex=2097152
   $prop.Update()

4. Checked Crawl Log for number of warnings: found 1405.
5. Set three instances of this warning to be recrawled and then launched incremental crawl: see Notes below for steps.
6. Checked Crawl Log for number of warnings: found 1402.
7. Set all instances of warning to be re-crawled and then launched incremental crawl.
8. Checked Crawl Log for number of warnings: found only 1271.  This indicates that 134 instances of this warning were resolved by increasing the MaxCharactersInPropertyStoreIndex value.

Solution

• Increase the value of MaxCharactersInPropertyStoreIndex to something greater than the Occurrences value in the warning message.

References

• TechNet
• Get-SPEnterpriseSearchMetadataManagedProperty
• Get-SPEnterpriseSearchServiceApplication
• Software boundaries and limits for SharePoint 2013: scroll down to the Search: item size limits section; then look in the table, fourth and fifth rows for specific discussions on the properties engaged above.
• Attachment size crawl issue
• DocParser error in SharePoint 2013 Search
• MSDN
• ManagedProperty. MaxCharactersInPropertyStoreForRetrieval
• ManagedProperty.MaxCharactersInPropertyStoreIndex
• Search Forum: The item has been truncated in the index because it exceeds the maximum size
• Waldek Mastykarz: 
• The item has been truncated in the index because it exceeds the maximum size
• SharePoint StackExchange: 
• SP 2013: The item has been truncated in the index because it exceeds the maximum size
• Network Steve
• DocParser error in SharePoint 2013 Search
• ShiPoint
• SharePoint 2010: Set Metadata Search Properties using PowerShell
• SharePoint Republic
• SharePoint 2013 – This item was partially parsed. The Item has been truncated in the index because it exceeds the maximum size

Notes

• To re-crawl an item appearing in the crawl log, perform these steps:
1. Go to the Search Administration page
2. Click Crawl Log (left quicklinks area)
3. In the Warnings column, click on the number that appears there
4. Hover the cursor over one of the instances of the warning: a dropdown bar appears
5. Click it and then select Recrawl this item in the next crawl.
• Chars: this value, in the warning message, indicates how much data is returned from the query. 
• The MaxCharactersInPropertyStoreForRetrieval managed property relates to this,
• Occurrences: this value indicates how much data may actually be stored in the index.  
• The MaxCharactersInPropertyStoreIndex managed property relates to this.
• After setting all remaining instances to be re-crawled, I found that six remained and that re-crawling these six was not affected by the change in the MaxCharactersInPropertyStoreIndex value.  Still not clear why that is.

SharePoint 2013 TIP: Help! The list view Delete button is missing!

If you don't see the Delete button, when trying to remove a list or document library view, it may be because it is the default view for that list or document library.  A quick way of determining whether it is the default view is to look in the view bar just above the listing: the default view will always be the first view listed here, from left to right.  Just make another view the default, and then the Delete button will appear again.

SharePoint 2013: the SharePoint item being crawled returned an error

Problem

During routine check of your farm's crawl log, you discover five errors of type, 

The SharePoint item being crawled returned an error when attempting to download the item.

Checking the URL View of the errors, you find that each of them involves opening a Microsoft Office item, specifically, a OneNote item.  Clicking the URL returns the usual error page:

Sorry, something went wrong
An error has occurred on the server
Technical Details...

 Troubleshooting

1. Check ULS logs of primary WFE (WFE1) for the correlation ID: you find a number of entries associated with this correlation ID.  One in particular phrase in one of these entries catches your attention:

   System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://localhost/SecurityTokenServiceApplication/appsts.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.IO.PipeException: The pipe endpoint 'net.pipe://localhost/SecurityTokenServiceApplication/appsts.svc' could not be found on your local machine.

2. Check status of Net.Pipe Listener Adapter service: reviewing server services, you find that this service is not running.  You start the service, and it starts successfully.
3. Check error message URL: you again attempt to navigate to the URL identified in the crawl error entry and this time you are able to view the page successfully.

Solution

• That phrase is indicative: if you see it in a ULS message, check the associated service.  If it's stopped, start it.

References

• AlsTechTips
• OWA 2013: Sorry, something went wrong
• SharePoint 2013: There was no endpoint listening at net.pipe...

Notes

• Two WFE farm, Windows NLB configuration.  WFE1 is NLB primary.
• I usually check the primary WFE first when finding errors like this one, since its more than likely the source of the error.

SharePoint 2013: A required certificate is not within its validity period

Problem

You are performing a routine check on your farm's Search service crawl history and you discover that incremental crawls are generating increasing errors.  It is a Tuesday.  Reviewing crawl history, you found that beginning at 12:55 PM on Monday, errors began increasing during incremental crawls.  Incremental crawls are configured on your farm to run every 15 minutes, from 4 AM for 16 hours, Mon-Sat. From 11 errors at 12:55 PM, Monday, it went to 21 errors by 7:40 PM that same day.  By Tuesday, 11:11 AM, 40 errors encountered during incremental crawls.  This is a two-tier, two server farm, externally-facing.  SharePoint Server 2013 Enterprise, patched current.  Tumbleweed standard is installed on all farm servers.

Troubleshooting

1. Check Central Administration Problems and Solutions report: found nothing related to crawling or search.
2. Check server event logs: found that beginning at 12:55:32 PM, Monday, the following appears in batches of 5 or so, every 10-15 minutes:

   Log Name:      Application
   Source:        Microsoft-SharePoint Products-SharePoint Foundation
   Date:          Monday 12:55:33 PM
   Event ID:      8311
   Task Category: Topology
   Level:         Error
   Keywords:      
   User:          DOMAIN\spContent
   Computer:      [SharePoint server]
   Description:
   An operation failed because the following certificate has validation errors:
   
   Subject Name: CN=[domain name], OU=[organization], O=[company], L=[city], 
   S=[state], C=[country]
   Issuer Name: CN=Symantec Class 3 Secure Server CA - G4, OU=Symantec Trust 
   Network, O=Symantec Corporation, C=[country]
   Thumbprint: [thumbprint]
   
   Errors:
   
    NotTimeValid: A required certificate is not within its validity period 
   when verifying against the current system clock or the timestamp in the 
   signed file.
   .
   Event Xml:
   ...
   

   followed by

   Log Name:      Application
   Source:        Microsoft-SharePoint Products-SharePoint Foundation
   Date:          Monday 12:57:38 PM
   Event ID:      2159
   Task Category: Unified Logging Service
   Level:         Error
   Keywords:      
   User:          DOMAIN\spSearch
   Computer:      [server]
   Description:
   Event 8311 (SharePoint Foundation) of severity 'Error' occurred 15 
   more time(s) and was suppressed in the event log
   Event Xml:
   ...
   

3. Check Site Access: you open a browser and try connecting to the root farm content site.  The connection is successful and the landing page displays without issue.  Checking the URL's certificate status, you find that the certificate is valid and no issues.  Customer access to their content is unaffected.
4. Check Search Index: you perform a simple search and find search results returned as expected.  Customer search capability is not affected.  However, you are aware that new content will not be searchable.
5. Perform Literature Search: searched on event message text and found a number of postings related.  Most postings indicated the current issue involved expired certificates.  However, the certificate in this case was valid and within its date range.
6. Check IIS Server Certificates: you found two certificates for the web server, the one you installed and a new one.  The existing one expired Tuesday, today.  The new one is valid beginning Sunday.  Thus there is overlap between the certificate that expired and the certificate that was newly installed.  You check with the lead sysadmin, who informs you that he installed certificates the Friday previous.
7. Check Crawl History Again: checking crawl history again later, you find that crawl errors began to decrease 2:08 PM the same day, and that by 2:15 PM crawls were completing successfully as they had previously.

Solution

1. Check site access and searchability of existing content: if these are successful then you need not worry about customer site access and searchability of existing content.
2. Do nothing: If after checking certificate expiration, you find that it is valid, it may be that some caching is involved and that it will take awhile for old certificate information to be flushed and new certificate information recognized by Search crawler.

References

• Sharepoint and SSRS report trust relationship ssl/tls secure channel remote certificate is invalid
• IIS: Make sure that your certificates are current
• "A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file." when installing a program.
• Troubleshooting Certificate Validation Errors
• Tumbleweed Desktop Validator
• Setup SSL in SharePoint 2013
• How to: View Certificates with the MMC Snap-in

SharePoint 2013: a web application isn't logging user request data

Problem

You are performing routine checking of production farm web front end (WFE) server IIS logs and discover that user requests are not being logged to the My Site web application on one of the farm web front ends (call it WFE1).  What is confusing about this is that requests are being logged for other web applications on this WFE, such as the primary content web application.  Your farm topology features two WFEs in Windows Network Load Balance configuration.

 

Troubleshooting

1. Check user request logging for other web applications on production WFE1: found that that requests are being logged for the primary content web application that is also on this WFE.
2. Check user request logging for web applications on WFE2: found that that requests are being logged for all web applications on WFE2.
3. Check user request logging for web applications on development: found that all web applications on all WFEs are logging user requests.
4. Check production WFE1 web server logging configuration against production WFE2: found that log file location, scheduling appear properly configured and configuration is fully consistent with that for WFE2.
5. Check web application pools on production WFE1: found that WFE1 application pool is started for the My Site web application.
6. Check permissions of the production WFE1 directory used for storing IIS logging data, E:\IIS, and compare with production WFE2: found that the local Administrators group (which the service account, spApp, is a member of) is configured for Full Control on both WFEs, but that for WFE1, all of the checks are grayed out.
7. On production WFE1, in IIS, changed the directory configured for My Site web application user request logging to E:\IIS2, and then clicked Apply: found that the new directory was immediately created and that, after a few moments, a log file was created and this log file was being populated with request data.

Solution

• Check permissions to the directory used to store IIS web application log files and compare with directory permissions of other WFEs. If any discrepancies are found, just point IIS logging to a new folder.  IIS automatically creates and configures appropriate security for the folder.

References

• Exchange 2013 : IIS 8 – change default log directory
• Default Log File Settings for Web Sites <logFile>
• Powershell command to set IIS logging settings