Crawl errors: Sandbox worker pool is closed RRS feed

  • Question

  • Hi

    We are currently setting our SharePoint farm and got into an issue I could not find any information about.

    After setting multiple content sources we get the following errors that can be found on the Crawl Log for some of the items:

    Processing this item failed because of an unknown error when trying to parse its contents. ( Error parsing document 'http://site/url'. Sandbox worker pool is closed.; ; SearchID = 6A9F9644-31EE-4796-B355-D92C35D50973 )


    The content processing pipeline failed to process the item. ( Error parsing document 'http://site/url'. It was not possible to acquire a worker. Proxy '131' failed to acquire worker. Sandbox worker pool is closed.; ; SearchID = 194A2340-CB92-4F36-AAB8-C55EC794F7C3 )

    A few more characteristics:

    • This does not occur for all items on content source, but only for a few of them.
    • When it starts it takes a very long time until the crawl completes.
    • After rebooting the back end and the search query servers this error is usually gone (we can start crawling items successfully) but after a few hours it is back.

    Any insight would be much appreciated.



    • Edited by abz Friday, January 10, 2014 1:17 PM
    Friday, January 10, 2014 1:14 PM


All replies

  • Do you have enough memory on the server running the content processing component?  You should measure the memory usage as the crawl is occurring to determine if you are starving the server.

    Chris Givens CEO, Architecting Connected Systems Blog Twitter

    Monday, January 13, 2014 3:00 AM
  • Hi Avishay,

    According to your description, my understanding is that you got an error when you used Search in SharePoint 2013.

    For resolving your issue, you can do as the followings:

    1. Open Local Security Policy
    2. Click Local Policy->User Rights Assignment
    3. Make sure that the search service account has the following rights:
      • Replace a process level token
      • Adjust memory quotas for a process
      • Impersonate a client after authentication

    After implementing the above changes, please run a clear configuration cache.

    More information, please refer to the link below:

    I hope this helps.



    Wendy Li
    TechNet Community Support

    Monday, January 13, 2014 4:40 AM
  • Hi

    First, our servers have quite a lot of memory so this was certainly not the case.

    For the security policy settings - two of them were already set. We have set the third one, cleared configuration cache and restarted the servers. Then we got into another issue which may or may not be related as all our servers stopped connecting via SSL 3.0 and only SSL 2.0 connections were available. This followed by a lot of SCHannel errors on the event viewer. Fixed that using registry changes (with assistance of IISCripto tool - and another restart to all servers and now everything works fine.

    I will mark it as answer, though it might be related to other issues we also fixed.

    Thank you for the support.


    Wednesday, January 15, 2014 3:49 PM
  • Avishnay

    I know this is an old thread, but there's a critical point missed thus far in the replies that it will be helpful to document for future readers.

    We've experienced the same issue and it is simple to understand resolve, once you know the cause.

    To begin with, when you first install the Search Service Application, the setup user administrator account configures Local Security policy on those servers in the farm hosting SharePoint Server.  In order for the service application to fully function, it requires specific local user rights, and these have already been noted by other responders, namely:

    • Adjust memory quotas for a process
    • Impersonate a client after authentication
    • Replace a process level token

    There should be no need to configure these manually.  These are configured by the installation process under the administrator account used to configure the Search Service application.

    These user rights are highly privileged and usually controlled by network administrators through appropriate GPO configuration, and this GPO is regularly pushed out to the members of the active directory.  For example, in my environment, the GPO is pushed out every 20 minutes.  Thus, on performing a fresh install of the Search Service Application, the user rights assignments that the installation configured will last for about 20 minutes and then go away.  We've even observed this by taking regular exports of User Rights Assignments and then seeing them change back after awhile; and this experience was repeatable.

    To resolve this, we had two options: modify the forest GPO or add the Search Service account to the local administrators group on each server hosting SharePoint server.  The GPO is not controlled or managed by my department and requires formal change request and justification.  We are currently engaging that process.  In the mean time, to ensure search operatability, we have added the Search Service account to the local administrators group, which is granted most user rights by default.

    In your case, I would first confir with your network and system admins and find out if GPO is managed and what the update shedule is.  In the mean time, just add the Search Service account to the local administrators group.

    As an aside, I have found that permissions issues lay at the root of about 80% of the issues I encounter and troubleshoot as a SharePoint systems administrator.


    Thursday, June 5, 2014 6:48 PM
  • I've added the search service account to the local admin group of the application / front end server but im still experiencing this issue. We have a GPO being applied to all of our servers which is overriding the local policy settings that you have identified here, but "ADMINISTRATORS" is one of the allowed groups.

    Im not sure why im still receiving the error, given that the SSA is a local admin, but the behavior is exactly as you describe here... after the initial setup the crawls fail with "failed to acquire a worker"

    Any other ideas?

    Wednesday, July 16, 2014 2:13 PM
  • Thestephenh

    The Administrators group is added to most of the User Rights Assignments security settings, but not all.  There are three critical user rights assignments that search service accounts must have:

    • Adjust Memory quotas for a process
    • Impersonate a client after authentication
    • Replace a process level token

    Adding the search service accounts (eg, spSearch, spContent) to the Administrators group will ensure that these accounts have the first two user rights, but not the last. You can see this for yourself by going to Local Security Policy control panel, expanding User Rights Assignments, and then perusing the various User Rights Assignments listed and looking for Administrators

    I have found from experience, that if search service accounts have the first two user rights, search will still function and you will see all search components up, when you go to the Search Administration page, but crawls will not be able to successfuly read all content items and you may see 10 - 50% of these items generating crawl errors.  Additionally, crawls may become unusually long - lasting for many days.  Once this last user right was granted, all these problems went away. 

    If GPO is controlled, system administrators will need to grant these three user rights assignments to the search service accounts.  The first one is pretty sensitive, and your NOS may not allow this user right to be granted.  So, adding search service accounts to the Administrators group may be the only option for getting this right configured.  The third user right is not so sensitive, and you will need to present your case to your IT management and your NOS to allow this to be granted to your search service accounts.  You absolutely need all three if your users want to be able to search all content successfully, so, you have a pretty good argument for getting this from your NOS or your sysadmin.

    If after granting all these rights, you still find errors appearing in your crawl reports, I would recommend removing and rebuilding the search service application from scratch.  It's actually easy to do, and a powershell script almost completely automates this.  For example, it takes me about half an hour to rebuild it for a five server farm (2 WFEs); and then performing a new index takes less than an hour for 60 GB of content.

    Wednesday, July 16, 2014 5:20 PM