Microsoft’s Content Management Server (CMS) does more than help you guide content workflow as you publish information on your Web site. CMS’s components work together to help you create your Web site’s structure and populate it with content. CMS is a complex product, so covering the whole process in detail isn’t practical. Instead, I’ll focus on the big picture. A quick tour of how you build a site with Content Management Server will help you understand the product better and get a feel for the role it can play in your enterprise.

Configuring the database and server
The first step in developing any Web site is to plan its appearance and content. When the planning is well along, the first step in creating the CMS structure is to configure the database and servers. One of the best ways to understand how CMS works is to run through the configuration process. I’ll cover the basic steps here to give you an understanding of the server side of CMS.

CMS includes a small utility called the Database Configuration Application that you use to set up the content repository. Through this tool you specify the database and its security options and language as well as the initial CMS administrator account. There isn’t much to setting up the database, although it’s a critically important step.

Setting server options takes a bit more time and planning. The Server Configuration Application (SCA) lets you configure a wide range of options that define the site structure and the way the server manages it. The SCA tool is Web based, so you can manage the server remotely if needed. The general settings for the server specify the URL format as either hierarchical or unique ID-based. Hierarchical sites emulate the directory structure used by vanilla IIS and other Web servers. Using the unique ID-based option causes CMS to automatically generate numeric URLs.

You also use the general settings to configure pruning for the site. If pruning is off, Site Builder users can see all containers in the site—even those for which they don’t have rights. Although they can see the containers, the users can’t open them. With pruning turned on, CMS prunes the containers for which users don’t have rights, and users see only the containers for which they have rights. You also use the SCA to configure cleanup options, which determine how CMS removes nonreferenced resources and expired postings.

The SCA also lets you configure the server’s cache settings. CMS caches resources and templates to increase performance. You can specify the folder location of the cache, the maximum disk cache size, and the maximum number of items (nodes) to cache in memory.

The SCA’s Web tab lets you set up the entry points to a site. Each server can have one or more entry points, and each acts as a virtual Web site that points to a CMS server. The Web tab lists each site, its IP address, port, host name, and whether it’s a CMS site. The only option you can configure is the last item: You can specify a site as a CMS site with or without authoring, or set it up as a non-CMS site. All other site configuration (address, host header, etc.) happens through the IIS console.

You use the Access tab in the SCA to configure authentication. CMS supports domain-based authentication as well as Lightweight Directory Assisted Protocol (LDAP) authentication. LDAP authenticates against either the Active Directory or Microsoft Site Server. The Access tab is the place to go to configure how CMS authenticates users for both development and access to the finished site. Depending on your needs, you can configure the server to use only domain authentication, only LDAP authentication, or both. If you enable LDAP, you’ll choose either Active Directory or Site Server and then specify the associated settings. For example, if you go with Active Directory (AD) as the LDAP back end, you’ll specify the AD domain and the AD containers (OUs) that you want CMS to query for accounts.

The SCA’s Security tab controls guest access. Guest access is disabled by default. Enabling guest access allows users to view postings that are configured for guest access and view postings in channels in which the specified guest account has rights. Enable guest access if you want to offer anonymous access to the site, specify the account to use for authenticating access (just as IIS uses the IUSR_machine account for anonymous access), or configure channels as postings as needed to control access.

The cookie settings on the Security tab determine how CMS handles cookies. When a user connects to the site, he or she receives a cookie. Subsequent requests use the cookie for authentication to relieve the authentication load. You use the Security tab to specify the time-to-live for the cookie as well as to enable or disable IP validation. When validation is turned on, CMS checks the client’s IP address with every request to validate that the traffic is coming from the same host. This can add an additional layer of security, but it isn’t practical for many public sites because some clients may have a different IP for every request, depending on the network infrastructure sitting between the clients and the CMS server(s).

Creating and managing site structure with Site Builder
Site Builder, a standalone application included with CMS, is the primary tool used to create and manage a CMS site’s structure. For example, you create the logical structure for the site by creating containers in Site Builder.

One container type, channels, helps define the navigational structure of a Web site and creates a hierarchical structure for site content. For example, you might create individual channels for sales, engineering, support, or product information. Channels store postings that define the publication parameters for the content, specifying its start and expiration date. In effect, the posting defines when the content can be viewed. Channels also control access to specific content according to the rights you apply to the channel. Like individual postings, channels can have start and end dates, and all content in the channel is subject to those availability dates. Although channels can have their own logical structure separate from the folders that you create to contain the content, it’s a good idea to use a similar structure to make it easy for everyone in the development cycle to find content.

Folders are another type of container. They store the pages that make up the site’s content. Template galleries store the templates created by the designers. Finally, resource galleries store the graphics, video, and other resources that are added to templates and pages by the team, either to the templates or by authors to the finished pages.

As you begin to set up a site with Site Builder, one of the first tasks is to create the channels. You then create the folders to store the content, in most cases using a one-to-one relationship between the folders and channels for simplicity. You can, however, add additional folders to suit the team’s needs. Finally, you create the resource and template galleries. When all that is in place, you’re ready to move on to the human side of things and create rights groups for the development team.

