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.
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 | 1x10^11 | 1x10^11 |
| ProcessHandleCount | Windows handles count | items | 10,000 | 1,000 |
| ProcessIOBypes | Windows handles count | items | 0 | 1x10^8 |
| ProcessThreadCount | Thread count in overall process | instances | 10,000 | 200 |
| ProcessVirtualBytes | Memory consumed | bytes | 0 | 1.0x10^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.
