SharePoint 2010 Sandboxed Solutions

With all the publicity surrounding SharePoint 2010’s new features, there’s an important feature that’s often undersold: sandboxed solutions. Sandboxed solutions, sometimes called user solutions, are a big deal, especially for SharePoint administrators. Put simply, they allow custom enhancements to be easily and safely deployed into your SharePoint environment. In this article, I’ll explain what sandboxed solutions are, help you recognize their advantages and disadvantages, and make sure you understand how to deploy and manage them. Before I get too far, though, I’ll clarify what a solution is in the context of SharePoint.

In addition to being a powerful product, SharePoint is also platform where custom applications can be developed to make SharePoint a better fit for specific needs. For example, you can develop new web parts, workflow, master pages, and many other customizations. The term solution, in this context, refers to the packaging of these customizations into something called a solution package or WSP.

Solution packages were introduced in SharePoint 2007 and are the preferred way of packaging and deploying all types of custom code enhancements. Traditional solution packages from previous versions are now called farm solutions, because they’re added into the farm. Farm solutions are deployed into the file system of your SharePoint web servers. Sandboxed solutions are also based on WSP packages, but are deployed into a site collection and are executed very differently.

Advantages and Drawbacks

The biggest problem with SharePoint’s custom enhancements is the support burden they add. Custom code is the number one root cause for SharePoint support problems, and when it causes problems, it’s usually the SharePoint administrator who’s implicated, not the developer. A troublesome web part, for example, can crash pages where it’s used, and depending on the severity, can take down an application pool and the web application with it. Sandboxed solutions, conversely, aren’t able to destabilize the farm.

Another advantage of sandboxed solutions is their ease of deployment. The SharePoint farm administrator should first review and then must deploy farm solutions. There’s not much guidance out there on how to review, and it really boils down to whether the solution is trusted or not. With sandboxed solutions, there’s no need for a review. They’re simply uploaded and deployed at the site collection level, which gives you the option of empowering site collection administrators with this responsibility. This is better for admins and better for business.

If your SharePoint system is hosted in the cloud, such as with SharePoint Online, you’re probably not able to take advantage of farm solutions. Sandboxed solutions, because they’re safe, can be deployed and used in both hosted and on-premise installations.

There are some limitations to sandboxed solutions, however. Safety features restrict the types of customizations that can be deployed as sandboxed solutions. There are two main ways that sandboxed solutions are controlled: a code access security (CAS) policy and a subset of SharePoint API calls that aren’t allowed. For example, a custom workflow developed with Visual Studio can’t be deployed as a sandboxed solution. To ensure its safety, all code originating from sandboxed solutions is restricted from performing functions outside the sandbox. This includes accessing the file system, registry, and network resources. So there’s no calling into external web services or accessing your ERP databases.

Some developers will lament these limitations, saying they’re too restrictive. As a developer myself, I understand. Sandboxed solutions won’t be the way to deploy all forms of custom code, but they’re certainly valid for a percentage of them. For organizations with hosted SharePoint, these solutions bring a much welcomed degree of flexibility. Also, sandboxed solutions support calling into separate, trusted code running outside the sandbox. This is called full-trust proxy and is a way of working around these limitations.

Running Code

Code that’s contained within a sandboxed solution is run differently than out-of-the-box code or code in a farm solution. For code not using this full-trust proxy, there are two processes that are used. Figure 1 depicts how this works at a high level. Let’s say that a user requests a page that’s running a custom web part that’s deployed inside a sandboxed solution. As with all browser requests, the Web Front End (WFE) running Microsoft IIS receives it first.

A part of the IIS worker process (W3WP.exe), called the Execution Manager, recognizes this as a special request and issues its own request to the sandbox service (SPUCHostService.exe) that may be running on a different server (which I call a sandbox host). The sandboxed service will then create a new worker process (SPUCWorkerProcess.exe), if needed, to execute the request. This worker process will first verify the code to ensure it is allowed and will then execute it, returning the output to the WFE.

This design provides many benefits. One is that you can have multiple sandbox host servers that can execute requests, giving you fault tolerance and scalability. Another is that if the custom code uses resources such as CPU or RAM heavily, it won’t slow down your WFE servers. You also have other options such as monitoring and throttling usage which is covered later.

Allowing Sandboxed Solutions

Before you can run sandboxed solutions, you must enable them by starting the Microsoft SharePoint Foundation Sandboxed Code Service. You can do this from Central Administration, System Settings, Manage services on server. Starting this service on a server in the farm makes the server a sandbox host.

You can, optionally, define how your sandbox requests are load balanced. The setting is located in Central Administration, System Settings, Manage user solutions. One option is to run the sandboxed code on the same WFE that received the browser request. The code will still run in separate processes, as shown in Figure 1, but the WFE won’t send the request to a different server. This option is a faster, but requires that you run the sandboxed code service on each WFE server—in other words, all your WFE servers are also sandbox host servers. This option is best if you have a small farm or don’t use many sandboxed solutions.

