Archive for July, 2011
$SecurePhrase=ConvertTo-SecureString “Passw0rd1” –AsPlaintext –Force
ConvertTo-PlainText( [security.securestring]$secure )
$marshal = [Runtime.InteropServices.Marshal]
$marshal::PtrToStringAuto( $marshal::SecureStringToBSTR($secure) )
I recently updated our documentation about sandboxed solutions to include new information about tiers and resource points. This blog post briefly describes these two new concepts, and includes links to new and updated articles that contain more information.
Tiers in the sandboxed solutions service provide a way to group sandboxed solutions together, based on how well (or poorly) they behave. You can have more than one tier inside the sandboxed solutions service (there is automatically one, by default). As illustrated in the figure below, each sandboxed solution runs inside a single application domain. The application domain runs inside a worker process, which, in turn, resides within a single tier. You can have one or more application domains (essentially, one or more sandboxed solutions), inside a single worker process, and you can have one or more worker processes within a single tier.
This structure provides a way to group or isolate sandboxed solutions to improve performance, security, and reliability. Because sandboxed solutions are monitored for their use of system resources, when a particular sandboxed solution starts using up too many resources, that solution, and all other sandboxed solutions within the same worker process are stopped. You can configure the tiers so that the next time the resource-heavy sandboxed solution runs, it will run in a different tier, and not affect other sandboxed solutions.
For more information about tiers, see Understanding the sandboxed solutions service in Sandboxed solutions overview (SharePoint Server 2010).
For examples of how to configure tiers by using Windows PowerShell, see Configure sandboxed solutions service tiers (SharePoint Server 2010).
As I said earlier, sandboxed solutions are monitored for how many system resources they use. There are 15 specific system resources that are monitored (called resource measures). When any one of these resource measures meets or exceeds a predefined threshold, a resource point is counted towards a quota that has been set for the entire site collection. This happens over and over throughout the course of a single day, as sandboxed solutions use system resources. If enough resource points are accumulated, and the quota for a site collection is met, all sandboxed solutions in that site collection are stopped until the Solution Daily Resource Usage Update timer job runs (usually, every night, unless you have changed it to run at some other time).
The default resource point limits have been carefully tested and should be fine for most scenarios where sandboxed solutions are used. However, farm administrators can adjust the resource point allocations for the 15 resource measures that are affected by sandboxed solutions.
For a complete list of the resource measures and their default settings, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010 (http://go.microsoft.com/fwlink/?LinkId=217149).
For more information about resource points, see Understanding quotas and resource points in the Sandboxed solutions overview (SharePoint Server 2010) article.
For guidance about how to plan for resource points, see Plan resource usage quotas for sandboxed solutions in the Plan sandboxed solutions (SharePoint Server 2010) article.
For examples of how to customize the resource points to meet the needs of your scenario, see Configure resource points for sandboxed solutions (SharePoint Server 2010).
SharePoint IT Pro content publishing
Microsoft IT has released several new resources related to the governance of Microsoft’s SharePoint service.
Implementing SharePoint 2010 Site Governance and Lifecycle Management
Webcast: How Microsoft IT Handles SharePoint 2010 Governance and Life Cycle Management (Level 200) (https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032487219&CountryCode=US)
Please note this post only talks about new installation using slipstreamed build, not updating an existing farm.
In the previous blog post I mentioned the following:
Should I use slipstreamed SharePoint server installation files to deploy SharePoint and its CUs?
Maybe – depending on if you want to use language packs or not. If language packs are not installed when you install SharePoint Server, and you install those LPs after the server has been installed, you may need to reapply SharePoint CU packages to get all those LPs up to date.
Now I got questions about this “maybe”. Let me go deeper in this topic…Slipstream is good – but you have to use it in the right way, with the right order.
A typical slipstreamed SharePoint Server install is like this:
Install SharePoint Server RTM + SP1 + June CU Slipstreamed
Install SharePoint Server Language Packs
Looks simple and clear. But it is wrong – you will have RTM version of Language packs in this way. Why? Think about the table we had in previous post, then think about Cumulative Update concept. If something is not installed when you apply the CU package, then those files of the missing component will not be installed at all. In this case, the language pack updates in the CU server package are the ones missing.
The following screenshot shows what this will look like (Chinese LP in 4763 RTM, but all other components are in June CU 6105)
To fix this issue you need to apply language pack SP1s and June CU again. So the installation order should be changed to something different:
Install SharePoint Server RTM + SP1 + June CU Server Package Slipstreamed
Install SharePoint Server Language Packs
Install SharePoint Server LP SP1(s)
Install June CU Server Package again
This would work. But why install June CU twice? It’s a waste of time so let’s change it again. The other thing is that you can slipstream LP SP1 into language pack installation files (extract and put all files in updates folder):
Install SharePoint Server RTM + SP1 Slipstreamed
Install SharePoint Server Language Packs + Server LP SP1 Slipstreamed
Install June CU Server Package
Now all language packs are updated to latest version.
What can you learn from this? Don’t slipstream CU if you need to install additional language packs. Always apply CU Server Package at the last step.
Microsoft has posted an updated version of SPDisposeCheck which is:
SPDisposeCheck is a tool to helps developers and administrators check custom SharePoint solutions that use the SharePoint Object Model in identifying correctly disposing of SharePoint objects to help you follow published best practice.
One of the updates includes a list of updated “do not check” rules. I’d suggest integrating this as part of your build process such as a CI setup.