Sitecore Fetch Squad

(Version 1.1 - October 11th, 2008)

In this series, I’m going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part
- Conclusion (Part 9)

Configuration

SharePoint and Sitecore both are platforms built with extensibility in mind to allow organizations to create their own functionality and integrate them into the product. This article will cover one aspect of this process by giving an overview of the way a developer has to configure different settings during the setup of a new project within an existing SharePoint or Sitecore installation. Of course there are several other "configuration tasks" a developer has to perform within SharePoint and Sitecore to develop additional features, for example to configure individual lists (SP) or to change what Rich Text options to show in an Rich Text Editor (SC), but those topics will be covered in a later part of this series.

To configure SharePoint, you usually have to take a couple of steps in different locations all over your server to setup a new project. Usually your journey starts in a special SharePoint site called "Central Administration". It is installed by the SharePoint installer and provides you with a task-oriented web interface to perform several operations: Configuring farm options, creating and configuring new "web applications" and "site collections", changing server parameters and so on. The settings that can be changed by Central Administration are either settings in one of several config files on disc (some of them in the "12 hive", some others in local config file of the selected SharePoint site collection) or in different SharePoint databases (global settings are stored in the administration database, other settings are stored in the content database of the selected SharePoint site collection).
Central Administration is also the main entry point to jump to another configuration portal for configuring so called "Shared Services Providers" (SSPs). SSPs are special SharePoint applications providing features that can be shared across multiple SharePoint web applications and site collections, like global search, user profiles, audiences and so on. Although it is relatively comfortable to reach, it is not always clear whether to look for a particular setting in the Central Administration web or in the configuration web of a particular SSP. As that configuration web is really a separate SharePoint site at its own URL, we have to count it as separate interface (which makes two places to look for settings in total).
When the administrator creates a new web app and a new site collection within a SharePoint content database, and before he (or she) can connect it with an appropriate SSP, SharePoint creates a new IIS web and a folder in the file system. This folder contains the Web.config responsible for configuring a lot of "local" options for the site collection - it is that file which tells the ASP.NET ISAPI module of the IIS Worker Process what to do with a request to this web application. Although you can change some options of that Web.config file using the Central Administration web site, there are other options you may have to configure by hand in the Web.config file. For example, you can change the way authentication works for a particular SharePoint site collection in Central Administration, but really fine tuning it is a task you should perform manually in the Web.config file. Makes three so far.
Now that you have created your SharePoint site collection you can access it at its own URL. The first site in the site collection, called the "root site", has an extended settings page. You can use that settings page to configure various options for the site collection and the site itself. Four.
Every site that you create underneath the root site using one of several site templates has of course its own settings page. It has not as many settings as the root site, because it cannot change site collection options, but some settings you changed at the root site do not influence other sites in the site collection, so you have to change them in the settings section of the particular site. That’s number five.
I already mentioned in the introduction that SharePoints functionality is packaged into deployment units named "features". Features are configured and deployed by the server administrator and can afterwards be activated for the whole farm, the server, the web application, the site collection or an individual site. To configure features and some other advanced options there is currently no web interface and no configuration file available. The only way to do this is using a command line utility named STSADM.EXE. This command line utility can in addition change a lot of advanced configuration options that cannot be changed using one of the web interfaces or configuration files, which makes it number six.

Okay, let’s wrap up this summary. SharePoint is targeted towards mid-sized and large organizations. In those organization there are theoretically several levels of system administration and that is what the SharePoint team tried to consider when they created different kinds of configuration interfaces. From that point of view it makes sense to have settings for the local site in a configuration panel at the local site, so that the site collection administrator (in contrast to the server or even the farm administrator) can configure some settings for his own people. Unfortunately in reality this concept is a little edgy. First of all, in practice there are seldom "administration levels" - usually there is a group of administrators and developers responsible for operations and maintenance of a SharePoint farm (or even a single server) and they perform the majority of work in terms of configuration and customization (We know that from enterprise customers like Siemens and others). Secondly, the concept is not consistently implemented. There are still features that need to be activated manually in config files somewhere over the server or by using some "external" utilities. Thirdly, I have to ask the question: Why not make one single well-designed web interface for all configuration options and use the security subsystem to decide, what option to show to or hide from the current user?

