This week we were helping one of our customers to resolve issue with sandbox deployment. The customer uses PDF SharePoint “WSP deployment” feature and was unable to activate sandbox solution. For those, who do not know what “WSP deployment” feature is, I recommend to check the following blog article: http://blog.pdfshareforms.com/deployment-of-pdf-template-as-sandboxed-wsp-solution/

During the activation of WSP package in Solution Gallery (right now we are talking about Sandbox solutions), the following error consistently presented itself.

“The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request”

There are several reasons why sandbox service can throw such error. The most common cause it that SharePoint service cannot check certificate revocation at crl.microsoft.com.

PDF Share Forms Information Worker

PDF forms, but smarter

PDF Share Forms is one of the best smart forms solutions for SharePoint. Our product is a strong alternative to InfoPath and custom app development. PDF, being an ISO standard, is a perfect fit for fixed layout forms that look and feel the same both on mobile and desktop devices. Document management automation empowered by PDF Share Forms that supports digital signatures and workflows brings your business one step closer to the paperless office. User friendly drag-and-drop design makes form creation process very accessible to non IT professionals. PDF Share Forms can use existing PDF forms as templates for new forms, significantly improving document management processes. Normally, a user would access the form via shareable link and fill in the form in the browser. Link can be made public for anonymous submissions. When a form is submitted – the information is extracted from the form and is synchronized with SharePoint

There are 3 methods to resolve this issue:

A. Change registry settings
B. Change host file to point clr.microsoft.com to local machine
C. Change system configuration files of Sandbox service to skip certificate verification in Code Access Security policies.

Option B usually is a “no-go” since IT administrators don’t rely like messing with their servers’ hosts files. Option C has another disadvantage: changing configuration files which provided with SharePoint 2010 means you will have to redo the changes if the files are ever overwritten by a service pack or other reinstallation.

So, we usually proceed with option A: setting WinTrust provider setting to the ‘correct’ value on all servers.

Approach #1 (using UI and a little of PowerShell)

  1. Open SharePoint 2010 Central Administration
  2. Navigate to “Configure service accounts” in Security section

    Selecting ‘Configure service accounts’
  3. Select ‘Windows Service – Microsoft SharePoint Foundation Sandboxed Code Service’ in the dropdown control.

    Locate service account for Sandboxed Code Service
  4. Then you will see which account is used for Sandbox Service. (in our example, it is DOMAINUserCodeServiceAccont)

Now we need to determine Security Identifier (SID) for this service account.

Here comes the SharePoint 2010 PowerShell command:

(Get-SPManagedAccount –Identity "DOMAINUserCodeServiceAccont").Sid.Value

As a result you will get something like this: S-1-5-33-1234504503-987654321-123456789-556677

Now, it is time to check and update registry settings for WinTrust.

  1. Open the registry editor and navigate to:
    HKEY_USERS{SID you obtained earlier}SOFTWARE/Microsoft/Windows/CurrentVersion/WinTrust/Trust Providers/Software Publishing
  2. Change value of “State” key to 0x00023e00.
  3. Restart Sandbox Service
  4. Perform IIS reset

Now, repeat the all 1-4 on all SharePoint servers where Sandbox service is running.

Approach #2 (all PowerShell)

Since this issue is quite frequent in SharePoint 2010 environments with Sandboxed service enabled, we just created a PowerShell script that does it all. You would run this script on all SharePoint servers that run “Microsoft SharePoint Foundation Sandboxed Code Service”.

Write-Host -ForegroundColor White "Getting 'Sandboxed Code Service' instance on current server..."
$srvInstance = Get-SPServiceInstance -Server $env:ComputerName | where {$_.TypeName -eq "Microsoft SharePoint Foundation Sandboxed Code Service"}
Write-Host -ForegroundColor White "Getting SID of process identity that runs Sandbox service instance..."
$sid = $srvInstance.Service.ProcessIdentity.CurrentSecurityIdentifier.Value

$path = "Registry::HKEY_USERS$sid/SOFTWARE/Microsoft/Windows/CurrentVersion/WinTrust/Trust Providers/Software Publishing"
$key = "State"
$oldValue = (Get-ItemProperty -path $path).$key
$newvalue = 0x00023e00

$hexOldValue = "{0:x}" -f $oldValue
$hexNewValue = "{0:x}" -f $newvalue

Write-Host -ForegroundColor White "Current registry value is: $hexOldValue"

If ($oldValue -eq $newvalue)
{
	Write-Host -ForegroundColor White "No change is required."
} else {
	Set-ItemProperty -path $path -name $key -Type DWORD -Value $newvalue
	Write-Host -ForegroundColor White "Registry value is set to: $hexNewValue"

	If ($srvInstance.Service.Status -eq "Online")
	{
		Write-Host -ForegroundColor White "Restarting Sandbox service..."
		Restart-Service SPUserCodeV4
		Write-Host -ForegroundColor White "Restarting IIS..."
		iisreset -noforce
	}
}

PowerShell , first attempts to access Sandbox Server on SharePoint server you are currently running this script;

