Managing SharePoint 2010 Customizations for the IT Pro Name Title Company
Agenda Solution packaging changes and options in 2010 Sandboxed solutions Deployment Monitoring Management
Solution Management and Design Changes in the solution management
Solutions – C hanges Two types of solutions Farm solutions Features deployed to front end Sandboxed solutions End-user submitted solution Features deployed to database – usable in site collection level Solution dependencies Upgrade infrastructure to support life cycle management of deployed functionalities
Solution Deployment Options Full trust deployment Local deployment only More or less the same as in 2007 Sandboxed solution deployment Deployed to a specific site collection by site collection administrators Code runs in a rights-restricted process with limited CAS permissions Server resource usage is monitored against a quota managed by the service administrators
Solution Deployment Considerations Now a design decision -- Farm || Sandbox WFE || App Server || All Some at Farm, others at Site Farm solutions can impact server uptime Sandboxed – limited scope/scale additional management Balance of: Costs – Management/QA Performance – safe/scale Audience - Business Unit/Everyone Time to market – ASAP/When ready
Sandboxed Solutions What are they and why would I use them?
Todays Problems, a big pain … Business Agility Farm Stability Hosting Providers IT Departments Online Collaboration
WSS 3.0’s Challenge Developers build custom solutions Administrators can only secure solutions with CAS Hard to control what is being done in custom code Largest 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
Introducing Sandboxed Solutions Sandboxed solution: site collection owners can upload to SharePoint Agile: enables site collection owners to deploy new functionality without involvement of administrators Local/remote development options Stable: self-regulating and monitored by administrators Limited set of permissions and functionality Resource quotas established and monitored by administrators Secure: site collection owner is in control
Sandboxed Solutions Help Enterprises Sandboxed solutions are important because Solve SharePoint hosting issues in corporate environments Make hosted SharePoint environments much easier to implement and manage Reduces time to deploying custom solutions Removing process of getting code approved and deployed by server administrators Improves stability of SharePoint servers Now badly performing code isolated to an AppDomain within a worker process and visibility is to a single site collection
Overview of the Sandbox 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
Types of Sandbox Solutions A Subset of existing Feature Model Web/Site Scoped Features Many XML constructs: <Modules>, <Lists>, < ContentTypes >, etc. Client JS, Iframe , etc. Supports Web Parts Event Receivers Feature Activation Events Custom Workflow Actions InfoPath Business Logic SPSite SPWeb SPList SPListItem
Sandbox Setup & Deployment Start on select servers to run sandbox processes
Site Collection Administration Solution Gallery -- _catalogs/solutions Empower SC Admins
Defining “The Sandbox” CAS Limited OM Quota/Blocked Solutions External Process
Central Administration Solution Administration Block Solutions Quota Templates
A S eparate Process User Code Service (SPUCHostService.exe) Sandbox Worker Process (SPUCWorkerProcess.exe) Sandbox Worker Process Proxy (SPUCWorkerProcessProxy.exe)
Sandbox Architecture Worker Service ( SPUCWorkerProcess.exe ) Full Object Model Host Services ( SPUCHostService.exe ) Execution Manager (Inside Application Pool) Subset Object Model Untrusted Code IIS (WPW3.EXE) FRONT END User Code Server
Sandbox Code Access Security AspNetHostingPermission , Level=Minimal SharePointPermission , ObjectModel =true SecurityPermission , Flags=Execution Full Trust wss_usercode.config User Code Framework Code My.dll Other.dll System DLL SharePoint DLL SharePoint OM Subset OM
Sandbox Boundaries Off-box connections, http, web services, etc ADO.net Enterprise features (Search, BCS, etc.) Threading P-Invoke IO Other sites x x x x x x x
Breaking out of the Sandbox Full-Trust Proxy Worker Service ( SPUCWorkerProcess.exe ) SPUtility SPProxyOperationArgs GAC SPProxyOperation SPProxyOperationArgs Untrusted Code Secured Resource
Deploying a Sandboxed Solution to the Solution Gallery demo
Load Balancing Sandboxed solutions can be run in two modes Local Mode Execute code on the SharePoint WFE Low administration overhead Lower scalability Remote Mode Execution on back-end farm machine Via dedicated service applications Load balanced distribution of code execution requests
Solution Validation [ GuidAttribute ( "34805697-1FC4-4b66-AF09-AB48AC0F9D97" )] public class PublisherValidator : SPSolutionValidator { public override void ValidateSolution ( SPSolutionValidationProperties properties){ properties.Valid = [true || false]; properties.ValidationErrorMessage = “no soup for you”; } public override void ValidateAssembly ( SPSolutionValidationProperties properties, SPSolutionFile assembly){ } } 28
Resource Management for IT Pro’s Resource’s monitored All sites are allocated resource quotas Established by server administrators Daily resource usage calculations Warning thresholds E-mail notification Hard threshold Sandboxed code doesn’t run for remainder of day Abnormal Termination CPU Execution Time Critical and Unhandled Exceptions Memory Consumption SQL Query Time Non-Responsive Proc’s Data Marshalling Size Handles and Threads
Sandbox Solution Monitoring How it works 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
Monitoring process
Monitored Resources Metric Name Description Units Resources Per Point Hard Limit AbnormalProcessTerminationCount Process gets abnormally terminated Count 1 1 CPUExecutionTime CPU exception time Seconds 200 60 CriticalExceptionCount Critical exception fired Number 10 3 InvocationCount Number of times solution has been invoked Count N/A N/A PercentProcessorTime Note: # of cores not factored in Percentage Units of Overall Processor Consumed 85 100 ProcessCPUCycles CPU Cycles 1E+11 1E+11 ProcessHandleCount Windows Handles 10,000 5,000 ProcessIOBytes (Hard Limit Only ) Bytes written to IO Bytes 1E+07 1E+08 ProcessThreadCount Number of Threads in Overall Process Threads 10,000 200 ProcessVirtualBytes (Hard Limit Only ) Memory consumed Bytes 1E+09 4 E+09 SharePointDatabaseQueryCount SharePoint DB Queries Invoked Number 400 100 SharePointDatabaseQueryTime Amount of time spent waiting for a query to be performed Seconds 20 60 UnhandledExceptionCount Unhanded Exceptions 50 3 UnresponsiveprocessCount We have to kill the process because it has become unresponsive Number 2 1 You can tweak these values to fit your need…
Sandbox Solution Monitoring Case Study A solution has executed 40 SQL queries (via the SharePoint OM) One point for SQL is 400 queries Means for SQL it’s consumed .1 resource points So the resource usage is for the day for that solution is .1 resource points + other counters
Managing Sandboxed Solutions demo
Summary Solution packaging changes and options in 2010 Sandboxed solutions Deployment Monitoring Management