Microsoft’s Content Management Server (CMS) lets you define a workflow structure for Web site development with a modular approach to content creation. A design team creates the site’s structure, resource developers create the graphics and other support resources, authors create the content, and editors and moderators approve the content. CMS handles security and other aspects of site creation as well as how the content is served. In this Daily Drill Down, I’ll explain the common steps in planning and deploying CMS.

CMS architecture
Knowing the key components and the parts they play is the first step in planning a CMS deployment. CMS comprises a handful of core components that work together to create the workflow structure for site development and content access for the site. CMS relies on Internet Information Server (IIS) as the Web server, not only for client requests for content but also for authoring and many aspects of site creation. The server-side Web Author component provides the link between the developer and the server. Web Author enables developers and content creators to hook into the site database to add and approve content without requiring a special-purpose application. Users work through a Web browser, such as Internet Explorer or Netscape, to develop the site’s content.

Site Builder is a stand-alone client application that site administrators use to create the site’s security framework. This includes defining development roles, creating containers, and setting permissions to control access and rights. Designers and developers use Site Builder to create the templates that authors will use to populate the site with content. Resource developers use Site Builder to manage the resources that will be used by the template designers and authors.

The CMS application installs on one or more servers and acts as the intermediary between the site’s database and the clients and development teams. CMS serves up pages dynamically as requests come in from clients, building the pages from the data stored in the content repository. CMS also caches content to improve performance.

At the back end of the site’s structure is the content repository, a SQL database and object model that stores all the site’s content, including templates, resource galleries, pages, and their associated content. CMS can store any type of data in the repository: documents, executables, multimedia, and so on.

Two other components help developers and administrators create and deploy the site. Site Deployment Manager lets you export a site and its content as an XML package from one CMS server to another. At the other end, you use Site Deployment Manager to import the package. The application can synchronize the content from the source server to the target server, locking the source data during the transfer to ensure data integrity and consistency between servers.

The other component is Site Stager, which administrators use to export the site to straight HTML for deployment to Web servers that don’t have CMS. Site Stager creates a static HTML snapshot of the site and all its content. Any Web server can host the resulting content, including non-IIS servers. Site Stager lets the site administrator create staging profiles that define what content is exported and when the export takes place. You can schedule exports to take place automatically, or they can be completely manual, depending on the site’s needs. You can use Site Stager to deploy copies of the site to multiple locations for site mirroring or backup. Or, you might use CMS for back-end development and use Site Stager to export the site on a periodic basis to your public Web servers.

Understanding network and back-end requirements
Whether you deploy CMS to support an intranet- or Internet-based site, it needs Active Directory (AD) to provide authentication. In the simplest configuration, all servers can reside in the same AD domain. However, it’s more likely that multiple domains will be involved. In either case, the server(s) on which CMS is installed must have access to the AD and DNS servers that serve the AD forest. The CMS servers are member servers in the domains in which they need to authenticate users, including the development team. Implicit trust relationships provided by the domain forest’s structure enable CMS to authenticate in other domains. You can create explicit trust relationships to allow CMS to authenticate users that reside in domains outside the forest’s implicit trust structure.

Another consideration is the development team’s location on the network in relation to the servers. Whether team members are using Site Builder or adding or managing content through a Web browser connection to Web Author, the traffic moves to and from the server through HTTP.If developers are outside a firewall, you must open port 80 on the firewall to let clients communicate with the CMS servers. If the CMS servers are acting as the final location for the content, or if non-CMS servers reside behind the same firewall and you use Site Stager to deploy to those servers, you naturally have to open port 80 to support client access to the live site. If you opt to use SSL to provide greater security for development and content posting, then you also need to open port 443 on the firewall to support SSL.

A third possibility is that the live servers reside in a perimeter network, with the CMS development servers residing behind the internal firewall. Whether you’re using Site Stager or not, the data transfer between the development servers and the live servers happens via HTTP, either nonsecurely or secured by SSL. For that reason, the internal firewall needs open ports for HTTP and, optionally, SSL. This reliance on HTTP for intrasite traffic simplifies network configuration.