Then script determines SID (Security Identifier) of service accounts that runs the service.

Then it gets registry value and verifies if update is necessary

PowerShell script then updates the registry and determines if service restart is necessary.

Other causes and solutions

Of course, there are other reasons for sandbox service to throw the error. You can see other possible causes and solutions in a very detailed article by SharePoint Development team: http://blogs.msdn.com/b/sharepointdev/archive/2011/02/08/error-the-sandboxed-code-execution-request-was-refused-because-the-sandboxed-code-host-service-was-too-busy-to-handle-the-request.aspx

Technical details

Strangely enough only very few SharePoint administrators question why do we have to do registry changes. So those few, here is a detailed technical explanation for solution we used above.

To understand technical aspects of our change, we should answer on the following 4 questions:

  1. What is “WinTrust?”
  2. What does “Software Publishing” provider do?
  3. What does my current value of “State” registry key mean?
  4. And what does magic value “0x00023e00” mean?

First of all, WinTrust is a name (and DLL) of Microsoft Trust verification services, which provide a common API for determining whether a specific subject can be trusted.

For example, when using Sandboxed WSP software, the service application needs to answer the following question: Is (this embedded in WSP code) trusted (to be labeled as provided by a trusted software publisher) according to the (Software Publisher Trust Hierarchy and System Settings)?

The answer to the question depends on the several factors:

  1. Type of information being verified for trust;
  2. The Trust Administrator’s local system policy regarding who and what to trust;
  3. The Trusted Authority who produced the subject.

Trust verification services are implemented by trust providers. There is a built-in trust provider: Software Publishing. The Software Publishing trust provider allows a calling application to determine whether a software component contains digital signatures that identify it as being authentic software released by a publisher that is trusted on the local user’s system.

Software Publishing trust provider uses registry key (on per user basis) to specify trust policy flags. The policy flags are defined as enumeration of WintrustGetRegPolicyFlags (you can see details here: http://msdn.microsoft.com/en-us/library/aa388197).

The WintrustGetRegPolicyFlags can have the following combination of bitwise values:

Flag Value Meaning
WTPF_TRUSTTEST 0x00000020 Trust any test certificate.
WTPF_TESTCANBEVALID 0x00000080 Check any test certificate for validity.
WTPF_IGNOREEXPIRATION 0x00000100 Use expiration date.
WTPF_IGNOREREVOKATION 0x00000200 Do revocation check.
WTPF_OFFLINEOK_IND 0x00000400 If the source is offline, trust any individual certificates
WTPF_OFFLINEOK_COM 0x00000800 If the source is offline, trust any commercial certificates
WTPF_OFFLINEOKNBU_IND 0x00001000 If the source is offline, trust any individual certificates. Do not use the user interface (UI).
WTPF_OFFLINEOKNBU_COM 0x00002000 If the source is offline, trust any commercial certificates. Do not use the checking UI.
WTPF_VERIFY_V1_OFF 0x00010000 Turn off verification of version 1.0 certificates.
WTPF_IGNOREREVOCATIONONTS 0x00020000 Ignore time stamp revocation checks.
WTPF_ALLOWONLYPERTRUST 0x00040000 Allow only items in personal trust database.

Source: “C:Program FilesMicrosoft Visual Studio 8VCPlatformSDKIncludeWinTrust.h”

In our experience the most common value is ‘0x00023c00’. If we use the table above, we can see that such value is a bitwise combination of the following flags:

  • WTPF_IGNOREREVOCATIONONTS
  • WTPF_OFFLINEOKNBU_COM
  • WTPF_OFFLINEOKNBU_IND
  • WTPF_OFFLINEOK_COM
  • WTPF_OFFLINEOK_IND

PDF Share Forms Information Worker

PDF forms, but smarter

PDF Share Forms is one of the best smart forms solutions for SharePoint. Our product is a strong alternative to InfoPath and custom app development. PDF, being an ISO standard, is a perfect fit for fixed layout forms that look and feel the same both on mobile and desktop devices. Document management automation empowered by PDF Share Forms that supports digital signatures and workflows brings your business one step closer to the paperless office. User friendly drag-and-drop design makes form creation process very accessible to non IT professionals. PDF Share Forms can use existing PDF forms as templates for new forms, significantly improving document management processes. Normally, a user would access the form via shareable link and fill in the form in the browser. Link can be made public for anonymous submissions. When a form is submitted – the information is extracted from the form and is synchronized with SharePoint

In order to change ‘State’ value from ‘0x00023c00’ to the magic value ‘0x00023e00’, we need to add flag WTPF_IGNOREREVOKATION. This flag will set policy for trust provider to ignore revocation check.

Now, we have answered all technical questions and we can make educated changes to your server registries.

7 thoughts on “Error: “The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request””

  1. Thanks! The script saved a lot of time for me 🙂
    // Anyway, in my case, “Network Service” is used for Sandbox Service and I can’t find its SID

  2. Hey neither method works for me… Particularly while using powershell I am facing a erros such as, Get-ItemProperty : Cannot find path HKEY_USERS************** because it does not exist…
    Any Ideas?

    Thanks.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.