SharePoint 2010 Architecture

SharePoint Architecture

Given its architecture and the different options available, User Management in SharePoint is a very complex subject, and thus it will be worthwhile for us to discuss and understand the out-of-the-box SharePoint user management, security, and architecture. The following diagram represents the logical SharePoint technologies architecture. SharePoint is now in its fourth major release and comprises the SharePoint Foundation 2010 (formerly Windows SharePoint Services version 3.0) and SharePoint Server 2010 (formerly Microsoft Office SharePoint Server 2007). SharePoint Foundation 2010 is a free add-on to the Windows 2008 server, running on top of SQL Server, Windows 2008 Server, and ASP.NET 3.x. SharePoint Server 2010 is a product that comes with different editions (Standard vs. Enterprise) and options (Excel Services, Content Management, etc.), and runs on top of SharePoint Foundation 2010.

Figure 1 - SharePoint 2010 Architecture

Since SharePoint Server 2010 is built on Windows SharePoint Foundation 2010, they both share a lot of similarity in architecture and foundation.  SharePoint Server 2010 provides more application-level features and services. It also has different and more extensive User Profile management features than SharePoint Foundation 2010. The important point about this architecture is that SharePoint relies on many user management and security principles from the Windows Network Operating system, IIS, and ASP.Net foundation. In the rest of this section we will take a look at:

• SharePoint Foundation 2010 and SharePoint Server 2010 architecture
• SharePoint Security (Authentication and Authorization)
• SharePoint User Profiles in SharePoint Server 2010 and SharePoint Foundation 2010

SharePoint Foundation 2010 Architecture
SharePoint Foundation 2010 contains the core platform services for SharePoint. SharePoint Foundation 2010 is a logical three-tiered architecture that contains a Front-end Web Server, the Search and Index server, and the Database Server.

Figure 2 - SharePoint Foundation 2010 Architecture

SharePoint Foundation 2010 is basically a Web-based ASP.NET application that extends an IIS website that process HTML requests through a set of ASP.NET (.aspx) pages, .Net application programming interfaces (APIs), and XML Web services. It processes and executes the business logic using a combination of .NET and SharePoint object assemblies. The data is stored in the back-end SQL database. SharePoint then presents the information to the user in the standard HTML format compatible with most Web browsers. An IIS website that has been extended with SharePoint Foundation 2010 is called a Web Application (and was called a virtual server in SharePoint 2003), which uses an HttpModule and an HttpHandler to re-route incoming traffic to the SharePoint business logic, thus enabling the SharePoint Web Applications to coexist with other IIS Web applications. Note that this architecture allows SharePoint and other Web applications to share the same user security infrastructures, mainly Windows Server and ASP.NET.
The Search and Index server is an executable (MsSearch.exe) that is installed as Web services in Windows Server. Its primary job is to index the content of the database to help with search operation on lists, documents, and files. Note that SharePoint Server 2010 uses entirely different search architecture than that of SharePoint Foundation 2010.
SharePoint Foundation 2010 uses Microsoft SQL Server to store both the configuration as well as the content in the databases. When SharePoint Foundation 2010 is installed, it creates a configuration database that stores the metadata, physical configurations, and information about every Web application that has been extended, as well as all the servers and their roles in the farm. SharePoint Foundation 2010 also creates an Admin database that stores the content of the Central Administrator toll. And for every extended virtual server, SharePoint Foundation 2010 creates a Content Database that stores the actual content of the sites. Note that SharePoint Foundation 2010 stores the user information in its content database.

Figure 3 – SharePoint Foundation 2010 Farm Architecture

SharePoint Foundation 2010 is also designed to be scalable. In a large or medium farm provision, you can assign multiple cluster databases on the back-end and install a load balancing architecture for the front-end Web server as shown in Figure 3 above. Note that there is only one Configuration database for the entirety of the SharePoint servers in the farm.

SharePoint Server 2010 Architecture
SharePoint Server 2010 runs on top of the SharePoint Foundation 2010 platform, so it shares a similar architecture. SharePoint Server 2010 provides a number of extended applications and feature sets, such as: advanced content management and publishing sites, the ability to search content in external databases, social networking, and more site templates and workspaces. SharePoint Server 2010 itself also provides two different levels: Standard vs. Enterprise options, where additional features, such as business data Web Parts and Microsoft Office Data services are available only at the Enterprise level.

Figure 4 – SharePoint Server 2010 Architecture

