Sandboxed Solutions

SharePoint 2010 introduces a new feature that grants site collection administrators, the privilige to upload solutions on their own… No need for a farm admin… Yikes!?!

Allowing site collection administrators to do this will allow organizations to deploy solutions quickly, but sandboxed solutions do not provide quick deployment by sacrificing stability or security.

Deploying a Sandboxed Solution – [Site Collection Administrator]

Let’s say that you’re a site collection administrator and you find a webpart on codeplex that meets a business need. In the past, you would need a farm admin to deploy the solution after he/she deploys it in testing environment to make sure that the webpart isn’t going to introduce problems to the farm. The validation process could take a long time and by then, maybe you don’t need it anymore.

So, how does a site collection admin deploy a solution without the farm admin?

In the site settings page, under the Galleries section, click the “Solutions” link


Once you select Solutions, you’ll be redirected to the solutions gallery. As you can see in the next image, the Solutions tab is selected. In the ribbon, the site collection administrator can simply click on Upload Solution and point to the desired wsp file. Once the solution has been uploaded, you’ll see it in the list of solutions on the page. You’ll also need to activate it. To do this, you’ll simply select your solution and click the Activate button found in the ribbon. Once activated, you can freely use your solution within your site collection.

Stability – [Farm Administrator]

Now that the solution is activated, how do we ensure that the solution doesn’t make your environment unstable. SharePoint 2010 allows you to define resource quotas that allow you to monitor your solutions and that will shut down a solution for the day or until the farm admin can reset the solution. So if a developer creates a solution that crashes consistently or runs too many list queries or misuses resources, the farm admin can block the solution until the developer can correct it.

In Central Administration, go to Application Management > Specify Quota Templates.

In this page, you can specify your quota threshold that’s based on a point system.



The following is a list of resources that are monitored:

Resource Description Units Resources per Point Absolute Limit
AbnormalProcessTerminationCount Abnormally terminated process occurrence 1 1
CPUExecutionTime CPU Execution Time for site seconds 3,600 60
CriticalExceptionCount Critical Exception Events events 10 3
InvocationCount Solution Invocation Events events 10 3
PercentProcessorTime Percent CPU usage by solution percentage 85 100
ProcessCPUCycles Solution CPU cycles cycles 1×10^11 1×10^11
ProcessHandleCount Windows handles count items 10,000 1,000
ProcessIOBypes Windows handles count items 0 1×10^8
ProcessThreadCount Thread count in overall process instances 10,000 200
ProcessVirtualBytes Memory consumed bytes 0 1.0×10^9
SharePointDatabaseQueryCount Number of SharePoint database queries instances 20 100
SharePointDatabaseQueryTime Elapsed time to execute query seconds 120 60
UnhandledExceptionCount Number of unhandled exceptions instances 50 3
UnresponsiveProcessCount Number of unresponsive processes instances 2 1

Now, Microsoft didn’t provide Sandboxed Solutions without ensuring that it won’t wreak havoc on your farm. So, how did they make sure that these untrusted solutions can run without harming the farm? Well, typically when a solution is run, it’s managed by the w3wp worker process, also known as the IIS worker process. Sandboxed solutions however are managed by different processes. When a user makes a request to the Front End server, the FE web server identifies the code as a sandboxed solution. Instead of loading the IIS worker process, it contacts the SPUC worker process host service. This is essentially the sandbox environment. The host service then calls the SPUC worker process which will run the untrusted code and grant it access to a subset of the SharePoint Object Model. Now, this isn’t a smaller version of the object model. This is, in fact the full object model, but the SPUC worker process ensures that portions of it are not allowed. Some of the things that aren’t allowed are connections between web parts, editor parts, cross site queries and access to databases and file systems. These restrictions will ensure that your solution doesn’t gather information that is not within the scope of the site collection. Now you can have, for example, a site collection for clients and you don’t have to worry about a web part being configured to access information from various client site collections.