Context. You have a log directory with hundreds of log files, you need to look for a specific string, but you don’t know which file it resides in.

With PowerShell we can restrict things down in two ways.

If we roughly know when the log entry was done, we can constrain on time.
We can then use Select String to filter further.

$daysToCheck = $(get-date).AddDays(-2)

-2 in this case indicates I want to find files that were modified at most 2 days ago. These means from right now, go back a max of 2 days.

Get-ChildItem -Recurse | ?{$_.LastWriteTime -gt $daysToCheck} | Select-String "String to Search for" -list | Select Path

In this example it’ll search the current working directory as it was not defined in the first command call. the list operation is important as to only list the file the string was found in once, else the file path will be listed for every instance the string is found within the file.

This will list all the files contain the string in question. What you wish to do with this is list is on you. However you at least now know where to look further for more information on whatever it is you might be looking for.

Hope this helps someone.

Broken SharePoint Crawl

Issue: SharePoint Search

First Issue: Crawl ends in 1 min 20 seconds.

Solution: Check to see if the Page Loads when queried from the front end server. If you get a credential prompt 3 times. Then you have to disable loop back checking.

How to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Add a new DWORD value named DisableLoopbackCheck and give it a value of 1. After setting the value reboot your server.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /t REG_DWORD /d 1

Second Issue: Crawl appears to complete but Errors in Log

Log Details of “the content processing pipeline failed to process the item ExpandSegments”

You may find lots of sources stating to watch out for multi valued attributes or property names such as this nicely detailed blog post however, watch for the details in the log message and it’s a bit different. However I feel this TechNet was answered incorrectly.

I tried some of the basics, such as clearing the index and adding the search account as site admin, did not help. On that note I learnt that separate search content sources within a search application do not have their own indexes. You have to create dedicated search applications for each SharePoint site if you wish them to have their own index (“Database/Tables”).

After a bit more scouring I found many instances of the same problem with the solution always being you have to create a new search application, such as this TechNet post and this TechNet Post.

Solution:

Remove the content source from the existing Search Service Application.

Create an entirely new Search Service Application.

Reboot the Front End.

Add Crawl Content on new SSA. Crawl should work.

Third Issue: Red X on Search Service Application Services

*NOTE* After creating the new Search Application, a front end reboot is required to remove the red X’s on some of the application services statuses.

Fourth Issue: Search results not working

This from my testing appeared to have resolved the crawl issue at hand. However I wasn’t able to get results returned when entering data in to search. I did a bit of searching and testing and I found the solution. Turns out you have to associate the web application with the new search service application (In my testing I created a new uniquely defined search application to have a separate index then the other SharePoint Sites).

Solution:

Navigate to Central Admin > Application Management > Manage web applications >Highlight the web application > Select Service Connections from top ribbon > Make sure your Search service application is selected.

This was it for me, however if you still experience issues I have also read updating the front end servers can resolve issues as well, as blogged about by Stefan Goßner.

Fifth Issue: Runaway Crawl

For some unknown reason, when I went to check out the SharePoint front end after the weekend, I noticed it was using near 100% CPU usage, very similar to a Front End that is actively doing a crawl, I knew this wasn’t a normal time for a crawl and it generally never happens during this time.

To my amazement 3 crawls were on going for over 70+ hours. Attempting to stop them from the front end option “Stop all crawl” resulted in them being stuck in a stopping state.

Googling this I found stop and starting the SharePoint Search Service under services.msc did help to bring them back to “idle”.

Now I believe this next step is what caused my next issue, but it is uncertain.

I clicked on Remove Index, for the primary search service application. It was stuck at “This shouldn’t take long” for a really long time, and I believe it was my impatience here that caused the next problem, as I restarted the search service again after this fact.

Sixth Issue: Paused by System

All solutions I found for this issue resulted in no success. Even rebooting the server the primary search service content crawl states were “paused by system. Regardless of:

1. Pausing and Resuming the Search Services
2. Restarting the Search Services
3. Rebooting the server

I was only able to resolve this issue the same way I fixed the initial issue with the crawl, rebuild the search service application.

I hope this blogs helps anyone experiencing issues with SharePoint Search functionality. Cheers!

Tag: Search

Log Searching with Powershell

Fixing SharePoint Search