Instead of running Search and Index on the same box as SharePoint Foundation 2010, SharePoint Server 2010 uses another application server called SharePoint Service Applications (this is a new architecture similar to the Shared Service Provider in SharePoint 2007). This is a collection of application services that can be configured on one or more servers and shared across many different SharePoint Server 2010 and SharePoint Foundation 2010 sites. The services on these servers include enterprise level applications such as Search, Index, User Profile, My Sites, Business Connectivity Services, Form Services, Excel Services, Job Scheduling, and Usage Reporting.
The new and true application layer architecture of Service Applications provides scalability such that you can load-balance the servers where the applications are hosted. It also provides granularity where each Web application or farm can consume distinct services.
From the user management perspective, SharePoint Server 2010 also has several additional services that differentiate it from SharePoint Foundation 2010: User Profile Services (includes Audience), and Secure Store Services (Single-Sign-On, or SSO). Unlike SharePoint 2007, these services now manage information using their own databases which can be scaled independently.
SharePoint Hierarchy Another important topic that you need to understand in relation to SharePoint user management is the hierarchy, or scope, of the SharePoint architecture. The security and user permissions are applied based on the scope. SharePoint uses the following hierarchy:

Figure 5 – SharePoint Server 2010 Hierarchy

1. Farm: This is the highest scope level, and refers to all SharePoint installations within a server farm. It can contain multiple servers, but each farm has a single configuration database.
2. Web Application: A Web application is the container for all sites on a particular server, on a specified IP address and port. Web applications map to one IIS website, which can consume multiple SharePoint Service Applications. This is what was called Virtual Server in SP 2003. As we said before, this is an IIS site that is extended to work with SharePoint.
3. Site Collection: A site collection is a top level site encompassing all of the sites within a particular Web application. Each site collection has its own content database.
4. Web: Refers to an individual site within a site collection. This the lowest scope level.

 

SharePoint User Authentication

SharePoint security consists of two main parts: Authentication and Authorization. This section will focus on the Authentication process, which determines how a user’s identity is verified before allowing access to SharePoint sites.
SharePoint itself does NOT handle user authentication, but relies on Windows, ASP.NET, and IIS to perform that function. Authentication in SharePoint Foundation 2010 has been redesigned on top of the new authentication provider infrastructure introduced with ASP.NET 2.0. SharePoint is shipped out of the box to work with Windows Authentication, but also allows users the capability to work with forms authentication based on SQL Server. The following identity management systems are supported:

• Windows: All Microsoft Internet Information Services (IIS) and Windows authentication integration options, including Basic, Digest, Certificates, Windows NT LAN Manager (NTLM), and Kerberos. Windows authentication allows IIS to perform the authentication for Windows SharePoint Foundation.
• ASP.NET Forms: A non-Windows identity management system that uses the pluggable Microsoft ASP.NET forms-based authentication system. This mode allows SharePoint to work with a variety of identity management systems, including externally defined groups or roles such as Lightweight Directory Access Protocol (LDAP) and lightweight database (SQL) identity management systems. Forms authentication allows ASP.NET to perform the authentication for SharePoint Foundation, often involving a redirect to a log-on page.
• SAML Token-Based: This is a new token-based authentication method introduced with SharePoint 2010 based on Security Assertion Markup Language (SAML).

Claims-based Authentication
When you create a new Web application in SharePoint 2010, you can select either a “classic-mode” authentication, or a “claims-based” authentication method. Classic mode authentication only supports the Windows authentication, in which all user accounts are treated as Active Directory accounts.
If you select Claims-based authentication, SharePoint will convert all user accounts into claim token identities. Claims are more than just user security information. User accounts can be augmented with additional tokens (via the administration interface or programmatically) with claims such as Age, Sex, and Birth Date.
The following table summarizes the authentication types for each mode:

Authentication Type	Classic-mode authentication	Claims-based authentication
Windows	Yes	Yes
Forms-based	No	Yes
SAML token-based	No	Yes

Claims-based identity management is a big and complex topic. It is a feature, based on Windows Identify Foundation, that establishes the authentication foundation which allows SharePoint to move into cloud platforms such as Azure. As you can see from the table above, there is no practical reason to use classic mode authentication in SharePoint 2010, unless you are migrating from SharePoint 2007 and need some backward compatibility. When using claims-based authentication in SharePoint, you should be aware of the following considerations:

• You can convert a Web application that uses classic-mode into claims-based authentication mode using PowerShell, but you cannot convert it back the other way.
• Beware of third party software and your own custom code that uses Windows identities. Most likely, you will have to update the code to work with a claims-based system.
• Search alerts are currently not supported with claims-based authentication.