Another issue is the fault tolerance and load-balancing mechanisms. It wouldn’t make sense to invest a large sum in CMS and then not make an equal investment in hardware and software to make sure the servers can handle the load and provide adequate failover capability.

CMS itself performs dynamic caching, placing requested pages in its cache and serving them from the cache to decrease the load on the database and network. It can also perform fragment caching, in effect caching specific, designated portions of a template. To further improve performance, you can implement a load-balanced server farm. CMS doesn’t provide load balancing but instead relies on the Network Load Balancing (NLB) in Windows 2000 Advanced Server and Datacenter Server as well as on third-party load-balancing software. Therefore, client requests can be routed to multiple CMS servers to spread the load across those servers.

CMS also supports clustering to allow multiple CMS servers to manage content in a single common database. This implies the use of the clustering features in Windows 2000 Advanced Server or Datacenter Server, Microsoft Application Center 2000, or a third-party clustering solution.

Planning the deployment
One of the first steps in planning a CMS deployment is to evaluate your existing network infrastructure to see how it fits CMS’s needs. Before planning the physical network, you need to look at the security roles you’ll use and where users are located in your existing directory/security structure. Once you understand where your development and authoring teams’ accounts are located or will be located, you can begin developing the necessary domain structure to accommodate CMS. Or, you might only need to make a few changes to integrate it with your existing structure. For example, you might be able to use your AD structure as is, or you might have to make changes, such as adding explicit trust relationships or additional domains. In any case, the key is to first understand where your development teams’ accounts will be located and develop the necessary directory structure to allow CMS to authenticate those users. Then you create accounts and security groups to support that structure.

When you look at security and directory issues, you also need to consider DNS requirements. As I mentioned previously, CMS servers need to be able to access the local DNS server or servers that handle the domain forest. These DNS servers won’t necessarily be the same DNS servers that provide public DNS resolution for your Web sites—the focus here is on DNS for AD resolution.

Because CMS relies specifically on HTTP for the site development and content creation traffic, there probably isn’t much you need to do to your firewalls to support CMS. It’s likely that you’ll already have port 80 open. If you intend to use SSL, you also need to open port 443.

Next, turn your attention to how you’ll locate your CMS servers in relation to the internal network and the Internet. There are several options, depending on the scope of the site, anticipated server loads, security needs, and so on. For intranet deployment or situations in which you need to keep hardware and software costs down, the simplest approach is to place a single CMS server along with a vanilla IIS server behind your firewall. The development team creates the site on the CMS server, and the administrator pushes it to the IIS server through Site Stager. As site size and requirements grow, you might need to add other CMS servers, perhaps breaking up development and live site hosting onto separate servers.

If your Web server sits in a perimeter network, you have two main options. The first approach is to deploy CMS on the servers in the perimeter network along with a SQL server (and probably a load-balancing solution). Although you could use these CMS servers for both development and production, a more secure approach is to place the development servers behind the internal firewall and place the production servers in the perimeter network. You then use Site Deployment Manager to replicate content from the development servers to the production servers. This also means you’ll have a SQL server on the internal network and another on the perimeter network.

Installing CMS
Installing CMS involves several steps because there are several components to install. One of the first steps is to install SQL Server on the computer that will host the content repository. CMS requires SQL Server 7.0 with SP2 or later, or SQL 2000. You’ll select and populate the database later in the process, after you install CMS.

With the database server in place, you can begin installing CMS. The first task is to create the CMS System Account, which CMS uses to assign rights to security objects. The CMS System Account needs, at a minimum, read privileges to all domains, organizational units (OUs), and user accounts to be authenticated by CMS. You must install CMS on a member server, and the System Account should reside in the same domain as the server itself. In addition, you need to create the initial administrator account you’ll use to log on to CMS for the first time. This account will also be used to create other accounts in Site Builder.

