Share via

Plan sandboxed solutions (SharePoint Foundation 2010)

  • Article

 

Applies to: SharePoint Foundation 2010

Sandboxed solutions in Microsoft SharePoint Foundation 2010 restrict access to network and local resources to provide greater security and stability. You can use sandboxed solutions for load balancing solutions, for solutions that have not been fully tested, and to deploy user solutions in a hosted environment. Sandboxed solutions run in a separate worker process so that they cannot access resources that belong to other solutions, and they have limited access to local and network resources.

When you plan sandboxed solutions, decide first whether to use sandboxed solutions at all. You should determine whether your primary consideration is performance or security. A farm that uses sandboxed solutions generates more worker and proxy processes than a farm that does not use sandboxed solutions. Using sandboxed solutions provides more process isolation, which improves the security of your farm.

For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010) and Sandboxed Solutions (https://go.microsoft.com/fwlink/p/?LinkId=220257).

In this article:

  • Determine when to use sandboxed solutions

  • Plan to load balance sandboxed solution code

  • Determine where to deploy sandboxed solutions

  • Determine who can deploy sandboxed solutions

  • Determine which site collections will run sandboxed solutions

  • Plan resource usage quotas for sandboxed solutions

  • Plan sandboxed solutions service tiers

  • Plan sandboxed solutions governance

Determine when to use sandboxed solutions

Using sandboxed solutions is appropriate in scenarios where you want to load balance solutions across multiple servers, or where you want to provide the ability to run code that has not been fully tested or that your organization does not support. Sandboxed solutions can play a valuable part of a scaled deployment path for developers in your organization, from their test environment to a sandboxed solution in the production environment. Sandboxed solutions can later be changed to full trust status by a farm administrator when the solution is shown to be safe for full deployment.

It is especially appropriate to use sandboxed solutions in the following scenarios:

  • When you want to load balance solutions between multiple SharePoint Foundation servers.

  • When an organization wants to run code for employees on a production SharePoint Foundation site, and that code has not been rigorously code-reviewed and tested.

  • When an Internet hosting provider wants to let the owners of hosted SharePoint Foundation sites upload and run custom code.

When you use sandboxed solutions, you must start the sandboxed solutions service on each server on which you want to run the sandboxed solutions.

Plan to load balance sandboxed solution code

You can select one of two load balancing schemes for sandboxed solutions. Based on the load balancing scheme, Microsoft SharePoint Foundation 2010 determines which server to run the solution on. In local load balancing, the solution runs on the same server that received the request. If you select remote load balancing, the server that the solution runs on is selected based on solution affinity, and the sandboxed solution is run on a server where it is already loaded and has already been run. This saves time in servicing the request for the solution. In both cases, each server that will host sandboxed solutions must be running the sandboxed solutions service.

Your load balancing choice determines the model that is used by the whole SharePoint Foundation farm. You cannot use a mixture of local and remote load balancing, but instead you must decide to implement one or the other. When you are deciding which mode to implement consider the following:

  • Local mode requires less administration, but its scalability is limited by the resources of the local server.

  • Remote mode is more scalable than local mode. However, it requires administrative tasks to be performed on more servers.

You obtain better performance by using the remote load balancing model in a SharePoint Foundation farm where there are multiple servers on which to run sandboxed solutions. If you are using sandboxed solutions as part of a development process, and you want to keep them restricted to the server from which they are called, use the local mode load balancing.

For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).

Determine where to deploy sandboxed solutions

Sandboxed solutions are deployed at the root of a site collection. Anyone who is a site collection administrator can deploy a sandboxed solution. When it is deployed in a site collection, the sandboxed solution can be used anywhere in that site collection.

You can decide to run sandboxed solutions only on certain servers in your SharePoint Foundation farm or on all servers. To enable sandboxed solutions on a server, you must enable the sandboxed solutions service. This service must be enabled on every server on which you want to run sandboxed solutions.

Determine who can deploy sandboxed solutions

