Application Hosting and Customization Introducing Sandboxed Solutions Executing Code in the Sandbox Sandbox Resource Monitoring

Developers build custom solutions Administrators can only secure solutions with CAS Hard to control what is being done in custom code Biggest cause of SharePoint support cases: custom code Design, build, and test customizations Developer Install and monitor customizations Administrator Activate and use customizations Site Collection Owner

Developers build custom solutions Site collection owners deploy, activate and implement the customizations Administrators leverage resource monitors to check site collection usage Automatic triggers “turn off” custom solutions in a site collection that are too expensive and taxing on the server Design, build, and test customizations Developer Monitor customizations Administrator Deploy, activate and use customizations Site Collection Owner

Allow a subset of ‘full’ solution features Code executes in sandbox Are deployed by a Site Collection administrator Stored in the Solution Gallery

Sandboxed solution: site collection owners can upload to SharePoint Empowers site collection owners to deploy new functionality w/o involvement of IT Local/remote development options Self-regulating and monitored by IT Limited set of permissions & functionality Resource quotas established & monitored by IT Secure: site collection owner is in control

Sandboxed solutions are important because Solve SharePoint hosting issues in corporate environments Hosted environments much easier to manage Reduces time to deploying custom solutions Removing process of getting code approved and deployed by IT Improves stability of SharePoint servers Now badly performing code isolated to site collection rather than potentially bringing down an entire server

Allows a subset of the full capabilities in the SharePoint API Secure – enforcing the sandbox Execute in a partially trusted environment Code executes in a special service process Subject to CAS Validation framework Provides way to do custom farm wide validation for the deployed packages Each solution is isolated to its site collection

Web Parts Lists List Templates Custom Actions Workflows Event Receivers Content Types Site Columns …

Root SPWeb of SPSite Solution gallery WebParts.wsp Web Part gallery Per-WFE AssemblyCache \company. intranet.webpart.wsp\ company.intranet.dll Sandboxed Code Serice

In general SPSite and below No SPSecurity No SPSite construction SPSite SPWeb SPList SPListItem

SandboxSandbox AspNetHostingPermission, Level=Minimal SharePointPermission, ObjectModel=true SecurityPermission, Flags=Execution Full Trust wss_usercode.configwss_usercode.config User Code Framework CodeMy.dllMy.dll Other.dllOther.dll System DLL SharePoint DLL SharePoint OM API Block List

Visual Studio 2010 uses IntelliSense to hide full-trust types All code is compiled against the full API Thus, no “sandbox” check at compile time… only at runtime Workaround: change the Microsoft.SharePoint.dll project reference to reference the sandbox’s version [..]\14\UserCode\Assemblies\Microsoft.SharePoint.dll NOTE: Switch it back before deployment! Use this as a temporary test - do not deploy code that references the sandbox’s assembly Full Object Model Subset Object Model MyWebPart.dllMyWebPart.dll ProxyProxy Runtime

Site collection quotas specify the warning and hard limits for number of resources that can be used per day Sum of resource measures are taken across solutions deployed to site collection i.e.: add up CPU Points for all solutions Max of resource utilization measures checked against site collection quota to determine if it should be throttled/blocked

Web Part in a sandbox solution executes 40 SQL queries (via the SharePoint OM) 20 SQL Queries = 1 point (default) Resource usage for this Web Part for the day: = (2 points * # of executions throughout the day) + other counters OOTB resource quota = 300, so one execution of this Web Part = 0.67% of site collection’s daily allocation

Configure site collection quotas from Central Administration Site collection owners can manage and view resource usage from Site Settings » Solution Gallery PowerShell administration Get-SPSite | foreach-object {$_.Quota.UserCodeMaximumLevel = 300} Get-SPSite | foreach-object {$_.Quota.UserCodeWarningLevel = 100} You can also block completely certain solutions in farm level Can be managed from Central Admin level

Sandboxed solutions can be run in two modes: Local Mode: Execute code on WFE Low administration overhead Lower scalability Remote Mode: Execute on dedicated SharePoint servers Load balanced distribution of code execution requests Create custom Load balancers

Restrict the solutions that are allowed to run Install with a farm level feature [GuidAttribute(" FC4-4b66-AF09-AB48AC0F9D97")] public class PublisherValidator : SPSolutionValidator{ [Persisted] List _allowedPublishers; public override void ValidateSolution( SPSolutionValidationProperties properties){ } public override void ValidateAssembly( SPSolutionValidationProperties properties, SPSolutionFile assembly){ } [GuidAttribute(" FC4-4b66-AF09-AB48AC0F9D97")] public class PublisherValidator : SPSolutionValidator{ [Persisted] List _allowedPublishers; public override void ValidateSolution( SPSolutionValidationProperties properties){ } public override void ValidateAssembly( SPSolutionValidationProperties properties, SPSolutionFile assembly){ }

Application Hosting and Customization Introducing Sandboxed Solutions Executing Code in the Sandbox Sandbox Resource Monitoring