Back to basics :4 Sharepoint config files

I always excited about the SharePoint product team's vision on the way they aligned multiple moving parts to achieve the business objectives of the product. One of the main things in that context is the configuration entity. SharePoint configuration settings exist at several levels. As in all ASP.NET applications that use the integrated pipeline, 

• some fundamental settings are in the machine.config file, 
• the global web.config file, and 
• the applicationhost.config file, which is the IIS configuration store. 

SharePoint makes no changes in the default versions of the first two files. It does make some changes in the IIS configuration store. Each IIS website and, therefore, each SharePoint web application, can have a web.config file in its root folder. This file is substantially customized by SharePoint whenever a SharePoint web application is created. 

SharePoint also takes advantage of the fact that web.config files can be applied to specific virtual or physical folders within a web application. For example, SharePoint puts a web.config file in the virtual directory _layouts\mobile (which is mapped to the physical directory %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Among other things, the web.config file registers a series of filters that control how a page is rendered, based on the capabilities of the mobile device that has requested the page.

Farm-wide configuration settings are stored in the SharePoint configuration database on the computer that is running SQL Server in the farm. Configuration for specific types of websites is contained in various kinds of XML files, such as the Onet.xml file, and configuration for specific instances of websites is contained in the content database. In addition, several classes in the SharePoint object model have property bags that can be used to store custom configuration information for specific objects, such as objects that represent websites, Features, alerts, and files.

Back to basics - 3 Sharepoint Solutions

SharePoint solutions are generally packaged in SharePoint solution package files . SharePoint solution package files can contain several kinds of elements, including assemblies, user controls, custom ASP.NET pages, XML configuration files, resource files, images, list definitions, Web Parts, Features, and others. JavaScript files and Silverlight .xap files can also be deployed to the servers by using SharePoint Solution Packages.

There are 2 kinds of solutions

Farm solutions that are deployed by farm administrators to the farm's solution store, which is in the farm's configuration database. This is done by using either the SharePoint Management Shell or the object model. Solution Deployment step requires a farm administrator and can be done by using either Central Administration or SharePoint Management Shell, or the object model. Some examples of how elements are deployed: user control files (.ascx) are copied to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\ControlTemplates and assemblies are deployed to the global assembly cache or to a web application's \bin folder. If there are SharePoint Features in the farm solution, they are in this step copied to a subfolder of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES.

Sandboxed solutions that are deployed to a specific site collection's Solution Gallery by a site collection administrator. The gallery is a special SharePoint list, so it is in the content database. Solution deployment to the gallery is done through the Site Actions UI of the site collection or by using SharePoint Management Shell. The deployment step is taken by a site collection administrator. There are limits on what kinds of elements can be in sandboxed solutions and where they can be deployed. For example, nothing can be deployed to the file system of the servers from a sandboxed solution. Features in sandboxed solutions are deployed to the content database.

Installation of a SharePoint solution package is a multi-step process:
1. Adding: A solution package file is added to one of two stores based on the solution type(farm, sandboxed).
2. Deploying: The solution package is unpacked and its elements are deployed to their appropriate places. It is also in this second step that any Features in the solution are installed in the Feature Gallery of the farm, web application, site collection, or website, depending on the scope of the Feature.

Within a SharePoint solution package, there can be an additional level of encapsulation because a solution can have one or more SharePoint Features. A Feature can be installed at the scope of the farm, the web application, the site collection, or the website. After it is installed, a Feature must be activated by owners of any website within the scope; so Activating becomes a third step of installation for Features. Features can contain content types, controls, custom actions, custom fields, files, workflows, list instances, list templates, event receivers, and document converters; although some of these cannot be included in certain scopes. (Features that are deployed in sandboxed solutions can be scoped only to a site collection or website. For site collection-scoped features in sandboxed solutions, the second and third steps are combined. The Features are activated when the solution is deployed.)

Some SharePoint solutions target one of the client object models, either exclusively or in addition to targeting the server object model: the JavaScript, Silverlight, and Microsoft .NET Framework client object models. The script files that define the JavaScript object model are downloaded to a client computer when a page that references them is opened. Similarly, a Silverlight .xap executable is downloaded to the client computer when a page that is hosting it is accessed. The SharePoint assemblies that contain the Silverlight client object model are encased in the .xap file. Those assemblies are Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll. 
Stand-alone .NET Framework applications (such as a WPF application) that target the SharePoint client object model are installed just as any other client applications: using MSI files or ClickOnce. The assemblies that contain this client object model, Microsoft.SharePoint.Client.dll and 
Microsoft.SharePoint.Client.Runtime.dll, must be distributed as part of the solution.

Back to Basics 3 - SharePoint Security

SharePoint extends a strong security framework around its deployments to protect from unauthorized users, and errant code. SharePoint's role based security controls user access at different levels right from web app to list item. SharePoint solely depend on the authentication mechanism extended by external systems - Windows Auth or non-Windows Auth. The authorization process implemented within sharepoint assumes the user is properly authenticated.

The default authentication mechanism supported by SharePoint is "Windows Claims based auth" which is built on top of Windows Identity Foundation. In this model, user presents an identity to the Farm as a set of claims (eg: user name, email) and the external identity system is configured to give SharePoint all the 
info that it needs about the user with each request along with cryptographic assurance that the identity data come from a trusted source. SharePoint 2010 also support Windows classic authentication and ASP.Net forms based auth.

Access to all securable sharepoint objectts controlled thru a role based membership system by which users, groups are assigned rles to authorize their access to SharePoint objects. SharePoint follows a inheritance model in granting / revoking user access. A role definition will logically group a set of rights (read list item, create item etc.) that can be associated with a user , group as part of setting role assignment. SharePoint supports both Domain groups and SharePoint Groups. Domain groups will exist outside SharePoint with a less flexibility to manage (add users, remove etc) it but it can be used anywhere within the scope of the Active Directory Service. SharePoint groups are scoped to the site collection level and will be visible within the scope of that site collection. 

As part of code security , SharePoint supports app pool seperation, ability to keep code in GAC and BIN which provides different levels of acces, sandboxed solutions

Every web application runs in an IIS application pool that processes HTTP requests. The pool itself runs in a user account known as the application pool identity. In a multiserver farm, this is usually a domain user. The application pool identity is the user identity for code that runs in an IIS worker process. However, access to various SharePoint objects is determined by the permissions of the user who has made the request that is being processed. The isolation of web applications into separate application pools ensures that if one of them crashes, the others are not affected. The IIS worker process calls assemblies that may operate under their own additional restrictions. If the assembly is loaded out of the global assembly cache, it operates in full trust. However, if the assembly is loaded out of the web application's \bin directory, it is subject to the trust limitations that are defined by a CAS policy.If the request is for a sandboxed solution, the SharePoint execution manager that runs in the IIS worker process spawns a sandboxed worker process. The latter process runs within a highly restrictive CAS policy, is limited to a subset of the SharePoint server object model, and can only access resources within the site collection to which the solution was deployed.

Back to Basics - 2 SharePoint 2010 Server Object Model

Server Object Model in SharePoint is a large and critical classes helps developers to manage

1. Physical object hierarchy : classes represent physical components like servers and farms.
2. Content  hierarchy  : classes that represents publishable items of data and the nested containers of data.
3. Services hierarchy : includes classes that represent web services, Windows services, other types of services, instances of services, and CFSIs of services. 

Main classes in Physical object hierarchy are

• SPFarm : represents a sharepoint farm and its config DB.* 
• SPServer : represenets a physical server in the farm.*
• SPService : represents a farm-wide service. *
• SPSolution : represents a solution on a farm.

Main classes in Content  hierarchy  are

• SPWebApplication : represents a sharepoint web app. *
• SPContentDatabase : represents a content database that contains all the data and the customized page files that constitute the site collections that belong to the database. *
• SPWeb : represents a single website. 
• SPSite : represents a collection of websites within a SharePoint web application that are grouped together for mainly administrative reasons (Among the SharePoint elements that can be scoped to the site collection level are master pages, Web Parts, themes, lists, content types, and Features. A site collection can also be a unit of backup and restoration. It is also the level at which groups of users are created and assigned default permissions. Site collections are the largest possible scope for a search in SharePoint Foundation, although broader search scopes are possible in SharePoint Server 2010. The content of a site collection is always included within a single content database.)
• SPList : represents a sharepoint list and it  has members for programmatically adding, deleting, and retrieving list items, and also for managing metadata about the list such, as its content types and fields. 
• SPListItem : represents individual items of a list and it has members for managing the item's fields, the values of its fields, its content type, and any associated workflows. 
• SPFolder : represents Folders of a List which give a hierarchical structure. 
• SPField : represents field (column) on a list item.

Main Calsses in Services hierarchy are 

• Child class of SPService : represent sharepoint service which provides members that get info about the jobs the service is performing.
• Child class of SPServiceApplication : represents CFSI of a service  *
• Child class of SPServiceInstance : represents each instance of a service. A given CFSI can run on multiple servers, in which case each server has its own actual instance (a running process) of the CFSI. If the service has no CFSIs, it still has instances on each server on which it runs, but there can be no more than one instance of such a service on a given server. 
• SPServiceProxy & SPServiceApplicationProxy  : Applications that consume services that conform to the framework are represented by proxies. The consumer proxy for a service is represented by an SPServiceProxy object and the proxy for the CFSI is represented by an SPServiceApplicationProxy object.*

* inherits from SPPersistedObject, which means that the object that instantiates the class persists in the configuration database

Notes after first Upgrade from SP2010 to 2013 preview

Ohh... as and when a new SharePoint version releases - techies like us will be asked to think and act on upgrade. Now its from SP2010 to SP2013 - I m just done with the first candidate upgrade from SP2010 to Sp2013. As most of us guessed, Database attach is the only method supported by SharePoint team right now. As we all aware this is a costly option where we will upgrade the data and sites on a separate farm from the source. 

Before the upgrade, it is recommended to gather info from the source farm (SP2010) - settings like AAM, Auth Providers and Auth Modes, Quota Templates, Managed Paths, Se;f Service Site Mgmt, email settings, custom components (WSPs etc) Certificates. environment info like - sites list, DB details and number of users. It is also recomended to do a clean up to eliminate poential upgrade errors, major clean up activities are to check and repair all DB consistency errors and turning off Web Analytics service application.

To proceed with database attach upgrade, a new farm should be available and the usual SP2013 setup steps should be employed to setup that. Let me refresh the steps in high level

1. Install software - DB server (SQL Server 2008 R2 or SQL Server 2012), Web / App Server - SP2013 prerequisites and SP2013 product
2. Run config wizard in   Web / App Servers
3. Do not use config wizard to configure setup BCS, MMS, PPS, Search, Secure Store, UPS. We willl do it as part of upgrade

Once the environment is setup properly, copy the following DBs to new environment

• Site Content DBs
• BCS DB
• MMS DB
• PPS DB
• Secure Store DB
• Search DB
• UPS DBs (profile, social, sync)

Note: You may set the DBs read only if you wish to restrict changes in source DBs

Next step is to upgrade service applications using the existing DBs and creating service app proxies using Powershell cmdlets like
New-SPProfileServiceApplication (Adds a User Profile Service application to a farm.)
New-SPProfileServiceApplicationProxy (Creates a User Profile Service application proxy on the local farm.)

Note: Please refer MSDN for full set of cmdlets @ technet

Now we can create and configure web applications, deploy customizations like wsps, site defs, CSS, web parts, web services, features, assemblies and web.config changes, form templates et al. No ned to create site collections since it will be created automatically when we upgrade content DB.

Make sure you are running Test-SpContentDatabase cmdlet before proceed with the next ste which is the Content DB upgrade. This step will verify the new environment has all of the components we need before we actually upgrade the DB.

Use Mount-ContentDatabase cmdlet to upgrade the DB. Note that this wont upgrade UI for the sites contained ion the DB.

Once the DBs are upgraded, site coll admins can upgrade their sites. I recomemnd the following steps for this

1. Run site collection health  checks  to identify and address potential issues in their site collections.
2. Optionally create an upgrade evaluation site collection. This will allow us to preview the new UI and address issues before actual upgrade.
3. Finally the Actual upgrade

You are all set to use the first upgraded SP2013 site!!!!