Deploy Microsoft Content Management Server 2002
Learn the ins and outs of deploying your MCMS application for intranets or the Internet.
by Bill English, Olga Londer, Shawn Shell, Todd Bleeker, and Stephen Cawood

Posted December 18, 2003

About This Article
This article is adapted from Microsoft Content Management Server 2002: A Complete Guide by Bill English, Olga Londer, Shawn Shell, Todd Bleeker, and Stephen Cawood. Copyright © 2004 by Addison-Wesley. Reproduced by permission. All rights reserved.

It is a common practice in many firms to create separate environments within their infrastructure. Essentially, an environment is the collection of hardware, software, and staff to support your site at a given stage in the development cycle. The reason for this separation is to allow each environment to satisfy the needs of a specific audience or application without affecting any other. For example, a development environment would contain the hardware, software, and staff to support your developers and the creation or modification of functionality within your Microsoft Content Management Server (MCMS)-based Web application. This development environment typically has early versions of code and/or components that are likely to be unstable or ill suited for a public or semipublic application. The hardware and software components in this environment are constantly changing, potentially breaking some features or functions while fixing others, so the development environment is the domain of the development staff only.

We'll begin with a look at the various environments you might consider implementing as part of a typical deployment. One deployment could be made up of one or more environments discussed here.

Environment Guidelines
Overall, your particular deployment strategy will be unique to your organization. In addition, a deployment might be different based on the audience that will be using the application. However, there are some basic guidelines that you can use in various forms to create an overall deployment strategy for your CMS application.

To begin, let's explore some of the questions you should ask as you plan your CMS deployment. Who is the primary audience of your application? Are the users of your application internal to your company (and your network), are they external, or are they a mix? Public-facing applications have additional security requirements and should be more "locked down" than applications that are completely internal. An example would be a public Internet site verses an intranet application.

How many content contributors will you have? How many content consumers will you have? These questions will help you determine the number of CMS servers you'll need for a given environment.

Will you be hosting the CMS server internally or externally? If you're hosting CMS servers externally, you might want to limit the number of "moving" parts at the hosting provider. In other words, you probably only want to have one environment at the hosting provider and house all other environments internally. Also, most hosting services don't provide support for application servers such as CMS, so it's a good idea to make sure that any environment that lives at a hosting provider be as clean as possible.

Is the development of your CMS application done internally or externally? If it is primarily done externally, it might not be necessary to create a formal development environment; the group or firm performing the development will handle this environment. However, you might still want to have a quality assurance (QA) environment to allow your staff to test the application properly in your environment.

Is there a need to test content? Some organizations need to provide an extra review of the site, even beyond the typical workflow that CMS provides. If you have this requirement, you might need a content QA environment (sometimes called a staging environment). This environment will allow various members of your organization to review the complete Web site before it's published to the production environment.

How many developers are working on your site? The more developers you have, the more you need a technical QA environment where all the developers can contribute their code for testing. A technical QA environment will allow a group, other than the developers, to test all the components that the various developers have written. This environment could also be called "system test" because you're doing a complete test of the application, as opposed to the component-level testing that a developer will perform typically. Another advantage of this environment is that it allows developers on the team to get the latest copies of code they're not writing.

How often does your content change? If your content changes frequently, you might want to create a content authoring environment. This environment will contain one or more CMS servers that are set up primarily to accept content from contributors.

Creating Environments
The most basic environment is a development environment. The development environment, as discussed earlier, is where your developers will work primarily. This environment is made up of a central server and all the development workstations your developers will be using. The central development server will run a copy of CMS and SQL. You can load both tools on one physical box or they can be separate; the choice is up to you. This central CMS server will hold the "master" copy of all the templates and controls that make up your application. It's not possible to perform "remote" development on CMS (in other words, you can't remotely connect to a CMS server using Visual Studio .NET), so each developer workstation will have its own copy of CMS, along with Visual Studio .NET. Each of the developer workstations will then connect to the central SQL server so that they can share template gallery items (TGIs) and postings. In this environment, developers can develop their components of the application on their individual workstations. Once they're done, they either copy the component to the central server or simply check it in to the source control utility of their choice. The development environment likely will be configured to use Windows authentication and have guest access disabled (see Figure 1).

