Best Practices for Site Deployment Using Content Management Server Site Deployment Manager

  • Article
On This Page

Introduction Introduction
Site Deployment Process Site Deployment Process
Exporting Content Exporting Content
Importing Content Importing Content
Additional Information Additional Information

Introduction

Deployment is the transfer of content from one server to another. Within Microsoft® Content Management Server (MSCMS), two tools support deployment: Site Deployment Manager and Site Stager.

Site Deployment Manager is an administrative component of Microsoft Content Management Server (MSCMS) used for deploying dynamic objects, which are assembled into content at run time, from one MSCMS server to one or more MSCMS servers. Deployment with Site Deployment Manager consists of transferring assets from a source MSCMS server to a target MSCMS server(s) through export and import operations. The assets are transferred as Extensible Markup Language (XML) packages, which are files with a .rop extension. Site Deployment Manager preserves the run-time feature set and dynamic behavior of the content after deployment on the target server(s).

Site Stager, which is not discussed in this paper, provides a static Hypertext Markup Language (HTML) snapshot of the dynamic content, which can then be browsed on any Web server regardless of platform. For more information about Site Stager, see the MSCMS Site Administrator's Guide at https://www.microsoft.com/CMServer/techinfo/.

This paper exclusively focuses on the best practices for deploying a site by using the Site Deployment Manager. The following topics are discussed in detail:

  • Site Deployment Process

  • Exporting Content

  • Importing Content

Please note that this paper is not intended as a planning guide. For more information about using Microsoft Content Management Server for site deployment, see the list of resources at the end of this paper.

Site Deployment Process

In a Web environment that uses Microsoft Content Management Server, deployment is the transfer of content, typically digital Web assets, from a source MSCMS server to one or more target MSCMS servers. Using Site Deployment Manager for deployment preserves the MSCMS run-time feature set and the dynamic behavior of the content. Retaining the dynamic behavior of the content has three distinct advantages.

  • Content can be modified on the target server without shutting it down.

  • The site dynamically recognizes user preferences, creating a personalized experience for each user.

  • During future deployments existing links between posted objects are updated seamlessly, even if the source object has been moved or renamed.

The first step toward smooth deployment is planning the server architecture so that deployments, which synchronize site content after the initial deployment, do not interfere with each other and only occur as a one-way process. For example, content would be deployed from the content creation server to the production server, never from the production server to the content creation server. Typical architecture contains the following servers:

Development Server—The development server has a database that contains the site structure, logic, server updates, server-side include files, and all the templates that are used for content presentation. This server also contains external assets, such as applications. The development server sets inside the internal firewall and has a short list of authorized users.

Content Creation Server—The content creation server is where, using the templates and structure from the development server, all of the content for the site is developed and then stored in a database. This server sets inside the internal firewall and all content developers are authorized users.

Quality Assurance (QA) Server—The optional QA server is where the content is tested before being deployed to the production server(s). This server sets outside the internal firewall, but inside the external firewall in the perimeter network (also known as DMZ, demilitarized zone, and screened subnet).

Production Server(s)—The production server(s) is the live site where users access the content. This server is typically read-only, with one write enabled port for deployment, and sets outside the internal firewall, but inside the external firewall in the perimeter network.

In general, Site Deployment Manager is best used for "1-way" deployments through environments. For example, objects should move from Development to Content Creation, and from Content Creation to QA/Production. This minimizes the chances of accidental overwriting of newer data. Some specific deployment scenarios are discussed in the following sections.

Deployment Between Development and Content Creation Servers

After the initial deployment of the site, deploying only new or changed templates and external assets from the development server to the content creation server prevents the possibility of overwriting content on the content creation server.

Figure 1: Development and Content Creation Server architecture

Figure 1: Development and Content Creation Server architecture

Deployment Between Content Creation and QA Servers

Deploying content from the content creation server to the QA server(s) verifies that the public site will work properly after deployment to the production server(s). If verification is successful, the same .rop file can be deployed to the production server(s).

Figure 2: Content Creation and QA Server architecture

Deploying from a Content Creation Server or a QA Server to a Single Production Server with Backup

When deploying content to a single production server with a backup, the following deployment method should be used.

  1. Deploy content to the backup server, and then put that server online.

  2. Move users to the backup server, and then take the live server offline.

  3. Deploy content to the live server, and then put the live server back online.

  4. Move users back to the live server, and then take the backup server back offline.

Figure 3: Single Production Server architecture with a QA Server

Figure 4: Single Production Server architecture without a QA Server

Deploying from a Content Creation Server or a QA Server to a Cluster of Production Servers

