I need to give a presentation on IIS roles in SharePoint Server 2010. Can anyone help me out?

  • 1
    Can you please add more details, like what is the purpose of this presentation? – Robert Lindgren Jan 8 '14 at 8:12
  • Just an overview relating all these things together. – Ramakant Jan 8 '14 at 9:45
  • possible duplicate of IIS, AD and Sql Server roles in sharepoint2010 – Jussi Palo Jan 8 '14 at 10:24
  • Flagged as duplicate of the exact question you posted 2 hours earlier. – Jussi Palo Jan 8 '14 at 10:24
  • Please note that the first one was closed as being too broad, I take this new question as an attempt of creating a less broad question. – Robert Lindgren Jan 8 '14 at 12:48

your asking a vauge question so im going to give you a vauge answer! IIS roles is massive, are you talking about the types of roles or how to setup roles for sharepoint?

for a list of roles that is required for sharepoint:


for actual info on the selected roles rather than what you need:

Web Server (IIS) Role Overview (2008 r2 iis 7.5)


Web Server (IIS) Role (2008 iis 7.0)


Available Web Server (IIS) Role Services in IIS 7.5


search services related to their roles and types of roles


just to define:

Web Server Role (WebFrontEnd) – This Role means that the server is being used to host our web content. It directs the request to an application server.

Application Servers (Application) – These servers have services running on them. They are there to provide the specific service needed such as Excel Calculation Services, Search, User profile and so on.



the highest level of organization in a SharePoint deployment, other than the farm itself, is the web application. A web application in SharePoint terminology is closely related to what is called a website in IIS terminology. An IIS website monitors for incoming requests through a particular port, and it checks for a particular host header or IP address, or both. Every SharePoint Foundation web application is hosted in an IIS website that has the same name as the web application. It can be helpful, especially when you are trying to see the relation between SharePoint and IIS from a high and broad perspective, to think of the SharePoint web application and its corresponding IIS website as a single entity.

Nevertheless, the SharePoint web application and the IIS website are not quite the same thing (and they are represented by different classes in the SharePoint object model: the SPWebApplication class and the SPIisWebSite class). For one thing, although there is usually a one-to-one relation between SharePoint web applications and IIS websites, this is not always the case. It is possible to extend a SharePoint web application to multiple IIS websites, although that is not a common design.

Figure 2 shows the IIS websites and application pools on a SharePoint Foundation front-end web server.

Figure 2. IIS Manager on a SharePoint Foundation front-end web server enter image description here

IIS showing websites and application pools Just as in any application that is built on the ASP.NET-IIS integrated pipeline, when a front-end web server receives a request from a client for a page or other resource in a SharePoint site, the request is passed through a pipeline of units that process the request. This processing includes authenticating the user, verifying the user’s authorization, building the response, sending the response, and finally, logging the request. For more information about the integrated pipeline, see ASP.NET Integration with IIS 7.

The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object (or to a handler factory class that creates HTTP handler objects) depending on the resource requested and the HTTP verb in the request. The assignment is determined by a stack of configuration files named applicationhost.config, machine.config, and web.config.

The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request. They are often used to preprocess requests or postprocess the response. The result of a module’s preprocessing is stored in the HttpContext object. For example, the value of the User property is produced by an authentication module.

The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.

SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file. For detailed information about SharePoint and the integrated pipeline, see Microsoft SharePoint Foundation as an ASP.NET Application.

Figure 3 shows the relations among the classes that handle HTTP requests for a SharePoint front-end web server.

Figure 3. SharePoint customizations of the HTTP request pipelineClasses that handle requests in SharePoint
enter image description here

In addition to its use of the integrated pipeline, SharePoint uses some other features of IIS and technologies from ASP.NET. Among them are the following:

Active pages (aspx files): SharePoint pages are ASP.NET pages. SharePoint controls are referenced in the page markup with a registered "SharePoint" prefix. (For more information about the ASP.NET page parsing and compiling system, see Understanding ASP.NET Dynamic Compilation. Note that the standard page parser of ASP.NET compiles a page the first time it is requested unless the page is explicitly set not to be compiled. However, SharePoint pages that have been customized by a SharePoint website owner are stored in the SharePoint content database and are not compiled when they are accessed. SharePoint uses a custom virtual path provider, an internal class named SPVirtualPathProvider that is derived from VirtualPathProvider, to locate a requested page from either the file system or the content database and load it.

The master page/content page distinction: A SharePoint page is a merger of a master page and a content page. For more information, see ASP.NET Master Pages and Master Pages. (For some SharePoint Server pages, a third foundational page is involved in the merger, a page layout.)

Web Parts: Web Parts actually originated in an early version of SharePoint. The idea was adopted by ASP.NET. In most SharePoint Web Part development situations, we recommend that you use the ASP.NET version, but in some situations the original SharePoint incarnation is a better choice. The SharePoint UI for mobile devices also uses the ASP.NET concept of registered Web Part adapters. For more information about Web Parts in SharePoint, see Building Block: Web Parts and Building Block: Mobile Pages, Controls, and Adapters.

User controls (.ascx files): Many SharePoint web controls and Web Parts are built with ASP.NET user controls.

Web services (.asmx files): Some, but not all, SharePoint web services are implemented as ASP.NET ASMX services. For more information about ASP.NET web services in SharePoint, see ASP.NET Web Services.

Virtual directories: SharePoint maps several virtual directories in each IIS website to physical folders in the SharePoint root, which is the folder %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14. When you as a developer need to provision SharePoint web applications with images, resource files, and other important files, they are deployed to the appropriate physical folder on the front-end web servers. This process is handled automatically by the solution deployment mechanism of SharePoint. For example, user controls are deployed to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ControlTemplates (or a subfolder), which is mapped to the virtual directory _controltemplates.

ASP.NET development experience can be an advantage for a SharePoint developer, but the SharePoint development experience is different from the ASP.NET experience in many ways. Some examples of the differences are as follows:

SharePoint has its own installation and deployment model. For more information, see SharePoint Deployment Models later in this article.

SharePoint makes a distinction, unknown in ASP.NET, between application pages and site pages. For more information, see Pages, Parsing, and Safe Mode later in this article.

SharePoint has its own systems for modifying web.config files. For more information, see Working with Web.config Files.

The ASP.NET worker process model is modified in SharePoint. See Process and Execution Trust Model later in this article.

For more information about how SharePoint development differs from ASP.NET development, see ASP.NET vs. SharePoint: How Development Differs.

Here is ref Link:


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.