Depending on the complexity of your application, you might also want a QA environment. This environment will consist of one or more servers that can simulate your production environment. The QA environment might or might not have production content, but it will certainly have all the "final" templates, user controls, or other components. Ideally, you will test all aspects of functionality and performance to determine if the application performs acceptably. If the configuration for this environment is exactly the same as your production environment, you should be able to predict accurately the application's behavior once it moves to your production environment. You probably will configure CMS in this environment for Forms authentication to allow your QA staff to test the different user roles (see Figure 2). Keep in mind that when we cover the production environment, you should be able to see similarities in the logical configuration without some of the physical network security.

Authoring in CMS places a certain load on a CMS server and provides the ability to create content. As a result, Microsoft recommends that you have one or more CMS servers dedicated to content contribution. This environment not only reduces the load on the production environment, but also unnecessary entry points to CMS. This environment will consist of one or more authoring servers running a server edition of Windows in addition to one or more servers running SQL Server. You probably will configure CMS in this environment for Windows authentication without guest access enabled. Depending on the number of content contributors you have, the authoring environment might or might not be load balanced (see Figure 3).

Some firms want to perform additional quality tests to ensure proper application function. The code should have been tested already in earlier QA phases, but a staging environment allows content-specific testing. This environment will allow you to perform additional quality tests on the site as it might look in production. Unlike the earlier QA environment, which might not contain production content, this environment will have both production content and a copy of all of the production code. As long as you don't need to perform additional load or performance testing, it's unlikely that you'll need more than one server running both SQL and CMS. There might be some confusion between this environment and the QA environment discussed above because they appear to accomplish the same thing. However, unlike the QA environment, the staging environment is primarily for taking one last look at the contributed content and pushing the content, templates, and code to production; think of the staging environment as the last stop before your application goes live. The staging environment, like the QA environment, likely will use Forms authentication to allow the various user roles that might be visiting your site to view the content. Note that the staging environment is set up similarly to the QA environment.

The last environment you need to create is the production environment. This environment will serve your site to all content consumers. You should have at least one database server and one CMS server. We always recommend load balancing two CMS servers for any site, regardless of traffic; load balancing makes maintaining your Web servers easier by allowing you to take one down to install patches or software updates. In addition, load balancing provides application integrity by reducing downtime caused by hardware failure. You might also want to consider database server clustering.

Depending on the kind of production environment you need, you could have one of several different authentication methodologies, such as Passport, Windows, or Forms; in an intranet environment, it's likely you'll use either Forms or Windows. For an Internet deployment, you'll probably use Passport or Forms, and you'll also enable guest (anonymous) access, whereas in an intranet environment, guest access will probably not be enabled.

Now you can begin to put together the various environments for specific deployment scenarios. Each of these scenarios will describe a generic application focus, such as an intranet or an Internet deployment. These deployment scenarios are meant to provide some guidance when you are deploying your application. However, you should always consult network and application architects to evaluate your specific needs.

Intranet Deployment
An intranet deployment describes how you might deploy a CMS-based application to a set of internal users. This application will also receive content from contributors inside your organization. One of the reasons you probably picked CMS for your intranet is that there are frequent content updates and/or you wanted to distribute the management of the intranet to the various groups that might own each of the microsites. Of the environments we discussed earlier, an intranet deployment typically includes a development environment, an authoring environment, and a production environment.

From the development environment to the authoring environment, you use Site Deployment Manager (SDM) manually to move TGIs and channels as well as galleries. In addition, you would move the template files and other file-based assets, such as images and user controls. Microsoft recommends using Application Center Server to move file-based assets. However, you can simply copy the files using xcopy.

Once you have copied the application-related components to the authoring environment, content contributors can create content. As they contribute content, it is simultaneously deployed back to the development environment as well as to the production environment. Pushing content back to the development environment (a manual operation) allows the developers to work with production content, simulating how the site looks in production. Be careful when you move content from authoring to development, because SDM will also try to move the templates associated with each deployed posting. The best way to handle this situation is to create an SDO file with your TGIs and galleries. Then, import the new postings from the authoring environment and reimport the original TGIs you exported in the first step.

