Managing Content Management Server (CMS) is relatively straightforward. In fact, most of CMS’s actual management is up-front site setup work and periodic maintenance. CMS is designed so that the majority of its day-to-day maintenance will be handled by content owners, such as department managers or Web authors within your organization. Your task will simply be to make sure CMS is set up to support the site that they will create and manage.

Site Builder

The CMS Site Builder, shown in Figure 19.1, is the tool you’ll use to create folders and channels, manage rights groups, and so forth. Site Builder uses a simple graphical user interface, similar in many ways to Outlook. Just click a category—channels, folders, and so forth—on the left-hand icon bar to manage the objects in that category.

Figure 19.1. The Site Builder is a standalone Windows application, not a Microsoft Management Console snap-in.

Note

The Site Builder is the only major .NET Enterprise Servers administrative tool that isn’t implemented in the Microsoft Management Console (MMC). Expect future versions of CMS to use an MMC snap-in rather than a standalone application.

Only site administrators have a use for Site Builder; Web authors have their own user interface. Administrators can also use the Server Configuration Application (SCA), which I’ll cover later in this chapter, to manage server settings and configuration parameters.

Web Author

The Web Author, shown in Figure 19.2, is a Web-based user interface that content authors can use to modify and create content for your site. Authors create new pages by starting with standardized templates, which help provide a consistent look and feel across your site. Special content authors referred to as template designers create and manage these templates. Authors can use graphics and other media from your site’s resource library, enabling designated resource managers to determine the types of content that will be approved for use in your site.

Figure 19.2. Authors can only modify the content areas of pages; they cannot modify the elements—such as graphics—included with the page templates.

Note

Although the current version of CMS has its own internal authoring tools, I would expect some future version to use Microsoft FrontPage instead. Remember that CMS wasn’t initially developed by Microsoft; future versions will likely integrate more fully with the rest of Microsoft’s products.

Administrators can access the Web author interface through Site Builder; Web authors can access the interface directly on any CMS computer that has authoring enabled.

While Site Builder is used to manage the structure and security of your site, the SCA is used to modify the site’s overall configuration. The SCA is an HTML application, which means it’s basically a little Web site that looks and behaves as a 32-bit Windows application. The SCA has five categories: General Configuration, Cache, Web Servers, Security, and Domains. The SCA’s General Configuration window is shown in Figure 19.3.

Figure 19.3. General Configuration provides access to basic parameters affecting an entire site.

In this window, you can determine the URL format used within the site, set the site’s maintenance parameters, and map channel names to host header names. This mapping capability can be useful in especially large sites. Host headers are an IIS feature that enables a single Web server to host multiple Web sites on a single IP address. IIS examines the host header sent by clients, which includes the URL the client is attempting to access. IIS can then direct the client to the correct virtual Web server (or Web site). CMS’s mapping capability allows channels to become individual virtual Web servers, rather than subsections of a single Web site. This might be useful if your company has multiple subdivisions: You can create a separate Web site and URL for each subdivision, while maintaining them internally as channels to support a unified publishing process.

The URL format—hierarchical or not—plays an important role in how users access your site. Suppose a user attempts to browse to a posting named Events, located within a channel named News, which is a child of a channel named CompanyInformation. The resulting URL would be something like http://www.company.com/CompanyInformation/News/Events.htm. That’s a hierarchical URL, because the URL itself reflects the hierarchy of your site. In a multilingual site, CMS will attempt to create URLs using the localized names of your channels. In some languages, this may require the use of non-ASCII characters, which mean the URL might not work correctly. If you’re building a multilingual site that uses non-ASCII characters, disable hierarchical URLs. CMS will use a flat URL namespace and eliminate any potential problems.

Figure 19.4 shows the SCA’s cache configuration window. In this window, you can configure your site’s cache folder and determine the size of the cache. The cache size can be configured on a server-wide basis (referred to as the global configuration), or on a per-server basis (the local override value). The cache enables CMS to temporarily store dynamically produced Web pages so that it doesn’t have to dynamically produce them for each and every user. The cache—which should be at least 100MB in size—therefore helps improve CMS’s performance and enables it to support more users. Global configuration items are stored in the SQL Server database for the site, where they are accessible to all site servers; local configuration items are stored locally on each server.

Figure 19.4. The larger your Web site, the larger your cache should be.

Figure 19.5 shows the SCA’s Web Server configuration window. In this window, you can determine which IIS virtual Web servers, or Web sites, will be used by CMS, and which will have authoring enabled. As shown, only the Default Web Site is managed by CMS, and it has authoring enabled. The other Web sites on the server are not used by CMS.

Figure 19.5. The IIS Administration Web Site cannot be used by CMS.

Figure 19.6 shows the SCA Access window, which is used to configure the domains that CMS imports user accounts from. CMS rights groups can only contain users from these domains, so make sure you specify all of the domains that contain users who will be Web authors, moderators, or editors within your site. As shown in this example, you can also include local user accounts on the CMS server by including the server name as a domain.

Figure 19.6. CMS supports the use of LDAP authentication to access Active Directory.

SCA’s last configuration window, Security, is shown in Figure 19.7. In this window, you can configure the user account and password used by CMS’s service, determine whether guests are permitted to access the site (and determine which user account will be used to represent guests), and configure the Web browser cookie settings for your users.

Figure 19.7. Disabling guest access means that only domain users will be able to use your site.

If you’re using CMS to host your sites on the Internet, you’ll need to enable guest access in order for public users to access your site. You’ll simply choose a Guest login account, and assign that account as a subscriber to the appropriate rights groups within your site. All unauthenticated users will be mapped to the Guest login account and receive the access granted through their rights groups.