Note: In this article we use the terms Authentication Provider or Service (frequently used with Active Directory), User Identity Management (frequently used with a custom system), User Authentication System, and User Membership Provider (which frequently refer to the LDAP provider) to mean the same system depending on the context of the topic. It is the system that keeps the user information and also provides access permission to a SharePoint site.
Multiple authentication methods to access a SharePoint Web Application
You can configure SharePoint Web Applications to be accessed by up to five different authentication methods, thus allowing content from the same websites to be accessed and authenticated by different target users. For example, employees can be authenticated using one of the standard Windows authentication methods, which can be Windows integrated login (NTLM) behind the firewall, and SSL outside of the firewall. Partners or customers can be authenticated against a simple Form Authentication against a SQL database or even their own identity management system.

Figure 6 – SharePoint 2010 Authentication Zones

To configure a SharePoint Web Application to be accessed by two or more different authentication systems, you configure additional zones by extending the Web Application in Central Administration. SharePoint Zones represent different logical paths to gaining access to the same physical application. After extending the Web application, you can configure a separate authentication method for the new zone. The avalable zones are: Default zone, Intranet zone, Internet zone, Custom zone, and Extranet zone.
The major change in SharePoint 2010 is that you are allowed to use different authentication methods in a single zone if you are using claims-based authentication in that Web application. When you use multiple authentication modes in a zone, keep in mind the following considerations:

• You can only implement one instance of form-based authentication in a zone.
• Multiple claims-based authentication providers can be implemented in a zone.
• You cannot implement more than one type of Windows authentication in a zone.
• If you are using classic-mode authentication on a Web app, you are limited to only Windows authentications (including SSL as an option).

 

SharePoint User Management

Since SharePoint uses an external user identity provider, its user operation is very simple.  The fact that SharePoint can be provisioned in many different ways, and the overlap between SharePoint Foundation 2010 and SharePoint Server 2010, tends to confuse most users as to how it actually works. Here are some of the important points to remember:

• Create Users: You do NOT create a user in SharePoint. Users are created in a user directory provider.  You can then add or invite a new user to SharePoint.
• Adding new users:  You can add or invite a new user from any zone, and all authentication methods that are configured, if the membership provider and role manager are registered in the current web.config file. When you add a new user, SharePoint Foundation resolves the user name against the following sources in the following order:
  • The UserInfoList table stored by SharePoint Foundation. User information will be in this list if users have already been added to another site.
  • The authentication provider that is configured for the current zone. For example, if a user is a member of the authentication provider that is configured for the default zone, SharePoint Foundation first checks the associated membership provider.
  • All other authentication providers.
• Deleting users:   User accounts are marked as deleted in the SharePoint Foundation 2010 database. However, the user record is not removed.
• Generally, users who are members of an authentication provider in one zone can manage accounts across all zones as long as they are granted permissions.

Some user authentication systems behave differently within SharePoint Foundation 2010, depending on the authentication provider. The following table highlights several common user account tasks that differ depending on the authentication method that is implemented:

Note also that SharePoint Server 2010 does NOT provide any user management functionality. SharePoint Server 2010 uses SharePoint Foundation 2010 to handle user management. SharePoint Server 2010 provides a User Profile database and has many people confused between User Management vs. User Profile Management, which we will review in next section.

 

User Profile Management

When you are using just SharePoint Foundation 2010, the user management situation is pretty simple as shown in figure 7 below. SharePoint Foundation 2010 has a People and Groups feature that keeps track of user information. The user information is managed by:

Figure 7 – SharePoint Foundation 2010 User Info Dataflow

1. When you add a user to SharePoint Foundation 2010, the system adds a limited number of properties from the user authentication provider, such as Active Directory, to the SharePoint Foundation 2010 Content database’s User Info table. This is a one-time sync between the User Directory Provide to the SharePoint Foundation 2010 database. SharePoint Foundation 2010 will try to map as much information as is in the UserInfo table from the User Directory Services when this happens.
2. You can add extra columns to the user info list, but they must be updated manually and will not be synced with the User Directory services.
3. This user info is stored per-site (remember, this is not per SharePoint Web; it is the top site collection). Clicking on the "My Settings" link takes you to a page where this information can be maintained.

SharePoint Server 2010, on the other hand, is a little confusing. SharePoint Server 2010 has a Profile Database that is stored in the User Profile Service Application database. It provides a much more extensive User Profile feature that allows for scheduled synchronization from one or more User Directory Services, which could be AD/LDAP/BCS/Custom, at regular intervals. You can define properties and set various policies on how data are imported from various user directory services.
As you can see in figure 8, there are more complex conditions in SharePoint Server 2010 when dealing with user management. The user information is propagating between various databases as follows:

Figure 8 – SharePoint Server 2010 User Profile Dataflow

