Introduction to SharePoint

Introduction to SharePoint

Microsoft SharePoint is a web application platform developed by Microsoft. First launched in 2001, SharePoint has historically been associated with web content management and document management, but recent versions have significantly broader capabilities.

SharePoint is a multi-purpose tool designed to cater to web requirements common for most organizations. By default, SharePoint provides a Microsoft Office-like interface and is heavily integrated with the Office suite of tools. The tools are designed for non-experts to leverage web tools and functions without having to understand the underlying technical platform. SharePoint's tools can facilitate intranet portals, document & file management, collaboration, social networks, extranets,  websites, enterprise search, and business intelligence. It also has capabilities around system integration, process integration, and workflow automation.

SharePoint Foundation 2010 provides the core engine, services, and facilities for creating and using templates. This core functionality employs Microsoft programming and Web platforms, such as ASP.NET; it can be enhanced and extended by developing custom templates, Web Parts, and code.

SharePoint Server 2010 significantly extends the functionality and capability beyond the core services offered by SharePoint Foundation. There are different editions of SharePoint Server 2010; some of the service applications and functionality discussed in this paper will only be available in Enterprise Edition.

Learn SharePoint by Tekslate - Fastest growing sector in the industry. Explore Online "SharePoint Training" and course is aligned with industry needs & developed by industry veterans. Tekslate will turn you into a SharePoint Expert.

SharePoint 2010 Versions

In SharePoint 2007 the versions we became very familiar with were:

• Windows SharePoint Services (WSS)
• MOSS 2007 Standard
• MOSS 2007 Enterprise

For SharePoint 2010 it has changed to:

• SharePoint Foundation Services
• SharePoint Server 2010 Standard
• SharePoint Server 2010 Enterprise

Tier Architecture

SharePoint 2010 has not changed from a Tier perspective. There are Web, Application, and Database tiers. What’s important is it to understand is how to architect those tiers. For SharePoint 2010 the Application tier has changed significantly as it is more sophisticated than what was available in SharePoint 2007. Some things that we will get into within this series are creating service farms and partitioned services.

Microsoft Office and SharePoint Client Applications 

SharePoint offers integration and ease-of-use benefits when used in conjunction with Microsoft Office Client applications. For example, documents stored in a SharePoint library can be directly opened from Microsoft Word, PowerPoint, or Excel. Also, from within Microsoft Outlook, users can subscribe to and display list items from a SharePoint site or RSS feeds provided by a SharePoint-powered blog. Users can also create blog entries directly from Word. This integration makes data stored in a SharePoint infrastructure more accessible to end-users.

SharePoint Designer 2010 is a client application that simplifies the creation of custom sites, templates, applications, and WebParts. SharePoint Workspace 2010 enables synchronization with SharePoint document libraries and provides the ability to access view, and edit documents when working offline.

Integrating with Other Microsoft Server Applications Installing a server farm for SharePoint Server 2010 requires the inclusion of certain infrastructure and services to fully exploit all SharePoint features and functionality. For example, Active Directory (AD) is a pre-requisite, because it provides authentication and authorization among the servers in a farm and can be used to import user profile information from AD into SharePoint. If your farm is heavily used, adding additional directory servers may be necessary to handle the authentication traffic.

SharePoint Containment Hierarchy

When designing and maintaining a SharePoint solution, it is important to understand the various levels at which information is organized and contained. The containers within a SharePoint infrastructure are outlined in Table 1. The most granular individual items are located at the bottom of the table, and the level of aggregation increases as you progress to the top of the table. These containers provide physical and logical boundaries to consider while designing and deploying a SharePoint infrastructure.

Check Out SharePoint Tutorial

Table 1: SharePoint Containment Hierarchy

SharePoint Farm	A set of servers that collectively provide the databases, applications, and Web services that comprise a SharePoint solution
SharePoint Servers	Individual servers that run the operating system and application software required to perform roles or provide services for the SharePoint farm. Examples include a Web front-end server, an application server, and a database server
IIS Application Pool	A container that is configured within the Internet Information Server (IIS) to constrain a defined set of content to operate within a defined set of system processes. Application Pools provide logical barriers that protect against the threat of a compromised site being used as a vector to attack other sites hosted on the same Webserver
IIS Web Application	An IIS Web site with a unique domain name that is created and used by SharePoint products. Three Web applications must be configured: Central Administration, Shared Services Provider (SSP), and content. Additional Web applications may be useful for providing content isolation or for establishing distinct management or SLA boundaries within the farm.
SharePoint Database	Individual SQL Server databases that are used to store information about or data from within a SharePoint farm. The core databases used by SharePoint are Configuration, Administration, SSP, Search, and Content. Depending on its architecture and needs, a farm may feature multiple SSP, Search, and Content databases
Site Collection	A set of sites that feature the same owners and administrative settings (such as content types or quotas). A site collection features a top-level Web site and may also contain several sub-sites. Generally, all of the sites within a site collection share a common navigational design. One content database can host multiple site collections, but data from a given site collection must reside in the same content database. Similarly, one or more site collections may be configured within the same Web application
Site	A set of Web pages stored within a site collection that delivers common features or content to users. Sites may be structured, such as a top-level portal site, or maybe ad hoc, such as team sites for collaboration. MOSS provides templates for several types of sites, such as blogs, wikis, team sites, and portals
List	A means of collecting, storing, and organizing data within a site. Some common examples include document collections, calendars, and tasks
Item	An individual data object within a list. Some common examples include document or image files, contacts, and calendar entries

Understanding SharePoint Applications

To summarize, SharePoint Server is a system with the following capabilities:

• Websites both inside and outside the firewall.
• Collaboration through wikis, blogs, and more.
• Enterprise Content Management, Web content management, and publishing systems.
• SharePoint products and technologies include a search engine that you can customize for your needs.
• Business intelligence.
• Composite Applications. Includes data access, user interface, processes, and infrastructure.

SharePoint products and technologies provide a scalable architecture that can be appropriate for several users or 100,000 employees of a large corporation. For websites outside the firewall, SharePoint Server 2010 for Internet Sites enables you to build scalable, flexible websites that you can maintain with the ease of maintaining a SharePoint site.

SharePoint integration with the Microsoft Office 2010 system is important. You can take advantage of this integration to build solutions in such a way that—regardless of whether the users are in an Office client application or in a web browser—the features of your application are discoverable and convenient for them.

SharePoint Languages and Platforms

• Microsoft Visual C#, Microsoft Visual Basic, and Microsoft .NET Framework. You use the .NET Framework in one form or another when you build full-trust applications for the server farm, sandboxed site-collection level solutions, or within Microsoft Silver light applications. You are a more effective developer if you understand the various LINQ technologies: LINQ to XML, LINQ to Entities, LINQ to SharePoint, and LINQ to SQL.

