Tag Archives: Crawls

Paused by system

Posted on by
1

If your Search Service Application shows a crawl status of Paused for:External request or Paused by system . You can use the following script to get it back online.

$ssa = Get-SPEnterpriseSearchServiceApplication “YOUR Search Service Application name here”

Resume-SPEnterpriseSearchServiceApplication $ssa

*NOTE*
Your Search App might be named something different than Search Service Application.
To find your Searh App name, navigate to your Central Admin site, under Application Management, click on Manage service applications. In the Type column, look for an item that says Search Service Application.

and credit for this post goes to a super smart coworker.

Monitor and Report on Long Running Crawls

Posted on by
2

Ever needed to know if your SharePoint crawls are running too long? I wrote the below script to keep an eye on my crawls, and report if they are running too long.

In the script, I’m getting the Search Service App. Looping through its content sources, then finding crawls that are running longer than 5 minutes.

#Get PowerShell Snapin
if ((Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null)
{
	Add-PsSnapin Microsoft.SharePoint.PowerShell
}

#get your Search Service App
$ssa = Get-SPEnterpriseSearchServiceApplication "Search Service Application"

#get the content sources from your Search Service App
$contentsources = Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $ssa 


#loop through the content sources
foreach($cs in $contentsources)
{
	#check for crawls that are running
	if ($cs.CrawlStatus -ne "Idle")
	{			
		$cLength = New-TimeSpan -Start ($cs.CrawlStarted) -End (Get-Date) 
		$cLength = $cLength.Minutes
		
		#if the crawl has been running for more than X minutes, send an email
		if($clength -gt 5)
		{
			#email someone that cares
		}
	}
}

SharePoint Crawls and Security Updates

Posted on by
Reply

Keeping an eye on my SharePoint crawls, I noticed some crawls were taking a long time.
The crawls were picking up a few items, but then I noticed the number of security updates.

Thanks to my friend Google, I found this posting on the subject.

A clip from the posting:

Question:

Why do security only crawls take so long?

Answer:

The time difference in crawl can be attributed to expansion of the SharePoint Group and also that the group is at the site collection level and affects items beyond the list. If a Sharepoint group has several thousand users at site collection level, you can see how this can be very expensive. Also, a large number of items within that site collection can add to the delay because new ACL changes will be pushed down to every item affected by the security change.

Question:

How can I work around this and prevent security only crawls from affecting incremental crawl times?

Answer:

Instead of users explicitly added to SharePoint groups, add AD groups instead. Managing adding/removing users from Active Directory security groups will not cause ACL changes within SharePoint. Because of this, no security only crawls will occur.

*Update*

Read this:

http://blogs.msdn.com/b/kaevans/archive/2013/05/06/clarifying-guidance-on-sharepoint-security-groups-versus-active-directory-domain-services-groups.aspx