Inside Sharepoint Building Your SharePoint Infrastructure Pav Cherny

Download the code for this article: SharePoint2008_05.exe (412KB)

Just as e-mail messaging transformed business communication, Web-based collaboration is changing how people work together and share information. As a good example, take a look at what SharePoint technology offers. With Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server
(MOSS) 2007, you can create team sites, portals, Web content management solutions, document libraries, and search centers, not to mention the 2007 Microsoft® Office system integration, XML-based forms, workflows, mobility support, and so on.
It's not always simple to get started with SharePoint®, however. The terminology can be confusing. The system architecture can be complex, and SharePoint requires you to deal with multiple components, including IIS, the Microsoft .NET Framework, SQL Server®, and possibly other technologies, such as Business Intelligence, InfoPath® Forms Services, Rights Management Services (RMS), Exchange Server, and ForefrontTM Security.
You can quickly lose your way with integrations and customizations given the many approaches you can take to create SharePoint solutions, whether through the built-in user interface or programmatically. Moreover, when a SharePoint application does not work, troubleshooting can be complicated. Oftentimes, you must have the mindset of an application developer to understand the components involved and how they interact. With all these challenges, where do you begin in order to build a robust, scalable, and manageable SharePoint infrastructure?
In this column, I'll show you how to get started first by building a foundation with a high-level architecture discussion and then by diving into the deployment of WSS, including very basic branding customizations. Using the Self-Service Site Management feature of WSS 3.0, you will see how to delegate permissions for creating and managing SharePoint sites to individual users while maintaining centralized administrative control over the SharePoint infrastructure.
By looking first at the SharePoint architecture, it becomes easier to understand the deployment and configuration steps necessary to implement a flexible and scalable infrastructure. So let's take a glance at the dependencies and then go straight into the deployment of WSS 3.0. For detailed deployment instructions, see the companion material for reference. You can find this material at the downloads section of the TechNet Magazine Web site at

SharePoint Architecture
With SharePoint, it is helpful to think about the technology from a system architect's point of view. You don't have to know all the nitty-gritty details, but if you are familiar with the overall dependencies that arise from the SharePoint architecture, you can arrive at solutions faster because you can anticipate what you need to configure and why.
SharePoint is a technology for provisioning Web applications and sites. It is an IIS-based Web site solution, integrating with IIS through ASP.NET and relying on a SQL Server database back end for storing configuration data and content. In short, SharePoint combines three different architectures at its core (IIS, .NET, and SQL Server), as illustrated in Figure 1.
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0 (Click the image for a larger view)

Don't let the diagram intimidate you. The architecture might look overwhelming at first, considering the sheer number of components. But all of these components fit into a logical framework that, when examined systematically, gives insight into the component dependencies.
As depicted, SharePoint relies on IIS and ASP.NET to handle HTTP requests and responses. Standard IIS components, such as the HTTP kernel-mode driver (http.sys) and the Worker Process (w3wp.exe), perform the initial queuing and routing of requests until they arrive at the ASP.NET ISAPI filter (aspnet_isapi.dll). When you install the .NET Framework, the setup routine registers aspnet_isapi.dll in the IIS Metabase (C:\Windows\System32\Inetsrv\metabase.xml), as follows:

Once IIS loads the ASP.NET ISAPI filter, all incoming requests for a Web site can be passed to ASP.NET, which is important because SharePoint must eventually receive these requests through ASP.NET. To accomplish this, SharePoint extends the configuration of the selected Web site by adding a wildcard application map that routes all incoming requests, regardless of the file name extension, to the ASP.NET ISAPI filter.
You can see this in IIS Manager after you install WSS 3.0 using the Basic installation option. The WSS setup routine deactivates the existing default IIS Web site on the server and creates a new default Web site on port 80 that has the ASP.NET wildcard application map defined, as shown in Figure 2.
Figure 2 Wildcard application map for ASP.NET ISAPI filter (Click the image for a larger view)

For ASP.NET to pass requests in turn to SharePoint, SharePoint must also extend the HTTP Request Pipeline through a custom HttpApplication object, which is implemented by means of a class called SPHttpApplication in the Microsoft.SharePoint assembly. SharePoint defines this custom application object in the ASP.NET application file (global.asax), which you can find in the file system in the root folder of SharePoint-extended Web sites. The following code lists the content of such a global.asax file:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET dynamically parses and compiles this file to instantiate the SharePoint application object.
For each received request, ASP.NET triggers a series of events that the Web application can process, such as BeginRequest, AuthenticateRequest, ProcessRequest, and EndRequest. The details of event handling are beyond the scope of deploying and managing SharePoint, yet it is important to know that, in addition to SPHttpApplication specified in global.asax, SharePoint implements custom HTTP handlers and modules defined in the web.config file for the site. For example, SharePoint uses an HTTP module based on the SPRequestModule class, registered as the first HTTP module prior to standard ASP.NET modules. SPRequestModule initializes the SharePoint runtime environment, such as by registering an SPVirtualPathProvider component with ASP.NET. SPRequestModule is for internal SharePoint use, but SharePoint solution developers can modify the web.config file to register additional components, such as custom HTTP handlers and modules. Through both custom and standard HTTP modules, SharePoint takes advantage of ASP.NET while maintaining tight control over all requests to SharePoint applications.
Note that when you create a Web application using the SharePoint 3.0 Central Administration site, WSS adds the ASP.NET wildcard application map to the selected IIS Web site and creates the global.asax and web.config files in the Web site's root folder. Each Web application uses its own set of top-level global.asax and web.config files.
To process requests and return meaningful information to browsers, WSS 3.0 and MOSS 2007 rely on the standard ASP.NET page parser, which compiles the requested ASP.NET pages or processes them in no compilation mode. But the ASP.NET pages that SharePoint passes to the ASP.NET parser are not necessarily located where they appear to exist. For example, you will not be able to find a default.aspx file in the root folder of a SharePoint-extended Web site, such as the SharePoint 3.0 Central Administration site, yet you are opening default.aspx when displaying the home page of that Web site. It is the SPVirtualPathProvider component that virtualizes the environment by loading the page content from the local file system or a SQL Server content database and passing it as a virtual file to the ASP.NET page parser. For the Central Administration site, SharePoint loads the default.aspx file from the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin folder.
The home page, as well as most other SharePoint site pages, is linked to an ASP.NET Master Page (default.master) that implements a common layout for menus and navigation controls. Default.master resides in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global folder and includes named placeholders for further content pages that can also reside on the local file system or in a SQL Server content database. The key point is that when you open a SharePoint site in a Web browser, you are actually viewing information from a collection of content pages that are not necessarily located on the local Web server and that are arranged according to a layout defined in a Master Page.
The general rule is that unmodified pages (or uncustomized pages in SharePoint terminology) exist as page templates on the local file system of every SharePoint server, and customized pages are written to the content database so that all SharePoint servers in a Web farm have access to the same set of pages (see Figure 3). It is assumed that uncustomized pages are identical across all servers and sites in the Web farm. However, if you customize a content page or a Master Page in a SharePoint site, perhaps by using Office SharePoint Designer 2007, SharePoint automatically stores the customized page in the content database.
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application (Click the image for a larger view)

In addition to customized pages and other Web site content, SharePoint also stores configuration data in a SQL Server database. SharePoint keeps the configuration data separate from the content because the configuration data is global in nature while the content is specific to each individual Web application and site collection. Accordingly, a Web farm can