When deploying to a cluster of production servers, there will be one production server that has a write-enabled port specifically for deployment. Avoid deploying through the load balance cluster by specifying the write-enabled port during the import operation. For increased security, restrict access to the write-enabled Web site for only internal IPs using the "IP Address and domain name restrictions" setting in Microsoft Internet Information Services (IIS). For detailed instructions about executing deployment, see the Site Administrator's Guide.

Figure 5: Cluster Server architecture with a QA Server

Figure 6: Cluster Server architecture without a QA Server

The following sections discuss some of the best practices to consider during the overall site deployment process.

Initial Environment Deployment

The initial deployment of a site copies the entire site database from the source MSCMS server to one or more target MSCMS servers. Although Site Deployment Manager is the most effective method of deploying a small to medium portion of site content, deploying all of a site's content at once is faster and more efficient with SQL Server transfer tools. Using the SQL Server transfer tools to copy the entire database decreases resource usage and improves efficiency.

Site Deployment Manager is optimal for smaller, more frequent deployments. For example, incrementally deploying new changes to the production server(s) from the content creation server at regularly scheduled intervals.

Timing for Site Deployment

Deploy content during low traffic times to minimize inconvenience to users. When deploying to an authoring server, deployment during low traffic times minimizes inconvenience to content developers, makes sure that the most current approved versions of objects are exported, and prevents the loss of work on objects that are being edited on the target server.

Site Performance

Site performance is measured by throughput (pages displayed per second, ASP executed per second, and Get operations executed per second) and by the number of concurrent users the site can handle. Deployment is a resource-intensive operation that affects site performance. During deployment, the resources that are used by the database server—and in the case of deployment to a production environment, the Web server—to complete deployment cannot be used to perform other tasks. For example, in a production environment, the resources for the Web server would be occupied with deployment rather than assembling pages in response to user requests.

If possible, implementing deployment during low traffic times minimizes the impact on site performance. Also, ensure that the target server has adequate resources to handle the expected user traffic, and deployment, for the time at which the deployment is scheduled.

Object Export

Within MSCMS, objects exist as more than one copy of themselves. The published copy, which is the approved copy of the object, is the live copy that can be accessed and deployed. The working copy, which exists only while an object is being modified, is the copy of the object where modifications are made. When the modifications are finished, the working copy becomes the published copy. Revision history is a series of previous versions of the published copy.

Only approved objects are exported, the working copy of the object is not available for export. However, if there is already a published version of the object on the source server, then that version is exported. For example, if an object is being modified in a content creation server while objects are being exported to a live production server, then the previously published version of the object is exported. Although revision histories are stored in MSCMS, they are not available for export.

Object Import

When content is being imported to the target server(s), the new content overwrites the content that already exists in the environment. For this to happen, editing access to already existing content is blocked. For example, if an object is being modified on a content creation server while a new version of the object is being imported from the development server, the modifications are locked out and overwritten by the new object.

Background Processing

Before deploying a site, make sure that background processing is not running. Typically, during periods of low traffic in a MSCMS environment, background processing clears expired postings and takes care of other maintenance issues for a site. Both deployment and background processing make significant changes to the content and cannot be run at the same time. If one starts while the other is already running, then the second operation is blocked and does not execute until the other operation is finished. To check or configure the schedule for background processing, use the Background Cleanup fields under the General tab of the Server Configuration Application.

Handling External Assets

External assets, which are not managed by Microsoft Content Management Server, include all non-MSCMS repository assets. For example, files system assets (such as include files and .dlls), other databases, registry settings, and IIS configuration. Although objects that are managed by MSCMS may contain links and references to external assets, external assets are not exported or imported during deployment because MSCMS does not have control over them. To properly handle these assets, use Application Center 2000.

For more information about Application Center 2000, see the Microsoft Application Center 2000 - Evaluation Guide at https://www.microsoft.com/applicationcenter/evaluation/productguide.asp.

Server Resources

Depending on the size and complexity of a deployment, the object package (.rop) file can be fairly large. Due to the potential size of a .rop file, server resources can be exhausted before deployment is finished. Make sure that the servers have adequately fast processors, enough memory, disk space, and that node cache is properly set to complete deployment. Small, frequent deployments require significantly fewer resources than large deployments, such as an entire large site, that occur less frequently. Because deployment is resource intensive, it should be used for smaller, more frequent content updates.

Processor Speed

Using a server with adequate processor speed minimizes the interruption in site performance and makes the most accurate content available quickly. The recommended processor speed for deployment is at least a Pentium3 500 megahertz (MHz).

Memory