Adding structure and security to Web development
CMS targets a handful of core goals to help organize and bring structure to Web development. First and foremost, CMS provides a framework by which your company can organize site development to provide better security and distributed development. CMS supports seven roles:

  • Subscriber
  • Author
  • Editor
  • Moderator
  • Resource manager
  • Template designer
  • Administrator

An administrator uses these roles in CMS to control the actions that specific users and groups can take on the site. Each of these roles determines the rights each user has within the framework of CMS and the permissions users have in the site’s containers. A user can have more than one role. For example, a user might be an author as well as a moderator, or a subscriber as well as an editor.

You use Site Builder to create and configure rights groups. Each rights group is associated with a particular role, and each group can have permissions in one or more containers. When you create a group, you select a role for the group and then add users to it. Next, you specify the containers and permissions for the rights group. So the rights a user has depend not only on the groups to which the user belongs, but also the containers and associated permissions assigned to those groups. This gives a great deal of flexibility in setting up the human resources aspect of your site. All of these roles work together to provide a framework in which a site is developed, maintained, and viewed. To understand that framework and the part each role plays, you need to understand authoring, channels, posting, and the approval process.

Site development begins with the resource managers and template designers. The resource managers create the resources that the template designers will use to create templates. Resources include graphics, video clips, buttons, and much of the other common content for the site.

The template designers create templates that control the appearance of the site’s content. Templates can contain HTML and other static content, resources created by the resource managers, and scripting and dynamically coded content. At this stage, the templates are much like any page developed outside of CMS. The template designers then add placeholders for the content that will be added by content authors and set properties for the placeholders to control the content. For example, the designer might set specific font properties for the placeholder to provide automatic formatting and make the author-added content fit the overall look and feel of the rest of the template. The designer can exercise control over the properties to either allow or deny the author the ability to modify those properties.

The resource managers and template designers work through Site Builder to add the resources and create the templates, although they can also use other applications in conjunction with Site Builder. For example, template designers specify the HTML editor they want to use to create templates, so a developer can use Dreamweaver, FrontPage, or other third-party applications to develop the templates. Site Builder provides a design palette window that gives the developer access to the resources and controls for the site—the developer simply drags components into the HTML editor to create the template. Development tools that don’t support drag-and-drop editing rely on the Clipboard to copy content to the template. Thus the development team need not learn a new environment to implement CMS—they can continue to use their existing suite of tools.

When the templates are in place, authors use a Web browser, such as Internet Explorer or Netscape, to connect to a special virtual directory on the server where they access the templates created by the development team and add content to the placeholders. This Web-based mechanism for authoring means no additional software investment is needed for users to create content, and users don’t need much training to start creating that content. Requiring the authors to work solely with placeholders to add content ensures that they add content only where it’s supposed to be, and only in the right format as defined by the template. For example, the author can’t add graphics to a placeholder that is limited to text, and vice versa.

As part of the authoring/editing process, the author or editor specifies a posting for each page. CMS checks the posting when requests come in for the content and displays it only if the current time falls within the specified range. The posting also defines the channel on which the content is published. Simply creating a posting doesn’t make a page available, however. The posting must be reviewed by an editor and approved by a moderator. Editors have the same content creation abilities as authors, but they can also approve or decline pages, delete pages, and modify postings. Moderators can modify posting schedules and approve or decline postings. Many of these tasks can be done through a browser via the Web Author, or team members can use Site Builder to accomplish them.

All of this structure creates a workflow for creating and publishing Web content. Template designers create the templates that contain the placeholders that authors use to add content. Resource managers create the graphics, video, and other rich content that supports the page creation process. The authors then create and post the content, editors check it, and moderators approve it. Finally, site subscribers can view the content—CMS generates the pages dynamically for subscribers from the data stored in the content repository, based on the start and expiration properties for the individual postings or channels.

You could accomplish the same type of structure and workflow by implementing policies and procedures, and/or by developing your own custom workflow solution. The former is a haphazard approach because people have a tendency to bypass policies and procedures if there is a way around them. The latter isn’t always practical because of the cost involved. While CMS’s cost might seem high to some, it’s a sound investment if you consider the amount of time needed to implement your own solution.

Perhaps most important of all, CMS packages all of these roles and tasks in a secure framework that you can implement almost right out of the box. Because CMS integrates with your existing security infrastructure, you can work within a familiar security context and focus on site development rather than security development. Your company’s developers can continue to use the development tools of their choice to create the templates and resources for the site, so there isn’t a major learning curve.

Even novices can add content to a page with no investment in client software and only minimal training. CMS also integrates with Microsoft Commerce Server and Site Server to support e-commerce applications, personalization, extended analysis and reporting, and many other features. You can use CMS in conjunction with Microsoft SharePoint Portal Server to link the authoring and publishing of Web sites and portals, share content between intranet and Internet sites, and use the features in CMS to simplify content development for portals.

CMS provides the framework for Web site success
If your company’s Web presence is limited and you’re not looking to expand, CMS is overkill. For larger sites and those that require nondevelopers to add content, CMS offers the framework you need to get the job done. It can also be an important tool for imposing a secure and logical workflow on site development, even if all of your content creators are experts.