Hi Rick, Everybody,
I'm the customer that you referred in your post. For sake of information of the group, here are the specs of the systems that we are using:
- Three separated SharePoint Server 2010 farms (Integration, Q&A, Production), two FE + two Application each, individual instance of SQL 2010 R2 each in the SQL Cluster
- Eight different SharePoint 2010 farms (development), each one in one separated box (Win, SP, SQL, VS)
- Everything running inside the same Domain Controller
- No one has Internet access
- Everything using http (not https)
When we try to install a SandBox solution (very simple solution, just a WebPart with one button and one label: if you push the button, you get "Hello world" in the label), we get in all the twelve environments the message "The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request"
- It is possible to install the solution in the "Solutions" gallery
- This message appears at installation of the WebPart in a page (using IE or Firefox)
- The Sandbox Service is running
- The Sandbox processes run using the super-administrator account (the account used to install the farms)
- If we install the solution in a farm outside the DC, everything works perfectly
After hours making traces we found that the Sandbox solution was trying to find certificate revocations using the Microsoft certificate server (crl.microsoft.com). The solution doesn't use any certificate, and all the other functionality in the farms is running as expected.
Based in our conclusions and as Rick mentioned, we were able to make it working using two different approaches:
1 Modifying the Registry Key that controls the check "Check for publisher's certificate revocation" in Internet Explorer (HKEY_USERS\[SID OF THE SERVICE ACCOUNT]\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing. The value of "State" need to be set to "0×00023e00".)
2 Using a host name in the servers: "127.0.0.1 crl.microsoft.com" (I used this solution and worked fine)
The first approaches is not desirable to be implemented in a production environment and, if the account where is applied is changed anyhow, the workaround will stop working. We are implementing right now the second approach as a temporary workarond, being not happy with it, but it works at least.
Very curious if the modification in the host name works also for the other cases described here.
Gr., Gustavo
Gustavo - http://www.gavd.net/ - http://geeks.ms/blogs/gvelez/
