A Lap Around SharePoint 2010 Sandboxed Solutions

Sandbox solution is a new feature introduced in SharePoint 2010. It's a secured wrapper around webparts and other elements with limitations. There is no thumb rule that every webpart in SharePoint 2010 belongs to Sandbox Solution. But it's recommended to develop webparts with Sandbox solution. It allows administrators to monitor the solutions and control as required. SharePoint Site Collection administrators can view the resource utilization of each solution and can block if it consumes too much resources. Usually when sites working slow, developers complain the server is slow whereas site/server administrators blame on Develepor code/solutions. Now Microsoft put a Full Stop to that. :)

Technically speaking SharePoint solutions run in seperate worker processes and not in w3wp.exe. So It doesn't require IIS Reset or Application Pool Recycling. Without disturbing the SharePoint site, Sandbox solutions can be deployed. Only thing while deploying new version of Sandbox solution over existing solution, SharePoint will display No Solution found error in Sandbox Webparts on the page. However within seconds sandbox solutions getting deployed and it'll start working. In SharePoint 2007, only farm administrators can install/deploy developer solutions. But Now site collection administrators can deploy solutions with web based interface. This reduces the dependency of Farm Administrator and improves rapid deployment.

Sandbox Processes
Here the processes which required for Sandbox solutions.

1. SPUCWorkerprocess.exe - Sandbox Worker process service which is a Seperate Service Application which actually executes Sandbox code. It should be started in every farm to use Sandbox solutions.
   
2. SPUCWorkerProcessProxy.exe - Sandbox Worker process proxy which is working as a proxy for Worker process and takes care of Sandbox code execution. It can also serve to other farms if configured. Basically it helps site administrator for load balancing.
   
3. SPUCHostService.exe - Sandbox User Code Service takes care of user code in Sandbox amd it can be started in the farms where to use Sandbox solutions.

Sandbox Limitations
As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in SharePoint environment. Few Key limitations which developers should know are listed below.

1. No Security Elevation - RunWithElevatedPrivileges which runs the specified block of code in application pool account(typically System Account) context is not allowed in Sandbox code. SPSecurity class also not allowed to use in Sandbox.
   
2. No Email Support - SPUtility.SendMail method has been blocked explicitly in Sandbox, However .Net mail classes can be used to send mails. Additionaly sandbox won't allow to read Farm SMTP address. So developers has to specify the SMTP address in code itself(may be some other workaround).
   
3. No Support to WebPartPages Namespace - Sandbox won't allow to use Microsoft.SharePoint.WebPartPages namespace.
   
4. No Support to external Webservice - Internet web service calls are not allowed to ensure security in Sandbox solutions. Allow Partially Trusted code also can't be accessed within Sandbox.
   
5. No GAC Deployment - Sandbox solutions are not stored in File System(Physical path) and assemblies can't be deployed to Global Assembly Cache(GAC). But it's available on C:\ProgramData\Microsoft\SharePoint\UCCache at runtime. Note the ProgramData is a hidden folder.
   
6. No Visual Webparts - Visual Studio 2010 by default won't allow to create Visual Webparts to deploy as sandbox solution. But with Visual Studio PowerTools extensions(downloadable from Microsoft MSDN website) Visual Webparts can be developed and deployed as sandbox Solutions.

SharePoint Online which is SharePoint environment provided by Microsoft to manage SharePoint Sites in internet accepts only Sandbox solutions. Because SharePoint Online sites are Windows Servers at Microsoft Datacenters, Microsoft won't allow GAC deployment or file system access. In future Sandbox solution will give more features for developers. 

Difference between Service Accounts and Managed Service Accounts in SharePoint 2010

With SharePoint 2010 we now have the ability to allow SharePoint to manage various service accounts thus foregoing the need to have IT administrators manually manage password changes. This new feature is a great benefit to SharePoint administrators and security conscious admins in general as it allows us to easily enforce our corporate security policies by changing these passwords on a schedule, and the administrators don’t even know what the password is so the likelihood of a compromise due to a disgruntled admin, though not eliminated, is somewhat reduced.