While objects are being copied and moved, physical and virtual memory are taxed heavily. Make sure that the servers have adequate physical and virtual memory before beginning a deployment. If there is not enough memory, an XML parse error may occur. The recommended memory is 1 gigabyte (GB).

Disk Space

Having enough disk space in the source environment to store copies of objects during deployment is critical to the process. Deployment requires at least twice the disk space of the MSCMS database. Without adequate disk space, failures may occur during the deployment process. Disk cache should be set in the Server Configuration Application so that it is large enough to handle the binary files.

For more information about Server Configuration Application, see the MSCMS Site Administrator's Guide.

Node Cache Memory

Node cache determines the number of objects that can be stored in the MSCMS memory cache. The default setting for Node Cache Memory is 2000. To accommodate a large deployment, node cache should be increased to increase export/import speed. The recommended size is 2 to 3 KB, plus the average page size. Node cache can be set through Server Configuration Application.

For more information about Server Configuration Application, see the MSCMS Site Administrator's Guide.

Exporting Content

Exporting is the first half of deploying content from the source MSCMS server to the target MSCMS server(s). Exporting copies approved objects, including all the objects upon which the approved objects are dependent, and bundles them into a .rop file. The .rop file is typically saved to a network share that is accessible to both the import and export client machines. The file can then be shared over the network or transported to other servers by other means. Unapproved objects and external assets cannot be exported with Site Deployment Manager.

Consider the following issues before executing an export operation:

  • Timing Export Operations

  • Object Dependencies

  • Using Profiles

  • Using Reports

Timing Export Operations

Export operations can be scheduled to occur at regular intervals, from once a week to once every few minutes. Depending on how often the deployments are scheduled to occur, different issues must be considered. If deployments are scheduled to occur frequently, with short intervals between them, the .rop files will be small and require few resources. For less frequent deployments, the .rop files will likely be fairly large.

With large, less frequent deployments, ensure that the most current content is included in the .rop file by scheduling an export operation during times when the source server is likely to be the least busy.

Only one export operation can occur at a time. Although content modifications can occur during export, it is not recommended. If content is being modified during the export, the version of the object being exported will be the most recently approved version of the object rather than the version with the modifications.

Object Dependencies

Objects such as channels, containers, individual files, and templates can be exported. However, an export will contain more than just the selected objects if the objects are dependent on other objects. For example, when a page is exported, the entire family of templates associated with that page is also exported.

An exception to this is a resource that has been added to an object without being added to the resource gallery and is not attached to the object as an external asset. This occurs when a resource is dragged into an object. For example, if a graphic is dragged into a page without being added to the resource gallery, then the graphic becomes a part of the page. Although the graphic always appears in the page, the graphic is not exported as a resource because it has been integrated with the page.

The following graphic depicts object dependencies in MSCMS when a channel is exported.

Figure 7: Object hierarchy for channel deployment

When exporting an object that contains a link to another object that is not exported, was not integrated with the exported object, and does not already reside in the target server(s), the link in the exported object appears as an inactive link. To reactivate the link, export the object into the target server(s).

Using Profiles

A profile is a snapshot of the currently selected options, the objects that are selected for export, and the path to the .rop file. Creating a profile is similar to setting a preset, or recording a macro, for deployments that occur often and for restoring often-used preferences. Using profiles streamlines the deployment process for future exports.

For more information about profiles, see the MSCMS Site Administrator's Guide.

Using Reports

Site Deployment Manager generates two interactive dynamic HTML (DHTML) reports for export operations. The first is an export preview report, and the second is a post-export report.

The export preview report contains information about the export operation before it happens. Along with selected options and objects that will be exported, the report lists objects that were selected for export but are not available, in addition to objects that contain inactive links. If an object is removed from the server before the .rop file is generated, it will become unavailable for export. If an object contains a link to another object that was not selected for export, inactive links will appear in the deployed content. In other words, if the objects that the link points to are not already on the target server, they will be inactive links on the target server. Use the Import Preview report (described in a later section of this paper) to double-check the links on the target server. Use the export preview report to get a clear picture of all the objects that are going to be exported and to identify any potential issues with the deployment. If issues are addressed after running the preview report, rerun the preview report before executing the export operation.

The post-export report contains information about what happened during the export operation. Assuming that no changes were made to either the source or target servers between when the export preview report was run and the export executed, the post-export report will look identical to the last export preview report. Using the post-export report gives a clear picture of the objects that were exported and any issues that were not resolved.

Importing Content

Importing content is the second half of deploying content from the source MSCMS server to the target MSCMS server(s). Although import operations are fully transactional, and therefore fail-safe, backing up the database in the target MSCMS server is recommended before executing an import operation. Backing up the database allows for efficient recovery of information that may be unintentionally overwritten during the import operation.