Advantages

1. A lot of features and settings can be configured using web interfaces.
2. SharePoint has an "administration hierarchy" which allows server- or farm-wide administrators to configure other options than site collection or site administrators.
3. SharePoint Central Administration handles all server-wide (or "global") configuration options as well as some individual settings for every SharePoint web application or site collection.

Drawbacks

1. Different places for similar settings make it sometimes difficult to know where to search for a particular option. It is even more confusing for non-administrators who has been granted some permissions to change certain options.
2. Although most features can be configured using one of several web interfaces, it is sometimes necessary to change some configuration files manually or to use the command line utility STSADM.EXE.
3. The intended separation of administrative levels is seldom reality in most companies. Because of that, administrators have to switch between several web interfaces to complete one operations request.

If you are a .NET Web Developer or an administrator who is familiar with IIS 7.0 on Windows Server 2008, configuring Sitecore is pretty straightforward. After you have installed Sitecore, there is basically one file where you can configure each and every aspect of the system: The Web.config file in the root folder of your Sitecore web.
Sitecore’s Web.config is a really big file with literally hundreds of settings in dozens of sections - but it is surprisingly easy to understand. There are several ways to learn about the Web.config: You can take part on one of several Sitecore Trainings (for example at Germany’s Top Sitecore Training Center) or you just take a look at the Sitecore Developer Network (SDN), but you can even just open the file and take a look for yourself. There are of course a lot of things you may not fully understand at first, but these are usually the options you won’t need in the beginning of your Sitecore journey.
As the Web.config has grown to some extend in the past, the developer team at Sitecore has started to move some settings from the main Web.config file to some smaller config files in the configuration directory named /App_Config (as intended by the ASP.NET 2.0 framework). The reason for this is basically to provide a better overview of all configuration options by grouping similar settings into separate files instead of one large file -and- to make it possible to switch between different configurations by just pointing to another file in the /App_Config folder.
Although Sitecore has only one single configuration file with some external extensions in the /App_Config folder, you can configure nearly every part of the system. It is even possible to extend, change, remove and replace core components, as well as to add your own. I will explain more about that in a later part of the series.
Well, that’s basically all you need to know about configuration in Sitecore.

Advantages

1. Configuring Sitecore is a very familiar task for .NET Web Developers and Windows Server 2008 Administrators.
2. There is only one place to look for configuring settings in a Sitecore installation.
3. Each Sitecore installation can be individually configured.
4. It is possible to point to central configuration files from more than one Sitecore installation.
5. It is possible to manage the configuration with SCCM (source code management) tools, and to copy it in a whole or in parts as necessary.

Drawbacks

1. Configuring Sitecore is indeed a developer or administrator task because there is no configuration web interface.
2. To provide a hierarchy of "administration levels" where some administrators can change more settings than others, you have to write custom code that enables changing options from the Sitecore UI -or- you have to split the Web.config into several configuration files and use the security features of the Windows file system to provide different levels of access.

Again, this article demonstrates two very different approaches. SharePoint tries to play nicely with organizational hierarchies and to provide web-based user interfaces to simplify tasks that would otherwise be very complex, because the settings that are changed by various configuration pages are indeed distributed over half a dozen files and databases. Sitecore, on the other hand, is very well integrated with the way ASP.NET handles configuration and provides a familiar interface for developers and administrators in form of XML-based configuration files. It has, however, no web-based administration interface to handle certain those tasks. As this is a series that covers both products from a developer perspective (and not from an administrator or an endusers point of view), Sitecore’s way seems to be more transparent and consistent.

Sitecore: +7 points = 16 points total
SharePoint: +6 points = 11 points total

For the next part of the series covering customization just click here.