But the introduction of this new feature isn't all good. The complication comes from the fact that SharePoint 2010 doesn't implement this capability consistently. So an account that is configured as a Managed Service Account and set to have its password changed automatically could also be used in certain places that don’t understand the managed account concept. When the managed account password is changed the feature that uses that account and only knows the username and password (so it does not use the managed account details) will effectively be broken. As an example, if you configure the Enterprise Search Service to use a managed account whose password is scheduled to be changed every 30 days and you use that same account for the content crawl account then when that password is changed the content crawl will cease to function as it will be unable to authenticate the account. It’s important to note, however, that this issue only comes to light when you configure the managed account to have it’s password changed automatically.

So what things can be managed accounts and what cannot? The following lists what I've come across so far (if I've missed anything please leave a comment so I can update these lists):

Managed Service Accounts:

• All Service Application Pool Accounts
  • Access Service Application
  • BCS Service Application
  • Excel Services Service Application
  • Metadata Service Application
  • PerformancePoint Service Application
  • Enterprise Search Service Application
  • Secure Store Service Application
  • Subscription Settings Service Application
  • User Profile Service Application
  • Visio Services Service Application
  • Web Analytics Service Application
  • Word Automation Service Application
  • Word Viewing Service Application
  • PowerPoint Viewing Service Application
  • Security Token Service Application
• All Content Web Application Pools
• Service Instances
  • Claims to Windows Token Service
  • Document Conversion Launcher Service
  • Document Conversion Load Balancer Service
  • Microsoft SharePoint Foundation Sandboxed Code Service
  • SharePoint Foundation Help Search
  • SharePoint Server Search (Enterprise Search)
  • Web Analytics Data Processing Service

Service Accounts (should not be managed):

• Search Crawl Accounts
  • For Foundation Search and Server (Enterprise) Search
• Unattended User Accounts
  • Excel Services Service Application
  • Visio Services Service Application
  • PerformancePoint Service Application
  • (in general, any Secure Store application credentials)
• Object Cache Portal Accounts
  • Super User Account
  • Super Reader Account
• User Profile
  • Synchronization Service Account (listed incorrectly on the FarmCredentialManagement.aspx page)
  • Synchronization Connection Account
• Server Search Custom Crawl Rule Accounts
  • Any crawl rule that specifies an account other than the default crawl account

Again, these are just the accounts that I’ve personally bumped up against so it may not be a complete listing.

Viewing and Creating Managed Accounts

To see the current list of Managed Service Accounts using Central Admin go to Security –> Configure managed accounts:

You can edit the settings for any managed account by simply clicking the edit icon associated with the account you wish to modify. Once on the Manage Account screen you can configure the automatic password change settings:

To perform the same tasks using Windows PowerShell we can use the Get-SPManagedAccount cmdlet to retrieve the list of managed accounts:

Or we can retrieve a specific account using the -Identity parameter or by passing in a Web Application or Service:

clTo change the settings for a Managed Account we can use the Set-SPManagedAccount cmdlet:

To create a new Managed Account we use the New-SPManagedAccount cmdlet. In the example below I’m manually creating a PSCredential object so that I can specify my password (pa$$w0rd) in script (very useful for building out dev or test environments – otherwise you should use Get-Credential to prompt for the password so that it is not hard coded anywhere):

Applying Managed Accounts

Once you have your Managed Accounts created you can begin to use them for things such as Service Instances and Service and Content Application Pools. To associate a managed account with a specific Service Instance using Central Admin you can go to Security –> Configure service accounts. On the Service Accounts page you can set the account used for the Farm Account, Service Instances, Web Content Application Pools, and Service Application Pools. The Service Instances are highlighted in the following image:

Happy sharepoint