Sharepoint 2010 on Resource allocation for Sandboxed Solution

The default quota is 300 server resources, how to understand it ? ( or Server Points ?)

How to calculate them ?.

 

ANSWER:

The default Resourcing system is divided into 14 measures and if you want to get the details on what is the Resource Count of each measure (like threadabort,memory, AbnormalProcessTermination, CriticalExceptionCount, etc) you will need to run following PowerShell command:

 

Try following on the PowerShell console to get the measure details:

***************************************************************************************************************************************

Add-PSSnapin Microsoft.SharePoint.Powershell

[System.Reflection.Assembly]::Load(“Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”)

$s=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local

$s.ResourceMeasures | Select-Object Name,ResourcePerPoint.

***************************************************************************************************************************************

 

Basically an output that looks like:

 

AbnormalProcessTerminationCount                                                                                       1

CPUExecutionTime                                                                                                   3600

CriticalExceptionCount                                                                                               10

InvocationCount                                                                                                     100

PercentProcessorTime                                                                                                 85

ProcessCPUCycles                                                                                           100000000000

ProcessHandleCount                                                                                                10000

ProcessIOBytes                                                                                                        0

ProcessThreadCount                                                                                                10000

ProcessVirtualBytes                                                                                                   0

SharePointDatabaseQueryCount                                                                                         20

SharePointDatabaseQueryTime                                                                                         120

UnhandledExceptionCount                                                                                              50

UnresponsiveprocessCount                                                                                              2

=============================================================================================================================

 

NEW FEATURES: Sharepoint 2010 a.k.a. Sharepoint 14 

I am sure I might not be the first one to write about this (although I didn’t check online if somebody has already written about this topic, so excuse me for a *repeat*).

 

Following are only the few great and basic features that are now part of SharePoint 2010 (and let me tell you SP 2010 ROCKS!!!):

1.       Service Applications: The SharePoint 2010 architecture for Shared Service Provider (SSP in MOSS 2007) is now changed and now we have something known as Service Applications. Service Applications. So now we are moving more towards Service Model in 2010. In MOSS 2007 the limitation of having only one SSP associated web-application, forced us to use ALL or NOTHING of all the services (Search, BDC, Profile, Excel) from the SSP. So we can’t consume more than one service from 2 or more different SSPs. This limitation is now gone with SP 2010, now we have SERVICE APPLICATIONS, with this a WEB-APPLICATION can choose from all the available SERVICE APPLICATIONS and choose it A-LA-CARTE. [I will try to write in details about this topic in future] One thing to note here is all these Services in Service Application are WCF Services. So the Advantages are:

a.       Each Service (Search, BDC, PROFILE, etc) is independent and can be independently scaled & configured to run on different Application Servers

b.       Web applications can be associated with any service application, not like MOSS 2007 where we were limited to use only those Service provided by the SSP.

c.       We can have an independent Farm that is hosting only Services and then we share these services across farms.

2.       SP 2010 *DEVELOPMENT* now on Windows-7 & VISTA+SP1 (64-bit OS): At least in Beta 2 both SharePoint Server 2010 and SharePoint Foundation 2010 [WSS 4.0] will be able to install on Windows 7 or Windows Vista+SP1 for doing the development in addition to Server operating systems. This is huge as dev teams now can leverage the non-Server OS as they do it for SQL Server, BizTalk, etc. This definitely deserves a 5 STAR rating isn’t it J, so let me highlight this in different color.

 

3.       Sandbox Solutions: As we had a WSP (Solutions) in MOSS 2007 we still have the same in SP 2010 but now there is a Step brother to it too J. That is when the developer compiles the custom code then can choose between 2 options 1. Sandboxed Solutions or 2. Full blown Solutions [I call it that]. Sandboxed solutions are compiled with a subset object model and can be uploaded to a Special gallery [SOLUTIONS] under the _catalogs. And these solutions can be given to the business admins to upload and use it instead of waiting for IT/Operations team to deploy the solution. Again a very HUGE feature but this article won’t be enough at all to explain the details.

4.       LINQ Support: The Microsoft.SharePoint.Linq namespace will contain the LINQ to SharePoint provider. It will translate LINQ queries into Collaborative Application Markup Language (CAML) queries, which means that developers do not need to know how to write CAML queries nor learn a different query language for each type of data source.