• NET.SharePoint is based on ASP.NET and is hosted in IIS. It uses master pages and application pages, which enable you to standardize page appearance and behavior. It also uses Web Parts pages and Web Parts, which allow users to configure their own pages. You can connect Web Parts to each other so that you can create parent/child data editing capabilities or web mashup applications.
• HTML/CSS.There are several areas in SharePoint development where it is helpful to write and understand HTML and CSS.
• ECMAScript and the HTML Document Object Model (DOM).JavaScript is a powerful tool in your tool chest. You can use the JavaScript client object model or the OData REST API from JavaScript to obtain data and documents from your sites. JQuery and AJAX enable you to add rich interactivity.
• Silverlight/XAML. Silverlight is a development platform for creating engaging, interactive applications for many screens across the web, desktop, and mobile devices. You can use the managed client object model within the Silverlight code to read and write site data and documents. Microsoft Expression Blend is an effective tool for designing Silverlight Web Parts for SharePoint.
• You have to know how to code valid XML documents. Regarding developing with XML, my personal recommendation is to learn and master LINQ to XML. It is a more effective way to work with XML. Knowing XSLT can be useful. You can manually write custom XSLT list views, although the main purpose of XSLT list views is to enable you to apply interesting formatting to lists by using Microsoft SharePoint Designer. In other words, XSLT is more often used as the output of tooling instead of as a frequently used developer tool.

SharePoint Evolutions (Versions)

SharePoint Capabilities

You can find much information about SharePoint capabilities from the Microsoft SharePoint 2010 Product Overview. The capabilities include the following:

• You can develop and manage all the business websites by using SharePoint 2010. SharePoint 2010 provides a full set of tools that users can use to create any kind of site. SharePoint provides the infrastructure that simplifies site management.
• SharePoint 2010 provides collaboration tools that anyone can use to share ideas, find people and expertise, and locate business information. By default, SharePoint has many collaboration capabilities, but extending SharePoint in interesting ways can make collaboration proactive instead of reactive. Integrating presence into SharePoint applications by using Microsoft Lync Server 2010 makes it easier for colleagues to contact one another.
• Publishing organizations come in a variety of forms, from international press organizations to small departments that are responsible for publishing documentation for a product. Organizations can use SharePoint 2010 to manage content and use Word 2010 to edit content. I also divide the content capabilities into the following three subcategories:

• Publishing Systems. You can use SharePoint Server 2010 to manage a comprehensive publishing system. You may deliver the final product in PDF, XPS, or some other form. Open XML is an especially powerful technology that you can use to build publishing systems. You may have to write a sophisticated transformation to other formats. For example, see Open XML to other forms such as XHTML.
• Web content management. Whether using SharePoint Server 2010 for Internet Sites to build external-facing websites or using SharePoint for building wikis and pages inside the firewall, SharePoint lets users build out rich content with a minimum of effort.
• Enterprise content management. Many organizations have lots of organizational experience, often in the form of documents that are managed by using revisions, approval processes, and metadata.

• Customizing the search experience can be critical to making information come alive for your users. With SharePoint Server 2010, you can customize to allow the SharePoint search engine to search through custom documents. See SharePoint Enterprise Search in SharePoint Server 2010 for more information. In addition, you can customize the search to allow it to search through external content types (ECTs).
• A recent survey asked CEOs of very large companies whose issues were "top-of-mind" for them. Business intelligence (BI) was mentioned most often as the top priority. Excel Services and the ability to build dashboards are important for building powerful, flexible BI systems. Performance Point Services for SharePoint provide another option to deliver customizable BI dashboards.
• Create innovative solutions that combine customer user interfaces, data access, business logic, and services. You can document and standardize business processes using workflows.

Varieties of SharePoint Applications

What are the varieties of applications that SharePoint developers build? This resembles asking the question about the varieties of applications that you can build on an operating system. Developers are creating uses for SharePoint that cover many scenarios. Here are several varieties of applications.

• Vertical markets. Vendors customize SharePoint for many markets such as real-estate management, resort, and entertainment management, or equipment rental.
• Customized team applications. Sometimes custom applications can help departments of large organizations meet their goals in a more organized and visible manner. A testing organization could build a system to maintain a library of testing instruments and resources.
• Content publishing systems. These systems can be as simple as a site or site collection that is maintained by a single author. They can be as complex as a technical document generation system that is used by hundreds of writers, developers, and managers such as the Office.com website.
• Accounting systems.Although Microsoft does not recommend that transactional systems be implemented in SharePoint, bringing data into SharePoint from external accounting systems significantly augments the user experience.
• Management information systems. Some automated management systems do not have the same transactional requirements as accounting systems. You can maintain lists of customers, products, assets, and resources by using a default SharePoint installation. When extended programmatically, you can provide a very sophisticated experience.
• Sales and marketing. Many aspects of market and sales systems resemble management information systems. The integration of SharePoint with CRM systems such as Microsoft Dynamics results in powerful hybrid applications. In addition, mobile access to SharePoint sites provides road warriors with tools to interact with data that they need to do their job.
• Project management. The integration of Microsoft Project Server 2010 with SharePoint Server Enterprise provides project and portfolio management to help organizations prioritize investments, align resources, and execute projects. You can develop for Project Server by using its API.

Although many examples of SharePoint applications fit into one of these categories, this list is definitely incomplete.

Changes in SharePoint Foundation 2010

Changes in end-user functionality added in the latest version of SharePoint include:

• "v4" User Interface, featuring a Fluent Ribbon
• Business Connectivity Services- providing interfaces for interacting with business data
• New Governance and Workflow functionality
• Use of Wiki-pages rather than Web-part pages in default templates
• Social Profiles and Social Networking features

Support for SharePoint Workspaces 2010

• A re-developed client editor (SharePoint Designer)
• Multi-browser support: Internet Explorer 7, Mozilla Firefox 6, and (WebKit-based) Apple Safari 4.04. Support for Internet Explorer 6has not been tested, according to Microsoft.

Major Server-side or Developer changes include:

• New central administration UI
• Replacement of "Shared Service Providers" with "Service Applications"
• jQuery & Silverlight Support, plus more theming flexibility
• New Client-side Object Model APIs for JavaScript, Silverlight, and .NET applications
• Claims-based authentication
• Support forWindows Power Shell
• Sandboxed solutions

Additional changes exist in paid/advanced versions of SharePoint 2010

SharePoint 2010 Overview

SharePoint 2010 Architecture

Most Common uses of SharePoint

The most common uses of SharePoint include:

Intranet portal

A SharePoint intranet portal is a way to centralize access to enterprise information and applications on a corporate network. It is a tool that helps a company manage its data, applications, and information more easily. This has organizational benefits such as increased employee, centralizing process management, reducing new staff on-boarding costs, and providing the means to capture and share tacit knowledge (e.g. via tools such as wikis/blogs)

Enterprise content and document management