1. Since SharePoint Server 2010 is based on SharePoint Foundation 2010, it also lets SharePoint Foundation 2010 manage its own user information. Meaning that when you add a user to a SharePoint Server 2010 site, such as a Team Site, SharePoint Foundation 2010 still copies a subset of the user information from the User Directory Services (A/D) to the UserInfo table in the content database, as shown in path 1 above.
2. At the same time, when you add a user to SharePoint Server 2010, it also checks to see if that user already has a record in its User Profile database. If a record does not exist, it creates a record in its User Profile table.
3. The User Profile table is stored in the User Profile Services Application database. Remember that this service application is independent of any front-end Web App, thus it can manage the users within a farm that has multiple Web Applications.
4. The User Profile Services Application database is kept up to date with the profile information in the User Directory services via an incremental profile timer import job. This is done in the Central Admin site of the SharePoint Farm. You can specify when the import runs, and what properties can be imported. This is shown in path 2 above.
5. A SharePoint Server 2010 timer job replicates the profile information in the User Profile Services Application database in the individual content database’s UserInfo table. This timer runs every hour and copies properties, such as picture and department. Note that only the profile properties that are marked with the option "replicable" can be replicated. This is shown as path 3 in figure 8.

With a SharePoint Server 2010 installation, you also need to be aware of several differences from a SharePoint Foundation 2010-only installation:

1. The most confusing factor for some people is how SharePoint Server 2010 displays user information. When you view an item’s CreatedBy and ModifiedBy fields, they come from the UserInfo table in the content database. But when you view information in a My Site, that information comes directly from the User Profile Services Application database. If you update a user profile in SharePoint Server 2010, there might be some delay in propagating this information from the User Profile database into the UserInfor table (sometimes the timer job also stops working altogether) and thus creates lots of confusion.
2. Since there is a Services Application, user profile information exists there. If you edit MySettings at a SharePoint site collection, it will actually edit the user profile information in the User Profile Services Application database. This is different from a normal SharePoint Foundation 2010 mode where MySettings would update the information in the UserInfo table.
3. Individual users can manage their information in the UserInfo table via the MySettings link, which is userdisp.aspx?ID={userid}, or useredit.aspx?ID={userid}. Again, note that this info will get overridden every hour by what sits in the User Profile Services Application. There are ways to prevent this overriding.

To make it more confusing, if your SharePoint installation has enabled My Sites, things are more interesting. In SharePoint Server 2010, My Sites are special SharePoint site collections that surface the user profile information and are personalized for each user. My Sites are installed by default, but are not enabled. You will need to set up a My Site site collection under the User Profile Service Application in order to configure its various options. The reason that site personalization is stored in the service application is so that larger organizations that have multiple Web Applications and Portal sites can reference ONE personalization site.
As soon as the My Site feature is activated, any user profiles from an existing installation of SharePoint Foundation 2010 are replaced by the public profiles that are part of My Site. A My Site link is added to the top menu bar for all sites in the site collection, along with the My Links menu. In other words:

1. If My Sites exist, the user has to manage their profile information via their My Sites link. The link at My Settings in this configuration is read-only.
2. If My Sites exist, then administrators can and should manage profile information via the SSP profile DB, or My Settings for the user being edited.

Figure 9 – Different access points to User Profile in SharePoint Server 2010

Lastly, deleting a user profile also has several implications in SharePoint Server 2010. When you delete a User Profile in SharePoint Server 2010, the profile record is moved from the UserProfile table in SSP to the DeleteUsers table, and the deleted user’s My Site will become inaccessible. This way, if the user is re-imported back in at a later date, some information, such as Document Libraries and the new My Site can be reinstated.
User Profile Information from BCS Business Connectivity Service is a feature in SharePoint Server 2010 (formerly called BDC in SharePoint 2007) that allows users to create an interface to external information systems (databases) without writing any code. You can also import external user profile information from a BCS interface into the SharePoint Server 2010 user profile database. A real-world example is to set up a BCS interface to your company payroll or financial system to import employee Social Security Numbers into their user profile in SharePoint Server 2010. This capability also provides some misconceptions as to how BCS plays into the overall SharePoint user management capabilities:

• Although you can import user information from a BCS interface into a SharePoint Server 2010 user profile, similar to how you import data from Active Directory, BCS cannot act as an authentication provider.
• Even though you can import data from a BCS catalog, this can only act as a supplemental import. Meaning that another primary user authentication provider such as Active Directory or LDAP has to be setup as the primary source before you can use BCS. This has implications in cases such as when you use a SQL Form as your primary authentication provider, in which case you will not be able to set up the automatic import from that source. Thus, you will also not be able to import supplemental data from a BCS catalog.
• Even though BSC provides read and write capabilities, user data from BCS can only be scoped to read into SharePoint, and you cannot update user profile data from SharePoint back into the BCS database.

 

