Looking back a decade ago, many companies were just learning about the World Wide Web and discovering their ability to reach customers using HTML-based content. Back then, most companies maintained a single public-facing Web site. That’s all they needed for the purposes of advertising their products and services.
Times certainly have changed since then. Today companies are using Web sites not just to reach customers, but also to provide applications for vendors, employees, and top-level management. It’s not uncommon for a large company to create hundreds or even thousands of Web sites. For example, a large corporation could require a new Web site to be created for each new marketing campaign or each new employee.
In a world without SharePoint products and technologies, it can be expensive and time consuming for a company to keep up with its need to continually create and manage Web sites. For example, let’s walk through what is required to create a Web site designed to track sales leads and customers.
First, the process requires a database administrator to create a new database and the required tables in SQL Server or some other DBMS system to track sales data. Next, a developer must create an ASP.NET Web site with Web pages and the required code to view and edit the sales data. Once the ASP.NET Web site is ready for deployment, a system administrator must then copy the ASP.NET application files to the target Web server and configure Internet Information Services 6.0 (IIS) to create a new virtual directory. If the ASP.NET application is to be deployed in a Web farm environment, the requirements increase because these administrative procedures must be duplicated across each front-end Web server in the farm.
As you can imagine, using this approach to get a new Web site up and running usually takes weeks, or sometimes even months, because of the need to coordinate efforts between a database administrator, a Web developer, and a system administrator. WSS was designed from the ground up to make the creation of Web sites faster and more cost effective. As a WSS developer, you will learn to develop components that others will use to create sites and workspaces.
At its core, WSS is a site provisioning engine. The architecture of WSS was specifically designed to operate in a Web farm environment. The act of provisioning (a fancy word for creating) a site in WSS can be accomplished by any member of the IT department in less than a minute by filling in the required information in a browser-based form and clicking the OK button. There’s no need for a database administrator to create a new database or any new tables. There’s no need for an ASP.NET developer to create a new ASP.NET Web site. There’s no need for a system administrator to copy any files or configure any IIS settings on the front-end Web server.
The WSS site provisioning engine is based on an integrated storage model that involves multiple SQL Server databases to store content and configuration data. When you install WSS, you can elect to use SQL Server 2005 or SQL Server 2000. For simple deployments and development scenarios, you can also use SQL Express, which eliminates the need to purchase a licensed copy of SQL Server.
It is important that you know the difference between Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server 2007 (MOSS). While WSS and MOSS are both pieces of software built by the Microsoft Office team, WSS is included as a part of the Windows Server 2003 operating system while MOSS is a separate product with its own SKU. You should think of WSS as the underlying platform and think of MOSS as a value-added set of components and services that has been built on top of this platform.
WSS does not have its own licensing model. Instead, the use of WSS is controlled through Windows Server 2003 licenses. This makes it very cost effective for companies to roll out applications that have been designed and built on top of the WSS platform. MOSS, on the other hand, has its own licensing model that includes server-side licenses and client access licenses (CALs). The MOSS licensing model is further broken out into a Standard Edition and an Enterprise Edition.
Every deployment of WSS is based on the concept of a farm. Simply stated, a farm is a set of one or more server computers working together to provide WSS functionality to clients. In the simplest deployment scenario, a WSS farm consists of a single server computer that acts as both the front-end Web server and the SQL Server database server. A more complicated WSS farm would consist of several front-end Web server computers and a dedicated database server, as shown in Figure 1-1.
Figure 1-1: A WSS farm provides Web applications.
Each WSS farm runs a single SQL Server database known as the configuration database. The configuration database tracks important farm-wide information. For example, the configuration database tracks which front-end Web servers are associated with the farm as well as which users have been assigned administrative permissions within WSS at the farm level.
WSS is built on top of Internet Information Services 6.0 (IIS). In particular, WSS relies on IIS Web sites to handle incoming HTTP requests. Therefore, you need to understand exactly what an IIS Web site really is. An IIS Web site provides an entry point into the IIS Web server infrastructure. For example, the Default Web Site created automatically by IIS listens for incoming HTTP requests on port 80. You can create additional IIS Web sites to provide additional entry points using different port numbers, different IP addresses, or different host headers.
An important characteristic of an IIS Web site is that its security settings are configured independently of other IIS Web sites. For example, you can configure the Default Web Site as a public-facing site that might involve using Basic Authentication and allowing anonymous access. You can create a second IIS Web site intended for use within the corporate LAN on a different port such as port 1000. Once you have created this intranet Web site in IIS, you can configure it to require integrated Windows authentication and to disallow anonymous access.
An IIS Web site must be specially configured when it is used to serve up WSS sites. We are going to defer discussing the technical details of this configuration until the next chapter. At this point, we want to introduce some important concepts and terminology.
An IIS Web site that has been specially configured to run WSS sites is known as a Web application. Every WSS site runs in the context of a specific Web application. This is important because the hosting Web application for a WSS site provides many important aspects of the WSS environment including the security configuration for user authentication.
The installation of WSS creates and configures a Web application named the WSS 3.0 Central Administration application. The WSS 3.0 Central Administration application provides pages that allow you to perform administrative chores such as converting a standard IIS Web site into a WSS Web application. The WSS Central Administration application also provides the option to create a new IIS Web site and automatically configure it to be a WSS Web application as well, all without having to use any of the IIS administration tools directly.
In the last version of WSS, the product team used the term virtual server to describe an IIS Web site that has been extended with WSS functionality. In the current version of WSS and its supporting documentation, the term virtual server has been replaced with the term Web application mainly to avoid confusion with another Microsoft product of the same name. However, as a WSS developer you must remember that the new term Web application and the old term virtual server are often used interchangeably. For example, the WSS object model provides the SPVirtualServer class to program against Web application objects.
Within a typical WSS farm, there are usually several different Web applications. The WSS Central Administration application is configured during installation as its own separate Web application. You then need one or more other Web applications to create and manage the sites that will be accessible to end users. For example, the Default Web Site can be configured as a WSS Web application to make WSS sites available through the standard HTTP port 80. You might decide to create additional Web applications within the farm such as an intranet Web application on port 1000. WSS configuration data is stored on a farm-wide basis in the configuration database, and the data associated with WSS sites is tracked in another type of database known as a content database. When you create a new Web application with the WSS 3.0 Central Administration application, WSS creates a new content database. If you stick with a simple deployment model, your farm will include one content database for each Web application, as shown in Figure 1-2. In scenarios that require higher levels of security or more granular storage planning, it is possible to use more sophisticated administrative procedures to distribute the sites within a Web application across multiple content databases.
Figure 1-2: A WSS farm provides Web applications that store their data in content databases.
When developing for Windows SharePoint Services, you are not permitted to directly access the configuration database or any of the content databases. For example, you must resist any temptation to write ADO.NET code that reads or writes data from the tables inside these databases. Instead, you should write code against the WSS programming APIs, which results in WSS running system code that accesses the configuration database and/or a content database on your behalf.
Let’s take a step back and ask a fundamental question-what is a WSS site? First, a WSS site is a storage container for content. Site content is primarily stored in the form of lists, document libraries, and child sites. Second, a site is a securable entity whose content is accessible to a configurable set of users. A site can either define its own set of users, or it can inherit the users of its parent site. A site also contains a configurable set of groups and permissions that define the level of accessibility that various users have on the site’s lists and document libraries.
Note that WSS doesn’t actually perform user authentication. Instead, WSS relies on the underlying layers within IIS and the ASP.NET authentication provider infrastructure to accomplish that. However, WSS does take charge when it comes to authorization. WSS provides user interface elements and supporting code that allows privileged users to configure authorization to various elements within their sites. WSS 3.0 also introduces valuable security trimming features so that commands and links to site elements are only shown to users who are authorized to access them.
Third, a site is an application with an extensible, fully customizable user interface. A site administrator can create pages and customize their layout and appearance. A site administrator can also modify a site’s navigation structure using the browser.
Finally, a site is the foundation for using the Microsoft Web Part Page and Web Part technology. Site administrators can customize Web Part Pages by adding and configuring Web Parts. A user can further personalize a Web Part Page by modifying, adding, and/or removing Web Parts. All the customization data and personalization data associated with the Web Parts on a Web Part Page are automatically stored in the content database.
Every WSS site must be provisioned within the scope of an existing Web application. However, a site cannot exist as an independent entity within a Web application. Instead, every WSS site must also be created inside the scope of a site collection. A site collection is a container of WSS sites. Each site collection requires a top-level site. In addition to the required top-level site, a site collection can contain a hierarchy of child sites. Figure 1-3 shows several possible site collections. The first site collection contains just a top-level site. The second site collection contains one level of child sites below the top-level site. The third site collection contains a more complex hierarchy of child sites.
Figure 1-3: Sites exist within site collections. Each site collection must have a top-level site and can contain a hierarchy of child sites.
When a company first begins using WSS or MOSS, one of the first questions that comes up is how to partition sites across site collections. For example, should you create one big site collection with lots of child sites, or should you create many individual site collections? These decisions are usually best made after thinking through all the relevant issues discussed in the next few paragraphs. You must gain an understanding of how partitioning sites into site collections affects the scope of administrative privileges, security boundaries, backup and restore operations, and site design.
You should be asking yourself why the WSS architecture requires this special container to hold its sites. For starters, site collections represent a scope for administrative privileges. If you have been assigned as a site collection administrator, you have full administrative permissions within any existing site and any future site created inside that site collection.
Think about the requirements of site management in a large corporation that’s provisioning thousands of sites per year. The administrative burden posed by all these sites is going to be more than most IT departments can deal with in a timely manner. The concept of the site collection is important because it allows an IT department to hand off the administrative burden to the business divisions that own the sites.
Let’s walk through an example. In many companies using WSS, someone in the IT department is responsible for provisioning site collections upon request from one of the business divisions. During the provisioning process, the IT department assigns one or more users from the business division with administrative permissions at the level of the new site collection. After that point in time, administrative users from the business division can add users as well as create site elements such as lists and document libraries without any assistance from the IT department.
They can also add child sites below the top-level site. This allows them to grow the hierarchy of child sites and configure security for these child sites any way they see fit.
When developers begin to use WSS, there is often confusion surrounding different terminology used between WSS and its version 1.0 predecessor SharePoint Team Services (STS). For example, the WSS term Site Collection is the equivalent of the old STS term Site. The new WSS term Site is the equivalent of the old STS term Web. The new WSS term Top-level Site is the equivalent of the old STS term Root Web.
Though the WSS team has been consistent using the new WSS terminology in the product documentation, there are still many places that use the term Web when you expect Site and that use the term Site when you expect Site Collection.
For example, the names of classes in the WSS object model are based on the old STS terms. As a result, you program against a site collection using an SPSite object, and you program against a site using a SPWeb object. An SPSite object provides a public property named RootWeb that returns an SPWeb object representing the site site. Once you understand this potential point of confusion, getting up to speed on various aspects of WSS becomes less confusing.
A second motivation for site collections is that they provide a scope for membership and security authorization. By design, every site collection is independent of any other site collection with respect to what security groups are defined, which users have been added as members, and which users are authorized to do what.
For example, imagine that the IT department at Litware, Inc. has provisioned one site collection for the Sales department and a second site collection for the Accounting department. Even though there are users within the Accounting department that have administrative permissions within their own site collection, there is nothing they can do that will have any effect upon the security configuration of the Sales site collection. That is because the WSS architecture sees each site collection as an island with respect to security configuration.
A third motivation for site collections is that they provide a convenient scope for backup and restore operations. You can back up a site collection and later restore it with full fidelity. The restoration of a site collection can take place in the same location where backup was made. Alternatively, a site collection can be restored in a different location and even inside a different farm. This technique for backing up a site collection and restoring it in another location provides a strategy for moving WSS sites from a development environment to a staging environment and then to a production environment.
WSS ships with a handy command-line utility named STSADM.EXE. This utility allows you to run interactive commands from the Windows command line and to script batch files that accomplish administrative tasks such as creating, backing up, and restoring site collections. When you run this utility from the command line or from a batch file, you must pass the –o parameter followed by one of the supported operations. Here’s an example of a command line instruction to create a new site collection at a specific URL.
STSADM.EXE –o CreateSite –url http://localhost/sites/Sales -ownerlogin LitwareServer\BrianC -owneremail firstname.lastname@example.org -sitetemplate STS#0
Note that this example has introduced line breaks between the parameters to make things more readable. However, you cannot actually use line breaks between the parameters when running the STSADM utility from the command line or from a batch file.
Keep in mind that the installation of WSS adds the STSADM.EXE utility to a WSS system directory deep within the Windows Program Files directory. If you want to be able to call this utility directly from the command line on your development workstation, you should add the following path to your configured System path.
c:\program files\common files\microsoft shared\web server extensions\12\bin\
When you write a batch file, you should also assume that it might be run on a machine that does not have the proper System path configured. Therefore, you should write batch files that explicitly specify the location of the STSADM.EXE utility.
@SET STSADM="c:\program files\common files\microsoft shared\ web server extensions\12\bin\stsadm" %STSADM% –o CreateSite –url http://localhost/sites/Sales -ownerlogin LitwareServer\BrianC -owneremail email@example.com -sitetemplate STS#0
Once again, the line breaks in the preceding example are only for readability. You will want to remove them when writing an actual batch file.
A final motivation for you to start thinking in terms of site collections is that they provide a scope for many types of site elements and custom queries. For example, the WSS object model provides the means for you to run queries that span all the lists within a site collection. However, this convenient query mechanism does not span across site collections. Therefore, if your application design calls for running queries to aggregate list data from several different sites, you have an added motivation to design these sites as child sites within the same site collection.
Users can also create several types of custom site elements for reuse across all the sites within a site collection. For example, if you create a site column within a top-level site, then this site column is reusable in all the child sites down below. This allows you to define the column characteristics such as formatting, validation, or a choice list one time and then to use this reusable column type across many lists within the site collection. Later, you can update the site column and have this update affect all the lists when the site column is used. Site columns are new to WSS 3.0 and are discussed more fully in Chapter 6, “Lists and Content Types.”
You cannot really appreciate the simplicity of WSS until you have provisioned your first site collection. We are now going to walk you through the steps of doing exactly that. You will play the role of a SharePoint farm administrator. Therefore, you will need the proper permissions.
Under the Windows Start menu, find the Administrative Tools group and then select the SharePoint 3.0 Central Administration menu to launch the WSS Central Administration application. Over the next few steps you will use this application to create a new site.
At the top of the home page of the Central Administration application, there are three tabs: Home, Operations, and Application Management. Select the Application Management tab.
On the Application Management page, locate and click the link titled Create Site Collection in the SharePoint Site Management section. This will take you to a page where you will enter the details that WSS requires whenever you want to create a new site collection.
Take a look at Figure 1-4, which shows the top half of the WSS Create Site Collection page. This figure shows an example of filling in the Title, Description, URL, and Site Collection Administrator fields when provisioning a new site collection.
Figure 1-4: When creating a new site collection, you are required to specify the name, the target URL, and user account information for one or two site collection administrators.
Figure 1-5 shows the bottom half of the WSS Create Site Collection page. You can see that this page allows the user to select a site template to use when creating the top-level site. As you can see, you can select from several different site templates including Team Site and Blank Site. Select the Blank Site template.
Figure 1-5: WSS prompts you to select a site template for the top-level site.
After you have filled in all the required information, you can click the OK button to start the provisioning process. WSS will provision a new site collection containing a top-level site. The top-level site will be created using the site template you selected. When the provisioning process has completed successfully, WSS will display the page shown in Figure 1-6.
Figure 1-6: WSS displays a success message–the new site collection has been created.
Congratulations. You have now created a new WSS site collection which includes a top-level site created from the Blank Site site template. You can now click on the link http://LitwareServer/sites/Sales to navigate to the home page of this top-level site, as shown in Figure 1-7. The site doesn’t contain any lists yet because it was created from the Blank Site site template. However, adding new lists and document libraries is very simple.
Figure 1-7: A new site created from the Blank Site site template