When you plan for the user roles that are involved in deploying sandboxed solutions, you must determine who will be authorized to deploy the solutions and who will be authorized to administer the solutions. Members of the site collection administrators group can deploy sandboxed solutions.

You must be a member of the farm administrators group to perform administrative tasks such as enabling or disabling the sandboxed solutions service, blocking or unblocking a solution, and adjusting or resetting quotas and quota templates.

Note

It is not enough to be a site collection owner: To deploy and activate a sandboxed solution, you must be a site collection administrator for the site collection where you are deploying the sandboxed solution.

Because farm administrators can change sandboxed solutions to fully trusted solutions that can be deployed anywhere on the farm, you should make sure that you limit the membership of the farm administrators group to appropriate users. The same consideration applies to adding users to the site collection administrators group if there is any concern over the security of the sandboxed solutions that are being deployed.

Determine which site collections will run sandboxed solutions by using quotas

Sandboxed solutions can be enabled or disabled on specific site collections by adjusting their quotas. If you set the quota for sandboxed solutions to 0 on a specific site collection, sandboxed solutions will not run on that site collection. In this manner you can fine-tune the use of sandboxed solutions in your farm.

To plan where you want to deploy sandboxed solutions, you should consider the following:

  • Which servers will run the sandboxed solutions service.

  • Which site collections will be able to run sandboxed solutions.

If you enable sandboxed solutions on some site collections, you should disable them on the remaining site collections by setting the quotas on those site collections to 0.

Plan resource usage quotas for sandboxed solutions

Sandboxed solutions are monitored for resource usage based on default quotas, which are monitored per site collection. If a sandboxed solution exceeds the cumulative total of the resource points, all sandboxed solutions in that site collection are disabled for the rest of the day. This helps administrators know when a particular sandboxed solution is making too many demands on shared resources or —in some cases — when a site collection that contains a resource-intensive sandboxed solution requires an increased quota.

Resource points are accrued for a whole site collection as sandboxed solutions run. When you view the resource measures in a quota you see the number of resources per point; these are the number of times that a particular resource can be used until a single resource point is accrued. When the resource usage reaches the limit that is specified by the ResourcePerPoint property, the site collection accrues a resource point. If the cumulative number of resource points exceeds the quota for a site collection, all sandboxed solutions in the site collection will be disabled for the rest of the day.

The default resource point limits are satisfactory for most scenarios. However, you can adjust individual resource point limits to permit increased limits where they are suitable. For more information about how to adjust individual resource point limits, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

When you plan quotas for sandboxed solution, you should consider the following questions:

  • Will you adjust resources per point for any of the resource measure categories?

    You can define the resource limits for all sandboxed solutions. In some scenarios it might make sense to limit a particular resource that is more sensitive to misuse or over-consumption of resources, such as CPU cycles on a server where the processor is already taxed. You can adjust resource limits to restrict sandboxed solutions that might overuse resources. You should examine the list of resources that are monitored by the sandboxed solutions quotas and determine whether you have to make adjustments.

  • Will you adjust absolute limits for any of the resource categories?

    An absolute limit is the highest or lowest limit that a resource usage per request can reach before the request is stopped. If a particular resource category is overused and reaches the absolute limit, the sandboxed solution will be stopped. You should evaluate the resource categories to determine whether any of them require adjustment to an increased or lower absolute limit.