After the accounts are in place, you can install CMS. The installation process itself is relatively simple, requiring little more than accepting the end-user license agreement (EULA) and specifying the target folder. After installation is complete, your next step is to run the Database Configuration Application (DCA), which you use to select and populate the SQL database to serve as the content repository, and specify the initial CMS administrator account. With that done, you can run the Server Configuration Application (SCA) to configure the server. If you’re installing multiple CMS servers that are served by load balancing or clustering applications, you need to run the DCA and SCA on each one. For more information about server configuration, see the Daily Drill Down “Build your Web site with Microsoft Content Management Server.”

With the CMS server or servers in place, you can start installing the additional software, depending on your requirements. This includes installing Site Builder on any workstations where developers and resource managers will access the site and where administrators will manage security roles, create containers, and perform other administrative tasks. You don’t need to install Site Builder on authors’ workstations since they’ll use a Web browser to access the CMS site and add content.

Depending on how you’ll deploy the production site, you might also need to install Site Stager from the CMS CD. Site Stager requires Windows 2000 Professional or Server, Internet Explorer 5.0 or higher, Microsoft Java Virtual Machine, the Task Scheduler service, and Active Directory Services Interface 2.5 or higher. Site Stager can reside on any computer in the CMS server’s domain.

Beyond the installation
When you finish installing CMS and such additional components as Site Stager and Site Builder, you might think that the entire process is finished, but there are still more steps to take. For example, you’ll need to build the site structure and security roles through Site Builder, which I explained in the Daily Drill Down I mentioned above. You’ll also spend some time fine-tuning security groups to build the security framework to support development and authoring. You can further fine-tune security by modifying the directory security settings in IIS for the virtual directories used by CMS.

There also are additional installation steps if you’re integrating CMS with Site Server or Commerce Server. CMS supports Site Server for membership authentication, allowing CMS to authenticate all users except the guest through Lightweight Directory Access Protocol (LDAP) and Site Server’s Membership Server component. Site Server, and therefore the LDAP server, can be installed on the same computer as CMS or on a separate server. Each CMS server needs its own local Membership Server, but those local servers can reference a remote Membership Server for the LDAP queries.

First, you must create a SQL database Site Server to use. When you install Membership Server, you’ll need to perform a custom installation and choose only Active User Object and LDAP services. Configure the server to use the SQL database you created for that purpose, and configure the server for Membership Authentication rather than NT Authentication. When Site Server is installed and configured, run the Server Configuration Application on the CMS server or servers, click the Access tab, and choose Site Server from the LDAP Authentication drop-down list. Configure other options as necessary and close the SCA.

In addition to supporting Site Server, CMS supports Microsoft Commerce Server. This lets you take advantage of CMS for site content development while still enjoying the benefit of Commerce Server’s e-commerce framework. CMS provides this integration through the Content Connector application included on the CMS CD. You’ll install CMS on the Commerce Server computers along with the Content Connector, which adds two additional categories, Content and Targeting, to the existing Commerce Server Business Desk application. These categories add several modules that help developers manage page profiling and content, and create and manage personalized content.

How you install and configure CMS for Commerce Server depends on the number of servers you’re using and their location in the network. For a single-server installation, install CMS and the Content Connector on the same server as Commerce Server. If you’d like to integrate CMS and Commerce Server, check out the Technical Resources link at, which includes a white paper on CMS and Commerce Server integration, as well as white papers and other documentation on CMS and its components.

Look before you leap
Installing CMS isn’t difficult, but it does involve quite a bit of planning. In addition to verifying the minimum requirements for each server, you need to analyze and adjust your network and security structure, possibly open ports on your firewalls, and install SQL Server. The process becomes a little more involved when you want to integrate CMS with Site Server or Commerce Server. With adequate planning and analysis, however, you can accomplish a trouble-free CMS installation in a relatively short period of time.