The other option, which is the default, is to route the request from the WFE to one of the sandbox host servers. Doing it this way allows you to distribute the requests across as many servers as you need. You define the servers by starting the sandboxed code service on them. These servers can be WFE servers or other application servers in your farm. This option is best if you want more control over where the code runs, if you have many sandboxed solutions, or if the code is resource heavy.

Deploying Sandboxed Solutions

Deploying sandboxed solutions is very easy and anyone who is a site collection administrator can do it. There are two steps. First, upload a WSP solution in the Solutions gallery that’s part of each site collection. You can access this gallery by going to Site Settings, Solutions from the top-level web site in a site collection. Farm administrators can also do it by running the Add-SPUserSolution PowerShell cmdlet from the SharePoint 2010 Management Shell.

Once the solution is uploaded, you need to activate it, which is done from the same screen. Activating a solution unpacks the WSP and makes the solution available to users in the site collection. To do this from PowerShell, use the Install-SPUserSolution cmdlet. Note that members of the owner group can upload WSP solutions, but only site collection administrators can activate them.

In addition to uploading sandboxed solutions, you can browse an online gallery of them from Microsoft. The concept is just like that of Apple’s App Store. At the time of this writing, there are no solutions available, but this will soon change. Expect this to become a common way to search and download SharePoint enhancements.

Monitoring Sandboxed Solutions

To prevent sandboxed solutions from overusing system resources, you can monitor and set resource quotas. The quota is set the site collection as whole, not on individual solutions. In Central Administration, go to Application Management, Configure quotas and locks and you’ll see this setting near the bottom of the screen, as Figure 2 shows.

Once you’ve seen the figure, I’m sure you’ll wonder what the display means by 300 points. SharePoint tracks resource usage based on CPU and RAM usage, number of SharePoint queries, number of exceptions, and some other factors. In total, it takes 14 different measurements, and each measurement’s resource usage is converted into a point score. Each solution’s point score is tracked separately, and the sum total for all solutions in a site collection count against the site collection’s quota.

By default, the resource quota is 300 points for all sandboxed solutions in a site collection. Whether this is too much of too little will require some benchmarking with the solutions you use, but it should be a good starting number.

In addition to the window Figure 2 shows, you can use the following PowerShell script to adjust the resource quota for a site collection:

$site = Get-SPSite "http://siteurl"$site.Quota.UserCodeWarningLevel = 200$site.Quota.UserCodeMaximumLevel = 400

Using PowerShell, you can also adjust how these points are calculated. For example, if you have plenty of processing power, you can make CPU operations less expensive. To see the complete list of all 14 counters and how points are calculated for each one, run this PowerShell command:

[Microsoft.SharePoint.Administration.SPUserCodeService]::Local.ResourceMeasures | Select Name,ResourcesPerPoint

For space reasons, I won’t print them all and will just introduce on one of them, CPUExecutionTime. Its default value is 200 resources per point. To make CPU execution time “less expensive,” just increase this number. Use this script:

$cpu2=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local.ResourceMeasures | where {$_.Name -eq “CPUExecutionTime”}$cpu2.ResourcesPerPoint = 400$cpu2.Update()

With this setting, 400 units of CPUExecutionTime equals one point. Similarly, to make CPUExecutionTime more expensive, use a smaller number. My advice is to not change these arbitrarily and only if necessary. Please note that these calculation rules are set at the farm level, so changes you make apply to all solutions in all site collections.

From the Solutions gallery where you add and activate a solution, you can also see current usage statistics for the currently activated solutions, as Figure 3 shows. Again, these are metered and count against the site collection quota that has been established.

The current usage is the usage sum of all activated solutions. By default, these resource points are recalculated every 15 minutes and get reset daily. Once the quota has been reached, no code from within any sandboxed solution can be run until a daily timer job runs which resets the value for the next day. Unfortunately, there’s no way to reset usage for a single day for a single site collection.

Other Options

In addition to monitoring, you can completely block certain solutions. This is useful if you encounter a solution that just causes too many problems. You can upload the WSP package, and SharePoint will prevent anyone from uploading it to any site collection. This is done from the same screen where you set the load balancing settings (Central Administration, System Settings, Manage user solutions).

You can also block solutions based on certain characteristics found in packages or code. This requires a developer to write the validation logic, but gives you precise control over which types of solutions you want to allow run in your farm. For example, you may want to block solutions that use event receivers.

Now you’ve learned what sandboxed solutions are, how they differ from traditional farm solutions, and how to add, deploy, and monitor their usage. While it’s too early to say for certain, knowing the popularity of SharePoint, the need to customize, and the inevitable movement towards the cloud, I predict these will become a big deal as SharePoint 2010 matures. If nothing else, they’ll ease the cost and burden of maintaining a SharePoint 2010 investment, and that’s better for all.