After creation of all of the content, the production content and templates deploy to the production environment. This is the last step in the process, where you're actually publishing both the application code and the content produced in earlier stages. The configuration of the production environment, unlike the other environments, will only have one read-only entry point. Unlike moving templates or postings between development and authoring, moving content to production will likely be automated by an incremental script.

An Internet deployment of CMS involves a few more steps than the intranet scenario. The Internet deployment and the intranet deployment share the development and authoring environments. However, given the public visibility of an Internet site, we recommend adding some additional environments to test your application properly.

You should notice immediately the additional environments added to the Internet deployment, the first of which is a QA environment. By adding a specific QA environment we're not suggesting that testing is less important in an intranet deployment. In fact, we're simply suggesting that Internet applications tend to be more complex, and because Internet sites are public, more testing might be necessary. This QA environment will allow a separate group of individuals to perform load and performance testing as well as full functionality testing. An intranet application has a predictable consumption audience with a presumably standard set of software (such as a browser version or utilities), but an Internet site has a somewhat unpredictable traffic level, with users who have varied browser versions, desktop operating systems, and utility software.

The Internet deployment has a staging environment in addition to the QA environment. The staging environment will provide an additional testing environment, which includes not only finalized code, but all production content. Just as the earlier QA environment provided the opportunity for rigorous testing of the application, the staging environment provides the same kind of environment for reviewing the content. You might be thinking that the QA environment theoretically takes care of content testing. However, traditional QA environments primarily focus on application testing, not content testing. As a result, a real quality process doesn't occur. For example, the staging environment will serve departments like marketing or legal, which might need to see "final" content in the context of the site before its deployment to the production environment.

In addition to providing a final QA environment for content, the staging environment is the launch pad for deployment to the production environment. Depending on the size of your site and the amount of content changes, having a staging environment provides an environment virtually dedicated to deploying content to the production environment. The staging environment might run CMS and Application Center Server for deploying file assets. In this way, you can be certain that all necessary objects for deploying to production are in one place. Further, any load that deployment places on equipment doesn't affect environments that are heavily active, like authoring.

CMS and Firewalls
A discussion of the firewall issues as they relate to CMS could entail an entire book because firewall security is a highly complex and exhaustive area of study. So this discussion is not exhaustive; rather, it points out some of the more basic considerations when it comes to deploying CMS on the Internet as it relates to your firewall structures.

For any external Web site, one of the biggest issues is the network topology required to support the CMS infrastructure. In this example, there are two firewalls used to separate the production environment from the Internet and from the internal network.

The first firewall separates the production CMS servers from the Internet-originating traffic. It must have port 80 open for HTTP traffic, and if your site uses HTTPS, it must also have port 443 open for SSL. The production servers are clustered for scalability, with a network load balancer (NLB) that directs traffic to the servers to provide high availability and performance. Only the NLB IP address is exposed to the Internet. The advantage of NLB is that the clustered servers can all be accessed by a URL from the Internet.

Microsoft Application Center can be used for deployment of CMS assets, such as ASP.NET files and registry settings, from the staging environment to the production environment. If you are using Application Center, you need to configure every production server in the cluster to use specified restricted TCP ports for DCOM. By default, DCOM can use any TCP port from 1024 to 65535. This is not a firewall-friendly configuration, because leaving such a wide range of ports open presents a big security hole. To this end, we need to restrict the number of DCOM ports.

We recommend that you use ports in the range above 5000 and allocate 15 to 20 ports. To set up DCOM port restrictions, using regedit32.exe to create the registry key HKEY_LOCAL_MACHINE\ Software\Microsoft\Rpc\Internet, add a value named Ports with the data type REG_MULTI_SZ, and specify the data value as 5000 to 5020.

The second firewall separates the production environment from the internal network, which hosts the CMS development environment as well as the content authoring and staging environments. You deploy the site to the CMS production cluster from the staging environment. CMS Site Deployment uses port 80. If you plan to use the Server Configuration Application on a production server, you will need to open port 443.