SharePoint is often used to store and track electronic documents or images of paper documents. It is usually also capable of keeping track of the different versions created by different users. In addition to being a platform for digital record management systems that meet government and industry compliance standards, SharePoint also provides the benefit of a central location for storing and collaborating on documents, which can significantly reduce emails and duplicated work in an organization.^[9]

Extranet sites

SharePoint can be used to provide password-protected, web-facing access to people outside an organization. Organizations often use functionality like this to integrate third parties into a supply chain or business processes or to provide a shared collaboration environment.

Internet sites

Using the 'Publishing' feature, SharePoint can be used to manage larger public websites.

Configuration and customization Web-based configuration

SharePoint offers a fluent ribbon user-interface that should be familiar to users of Microsoft Office. This interface provides a general user interface for manipulating data, page editing ability, and the ability to add functionality to sites.

Broadly, the web-based interface provides the ability to:

• Manipulate content in lists & libraries, pages, and sites.
• Copy, create, delete, or rename lists & libraries, pages, sites, and web-parts
• Manage user permissions, and view document/page version histories
• Manage definitions and properties of lists & libraries, pages, sites, and web-part
• The SharePoint 'Client Object Model' (available for javascript, Silverlight, and .NET), and REST/SOAP APIs can be referenced from within a custom page or feature.^[12]
• 'Sand-boxed' solutions packages can be uploaded by any end-user who has been granted permission. These are security-restricted and can be governed at multiple levels (including resource consumption management). In multi-tenant cloud environments, these are the only customizations that are typically allowed.
• Farm features and solutions are typically fully trusted codes that need to be installed at a farm-level.
• Service applications — It is possible to integrate directly into the SharePoint SOA bus, at a farm level.

SharePoint Designer

Integration & Development Models

Customizations may be surfaced via

• application-to-application integration with SharePoint
• Extensions to SharePoint functionality (e.g. custom workflow actions)
• 'Web Parts' (also known as "portlets", "widgets", or "gadgets") that provide new functionality when added to a page
• Pages/sites or page/site templates^[12]

Core platform functionality

Sites

A SharePoint Site is a collection of pages, lists, and libraries configured for the purpose of achieving an express goal. A site may contain sub-sites, and those sites may contain further sub-sites. Typically, sites need to be created from scratch, but sites can also be created according to pre-defined templates that provide packaged functionality. Examples of Site templates in SharePoint include Blogs, My Sites, collaboration (team) sites, document workspaces, group worksites, and meeting workspaces.

Sites have navigation, themes/branding, custom permissions, workflows, and have the ability to be configured or customized in a number of ways. In order to achieve a greater degree of maintainability, sites typically inherit site-level settings from their parent sites.

Lists & libraries

Lists and libraries are stored in SharePoint Sites. A-List can be thought of as a collection of pieces of information — all of which (typically) have the same properties. For instance, you can have a list of links called "my links", where each item has a URL, a name, and a description.

Lists have many features such as workflows, item-level or list-level permission, version history tracking, multiple content-types, external data sources, and many more features. Some of these features depend on the version of SharePoint that is installed.

A Library is a list where each item in the list refers to a file that is stored in SharePoint. Libraries have all the same behaviors as lists, but because libraries contain files, they have extra features. One of these is the ability to be opened and modified through a compatible WebDAV client (e.g. Windows Explorer).

Microsoft SharePoint comes with some pre-defined list and library definitions. These include Announcement Lists, Blogs, Contacts, Discussion Boards, Document Libraries, External Content (BCS) lists, Pages, Surveys, and Tasks.

Some of these pre-defined lists have additional integration. For example, lists based on the contact content-type can be synced directly with Microsoft Outlook.

Web-parts

Web-parts are sections that can be inserted into Pages in SharePoint sites. These sections are UI Widgets whose typical uses are

• Displaying content defined in the web part's settings (e.g. custom content or an iFrame)
• Displaying items from Lists/Libraries (this can be customized in SharePoint Designer, using XSLT & CAML)
• Providing Access to Features in the SharePoint platform (e.g. Search)

Web-parts based on completely custom code can be built in Microsoft Visual Studio 2010 and uploaded by end-users to SharePoint as packaged, sandboxed features. Due to the prevalence of SharePoint, third-party vendors often provide SharePoint web-parts for intranet sites.

SharePoint Web-parts were formerly implemented separately from ASP.NET Web-parts, but as of SharePoint 2007, SharePoint's Web-parts are now based on it.

Pages

SharePoint has three primary page content-types: Wiki pages, Web-part pages, and Publishing Pages. Unlike prior versions of SharePoint, the default page type is a 'Wiki Page', which enables free-form editing based on the ribbon toolbar. It is possible to insert Web-parts into any page type.

Search

SharePoint Foundation contains a limited search engine. Microsoft produces a free product called Microsoft Search Server Express to complement SharePoint Foundation. Different SharePoint search versions offer different features, including the ability to search within documents and - except in cloud environments: across external data sources (such as file systems). You can read a SharePoint Enterprise Search features deep comparison.

The architecture of SharePoint (Topologies)

Architecture

The SharePoint platform is a flexible, n-tier service-oriented architecture (SOA). It can be scaled down to operate entirely from one machine, or scaled up to be managed across hundreds of machines.

Farms

A SharePoint farm is a logical grouping of SharePoint servers that share common resources. A farm will typically operate stand-alone, but it can also subscribe to functionality from another farm, or provide the functionality to another farm. Each farm has its own central configuration database, which is managed through either a Power Shell interface or a Central Administration website (which relies partially on Power Shell’s infrastructure). Each server in the farm is able to directly interface with the central configuration database. Servers use this to configure services (e.g. IIS, windows features, database connections) to match the requirements of the farm and to report server health issues, resource allocation issues, etc.

Web applications

Web Applications (WAs) are top-level containers for content in a SharePoint farm and are typically the interface through which a user interacts with SharePoint. A web application is associated with a set of access mappings or URLs which are defined in the SharePoint central management console, then automatically replicated into the IIS configuration of every server configured in the farm. WAs are typically independent of each other, have their own application pools, and can be restarted independently in IIS

Site collections

A site collection is used to provide a grouping of 'SharePoint Sites'. Each web application will typically have at least one site collection. Site collections may be associated with their own content databases, or they may share a content database with other site collections in the same web application.

Service applications

Service Applications (SAs) provide granular pieces of SharePoint functionality to other web and service applications in the farm. Examples of service applications include the User Profile Sync service and the Search Indexing service.

An SA can be turned off, exist on one server, or be load-balanced across many servers in a farm. SAS is designed to be as independent as possible, so depending on the SA — restarting an SA, experiencing an SA failure, or misconfiguring an SA may not necessarily prevent the farm from operating. Each SA enabled on the farm typically has its own process that requires a certain amount of RAM to operate, and typically also has its own configuration database and Active Directory (AD) service account. SharePoint Server and SharePoint Enterprise include all the SharePoint Foundation SAs, as well as additional SAs.