For a list of the individual resource measures and the minimum threshold, absolute limit, and resources per point for each resource, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010 (https://go.microsoft.com/fwlink/p/?LinkId=217149). For information about how to configure the absolute limit and the resources per point for specific resource measures, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

Plan sandboxed solutions service tiers

Based on the average number of resources that sandboxed solutions use, they can be grouped into tiers in the sandboxed solutions service. A tier in the sandboxed solutions service contains one or more worker processes in which sandboxed solutions run. Each sandboxed solution runs in its own application domain, which is reused when the solution is invoked. By default, all solutions run in the sandboxed solutions service in one tier. You can configure additional tiers and worker processes within the sandboxed solutions service to separate solutions for performance, security, and reliability. Sandboxed solutions automatically separate into additional tiers based on their resource usage. For more information about tiers, see Sandboxed solutions overview (SharePoint Foundation 2010) and Sandbox Tiers (https://go.microsoft.com/fwlink/p/?LinkId=217145).

You can configure as many tiers as necessary, and as many worker processes, connections, and application domains as you want. However, creating too many tiers adversely affects the performance of your SharePoint Foundation server. When you plan to configure the sandboxed solutions service, you should consider the following questions:

  • How many tiers are you going to create?

    Configuring multiple tiers enables you to separate "well-behaved" sandboxed solutions from "poorly behaved" sandboxed solutions, which frequently crash or use lots of resources. By running sandboxed solutions in separate tiers, you reduce the effect that poorly behaved sandboxed solutions have on well-behaved sandboxed solutions. This helps make the system more stable and responsive. In general, you should not have to have more than two or three tiers to achieve separation of sandboxed solutions.

  • For each tier, how many worker processes are you going to set?

    The largest number of sandboxed solutions that run at the same time in a particular tier can be calculated by using the following formula:

    Number of work processes in the tier × maximum connections per process = largest number of concurrently running sandboxed solutions in a single tier

    By configuring tiers to run more worker processes, you can run more sandboxed solutions concurrently in the farm. Adding more worker processes can increase throughput on a given server, but only up to a certain point. Because the overhead of additional worker processes can reduce the overall throughput of a server, you should configure fewer than 20 worker processes across all tiers on a single server.

  • How many connections per process must you have?

    The maximum number of connections per process should always be less than or equal to the number of application domains per process. If two sandboxed solutions are running in the same process at the same time and one of them crashes, the other will also crash. The larger the number of maximum connections per process, the larger the number of sandboxed solutions that can run in the same process at the same time, which makes it more likely that a sandboxed solution that crashes will affect other running requests. It is typically better to have smaller numbers of connections per process in tiers in which the ResourceMaxValue property is higher, where the sandboxed solutions are typically less reliable. More reliable sandboxed solutions run in tiers where the ResourceMaxValue property is lower. In general, you should increase the number of connections per process to increase throughput, which will reduce the effect caused by other sandboxed solutions that might crash in the same process.

  • How many application domains per process must you have?

    Only one sandboxed solution can run in each application domain at any time. Therefore, application domains represent the number of sandboxed solutions that can be loaded at the same time. You should plan to configure at least as many application domains as the number of connections per process.

For information about how to configure the tiers, see Configure sandboxed solutions service tiers (SharePoint Foundation 2010).

Plan sandboxed solutions governance

As long as you are still planning for sandboxed solutions, you should consider your processes for governance issues. This includes the following:

  • At what point will the farm administrator block or unblock a sandboxed solution? Identifying the administrative policy for blocking and unblocking sandboxed solutions can help eliminate confusion.

  • At what point will you transfer a sandboxed solution to the global catalog as a full trust solution? This decision applies to solution code that is developed by your organization’s developers. You should establish a policy for determining what level of testing is required for a sandboxed solution to be considered ready for production use in your organization.

  • When you plan for who can deploy sandboxed solutions, will you decide to add people to the site collection administrators group or establish a procedure for a limited number of site collection administrators to deploy sandboxed solutions on behalf of their users? Depending on the security concerns in your organization, you can decide to add people directly to the site collection administrators group instead of requiring them to ask permission to deploy the sandboxed solution.

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)

Other Resources

Sandboxed solutions administration (SharePoint Foundation 2010)
Sandboxed Solutions Resource Center
Sandboxed solutions architecture (https://go.microsoft.com/fwlink/p/?LinkId=177368)
Sandboxed Solutions in SharePoint 2010
Installing, Uninstalling, and Upgrading Sandboxed Solutions in SharePoint 2010