5.       Client Object Model: WSS 4.0 [a.k.a. WSS FOUNDATION] Introduces three new object models for interacting with SharePoint sites: from script that executes in the browser, from code (Microsoft® .NET Framework 2.0 or later) that executes in a .NET managed application, or from code that executes in a Silverlight 2.0 application. The new ECMAScript, .NET managed, and Silverlight object models each provide a subset of the object model that is defined in Microsoft.SharePoint.dll, including objects that correspond to the major objects in the server-side object model at the site-collection level or lower in the Windows SharePoint Services 4.0 hierarchy. Just to give some little details here, following table should help:

 

Server

.NET Managed and Silverlight

ECMAScript

Microsoft.SharePoint.SPContext

Microsoft.SharePoint.Client. ClientContext

SP.ClientContext

Microsoft.SharePoint.SPSite

Microsoft.SharePoint.Client. Site

SP.Site

Microsoft.SharePoint.SPWeb

Microsoft.SharePoint.Client. Web

SP.Web

Microsoft.SharePoint.SPList

Microsoft.SharePoint.Client.List

SP.List

Microsoft.SharePoint.SPListItem

Microsoft.SharePoint.Client.ListItem

SP.ListItem

Microsoft.SharePoint.SPField (including major derived classes)

Microsoft.SharePoint.Client.Field

SP.Field

Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager

Microsoft.SharePoint.Client.WebParts.LimitedWebPartManager

SP.WebParts.LimitedWebPartManager

 

6.       Master Pages for Application Pages: In WSS 3.0, application pages and content pages use different master pages with different content placeholders. The master pages for the application pages could not be changed. There was no out of the box way [but only thru code] to change the master page for application pages created an inconsistent look and feel. In WSS 4.0, application pages use the same master page as content pages so we get consistent look and feel [no more blue pages]. We most likely will have a SIMPLE or BASIC master page with only the placeholder controls necessary/required. Another thing I thought of mentioning here was about the PAGES library and yes now we can have FOLDERS in PAGES library also and this is supported now in SP 2010.

7.       Ribbon Menu:   as we have Ribbon menu in Office 2007, we have a similar Ribbon Menu in SP 2010 and best thing is you can extend it and choose to use or not. Basically it is a SharePoint control that looks like this:

<SharePoint:SPRibbon  runat="server"  PlaceholderElementId="RibbonContainer" FixedPositioningEnabled="true" PermissionsString="EditListItems, AddAndCustomizePages" PermissionMode="Any"

Visible="false" ApplyPermissionsToRibbonOnly="false">

8.       Themes: Yes themes were available in MOSS 2007 but then you had to create themes and get it deployed thru the IT/Operations team and needed some knowledge of CSS too. But now in SP 2010 the business users can define the themes in the browser and use it. You can modify colors and fonts by applying a .thmx file to your site and can apply a "theme" by using a simple, Web-based UI that requires no knowledge of CSS. The "themes" feature provides broad, clear control of colors and fonts on a Microsoft SharePoint Server 2010  site. It also supports the re-coloring of site images. 

9.       New Event Handler: In SP 2010 we have some much needed event handlers like Web-Adding: this event fires when a new Web site is created. If cancelled, then no Web site is created and the provisioning process does not begin. WebProvisioned : This event fires after the Web site is fully provisioned and the provisioning process has stopped. It can be either synchronous or asynchronous.

10.   POWERSHELL Command-let: Windows PowerShell introduces the concept of a cmdlet: a single function command-line tool built into the command shell. PowerShell is the big thing in SP 2010 and its better we all learn it now, its really not difficult. We have close to 652 command lets in SP2010 that we can use to manage SP 2010 with scripting model. Advantages: Great Performance compared to STSADM, Remoting interface that helps to run the command from one machine in a farm kind of scenario instead of running it on individual servers. There are 2 types of PowerShell Commands: 1. LOCAL ["BOX"]: This command must run on each box and 2. Global: This command only runs *once* per farm.

11.   Developer Dashboard: This one great thing I have seen for the developers who get a lot of beating from the performance labs. This feature displays us (the developers) the diagnostic and performance related statistics. Something like how long did the request take to run, what event handlers were fired, in what sequence did these event handlers fire.

12.   Improvements to SPD Workflows: This is HUGE as in MOSS 2007 the problem was the SPD workflows couldn’t be moved easily between lists/Sites, etc. But now in SP 2010 this issue has been resolved and now we can create Workflows that are reusable. The workflows can be easily moved around different lists/sites once they are defined in SPD. Also another thing to note is you can modify some of the out of the box workflows also.

13.   Visual Studio 2010 Improvements for WSS: VS 2010 we have a very good integration support with SP2010 and we can easily build Sharepoint Artifacts and debug artifacts like web-parts just by hitting (CTRL-F5) that is so cool, you dont have to go thru the hasle and steps as we used in VS 2008. For building custom web-parts, list definitions, etc out of the box i.e. no need to install a separate set of templates as we used to do it in MOSS 2007. The UI is cool which also gives us an option to preview the web-parts yes DESIGNER view for web-parts this was not there in VS 2008. Also thing to note here is you *can’t* use VS 2010 and SPD 2010 with MOSS 2007 or WSS 3.0, no backward compatibility. Just an exception to this fact is workflow projects of MOSS 2007, you can use it with VS 2010.

14.   Sharepoint Designer [SPD] 2010 : This is the no-code tool that was free in 2007 and will continue to be provided FREE in 2010. The navigation is changed and is more friendly compared to what we had in SPD 2007. Great tool to build custom artifacts without writing a single line of code.

15.   Off-box SSL support for HOST NAMED SITE COLLECITONS: This is another huge thing that most of the teams were requesting. With SP 2010 Off-box SSL will be supported in host named/ host-header site collections. This was *not* supported in MOSS 2007 only path based site collections were supported in MOSS 2007 with off-box SSL.

 

==========================================================================================

Shared SSP and Web-application creation in Sharepoint 2007 (Alternate URL Synchronizer)

At one of my customers we have a situation where we are Sharing the SSP from one Farm (i.e. Parent Farm) to another Farm (Child Farm). We also need to create a web-application with the same host header name (e.g. http://secure.msft.com) in both the Farms.

Following is the main crux of the issue:

1.       We have a Parent Farm (This farm provides the  SSP to child Farms), lets call this Farm ASIAFARM.

2.       We create a web-app with url “secure.msft.com“ in the ASIAFARM, and the web-app is created.

3.       Now we create the AAM entries for this web-app in the Parent farm (3 entries).

4.       We now go to the Child Farm (This farm consumes the  SSP provided by the Parent Farm), lets call this Farm USFARM.

5.       We try creating a web-app with the same url i.e. “secure.msft.com“ in the USFARM and the web-app creation fails with the error: http://secure.msft.com is already routed to the Default zone of another application. Remove that mapping or use a different URL. 

6.       This is because of the reason that “Alternate URL Synchronizer” timer job syncs all the entries from the Parent Farm to the Child Farm and hence can’t create the web-app.

7.       Then we disabled this (“Alternate URL Synchronizer” ) timer job in the Child Farm and deleted all the AAM entries from the Child Farm.

8.       Then we tried creating a web-app with the same url i.e. “secure.msft.com“ in the USFARM and it succeeded. And we were able to create the additional AAM entries.

 

So bottom line is the (“Alternate URL Synchronizer” ) timer job Synchs the information (AAM) from Parent Farm into the Child Farms. If you want to take a look at the EXECUTE method of this timer job (using Reflector), just open the Assembly name: Microsoft.Office.Sharepoint.Administration

Class Name: AlternateUrlSynchronizerJob [This is  basically a SEALED class).

 

After looking @ the source code of this TIMER JOB we found that it only writes the AAM (Alternate Access Mapping) from the Parent Farm to Child Farm, so now if you try to create a web-application with a host header that is already created in Parent Farm it will not be successful and it will not allow you to create a web-application in Child Farm with that host header. [PLEASE NOTE: This scenario only happens when you are sharing the SSP (Shared Service Provider) with two farms i.e. Child Farm uses SSP of Parent Farm, and that creates this Alternate URL Synchronizer Timer Job).

 

So be cautious (while architecting) when you propose this approach, as you will not be able to create a web-app with same host headers. I am still to find the answer for where all these AAMs are use (my *guess* is Search might be using it, dont what else would be using it).

As disabling this Timer Job (thru Central Admin-->Operations-->Timer Job Definition-->Disable) you will be able to create the web-apps requied in both the farms but not sure if you would be in a supported state, as we are still not aware of where all the AAMs are used.

 

=======================================================================================================