Administration and security

The modular nature of SharePoint's architecture enables a secure 'least-privileges' execution permission best practice

SharePoint Central Administration (the CA) is a web application that typically exists on a single server in the farm; however, it is also able to be deployed for redundancy to multiple servers. This application provides a complete centralized management interface for web & service applications in the SharePoint farm, including AD account management for web & service applications. In the event of the failure of the CA, Windows Power Shell is typically used on the CA server to reconfigure the farm.

The structure of the SharePoint platform enables multiple WAs to exist on a single farm. In a shared (cloud) hosting environment, owners of these WAs may require their own management console. The SharePoint 'Tenant Administration' (TA) is an optional web application used by web application owners to manage how their web application interacts with the shared resources in the farm.

Service Application

Important changes that you should be aware of:

1. In SharePoint 2007 there were Shared Service Providers (SSP) which was used to host services. SSPs have been completely removed from SharePoint 2010 and services can be run independently.
2. Some services in SharePoint 2010 will be referred to as Service Applications. Not all services in Central Administration are Service Applications. In the table below, you will see which services are considered to be Service Applications. You will see a trend that Service Applications tend to map to major features of SharePoint rather than services which could be considered part of the infrastructure of SharePoint.
3. Service Groups have been introduced to logically manage Service Applications. When Service Applications are added they will be included in a Default Group. Web Applications can use that Default Group or use a Custom Group of Service Applications. What this provides is greater control of which Service Applications are available to specific web applications. If you are familiar with SharePoint 2007, the Service Group concept is one of the reasons we created different SSPs because sometimes we needed to create barriers between web applications.
4. SharePoint 2010 services can be reused within and across farms. This was not available in SharePoint 2007 and provides a significant amount of scalability options.
5. SharePoint 2010 supports Service Partitioning. If you are familiar with database partitioning, think of it is horizontal partitioning of data within a SharePoint service. Not all services support service partitioning; partitioning is only used in services that are data-driven. A typical scenario is that a centrally managed/cross farm service with data that should not be exposed to all subscribing farms. If that is the case, a farm would subscribe to a partition of centrally managed service. In SharePoint lingo, each partition is referred to as a “tenant”.

Knowing what we now know, when scaling out these services we will take the following into consideration:

• Multiple instances of the same Service Applications can be initiated within a farm.
• Service Applications are shared across Web Applications within a farm by Service Group.
• Some Service Applications can be shared across multiple farms while others cannot.
• Service Groups can logically contain Service Applications that reside in other farms.
• Web Applications have the flexibility to use multiple instances of the same type of Service Application (regardless of which farm hosts that service).
• Service Applications can have its data partitioned and only accessible to specific subscribers.
• Service Groups can be used to logically scale for performance, security, and scalability.

Some side notes:

• Service Applications are hosted within IIS. It is possible to have Service Applications deployed to different application pools to achieve process isolation (important for both security and fault tolerance). So it is possible to have a single machine host many services and isolation between them.
• Each Service Application instance has a Connection which Web Applications connect to. Web Applications use these Connections (sometimes referred to as proxies) to send and retrieve data from a Service Application.
• If the same type of Service Application is used more than once in a single Web Application, one of the Connections will be marked as the primary.
• Services are deployed through the Configuration Wizard, Central Admin, and using Windows Power Shell. Services can be managed through Central Admin and Power Shell.

Given this flexibility in service configuration you now can:

• Have a better ability to share dedicated services across regional locations.
• Have the ability to create dedicated services by business unit. For instance, a Finance Web Application may have a dedicated Excel Services Service Application instance while a different Excel Services Service Application instance may be available to the rest of the farm.
• Now have greater control to ensure that data cannot be shared between logical groups of users. For instance lockdown departmental or intranet data.
• Have the ability to support hosted models in a more secure and efficient manner.
• Service Applications that have expensive operations, like Search, can be centralized and reused across farms.

We will put these rules for Service Applications into action in the next part of this series.

SharePoint 2010 Services

In SharePoint 2007 we commonly had to configure the following services:

• Document Conversions Launcher Service
• Document Conversions Load Balancer Service
• Excel Calculation Services
• Office SharePoint Server Search
• Windows SharePoint Services Help Search
• Windows SharePoint Services Web Application

In many cases with SharePoint 2007 implementations services were not configured correctly. This resulted in poor performance and the inability to scale to meet business demands. Many people implementing SharePoint 2007 did not understand that both logical and physical architectures have to be aligned to how SharePoint services will be utilized. This will be a problem for many on the 2010 platform.

As discussed the service architecture has changed for SharePoint 2010 in many ways. Before we dive into all of the strategies of how services should be aligned in both the logical and physical architectures let us understand what the new services are.

Here is a list of services for SharePoint 2010. I found several pieces of information and I manually created this table with the information that I have.