SharePoint Authorization

Once a user has been authenticated to be able to access a SharePoint site, the SharePoint authorization process determines which objects in the system a user can access and perform actions on. With the latest release of SharePoint Server 2010, permissions are handled strictly at the SharePoint Foundation 2010 platform level.
In this section, we will describe several important concepts that make up the authorization process in SharePoint:

• Permissions
• Permission Levels
• Securable Objects
• SharePoint Groups

Permissions
Permissions (which were called Rights in SharePoint Foundation 2010 v2) are the rights for a user to perform specific actions such as viewing pages, editing items, and creating sub-sites. SharePoint Foundation 2010 provides 33 pre-defined permissions that you can use to allow users to perform specific actions that are grouped into 3 main categories: List, Site, or Personal. SharePoint permissions are not assigned directly to users or SharePoint groups, but are assigned to one or more permission levels, which are in turn assigned to users and SharePoint groups.

Permission level 
SharePoint Permission Level (which was called site groups in previous version) is a group of permissions that can be granted to users or SharePoint groups so that they can perform specific actions on securable objects such as a site, library, list, folder, item, or document on your site. Permission levels allow you to group permissions and apply them to users and SharePoint groups on the various sites in your SharePoint installation.
When you create a new SharePoint site, there are 5 permission levels which are provided by default:

• Full Control: The least restrictive permission level; allows full control over a site. You cannot modify or remove this permission level.
• Design: Can view, add, update, delete, approve, and customize lists, libraries, and pages on your site, including themes and style sheets.
• Contribute: Can view, add, update, and delete previously created list items and document libraries.
• Read: The most restrictive permission level; allows users or groups to read pages on the site including the resource libraries.
• Limited Access: A permission level that is automatically assigned to a user or group and therefore cannot be directly assigned by the administrator. It is used when you assign the users or groups to a child object without having access to the parent object. You cannot modify or remove this permission level.

Securable Objects Permission
SharePoint provides the ability to manage item level permissions on individual objects (such as lists and libraries) even down to the individual folders, documents, and list items within those lists and libraries. These items, which you can apply permissions to, are called Securable Objects. Each site contains additional securable objects which have a particular position in the site hierarchy, as shown in the following figure.

Figure 10 – SharePoint Securable Objects

Hierarchy and Inheritance
In SharePoint, permissions on any securable objects, such as Web, lists, libraries, folders, and documents, are inherited from their parent object. However, you can break this inheritance for any securable object at a lower level in the hierarchy by creating a unique permission on that securable object. For example, you can create a sub-site (Web) and break the permission inheritance from the parent if you want to limit (or expand) the group of users who can have access permission to the site for security reasons. When you break the inheritance from the parent, the securable object from which you broke the inheritance receives a copy of the parent's permissions. You can then edit those permissions to be unique — meaning that any changes you make to the permissions on that securable object do not affect the parent.

Figure 10 – SharePoint Security Inheritance

In our example, sub-site A/B/C inherits permissions from the top-level Web site. This means that changes made to SharePoint groups and permission levels on the top-level site also affect all of those sub-sites. When you make any change in sub-sites A, B or C, you are actually making changes at the parent site, since SharePoint does not allow you to manage permissions on a sub-site that is inheriting permissions from its parent site.
Sub-site D has unique permissions, which are not inherited from its parent site. Therefore, any changes made to the permission levels and SharePoint groups on Sub-site D do not affect its parent site.

 

SharePoint Users and Groups

You can add any user to SharePoint who has a valid account that has been authenticated as mentioned in the previous section. When a user is added to the system, you can assign direction permissions to a securable object (Web, list or library, etc.) or indirectly through a SharePoint group. Use a SharePoint Group, which is the recommended practice when managing security since it’s easier to manage changes, and apply the same group to different objects across your sites.
A SharePoint Group (which was cross-site group in the previous version) is a logical grouping of users that you can create to manage permissions to the site and to provide an e-mail distribution list for site members. All SharePoint groups are created at the site collection level and are available to all sub-sites in the site collection. You can also create groups that only have permissions on a particular sub-site.
SharePoint groups can contain Windows (Active Directory) security groups, ASP.NET Forms authentication groups (using the roles within the role membership provider), and individual users with a user account on the local server or a Windows domain.

Figure 11 – SharePoint Groups and Users Scope

SharePoint provides three default SharePoint groups with default permissions on the top-level site, each with a Site name prefix:

• Site Owners: have Full Control permissions in the site.
• Site Members: have Contribute permissions.
• Site Readers: have Read permissions

Each of these SharePoint groups is associated with a default permission level, but you can change the permission level for any SharePoint group as needed.

 

SharePoint Audience

A useful way to use user profiles out of the box is for audience targeting. Audience targeting refers to the ability to create an audience based on a specific set of rules and then target content to that specific audience. You can target specific contents such as a SharePoint list, library items, navigation links, and Web Parts to a specific group of people.
You can create an Audience in SharePoint Server 2010 using its Central Administration tool. Audiences are created based on a set of rules. The example below shows how a Sport Fan audience is created by looking for the world “NFL” in the About Me field in their user profile.

Figure 13 - Create an Audience in SharePoint Server 2010 using rules

Once the Audiences rules have been created, you can then target different items by enabling the targeting, and then specifying who can be exposed to the content.

Figure 14 - Target a document library to a specific Audience

 

SharePoint Server 2010 Secure Store Services

SharePoint Server 2010 provides another capability to help with user security management which is called Secure Store Service and is used to provide Single-Sign-On capability. This is a feature that does not affect the internal operation of SharePoint Server 2010, and is disabled by the default installation program. SSS is a database created in SharePoint Server 2010 to keep and manage a set of user names and passwords that can be used to access specific external systems that require access authentication.
An example is if you have a need to crawl and index a back-end office system, such as SAP or Oracle, to retrieve information that is then made available to the SharePoint enterprise search. These systems might need access to log in, and these accounts access information which can be retrieved for those purposes. There are several benefits to using SSS, such as the access information is encrypted and is more secure, and that the account information can be managed by an IT administrator while the Web Parts or code that uses the account does not to know the account, but just how to use it.

 

Summary

Hopefully, this article gave you a good basic understanding of how SharePoint 2010 manages its users. Additional information can be found in various books and online articles, some of which are listed in the reference section below. Given the complexity of managing users in SharePoint, Bamboo Solutions has provided several Web Parts that are very useful in helping you keep the situation under control and create a happy and productive work force. Check out these products on Bamboo Solutions’ website, each of which is available for a 30-day free trial:

• User Account Setup Web Part. Quickly and easily create new users in both Active Directory (or NT) and SharePoint from one location, saving IT Administrators time and effort.
• Password Reset Web Part. Allow SharePoint users to reset their Active Directory or NT password without administrator intervention.
• Password Change Web Part. Alleviate the workload of SharePoint Administrators by allowing users to change their own passwords while automatically adhering to your security policy.
• Password Expiration Web Part. Send your SharePoint users e-mail notifications before their password expires.
• User Profile Sync. Synchronize user profile information between your SharePoint Directory and Active Directory databases.

Service Application Details

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 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 allows 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	Service provide 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 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 provides 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.

The request failed with HTTP status 401: Unauthorized.

There are two methods to work around this issue, use one of the following methods, as appropriate for your situation.

Method 1: Specify host names (Preferred method if NTLM authentication is desired)

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Set the
   DisableStrictNameChecking
   registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
   281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
4. Right-click MSV1_0, point to New, and then click Multi-String Value.
5. Type BackConnectionHostNames, and then press ENTER.
6. Right-click BackConnectionHostNames, and then click Modify.
7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
8. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check (less-recommended method)

The second method is to disable the loopback check by setting the DisableLoopbackCheck registry key.

To set the DisableLoopbackCheck registry key, follow these steps:

1. Set the
   DisableStrictNameChecking
   registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
   281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
4. Right-click Lsa, point to New, and then click DWORD Value.
5. Type DisableLoopbackCheck, and then press ENTER.
6. Right-click DisableLoopbackCheck, and then click Modify.
7. In the Value data box, type 1, and then click OK.
8. Quit Registry Editor, and then restart your computer.

Download SharePoint 2010 build level and version numbers

Very interesting url - 
http://blogs.technet.com/b/sharepointjoe/archive/2011/02/01/sp2010-sharepoint-2010-build-level-and-version-numbers.aspx

SharePoint 2013 Beta is released Today (16-July-12)

Microsoft released SharePoint 2013 today which requires
1. Windows Server 2012
2. SQL Server 2012
3. Visual Studio 2012

This will support to Office 2013.

Installation details -
http://www.gokanozcifci.be/subsite/install-and-configure-sharepoint-13-preview.html?goback=.gde_2252791_member_135256809

Training details -
http://www.criticalpathtraining.com/Pages/default.aspx


TechNet official site-
http://technet.microsoft.com/en-us/sharepoint/fp142366

The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator

One of the major reasons that this List View Threshold (LVT) feature was created is to protect the server from unintentional load that may either bring it down, or at least cause other users higher latency or failures. Changing this limit (default 5000) is quite simple, but I wouldn't recommend it unless you are positive that it will not negatively affect your system. One valid example of when you might want to do this is if you are using your farm to serve heavily cached content, that only gets updated once a day, and do not want the limit to apply for that. Even in that case, I'd recommend that you test this thoroughly before changing it. There's an awesome white paper out there that describes in full details what effects this has on the server, with a lot of pretty graphs and such to depict the performance implications.  Here it is: Designing Large Lists and Maximizing List Performance (http://technet.microsoft.com/en-us/library/ff608068(office.14).aspx). Also here's a link to the help topic that explains the basic limits and what they mean: http://office2010.microsoft.com/en-us/sharepoint-server-help/manage-lists-and-libraries-with-many-items-HA010378155.aspx?redir=0  

If you've got your mind set on changing the LVT or another resource throttling setting, here's how to do it:

1- Login to Central Admin

2- Go to Application Management -> Manage Web Applications

3- Pick the Web application for which you want to change the LVT (If you only have 1 web app plus the central admin one, the one you want to pick is the 1 web app; changing this for the central admin does you no good)

4- In the ribbon above, click General Settings. That will bring down a menu, from which you should pick Resource Throttling

5- Change the LVT (first item in this list) to another value and press OK, but please try to keep it to a reasonable number!

Following those steps will take you to the page where you can also edit a bunch of other settings. Here's a list of them, and a brief description of what they do and best practices or recommendations on how to set them:

- List View Threshold for Auditors and Administrators: This is by7 default a "higher limit". Queries that are run by an auditor or administrator that specifically (programmatically) request to override the LVT will be subject to this limit instead. It's 20,000 by default as opposed to the 5,000 for the LVT. I wouldn't raise this past 20,000 for the same reasons of not raising the LVT.  If you'd like to read more about how to use this, take a look at this post.

 - Object Model Override: If you commonly use custom code on your deployment, and have a need for overriding the LVT to a higher limit, then it may be a good idea to allow the object model override, and give auditor or administrator permissions to the application that will perform the queries. This setting is on by default, but you may disable it if you do not need it. A good example of when you might want to use this is if you've implemented some code that will perform caching of a larger set of results that are accessed often for, say, several minutes.  If you are not planning on caching the content, and are planning on running these queries often, then I wouldn't recommend using this method to get around the LVT as it will adversely affect your server's performance. In short: "tread lightly". If you'd like to read more about how to use this, take a look at this post.

- List View Lookup Threshold: This feature limits the number of joins that a query can perform. By number of joins, I mean the number of Lookup, Person/Group, or Workflow Status fields that are included in the query.  So for example, if you have a view that displays 6 lookup columns, and filters on another 3 distinct lookup columns then by default that view won't work, since the List View Lookup Threshold is 8, and the view is attempting to use 9 lookups.  I would recommend that you do not increase this number beyond 8, because through thorough testing we've observed that there's a serious non-gradual performance degradation that shows up above 8 joins. Not only does the throughput that the server can handle drop significantly at that point, but the query ends up using a disproportionately large amount of the SQL Server's resources, which negatively affects everybody else using that same database.  If you'd like to read more about this, take a look at the "Lookup columns and list views" section of this white paper: http://technet.microsoft.com/en-us/library/ff608068(office.14).aspx 

- Daily Time Window for Large Queries: This feature allows you to set a time every day where users can 'go wild'. Some people call it "happy hour", but I really think it would be a very unhappy hour for the server so I avoid that terminology :-). There are a few things that you should carefully consider before deciding what time to set this to:

1. It should be an off-peak hour, or at least a time during which you expect the least load, so as to affect the least number of individuals. If you pick the time to be in the middle of the work day for the majority of your users, then even those who are not using the large list may be affected negatively. 
2. Try to keep it to a reasonable timeframe such that people can actually use it to fix their lists, rather than bug the farm admin (possibly you!) about it. If, for example, you set it to be "2-3 am", then it's unlikely that the users will be very happy about that. They won't want to wake up at 2 am just to delete this large list they no longer need, so they're more tempted to ask the farm admin to handle it for them.

3. Remember that operations started during the window won't just abort once the window ends.. So if your window lasts till 9am, and at 9 you need the server to be crisp and clear because you get a huge load spike, people who started their list delete at 8:59 may negatively affect that experience.