You’ll normally only launch the SCA to initially configure a new server; once configured, you probably won’t need to change the server’s configuration very often. Running the SCA should be one of the first things you do when you install CMS. In fact, CMS Setup will offer to launch the SCA for you when Setup completes, reminding you to configure your new server.

With the SCA out of the way and your servers properly configured, you can begin creating your site’s overall structure.

There are five tasks that need to be completed before Web authors can begin creating pages:

Of these tasks, the first three are handled by an administrator. I like to start by creating the folder and channel structure within Site Builder. Generally, the two structures will be similar. Remember that folders are used to organize authoring, while channels are used to organize actual Web site navigation. Keeping the two hierarchies the same simplifies CMS management and Web content creation and publishing.

Once your folders and channels are created, start creating rights groups. As shown in Figure 19.8, you can select users from any domain that CMS is importing them from, and add them to the rights group. You can click the Synchronize button to force CMS to import any new user accounts from the domain; this import process normally occurs automatically about every 10–15 minutes.

Figure 19.8. The rights group will become an author, editor, or moderator, so add all of the users who should have those rights within a folder or channel.

Figure 19.9 shows how you can assign the rights group to particular channels. In this example, the channels with a checkmark are accessible by the rights groups, while channels with an “X” are not.

Figure 19.9. Click on the X or checkmark icon to toggle the icon between the two states.

Once you’ve set up your rights groups, you can assign them to folders. When you create a rights group, you designate it as an author, editor, or moderator; as shown in Figure 19.10, you can select the appropriate rights groups to assign to each folder in your site.

Figure 19.10. A single folder will have multiple rights groups assigned for the three roles within CMS.

In this example, I’ve assigned the Sales Authors rights group as an author of the Product Development folder. Your organization might use a single group of authors for all folders; if so, the rights group might simply be named “Authors,” and you would assign the group as an author to all of the folders in your site.

While you’re working with your folder properties, you can select the channel that each folder will publish to. Figure 19.11 shows the selection dialog. You’ll make CMS management easier if every folder has a corresponding channel to which it publishes content.

Figure 19.11. There’s nothing stopping you from publishing the Marketing folder to the Sales channel, but it’ll be very confusing for your users!

Once your folders are configured, you can configure the properties for the corresponding channels. Figure 19.12 shows a channel’s configuration dialog box with the Publishing tab selected. This tab enables you to hide the channel, set the channel’s lifetime (which determines when the channel is available to subscribers), and set the channel’s template and cover page.

Figure 19.12. You can use the channel’s lifetime to automatically reveal and hide channels that have a limited-use purpose, such as a special events channel.

Figure 19.13 shows the channel’s Web Authoring configuration, which enables you to decide whether or not authors can post content to the channel. If they can, then you’ll need to specify the channel’s corresponding folder, template gallery, and resource gallery.

Figure 19.13. Multiple channels can share a template and resource gallery, but not a folder.

The Sorting tab, shown in Figure 19.14, enables you to determine the precedence of postings within the channel. For more information on this feature and its impact on your site, consult the CMS documentation. In general you shouldn’t have to modify this configuration.

Figure 19.14. Channels can contain multiple posting types.

Finally, as shown in Figure 19.15, you’ll configure the channel’s rights. Clicking the Modify button displays a window similar to that shown in Figure 19.10, while the main Rights tab shows a summary of the rights groups assigned to the channel.

Figure 19.15. You can assign as many rights groups as necessary to a channel.

When you’re dealing with rights groups, channels, and folders, keep the following tips in mind:

Figure 19.16. CMS won’t allow you to proceed until you let it synchronize (or coordinate) the rights on the folders and channels.

Once all of your channels, folders, and other objects are in place, your authors, editors, and moderators can go to work. Editors and moderators will need to use Site Builder (or Web Author) to approve content for publishing and posting; as shown in Figure 19.17, Site Builder displays changed content by placing a “Yes” in the Is Replacement column of the folder. You can right-click any content item to approve it, or you can revert to the previous version of the content.

Figure 19.17. Moderators perform a similar task with postings by using the Channels portion of Site Builder.

CMS optimization basically comes from scalability, or in other words, adding more CMS computers to your Web site. A single SQL Server computer can be expected to support four or five CMS computers, and a single CMS computer, properly configured, can be expected to support about 65 page views per second.

Other than adding more CMS computers, your only real optimization option is to fine-tune CMS’s cache settings, which were shown in Figure 19.4. The cache enables CMS to serve a greater quantity of pre-generated dynamic pages, which can be served much more quickly—thousands of pages per second—than pages that CMS must generate on the fly.

Of course, optimizing SQL Server to provide CMS with the fastest possible database access can help your site support more users, too.

Since everything of value in CMS is stored in SQL Server, disaster recovery for a CMS-based Web site is primarily a matter of SQL Server disaster recovery. You’ll also need to make sure that your domain is well-protected against failure, since CMS relies on the domain to authenticate users.

To keep CMS from occupying more administrative time than necessary, follow these basic tips for making CMS more efficient:

CMS administration is primarily up-front, involving site creation, access control, and so forth. Day-to-day operations will mostly be handled by designated authors, editors, and moderators. You will need to optimize both CMS and SQL Server to keep your site running at peak efficiency. CMS’s dependence on SQL Server is so total, in fact, that CMS doesn’t really have any disaster recovery concerns of its own. Simply protecting SQL Server (and the domain that CMS belongs to) is sufficient to ensure the safety of your site’s content.