Services	Description	Service Application	Cross Farm	Partitioning	Available On
Access Database Services	New service that allows for viewing, editing, and interacting with MS Access through a browser.	Yes	No	Yes **	SharePoint Server 2010 Enterprise
Application Registry Service	Enables users to search and collaborate around business data. Provides backward compatibility to BDC service.	No	No	NA	SharePoint Foundation 2010 and up
Business Data Connectivity	Access to the line of business systems. Service now supports writing to data services.	Yes	Yes	Yes	SharePoint Foundation 2010 and up
Central Administration	Central Admin Site	No	No	NA	SharePoint Foundation 2010 and up
Document Conversions Launcher Service	Schedules and initiates document conversions.	No	No	NA	SharePoint Foundation 2010 and up
Document Conversions Load Balancer Service	Balances document conversions across the SharePoint farm.	No	No	NA	SharePoint Foundation 2010 and up
Excel Calculation Services	Ability to interact with Excel files in a browser. New extended functionality.	Yes	No	No	SharePoint Server 2010 Enterprise
Lotus Notes Connector	Index service connector to index Lotus Notes Domino Servers.	Yes	Yes	Yes	SharePoint Server 2010 Standard and up
InfoPath Service	Supports hosting InfoPath forms in SharePoint.	No	Yes	Yes **	SharePoint Server 2010 Enterprise
Managed Metadata Service	New service that manages taxonomy structures and definitions.	Yes	Yes	Yes	SharePoint Server 2010 Standard and up
Microsoft SharePoint Foundation Incoming E-mail	Email service. This will run on the machine where the web application is running.	No	No	NA	SharePoint Foundation 2010 and up
Microsoft SharePoint Foundation Subscription Settings Services	New service used to track subscription IDs and settings for services that deployed in partition mode.	Yes	NA	NA	SharePoint Foundation 2010 and up
Microsoft SharePoint Foundation User Code Service	New service runs code deployed as part of a sandbox solution and runs in restricted mode. Must be started on any machine in the farm that needs to run Sandbox code.	No	NA	NA	SharePoint Foundation 2010 and up
Microsoft SharePoint Foundation Web Application	The service that runs the web application.	No	No	NA	SharePoint Foundation 2010 and up
Microsoft SharePoint Foundation Workflow Timer Service	Responsible for running timer jobs.	No	No	NA	SharePoint Foundation 2010 and up
PerformancePoint	BI Dashboard services.	Yes	No	NA	SharePoint Server 2010 Enterprise
PowerPoint	New services that allow viewing, editing, and broadcasting PowerPoint in a browser.	Yes	No	Yes **	SharePoint Server 2010 Enterprise
Project	Host project server 2010.	Yes	No	Yes	Additional server product.
Search Query and Site Settings Service	Service that performs a query across built indexes.	Yes	Yes	Yes*	SharePoint Server 2010 Standard and up
Secure Store Service	The service provides SSO authentication.	Yes	Yes	Yes	SharePoint Server 2010 Standard and up
SharePoint Foundation Search	Service that provides search capabilities for SharePoint Foundation Search only. For SharePoint Server 2010 Standard and Enterprise this service will perform an online Help search.	No	No	NA	SharePoint Foundation 2010 and up.
SharePoint Server Search	Crawls content creates indexes and performs queries. Automatically configured.	Yes	Yes	Yes*	SharePoint Server 2010 Standard and up
State Service	New services that provide temporary storage of user session data for SharePoint components.	Yes	No	Yes **	SharePoint Server 2010 Standard and up
Usage and Health Data Collection	Reporting services that provide farm-wide usage and health.	Yes	No	Yes	SharePoint Foundation 2010 and up
User Profile	New and expanded social networking services and features.	Yes	Yes	Yes	SharePoint Server 2010 Standard and up
User Profile Synchronization Service	Synchronizes user and group profile information that is stored in the SharePoint Server 2010 profile store with profile information that is stored in directory services across the enterprise. Works with AD, BDC, Novel LDAP, and Sun LDAP (more info).	Yes	Yes	Yes	SharePoint Server 2010 Standard and up
Visio Graphics Service	Ability to view published Visio diagrams in a browser.	Yes	No	Yes **	SharePoint Server 2010 Enterprise
Web Analytics Data Processing Service	Captures data for analytics.	Yes	Yes	Yes	SharePoint Foundation 2010 and up
Web Analytics Web Service	Web service interfaces for analytics.	Yes	Yes	Yes	SharePoint Foundation 2010 and up
Word Automation Services	Service that performs automated bulk document conversions.	Yes	No	Yes **	SharePoint Server 2010 Standard and Up

* FAST Search cannot be partitioned. ** Supports partitioning but is not needed because there is no tenant data.

SharePoint 2010 Changes

The biggest change in SharePoint 2010 is the flexibility you now have with the configuration and re-use of services. In the previous blog in this series, I identified several rules that you should know which will directly apply to how the logical architecture of SharePoint 2010 would be done. Here they are again:

1. Multiple instances of the same Service Applications can be initiated within a farm.
2. Service Applications are shared across Web Applications within a farm by Service Group.
3. Some Service Applications can be shared across multiple farms while others cannot.
4. Service Groups can logically contain Service Applications that reside in other farms.
5. Web Applications have the flexibility to use multiple instances of the same type of Service Application (regardless of which farm hosts that service).
6. Service Applications can have its data partitioned and only accessible to specific subscribers.
7. Service Groups can be used to logically scale for performance, security, and scalability.

In the following sections, I have identified some common scenarios for the configuration of the SharePoint 2010 logical topology based on these rules. It will not be possible in this blog to go over every permutation of these rules.

As well as best practices for the configuration of these services is still not very well known other than the information is being provided to us by Microsoft and our experiences with SharePoint 2007. However, you should be able to take these examples and use them as a way to start doing some early planning for the implementation of SharePoint 2010.

Side Note – If you are familiar with some of the logical topology diagrams that are provided by Microsoft they usually include Application Pools in those diagrams. I have decided to exclude that from these diagrams to make understanding the logical topology simple. Albeit understanding how the Applications Pools are incorporated into the topology is extremely important (security and fault tolerance). Usually, when architecting a SharePoint topology I start with understanding how I want to organize service to achieve the best possible performance, security, and redundancy. Once I have that organized, I will then use Application Pools to help attain those tenants.

Single Farm Single Service Group

This first topology depicts a standard SharePoint farm that has a single service group that is shared across all types of sites. Any time new sites are added within this farm, they will have access to all of the services that are available in the Default Application Group.

Advantages:

• The most simple architecture to implement.
• All web applications added to the farm have immediate access to all the available services.
• All services are grouped together and can be managed centrally.

Disadvantages:

• Does not allow for isolation of data used within the services. This means that all websites have access to each other’s data.
• Cannot create dedicated services for specific web applications.
• Will not scale well because publishing and collaboration would be occurring in the same farm.

Recommendations:

• This is an initial place to start as your configuration for SharePoint 2010. It can always be scaled or reconfigured to support more demand.
• It would be recommended to make sure that each service that can be partitioned be made partitioned. This is important because it not possible to partition a service after has been created. If services are partitioned from the beginning you have the ability to create some isolation of data between site collections.
• These sites could all be installed on a single web application but that is not recommended. It is better to created dedication Web Applications for each running within their own application pool. This provides long-term scalability.

Single Farm Multiple Service Groups

This second example is a reconfiguration of the previous farm; the difference is that multiple Application groups have been created. There is a Default Application Group which has some of the core Service Applications that can be used by all the sites. Some sites, however, will have dedicated services. You will want to have dedicated services for scalability, performance and security reasons and this will be covered later on from a physical perspective.

Observations:

• The first thing that is interesting about this configuration is you see the Managed Metadata Service is configured into each application group. One interesting thing we will see with SharePoint 2010 is a better ability to manage Information Architecture, a key ingredient for Governance. We now have the ability to create reusable Information Architectures across sites and farms as well as created dedicated ones.

Second, you will notice that Search has been centralized as part of the default application group and has been made a resource to all the sites. This is because it is a resource-intensive process and it is not likely

• you will be creating dedicated search farms for a specific site. Note that the FAST search cannot be used in this manner. FAST can either be used behind the firewall or outside but the same servers cannot be used for both.
• Third application services have been distributed and dedicated. For instance Excel Services, BCS, Access Service, etc. are broken out.

Advantages:

• Supports the ability for multiple goals to be met in the same farm.
• Provides the ability to have better isolation of services. This provides the ability to have a granular implementation that better supports scalability, performance, and security.
• Allows for divisional, department, or program administration.

Disadvantages:

• Complex configuration to manage.
• Requires more Governance and administration.
• Will require more hardware/virtual resources to host.

Recommendations:

• This configuration is good for a small SharePoint implementation within a department, division, or business unit.

Multi-Farm

In this farm configuration, we have broken it out and created several independent SharePoint farms that still use the central services farm.

Observations:

• Sites have been separated into dedicated farms based on usages such as public internet, extranet, internet, and intranet.

• Each farm has dedicated application groups of services that specific to their use.
• All the farms have access to shared services in the central services farm.

Advantages:

• There is a clear separation between the sites by placing them in dedicated farms. This is very important because publishing farms and collaboration farms have been separated.
• Organizations can be segregated from each other and prevent the initiatives of one from interfering with the initiatives of another.
• Farms can be configured with service groups that are specific to their needs.
• Central services can still be shared across farms where it makes sense.

Disadvantages:

• A more complex configuration that requires more considerable time to administer and govern.

Recommendations:

• This is an enterprise farm configuration.
• This configuration should be implemented when a company has the need to optimize administration and hosting at the enterprise level.
• This configuration is needed when data and services need to be isolated but there is still an opportunity for reuse.

Multi-Farm with Application Service Partitioning

This farm configuration introduces service partitioning into the previous diagram. It is recommended that all services be partitioned when they are initially set up, even if one partitioned is only used. It is not possible to change a service to allow for partitioning after it has been started in an un-partitioned state.

Observations:

• In this diagram, you will see in Farm A both the Managed Metadata and Business Connectivity Services have been partitioned. Others could have but just selected these for discussion. Now Farms B through E and utilize partitions that are just for them and they will have isolation.
• Notice in Farm D we were able to remove those services from the configuration. This makes the management of that farm less complex.
• Notice in Farm E we kept the Managed Metadata service. There is nothing from stopping that and can still be considered completely legitimate. For instance, the administrator in Farm C does not have access to Farm A, and all they are using from Farm A is a partition of Managed Metadata that all the farms are using. If that is the case, they may want to still have a Managed Metadata service in Farm C so that they can make tactical additions to the Information Architecture.

Advantages:

• Provides even more granularity and isolation of data management within SharePoint 2010.

Disadvantages:

• Again an even more complex scenario for managing services for an enterprise farm.

Recommendations:

• Using service partitioning must be a strategy considered when setting up an enterprise SharePoint 2010 farm.

Hosted Partitioned Farm

The last farm configuration I will introduce to you is the concept of a completely hosted farm. This is a very interesting scenario because you were not empowered to do this very well with SharePoint 2007. Some SharePoint service companies provided SharePoint hosted solutions but given what was available in SharePoint 2007. Now with SharePoint 2010 and Microsoft Azure those limitations have been removed.

Observations:

• This scenario should not just be considered for providing SharePoint 2010 hosted solutions by a services company. A company itself can consider creating a solution like this for creating on-demand solutions for provisioning full farms in a rapid fashion.
• This scenario would also make sense for a parent company that has many subsidiary companies that they want to serve in an economical fashion.
• As you will notice this approach heavily uses service partitioning. The goal is to make the farms as lightweight as possible.

Advantages:

• Utilizes many of the enterprise best practices discussed so far.
• Since partitioning is utilized, there is the isolation of data between farms.
• Governance and administration are centralized into a single location and is not spread across farms.

Disadvantages:

• Because all services are centralized, it is not possible to create customizations at the farm level. This means that if a farm has a special functional, performance, or security requirement it may be hard to support that requirement.

Recommendations:

• If you are creating a hosted solution and the expectations can be set ahead of time this is a good approach. However, this is very hard to do and more often than not there will be requirements that will require dedicated services within the farms. It is ok to set out with this in mind but you must remain flexible to support architecture like the one in the previous section.

SharePoint FARM

SharePoint 2010 Database Layer 

Microsoft SharePoint Server 2010 introduces both new databases and databases whose distribution and purpose differ over previous versions of Microsoft SharePoint Products and Technologies. This post details the changes in the Microsoft SharePoint Server 2010 database layer. This section provides information about Shared Service Applications that have a database dependency and is not an exhaustive list of all Shared Service Applications available in Microsoft SharePoint Server 2010.  At the time of publication, this is not 100% complete.

Usage and Health Data Collection Service

The Usage and Health Data Collection Service collects and logs SharePoint health indicators and usage metrics for analysis and reporting purposes.

Logging Database

The logging database is the Microsoft SQL Server, MSDE, or WMSDE database that stores health monitoring and usage data temporarily, and can be used for reporting and diagnostics.

Search Service

Administration Database

The Administration Database is what the Shared Services Provider database was in Microsoft Office SharePoint Server 2007 and is instantiated once per Search application aligning with the Administration Component. The Administration Database hosts the Search application configuration and access control list (ACL) for the content crawl.

Property Database

The Property Database stores crawled properties associated with the crawled data to include properties, history data, crawl queues, etc.

Crawl Database

The Crawl Databases host the crawled data and drives crawl - the Crawl Database is what the Search database was in Microsoft Office SharePoint Server 2007.

Web Analytics Service

The Web Analytics Service provides rich analytics giving you insights into your web traffic, search, and SharePoint assets enabling you to better understand your user and deployments. With SharePoint Web Analytics, you’ll be able to tailor the system to meet the needs of your users, optimize how they use and discover information, and create targeted content for your sites.

Staging Database

The Web Analytics Staging database is the working database that stores un-aggregated Fact Data, asset metadata, queued batch data, and provides short term retention of this content.

Reporting Database

The Web Analytics Reporting database stores aggregated standard report tables, Fact Data aggregated by Site Group, date, and asset metadata in addition to diagnostics information.

Configuration Database

The configuration database handles all administration of the deployment, directing requests to the appropriate database, and managing load-balancing for the back-end databases. When a front-end Web server receives a request for a page in a particular site, it checks the configuration database to determine which content database holds the site's data. You can run the

configuration database on the same computer as a Web server or on a remote computer running Microsoft SQL Server. The configuration database concepts are relatively unchanged in Microsoft SharePoint Server 2010. In Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0, the Sitemap table was stored in the configuration database which provided information about which content database contains data for a given site. When Windows SharePoint Services or Microsoft Office SharePoint Server 2007 received the URL of a request, settings in this database determine which content database contains data for the site. In Microsoft SharePoint Server 2010 and Windows SharePoint Services 4.0, the Sitemap is serialized to disk to improve performance and reduce database callback operations that could result in contention when serving requests on large server farm deployments.

Content Database

The back-end content database stores all site content, including site documents or files in document libraries, list data, and Web Part properties, as well as user names and rights. All the data for a specific site resides in one content database on only one computer.

Central Administration Content Database

See also Content Database.

Shared Services Provider (SSP)

The Shared Services Provider layer is obsolete in Microsoft SharePoint Server 2010 replaced with Shared Services Applications, to understand changes in database design associated with the Shared Services Provider database, see also Search and People in this section.

NOTE