During an import, objects are written to the MSCMS database in the target server(s) through the MSCMS Site Builder Client from a .rop file. For this to happen, all other write operations are blocked during an import operation. Objects that are imported are automatically approved and will overwrite any existing object-level locks. The amount of time an import operation takes is dependent on the selected import options, the number of objects being imported, and whether or not the object(s) being imported is new or a new version of an existing object.

The following issues should be considered during import operations:

  • Timing Import Operations

  • Replacing Templates

  • Using Match Container

  • Using Destructive Synchronization

  • Using Profiles

  • Using Reports

Timing Import Operations

Import operations can be scheduled to occur at the same regular intervals as export operations.

To minimize the impact on site performance and content modifications during large deployments, an import operation should be performed during times when the server is not busy. During an import, all other write operations are blocked on the target server(s).

Pages are the most frequently imported objects. If a page is being modified on the target server(s) when the import starts, the modifications will be lost if that particular page is overwritten during the import.

Although it is most common to import content to a back-end database that supports a cluster of servers, the same data may also be imported to multiple target servers that are connected to different databases. The most efficient method for implementing this kind of import is to import to one server at a time by taking the server offline, importing the content, and then re-enabling the server.

Replacing Objects

During the import process, it is likely that some objects will be replaced. In MSCMS, an implicit globally unique identifier (GUID) identifies objects, rather than their name/location in the system. As a result, moving an item that you don't want to get overwritten in the target system will not prevent it from being overwritten, since it will still have the same GUID. The safest way to avoid this is to browse through the package in the Site Deployment Import dialog box and select the object in question. If the object exists on the target system and will be overwritten, the Action field will display "Replace." If not, the Action field will display "Add."

Replacing Templates

During the deployment process, templates may be replaced. The new template should be compatible with the template that is being replaced. If a template is incompatible, it does not contain the same placeholders as the version that is being replaced and unexpected behaviors may be observed in the pages that use that particular template.

For example, when importing a modified version of a template to the target server, it will replace the previous one. Pages that are already using the previous template will then use the new template. If a placeholder that contains default text has been added in the new template and a page that uses that template has been edited since the template was updated, then that page will display the text that is in the placeholder on the template unless useful content was added to the page in the new placeholder area.

Using Match Container

If the hierarchy of the content in the target server(s) does not match the hierarchy of the content from the source server, the import operation can change the structure in the target server(s) to match the structure from the source server. Using the Change container hierarchy on destination to match the package hierarchy option during the import operation automatically mirrors the hierarchy from the source server on the target server(s).

For example, in the following diagram, the source server hierarchy (A) is different from the hierarchy on the target server (B) before the import operation. After the import operation the hierarchy on the target server (C) matches the hierarchy on the source server.

Figure 8: Deployment using Match Criteria

For more information about executing an import operation, see the MSCMS 2001 Site Administrator's Guide.

Using Destructive Synchronization

When an object has been removed from the source server and also needs to be removed from the target server(s), using the Destructive Synchronization option during an import operation automatically removes the object from the target server(s). Destructive synchronization only works when an entire container is being imported. When this option is turned on, the contents of the container in the .rop file are compared to the contents of the container on the target server(s). Any objects that are in the container on the target server(s) but not in the container in the .rop file are removed from the target server(s).

For more information about executing an import operation, see the MSCMS 2001 Site Administrator's Guide.

Using Profiles

A profile is a snapshot of the currently selected import options and the name of the .rop file that is being imported. Creating a profile is similar to setting a preset, or recording a macro, for frequently imported .rop files and for restoring often-used preferences. Using profiles streamlines the deployment process for future imports. Profiles are stored as XML files with an .rip (Import Profile) extension.

For more information about profiles, see the MSCMS 2001 Site Administrator's Guide.

Using Reports

Site Deployment Manager generates two interactive DHTML reports for import operations. The first is an import preview report and the second is a post-import report.

The import preview report is an essential piece of the import operation because of the information that it contains. Along with selected options and a list of objects that will be imported, the report lists objects that will be deleted on import and destination objects that may contain inactive links after import. An object will be deleted on import if the Destructive Synchronization option is turned on. However, Destructive Synchronization will not delete objects that have other objects dependent on them. For example, if a page on the target server(s) uses a template that was removed from the source server and would be removed from the target server(s), the template is not removed. Objects will contain inactive links if they link to other objects that are not present on the target server(s). Use the import preview report to identify changes that will occur after the import process is complete.

The post-import report contains information about what happened during the import operation. This report will look identical to the import preview report.

Additional Information

For more information about Microsoft Content Management Server and site deployment, see the following resources: