SharePoint Server 2010 capacity management: Software boundaries and limits

Please refer the following site to get more details.

http://technet.microsoft.com/en-us/library/cc262787.aspx#UPA

Workflow Links

This are the good links available for workflows,

http://blogs.msdn.com/b/sharepoint/archive/tags/workflow/

For creating State machine workflow
http://blogs.msdn.com/b/sharepoint/archive/tags/workflow/

Integrating infopath with workflows
http://nisha081.spaces.live.com/Blog/cns!6F578843FD095913!1265.entry

How to access web.config in timer job code

This is common scenario where some times we may need to access the web.config file in sharepoint custom timer job. But timer job is running under OWSTIMER.EXE, but sharepoint is running under the context of w3wp process, So its difficult to access the web.config file in the timer job code. To overcome this we need to create the instance of the webapp and Configuration and then we can access the web config file.

Below is the sample snippet code where we can access the web.config file.

//Get the instance of the current webapplication
SPWebApplication webApp = this.Parent as SPWebApplication;

//Create the webconfig instance by using web application name
Configuration webconfig = WebConfigurationManager.OpenWebConfiguration("/", webApp.Name);
//Get the configured value from web config using the key value in my case its "MYKEY"

string appValue = webconfig.AppSettings.Settings["MYKEY"].Value.ToString();

The above code needs to written in Execute method of the timer job definition file.

Updating Master Page and Page layout

Updating MAster page and page layout through feature receiver

http://narunkumar.wordpress.com/2010/06/25/updating-a-sharepoint-master-page-page-layout-via-a-solution-wsp/

Infopath form services in sharepoint 2010

Some times Infopath form services are not available in sharepoint(2010) under general application settings in central admin.



How to get this links?

Follow this steps to get the infopath form services in sharepoint cetral admin.

1) Install the feature "IPFSAdminWeb" either by using stsadm or PS(Powershell)
2) After this feature is installed the infopath form services will be availabel, if this feature is not available then we need to activate this feature explicitly in sharepoint central admin. This can be done through stsadm or PS.




3) If everything works fine then well and good but some times when we click on infopath form services then we will get the page not found error.

Then there should sharepoint version problem. If sharepoint Client Access License is installed then this will cause the problem.

4) How to change the version
Open SharePoint Central Administration and went to the (i.e. upgradeandmigration.aspx on the Central Admininstration site).
In the "Upgrade and Patch Management" section click on the "Convert farm license type" link to bring up the Conversion.aspx page.
Enter in the new product key and convert to the "SharePoint Server with Enterprise Client Access License" edition.
Now go back to the General Application Settings page in SharePoint Central Administration and you should now see the "InfoPath Forms Services" section with its links.

Code deployment in sharepoint 2010

There are basically now three different ways to deploy custom assemblies:

•Full trust solutions - The assemblies are registered in the GAC and runs under full trust
•Partial trust solutions - The assemblies are deployed to the bin folder of a specific Web Application
•Sandboxed solutions - The assemblies (solutions) are deployed to the Site Collection gallery

Sandboxed Solutions
The Sandboxed Solutions runs inside the a special service, called Microsoft SharePoint Foundation Sandboxed Code Service, which is a completely and separate application domain than the SharePoint application pools. The Sandboxed solutions are monitored and if they consume to much resources or fails to many times SharePoint automatically shuts the solution down. The code running in a Sandboxed assembly does not have access to the full SharePoint API, basically it's just the classes from Site Collection level and below. The sandbox is also protected with a very minimal CAS policy which for example prohibits the user code solutions from calling web services, making database calls or accessing the file system.

Sandboxed solutions are deployed into the Solution gallery of a Site Collection and only access that Site Collection. They can be deployed without having any downtime of the farm or web application. Anyone within the Site Collection Administrators group can upload solutions to the gallery and activate them. Farm administrators controls how much resources each Sandbox can use and can also block specific solutions from running at all.

Pros Cons
Can easily be deployed by Site Collection Administrators Very limited CAS policy
Resource usage is monitored * Current uncertainty about the monitoring stability
Secure Hard to deploy in a farm
Great support in Visual Studio 2010
Only crashes the Sandbox if it blows

There is a timer job which is running every 15 minutes to check the resource usage. Based on this timer job it will block the solution from running.

Farm Solutions
The Farm solutions or full trust solutions adds the assembly to the Global Assembly Cache, GAC, which means that they can run without any CAS policies, i.e. under full trust. The assemblies can be accessed from any application in the farm. Full-trust solutions are the most common way to install solutions since it is easy and requires no knowledge of for instance CAS policies. The code running in a full trust solution has the same access as the application pool account to the local server and can do almost what it want with the server. Deploying Farm solutions should only be done with code that we really trust.

Only farm administrators can upload new farm solutions to the configuration database and most often an application pool recycle is needed, especially when updating solutions.

Pros Cons
Easy to implement Only Farm Administrators can add new solutions
Great support in Visual Studio 2010 Downtime when updating
Runs in full trust Have to much privileges
Can crash the whole server

Web Application Solutions
Solutions deployed to the web application bin directory was the way to go in SharePoint 2007 when we wanted/needed to secure our application using CAS. This partial trust option is still valid in SharePoint 2010. Web application deployed solutions by default only have a very minimal CAS policy applied. Using custom CAS policies it is easy to give more privileges to assembly. Installing these solutions also requires a Farm Administrator but they are only applied to specific Web Applications. Updating the assembly does not require an application pool recycle.

Visual Studio 2010 have support for Web Application deployment but not for custom CAS policies. We have to install the solution using PowerShell or create our own Visual Studio SharePoint Deployment Steps.

Pros Cons
Security policies can be configured and kept minimal Only Farm Administrators can add new solutions
Minimal downtime when upgrading No support OOB for custom CAS policies in Visual Studio 2010
Only crashes the web application

State machine vs sequential workflow

Sequential Workflow:
A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process.
We use a sequential workflow when we can encode most of the decision-making inside the workflow itself.

State Machine Workflow:
A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world.
We use a state machine workflow when the decision-making happens outside the workflow.

We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decision-making happens outside the workflow.

State machine vs sequential workflow

Sequential Workflow:
A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process.
We use a sequential workflow when we can encode most of the decision-making inside the workflow itself.

State Machine Workflow:
A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world.
We use a state machine workflow when the decision-making happens outside the workflow.

We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decision-making happens outside the workflow.

State machine vs sequential workflow

Sequential Workflow:
A sequential workflow is a predictable workflow. The execution path might branch, or loop, or wait for an outside event to occur, but in the end, the sequential workflow will use the activities, conditions, and rules we've provided to march inevitably forward. The workflow is in control of the process.
We use a sequential workflow when we can encode most of the decision-making inside the workflow itself.

State Machine Workflow:
A state-machine workflow is an event driven workflow. That is, the state machine workflow relies on external events to drive the workflow to completion. We define the legal states of the workflow, and the legal transitions between those states. The workflow is always in one of the states, and has to wait for an event to arrive before transitioning to a new state. Generally, the important decisions happen outside of the workflow. The state machine defines a structure to follow, but control belongs to the outside world.
We use a state machine workflow when the decision-making happens outside the workflow.

We use a sequential workflow when we can encode most of the decision-making inside the workflow itself. We use a state machine workflow when the decision-making happens outside the workflow. In this chapter, we will take a closer look at how state machines operate.

Timer Jobs

Creating custom field with multiple line of text (object model)

If we want to create field multiple line of text through object model then we can use SPFieldType.Note(this will create multiple line of text column).
If we create with SPFieldType.Text then it will be single line of text.

Cannot insert the value NULL into column Name

This problem will arise when activating event handler/not sure about other feature.
The reason behind this is the commented code in the element.xml. After removing the commented code the feature will be activate sucessfully.

Using Objects in Event Receivers

Event receivers that instantiate SPSite, SPWeb, SPList, or SPListItem objects instead of using the instances passed via the event properties can cause the following problems:

They cause additional roundtrips to the database. (One write operation can result in up to five additional roundtrips in each event receiver.)


Calling the Update method on these instances can cause subsequent Update calls in other registered event receivers to fail.