A Microsoft Office SharePoint Server 2007 Shared Services Provider when upgraded will result in a new Search, User Profile, Excel Services, Application Registry Backwards Compatibility, and Managed Metadata Service shared services applications. New databases will be created as required to support the upgrade and Web application settings are preserved through establishing a proxy for each service application.

User Profile Service

The User Profile Service encompasses user-profiles and My Sites.

Profile Database

The user profile database is a flexible database that stores and manages users and associated information. The database allows for a flexible schema that supports multiple data types. It can be queried and it can be updated. For example, a company can define the attributes of an employee record in the profile database. Then for each record, an employee object will be created and saved. This information is now usable in a number of ways, such as in WebParts, in the Web service, or to create rule-based groups or roles.

1. 1. Properties
   2. Profiles
   3. Multiple values
   4. Vocabularies
   5. Colleagues
   6. Memberships
   7. Change Log

Synchronization Database

The synchronization database is used to store configuration and staging data for synchronization of profile data from external sources such as Active Directory. Social Tagging DatabaseThe social tagging database stores social tagging records and their respective Url which are coupled with information from the profile and taxonomy databases at the front-end layer at execution/request. This database is used to store social tags and notes created by users. Managed Metadata ServiceThe Managed Metadata Service publishes a term store and, optionally, a set of content types. Term Store database in which managed metadata is stored. The Web front end public APIs interact with the data layer to get or set data. The data layer talks to the term store directly if the shared service is local to the farm, or it talks to a backend Web service on an application server if the shared service is not local. The backend Web service then interacts with the data layer on the application server to get to the term store. State ServiceThe State Service maintains temporary state information for InfoPath Forms Services. State DatabaseThe state database maintains temporary state information for InfoPath Forms Services. Business Data Connectivity ServiceThe Business Database Connectivity Service provides a means for storing, securing, and administering external content types and related objects. Database

Stores external content types and related objects.

Secure Store Service

The Secure Store Service replaces the Single Sign-On Service in previous versions of the product.

This service provides storage and mapping of credentials such as account names and passwords. Portal site-based applications can retrieve information from third-party applications and back-end systems such as Enterprise Resource Planning (ERP) and Customer Relations Management (CRM) systems.

The use of Secure Store functionality enables users to authenticate without asking the user multiple times for the credentials needed to authenticate in that system.

Store Database

 

Provides storage and mapping of credentials such as account names and passwords.

Standard SharePoint Server 2010 Enterprise edition installation, out of the box you’ll have the following databases:

Application_Registry_Service_DB_GUID Bdc_Service_DB_GUID Managed Metadata Service_GUID PerformancePoint Service Application_GUID Search_Service_Application_CrawlStoreDB_GUID Search_Service_Application_DB Search_Service_Application_PropertyStoreDB_GUID Secure_Store_Service_DB_GUID SharePoint_AdminContent_GUID SharePoint_Config StateService_GUID User Profile Service Application_ProfileDB_GUID User Profile Service Application_SocialDB_GUID User Profile Service Application_SyncDB_GUID WebAnalyticsServiceApplication_ReportingDB_GUID WebAnalyticsServiceApplication_StagingDB_GUID WordAutomationServices_GUID WSS_Content WSS_Logging

Introduction to Web Parts:

Web Parts as you know are Reusable components that can be deployed and added to many different SharePoint site pages. In this post, we will talk about custom and Out-of-box web parts in SharePoint 2010. In SharePoint 2010 we can create two kinds of custom Web Parts:

1. Visual Web Part - While creating a Visual web part you will have a design interface available with you, where you can simply drag and drop checkboxes, labels, or your own custom controls to make up the web part UI. To add the business logic, a code-behind file is also attached to the web part

Technically, a Visual web part in SharePoint 2010 is an ascx User Control that is hosted inside a standard asp.net web part. If you notice that the web part class does not now inherit from Microsoft.SharePoint.webpartpages.webparts or System.Web.UI.WebControls.WebParts instead it inherits from the UserControl namespace.

2. 2. Standard AsP.NET WbeParts - Here you will have to build up your user interface and logic in a class file. Unlike, visual web part standard asp.net web parts in SharePoint 2010 do not give you any drag and drop design surface for developing WebPart UI. This type of web part Inherits from the Standard ASP.Net web part instead of UserControl or SharePoint.webpart.

WebPart Packaging - Visual Studio 2010 package and deploy web parts when you press Clt + F5. It has a packaging and deployment processor which will create the needed solution package for your web part and will deploy it in your SharePoint site. You can then add the web parts on any SharePoint site page from the web part gallery. 

In SharePoint 2010 we can create two types of web parts.

General-Purpose Web Parts

General-Purpose Web Parts
Web Part Category	Example Web Parts	Description
Lists and Libraries	XSLT List View Web Part	Use to create custom list views with SharePoint Designer 2010. Lists and libraries use XSL style sheets to control output.
None	Data Form Web Part	Use this Web Part in SharePoint Designer 2010 to create custom queries and displays.
Content Rollup	Content Query Web Part*, Summary Links Web Part*	Query content from anywhere in the current site and customize its presentation.
Content Rollup	RSS Viewer Web Part*, XML Viewer Web Part	Use an RSS feed or XML file as the data source and customize its presentation.
Media and Content	Silver light Web Part	Display a Silver light application with this Web Part.

*Requires SharePoint Server 2010 Standard license Specialized Web Parts

Specialized Web Parts
Web Part Category	Example Web Parts	Description
Business Data*	Business Lists	Display items from external data sources, such as databases.
People**	Note Board	Allow users to add comments to any page.
Navigation**	Tag Cloud	Displays a tag cloud for tags found in the current site.
Search**	Refinement Panel, Search Core Results	Use to create custom search experiences.

*Requires SharePoint Server 2010 Enterprise license; **Requires SharePoint Server 2010 Standard license

A Brief on Sandbox Solutions

Sandbox solution is a new feature introduced in SharePoint 2010. It's a secured wrapper around web parts and other elements with limitations. There is no thumb rule that every web part in SharePoint 2010 belongs to Sandbox Solution. But it's recommended to develop web parts 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 many resources. Usually, when sites working slow, developers complain the server is slow whereas site/server administrators blame on Developer code/solutions. Now Microsoft put a Full Stop to that.

Technically speaking SharePoint solutions run in separate 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 a new version of Sandbox solution over the existing solution, SharePoint will display No Solution found an error in Sandbox Web parts on the page. However, within second’s 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 a web-based interface. This reduces the dependency on the Farm Administrator and improves rapid deployment.

Sandbox Processes Here the processes required for Sandbox solutions.

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