4. Consider different time zones. This is especially important if your organization or customers (if you're hosting SharePoint for others) are heavily geographically distributed. Setting it to 6pm may seem like a good idea for your own location, but would not be great in say, Sydney, Australia.

- List Unique Permissions Threshold: This is the number of unique permissions allowed per list. If you have a folder that you break inheritance on for permissions, and set some permissions for it (and all the items inside it), then that counts as 1 against your List Unique Permissions Threshold. Unlike the LVT and other settings, this threshold is not triggered by viewing the content or performing some other operation on it, but explicitly when changing permissions. If you can afford to, then I would recommend reducing this number. It defaults to 50,000 and that is a lot of unique permissions! Your list is very likely to encounter problems with permissions before it reaches this number, so preemptively tweaking it to what might work in your environment is a good idea.

Thanks for reading.

SSO between MOSS2007 and Cognos 8.4

Recently I Implemented single sign-on between MOSS 2007 and Cognos 8.4. I followed the guidelines given by IBM team here
http://public.dhe.ibm.com/software/dw/dm/cognos/security/general/integrating_microsoft_sharepoint_portal_2007_or_sharepoint_services_3.0_with_c8v3.pdf

but it is not given detail steps what to do on MOSS server and cognos server in case of both software are installed on different servers.

Below are my findings and would like to share with all of you.

1 Cognos Server

Note: - Here assuming that MOSS2007 and Cognos 8.4 are installed on separate servers and both softwares are working fine.

1.1 Set Virtual Directory Properties

1.1.1 CognosR3

Create virtual directory in IIS (CognosR3 name is just example given in this document). Set its properties as below

· Local path – Webcontent folder

· Read, Log visits and index this resource is checked

· Application Name – cognosR3

· Execute Permissions – None

· Application Pool - DefaultAppPool

Go to ‘Security Directory’ tab and set below properties

· Enable anonymous access - selected

1.1.2 Cgi-Bin

Create virtual directory as cgi-bin under cognosR3 directory in IIS and set its properties as below

· Local path – cgi-bin folder

· Log visits and index this resource is checked.

· Application Name – cgi-bin

· Execute Permissions – Scripts and Executables

· Application Pool - DefaultAppPool

Go to ‘Security Directory’ tab and set below properties

· Enable anonymous access - selected

1.2 Set Environment tab

In Cognos configuration, set the below properties

· Gateway URI – http:// address:port number>/cognosR3/cgi-bin/Cognos.cgi

· Allow namespace override – True

Note – Replace all ‘localhost’ with IP address in all URLs.

1.3 Set Portal Services

In Cognos configuration, open ‘Portal services’ and set below properties

· Web Content URI - http:// address>/cognosR3/cgi-bin/cognosisapi.dll/wsrp/cps4/portlets/nav?b_action=cps.wsdl&wsdl (Optional)

· Trusted Signon Namespace ID – ADS

· Shared secret – Training (Optional)

1.4 Set Namespaces

1.4.1 ADS

In Cognos configuration, create ‘ADS’ as new namespace and set its properties as below

· Type – NTLM

· Namespace ID – ADS

· NTLM domain name –

· Advanced properties – singleSignonOption (Optional)

1.4.2 CPS Trust

In Cognos configuration, create ‘CPSTrust’ as new namespace and set its properties as below

· Type – Custom Java Provider

· Namespace ID – CPSTrust

· Java class name – com.cognos.cps.auth.CPSTrustedSignon

Note: - After setting all properties in Cognos configuration, save and restart it.

2 SharePoint Server

2.1 Copy SharePoint folder

Copy ‘SharePoint’ folder from Cognos server location “:\Program Files\Cognos\c8\cps\SharePoint”

To SharePoint server at below location

C:\Inetpub\wwwroot\WSS\VirtualDirectories\

Note: - Please take the backup of ‘bin’ and ‘wpresources’ folders. During copying the folders, you may get a warning that you are about to overwrite existing files/folders. Select ‘Yes to all’.

2.2 Config files

2.2.1 Wss_cognostrust.config

Copy below file to location “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG”

2.2.2 Web.config

Open web.config. sample below file and make the changes in existing web.config file which are commented in // IBM COGNOS // lines

2.3 Dwp files

Open dwp files from location (“C:\Inetpub\wwwroot\WSS\virtualDirectories\\wpcatalog”) and make changes in tags below

http:// address>/cognosR3/cgi-bin/cognosisapi.dll/wsrp/cps4/portlets/nav?b_action=cps.wsdl&wsdl

Note: -Need to make changes in all .dwp files

2.4 Reset IIS

After making all changes, need to reset IIS and open SharePoint site.

2.5 Add web parts

Open SharePoint page and edit it. Add Cognos Navigator web part. It should display home page from Cognos site as below.