If you use Application Center for deployment, there are additional ports you need to open. Application Center requires that TCP ports 4243 and 4244 are open for data transfer, and TCP port 4242 is open for remote administration. You also need to open the DCOM ports that you configured on the production servers—for example, 6000 to 5020. In a DCOM environment, clients discover the port associated with a particular object by connecting to and using the services provided by DCOM's Service Control Manager (SCM). The SCM always operates at a fixed network port on every computer; this is always port 135 for both TCP and UDP.

Depending on your company security policy, you might consider changing the network topology discussed here. For example, you might use an additional firewall in the production environment to separate CMS production servers and the SQL server hosting the CMS Content Repository (see Figure 4). For simplicity, only one SQL server is shown; however, for resilience, high availability, and scalability, SQL servers may be clustered.

The second firewall in Figure 4 requires additional ports to be open for communication with the SQL server. By default, the SQL server uses TCP port 1433 to receive data; you can change this if necessary. The firewall should be configured to forward the production server IP address through the default port 1433 or through another TCP port configured for the SQL server to receive data. The SQL server uses UDP port 1434 to establish communications links from applications; therefore, you also should configure the firewall to forward requests for UDP port 1434 on the same IP address.

Once again, if you are using Application Center for deployment to the CMS production cluster using TCP, ports 4243 and 4244 need to be open for data transfer, port 4242 for remote administration, ports 5000 to 5020 for DCOM, and port 135 (both TCP and UDP) for SCM. If you wish to provide a full user-acceptance testing environment for your CMS site, you need to replicate the firewall configuration using a separate perimeter network.

You must determine how many firewalls to use in your environment based on the anticipated security risks and your company security policy.

Deployment Guidelines
Regardless of the deployment scenario you're working with, there are some basic guidelines for deploying a CMS site.

Create deployment profiles. Creating deployment profiles in SDM will eliminate the manual selection of objects to deploy and will reduce human error. You'll probably create several profiles for the manual deployments between environments.

Use scripted incremental deployments for moving content to production. As you add content to the final environment, it can move automatically to production on a scheduled basis.

Make sure to move file-based assets to an environment before using SDM to move CMS-based assets. Moving CMS-based assets to an environment before the file-based assets can cause errors. For example, if a TGI is moved to an environment before the template file, all postings dependent on that TGI will break.

Use a SQL backup and restore to move a CMS database initially. Especially for large repositories, using a SQL backup and restore will be faster than using Site Deployment Manager. However, if you're moving a database between environments that use different Active Directory structures, you'll have to reconfigure the destination CMS environment manually so that it uses the appropriate tree and user IDs.

All environments up to production should use a common Active Directory structure. In an intranet deployment, all environments, including production, will likely use the same Active Directory structure. In an Internet deployment, however, the production environment probably will use a separate Active Directory structure. Keep this in mind when you're moving TGIs, channels, or templates between environments. For most environments, you'll need to move groups and users along with the content. However, when moving content from production, you might or might not need to move groups and users.

There are various opinions on whether the authoring environment and the production environment can be the same. Microsoft generally recommends that the authoring environment and the production environment be separate for performance and security reasons. It is possible technically to combine both logical environments into one physical environment, but we wouldn't recommend this configuration in a public site, though it might be appropriate for an intranet application. The primary reason beyond security is performance—as you contribute content, you defeat your cache, thereby affecting performance (to what extent depends on your application). You should consult network and software architects to review your specific requirements to determine the optimal configuration for your organization.

About the Authors
Bill English is the author or coauthor of eight books and is a Microsoft Most Valuable Professional. Olga Londer is a principal technologist at QA and has authored most of QA's courses on Web development, design, and support. Shawn Shell is the national content management practice manager for Dell Professional Services. Todd Bleeker, Ph.D., is a seasoned professional technology manager working for Fortune 100 companies. Stephen Cawood is a member of the Microsoft Content Management Server product team and is a regular speaker at conferences such as Microsoft TechEd.