Sandbox Limitations As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in the SharePoint environment. Few Key limitations that 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 using 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. Additionally, sandbox won't allow reading Farm SMTP address. So developers have to specify the SMTP address in the code itself (maybe some other workaround).
3. No Support to WebPartPages Namespace - Sandbox won't allow using 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:ProgramDataMicrosoftSharePointUCCache at runtime. Note the ProgramData is a hidden folder.
6. No Visual Webparts - Visual Studio 2010 by default won't allow creating Visual Webparts to deploy as a 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 a SharePoint environment provided by Microsoft to manage SharePoint Sites on the 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 the future Sandbox, the solution will give more features for developers.

Sandbox Solutions support the following SharePoint item types:

• List definitions
• List instances
• Content Types/Fields
• Navigation
• Web Parts derived from WebPart
• Event receivers
• Custom Workflow Actions
• Workflows

Sandboxed Web Part

Building a sandboxed solution is the same as building a farm solution. The best way to understand the development process is to walk through the creation of a sandboxed solution using Visual Studio 2010.

Start by opening Visual Studio 2010. You can see in Figure 2 that Visual Studio 2010 has a number of SharePoint project templates built-in, and there are templates for both Visual Basic and C#.

You want to build a sandboxed web part solution, so you must start with an empty SharePoint project.

The Visual Web Part project template isn't supported in the solution gallery because it contains a .ascx control that must be deployed to the _layouts directory and deploying controls isn't allowed in any directory in sandboxed solutions. For this example, name the solution SimpleWebPart.

After you click OK, the project wizard will ask you what type of project you're creating and for a path, as shown in Figure 3.

The default is to deploy as a sandboxed solution. It's important that you set the correct path to the local site in this dialog because Visual Studio will use this path to deploy and debug the solution.

If you're unsure, it's a good practice to click the validate button to ensure that Visual Studio can connect to the site using the path you set. There's also a link at the bottom of the dialog to learn more about sandboxed solutions from the help system.

After you click Finish, you'll have an empty SharePoint sandboxed solution project. You could press F5 and deploy the project at this point, but you wouldn't see much because it contains no features.

Take a minute to understand what's included in the project, shown in Figure 4.

The empty project contains the standard references you would expect in a .Net project and a reference to Microsoft.SharePoint.dll and Microsoft.SharePoint.Security.dll.

There's a node called Features that's empty and will contain the features of your solution package. There's a package node that contains the SharePoint package information. And finally, there's a default strong name key file called key.snk.

Add a Web Part to the project by choosing Add New Item from the project context menu or by pressing ctrl-shift-A (if you're using the C# profile). Be sure to choose the Web Part item, which Figures 5 shows, not the Visual Web Part item. The default name of WebPart1 is fine for this walkthrough. Click Add to add the Web Part feature to your package. At this point, Visual Studio creates a feature called Feature1, shown in Figure 6, that contains your Web Part.

It also adds a node for the Web Part that contains the SharePoint Elements.xml file, code file, and the .webpart file. Visual Studio contains a visual package designer that will allow you to manage and organize your SharePoint package without editing any xml files.

You can now add the code for your Web Part in the WebPart1.cs file. This code, shown in Listing 1is exactly like code that you may have written in the past for farm-level solutions.

The code displays a list of the lists that are in the current site in a listbox control. Accessing list data and creating lists are two of the most common tasks for a SharePoint solution, and in a sandboxed solution you can work with lists and libraries just as you would in a farm solution. One of the only restrictions is that you can only access lists and libraries within the site collection where the sandboxed solution is installed.

Once you've written the code, you can easily deploy and debug the code from the Visual Studio IDE. Just like most other Visual Studio projects, pressing F5 will compile and debug the project.

In any SharePoint project, there are a number of steps that occur when you press F5--you can see an example list of SharePoint lists in Figure 7. The steps that Visual Studio takes are extensible and you can control all aspects of the build process.

By default, Visual Studio compiles the project then builds the SharePoint solution package file—this is a standard, compressed cabinet (cab) SharePoint package file with a .wsp extension. Next, because this is a sandboxed solution, Visual Studio will upload the solution package to the Solution Gallery and activate it.

It will attach the debugger to the sandboxed solution worker process, SPUCWorkerProcess.exe, and start the web site in the browser. You may be prompted for confirmation to attach to the worker process, as shown in Figure 8.

Debugging this SharePoint code is exactly the same as any other Visual Studio project. Simply set a breakpoint on the line of code.

The best part about developing sandboxed solutions is that you don't have to learn a new way of doing things. If you've developed in .Net in the past, SharePoint development shouldn't have much of a learning curve, and you'll be up to speed developing on SharePoint, Microsoft's fastest-growing development platform.

SharePoint 2010 Sandboxed solutions run as an isolated and monitored process. In case unusual operation like the one above is detected the process will finalize its execution.

Monitoring Sandbox Solutions

As Site Collection administrator you can monitor the resource usage of SandBox solutions via Site Actions > Site Settings > Galleries > Solutions. The simple dashboard shows how much resources have been consumed by deployed solutions. To learn more about SharePoint resource usage configuration

Interested in SandBox Solutions? Stay tuned as I will be posting some interesting samples in the next few posts.

Figure 1: Sandbox upload process in SharePoint 2010

Once the WSP package is loaded successfully, don't forget to "activate" it before using it on a page. Otherwise, the Web Part will not show up in the Web Part Gallery and it will take a while before the problem is identified.

Differences Between Sandboxed and Farm Solutions

When you compile a SharePoint solution, it deploys to the SharePoint server and a debugger attaches to debug it. The process used to debug the solution depends on the setting of the Sandboxed Solution property: sandboxed solution or farm solution.

Farm Solutions Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm. When you debug a SharePoint project whose Sandboxed Solution property is set to "farm solution," the system's IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project's site URL is recycled.

Sandboxed Solutions Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.

Either Type of Solution With either solution type, Visual Studio also attaches the debugger to the browser to enable client-side script debugging. Visual Studio uses the script debugging engine for this purpose. To enable script debugging, you must change the default browser settings when you are prompted.

Visual Studio attaches the debugger only to the W3WP or SPUCWorkerProcess processes running the current site. Visual Studio also attaches the managed COM Plus and workflow debugging engines.

The Future is Sandboxed

Sandboxed solutions are going to change the way that people think about SharePoint as a development platform. You're going to see an explosion in the number of SharePoint solutions that developers create and deploy.

You'll also see the number of community solutions grow as companies running SharePoint trust that the solutions users are running won't compromise the health of the SharePoint farm.

This article only touches on some of the basics of what you can do in sandboxed solutions from the developer perspective. If you're a farm administrator, the sandbox provides new ways for you to monitor and validate solutions that are running in the farm.

I encourage you to install SharePoint 2010 and read the SDK, and as you build solutions using SharePoint 2010, you should always start with a sandboxed solution. Sandboxed solutions provide a quick and safe development model for creating rich agile business solutions

For an in-depth understanding of SharePoint click on

• SharePoint Lists
• Application Pages
• SharePoint Security
• SharePoint Pages Types