Microsoft Commerce Server 2000: Deploying Content

This chapter describes how to deploy content on a Microsoft Commerce Server 2000 site. If you are deploying content on a new site, be sure to read "Deploying Your Site" in Commerce Server 2000 Help, particularly the "Using Site Packager" section. Also, read the "Application Center 2000" section later in this chapter, which describes how you can deploy your site using Microsoft Application Center 2000.

This chapter also describes how to migrate from the Site Server Content Replication System (CRS) to Commerce Server using Application Center. For more information about migrating from Site Server to Commerce Server, see Chapter 11, "Migrating from Site Server to Commerce Server 2000."

The following are some examples of site content:

  • Web pages and page elements, including:

    • Static content (Hypertext Markup Language (HTML), graphics, digital media, advertisements, and so on)

    • Dynamic content (such as Active Server Pages (ASP) and scripts)

  • Applications, middle-tier components (such as COM+), database procedures, and other programming logic

  • Data that supports the creation of dynamic Web pages or enables customers to make transactions (such as the product catalog, campaigns and ads, and user profiles)

  • Reports

  • Files of all types that users can download or view online (including Microsoft Word documents, Portable Document Format (PDF) files, compressed file archives, graphics)

  • Content on related support sites, in addition to the primary public site

This chapter describes content deployment for the following three scenarios:

  • Small-to-medium site. Usually contains development, test/staging, and production environments, with 1 to 20 servers in each of the three environments. This type of site contains a small-to-medium volume of content (approximately 1 to 2 GB), with a low amount of content turnover.

  • Medium-to-large site. Usually contains development, test/staging, Enterprise Resource Planning (ERP) systems, and production environments, with 20 or more servers in the production environment and 10 to 20 servers in each of the other environments. This type of site contains a medium volume of content (more than 2 GB), with a medium amount of content turnover. When you deploy content to a medium-to-large site, you should consider deploying in stages, rather than trying to deploy all of the content at once. You should also consider compressing content during replication.

  • Global site. Usually consists of several large, geographically separated sites connected by a dedicated wide area network (WAN). This type of site contains a large volume of content, with a medium amount of content turnover. When you deploy content to a global site, you should consider deploying in stages, rather than trying to deploy all of the content at once. You should also consider compressing content during replication, and make provisions for recovering from errors due to failures in the WAN link.

Although each of these scenarios varies in complexity and approach, they all share a common development life cycle. Figure 15.1 shows how content moves from the development environment to the test/staging environment, and then to the production environment.

Cc936693.f15csrk01(en-US,CS.10).gif 

Figure 15.1 Content development and deployment 

In the content development and deployment model shown in Figure 15.1, you do the following:

  1. Develop new content within the confines of the corporate network, using tools such as Microsoft Visual Studio (C++, Microsoft Visual Basic, Microsoft Visual InterDev), Microsoft Visual SourceSafe, and Microsoft PhotoDraw.

  2. Unit-test changes in the development environment.

  3. When content is ready for integration and regression testing, you move it from the development environment to the test/staging environment. The test/staging environment should be similar in network topology to the production environment, at smaller scale (fewer processors or Web servers, and so on). It might be located within the corporate network, if you are developing and administering applications in-house; or it can be located offsite at the Internet Service Provider (ISP)/Application Service Provider (ASP) if your site is being administered externally.

  4. When you have successfully completed regression testing, you can move the content from the test/staging environment to the production environment.

You create content in the development environment and administer it in the production environment. Business managers and system administrators use Commerce Server Business Desk and Commerce Server Manager to create and administer various types of content. The following is a list of the organizational roles that are usually involved with creating, administering, and deploying content:

  • Business managers. Add, change, and delete content, using Business Desk in the development environment. Business managers work with the following types of content:

    • Catalogs (products, prices)

    • Campaigns (discounts, advertising, direct mail, expressions)

    • Reports

    • Orders

    • User profiles

    • Site terms

    • Shipping methods and tax rates

  • Site developers. Add, change, or delete content, using Visual Studio or another tool, in the development environment. Site developers work with the following types of content:

    • Pipelines

    • COM+ components

    • Internet Server Application Programming Interface (SAPI) filters and extensions

    • Dynamic content (ASP pages, Visual Basic scripts, and so on)

    • Static content (HTML, Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), streaming media, and so on)

    • Database schema changes

    • Data (catalogs, campaigns, user profiles, site terms, and so on)

  • Testers. Test and approve newly developed content in the test/staging environment, prior to deployment in the production environment.

  • System administrators. Administer change requests from both business managers and site developers, using Commerce Server Manager resources or Business Desk modules. System administrators are responsible for:

    • Deploying new Business Desk modules.

    • Managing Internet Information Services (IIS) 5.0 metabase changes.

    • Timely and accurate deployment of new site content in all environments (development, test/staging, and production).

Typically, business managers add new campaigns, manage catalog changes, and make other related system changes within the development environment. These changes are tested in the test/staging environment and, when approved, moved to the production environment.

Developers also work in the development environment. Their changes are also tested in the test/staging environment and, when approved, moved to the production environment. System administrators adjust the supporting infrastructure (software, hardware, and network) within the development environment. You need to duplicate these changes in the test/staging environment for testing and, when approved, duplicate them in the production environment.

The content management process usually contains the activities listed in the following table.

Activity

Description

Design

Define the content that authors should publish on the Web site.

Author

Develop and produce the content. Graphic artists, videotape production crews, photographers, technical writers, advertising writers, application developers, Web page developers, lawyers, human resource personnel, marketers, or anyone else who produces original material for the Web site create this content. You usually use a source code management system, such as Visual SourceSafe, to track the authored content.

Review

Review content. You should make sure that reviewer responsibilities are well-defined and technical reviewers identified before content is created and deployed.

Approve

Approve content for deployment. The cross-functional nature of Web content makes it important to have a well-defined content-approval process in place and approvers named, beginning with the earliest stages of content creation through final deployment.

Convert

Transform content from the format in which an author created it to the format in which you can display it on your site. For example, word processor documents must be converted to formatted HTML text, bitmapped images must be modified so that they load faster on the Web, and image formats might have to be changed. Site developers use templates, layouts, themes, and other methods to convert text into uniformly formatted Web pages.

Store

Place content in file systems, version-control systems, or other types of repositories. Integrated application development systems store varied Web content in a file system that replicates the hierarchical structure of the Web site.

Stage

If you have a separate staging environment, you should use it to assemble all content after the content has been thoroughly tested and before you move it to the production environment.

Test

Test the finished content. For example, testing should include identifying broken or missing links, identifying pages that load slowly, load testing, component testing, database access testing, script testing, and performance testing. Comprehensive, final integration testing should be done in a test/staging environment that exactly mirrors the production environment. Developers need to make sure that database connections are valid for the test/staging environment and the production environment. For more information about testing a Commerce Server site, see Chapter 16, "Testing Your Site."

Deploy and replicate content

Place new content into production. You must be sure that all content gets moved to the live system, including middle-tier components and transactional packages.

Monitor and update

Monitor your production site and update the content when necessary. The content management process does not end when you install content in the production environment. You must continuously monitor and update content, in order to keep the site current and working properly.

Remove and archive

Remove stale or out-of-date content from the production environment and archive it for a pre-determined length of time.

Analyze

Analyze the site and user traffic on an ongoing basis.

Deployment Tools

Cc936693.spacer(en-US,CS.10).gifCc936693.spacer(en-US,CS.10).gif

Today, no single tool appears to be sufficient for deploying all types of content or for fulfilling the needs of everyone involved (business managers, site developers, or system administrators). You should evaluate and choose a deployment tool based on its core capabilities, supportability, and ease of use. This section describes the following tools for deploying Commerce Server content:

  • Application Center 2000

  • Content Replication Service (CRS)

  • Custom SQL Server Data Transformation Services (DTS) tasks and packages

  • Custom scripts (Visual Basic, Visual Basic Script)

  • Third-party deployment tools

For an explanation of how to use Commerce Server Site Packager to unpack your Web site and settings, see "Using Site Packager" in Commerce Server 2000 Help.

In addition to the tools described in this section, you can also use Visual Studio or Visual InterDev to publish a Web site by copying the files in the Web site to a destination such as a Web server. For more information about Visual Studio, see https://msdn.microsoft.com/vstudio/ . For more information about Visual InterDev, see https://msdn.microsoft.com/vinterdev/ .

Application Center

Application Center is a deployment and management tool that consists of a suite of monitoring and diagnostic tools for Web applications. You can use Application Center to manually define the composition of a Web application. This composition, called the application image or resource set, contains the following content and components:

  • System data source names (DSNs)

  • File system paths (pipelines)

  • COM+ applications and ISAPI filters

  • Dynamic content (ASP pages, Visual Basic scripts, and so on)

  • Static content (HTML, GIFs, JPEGs, video, and so on)

  • Registry keys

  • Web sites (default and administration) and virtual directories

Application Center automatically synchronizes online content and server configuration settings when they are updated. You can also manually synchronize the settings at any time from the cluster controller. In addition, you can deploy COM+ applications across an Application Center cluster or outside the cluster. Application Center supports the following functionalities:

  • Administration of IIS 5.0 metabase changes and related content, effectively replicating the metabase from the cluster controller to all members of the cluster (or outside the cluster) and overwriting metabase settings for each member of the cluster.

  • Replication of Microsoft Windows NT and Microsoft Windows 2000 access control lists (ACLs).

Application Center does not support the following functionalities:

  • Deployment of changes to the database or database schema. This includes nearly all of the functionality required to replicate the tasks that business managers perform using Business Desk.

  • Content replication over a WAN link.

  • Distribution of application installation packages like new Business Desk modules, Commerce Server, or Windows 2000.

  • A native roll-back feature.

For more information about Application Center, see https://www.microsoft.com/applicationcenter/ .

Content Replication Service

Content Replication Service (CRS), which was a feature of Site Server 3.0, is now available on the Application Center 2000 CD. With CRS, you can easily replicate file-based content, such as files, directories, metadata, and ACLs from directory to directory, between local servers, or across the Internet or a corporate intranet. You can also use CRS to replicate and install server applications, including Microsoft ActiveX Server Components and Java applets. You can use CRS to replicate the following types of content:

  • File system paths (pipelines)

  • COM+ components

  • Dynamic content (ASP pages, Visual Basic scripts, and so on)

  • Static content (HTML, GIFs, JPEGs, video, and so on)

CRS supports the following functionalities:

  • Deployment over WAN links, through firewalls on TCP port 507

  • Pre- and post-replication script execution

  • User-defined rollback

  • Transaction-based processing of replicated content

  • Transaction logging

  • Command line-based administration

  • Replication of Windows NT and Windows 2000 ACLs

CRS does not support the following functionalities:

  • Deployment of database or database schema changes. This includes nearly all of the functionality required to replicate the tasks that business managers perform using Business Desk.

  • Distribution of application installation packages like new Business Desk modules, Commerce Server, or Windows 2000.

  • Administration of IIS 5.0 metabase changes, unless manually scripted.

Custom SQL Server DTS Tasks and Packages

You can't use Application Center or the CRS tool to deploy database or database schema changes throughout a three-tier environment. However, you can use Microsoft SQL Server 7.0 or SQL Server 2000 to create DTS packages that move both schema and data changes between two servers running SQL Server. Each of the tasks that business managers perform when they add, change, or delete content should have an associated DTS task.

You can create DTS tasks and packages to support the following functionalities:

  • Deployment over WAN links, through firewalls on TCP port 1433

  • Pre- and post-replication script execution, as part of the DTS package, or scheduled after using another mechanism like Windows Task Scheduler

  • User-defined rollback (such as database backup prior to DTS execution)

  • Transaction logging

  • E-mail notification (such as SQL Mail or a Collaboration Data Objects (CDO) message)

  • Deployment of database or database schema changes

DTS tasks and packages do not support the following functionalities:

  • Command line-based administration (only SQL Server graphical user interface (GUI) or Executive Scheduled Task are supported)

  • Distribution of application installation packages like new Business Desk modules, Commerce Server, or Windows 2000

  • Administration of IIS 5.0 metabase changes

Custom Scripts

Although it is possible to write custom Windows Script Host (WSH) scripts to automate the entire content deployment process, it is much easier to use other tools (such as Visual Basic or Visual Basic Script). You should create WSH scripts only to enhance the capabilities of the other tools you're using or to integrate their processes. For example, you can define pre- or post-processing of scripts in a deployment project managed with tools such as CRS, Application Center, or OpenDeploy. (OpenDeploy is discussed in the following "Third-Party Deployment Tools" section.)

The object model in Commerce Server also provides the ability to script certain tasks, such as updating prices for all of the items in a catalog. For more information about using Commerce Server to create custom scripts, see "Programming with Commerce Server Objects" in Commerce Server 2000 Help.

Third-Party Deployment Tools

Interwoven OpenDeploy 4.2 is content replication software for the Web that provides a secure, flexible, and scalable solution for transferring transactional content between servers.

OpenDeploy 4.2 supports the following functionalities:

  • Comparison of content in the development and production environments

  • Deployment of Web content over WAN links through firewalls

  • Transfer of data by list, delta, and package

  • Automatic site rollback

  • Transactional rollback

  • Retries and retry intervals for locked files on production servers

  • Encrypted deployment (48-bit symmetric key encryption and 128-bit asymmetric key support) to ensure transfer of content only between approved sources

  • Command line-based administration

  • Configuration files with multiple "named deployment" configurations.

For more information about Interwoven OpenDeploy, DataDeploy, and TeamSite, as well as other software developed especially to work with Commerce Server 2000, see: https://www.microsoft.com/commerceserver/ .

Deployment Scenarios

Cc936693.spacer(en-US,CS.10).gifCc936693.spacer(en-US,CS.10).gif

This section describes how to apply the tools discussed previously in this chapter to the following types of sites:

  • Small-to-medium

  • Medium-to-large

  • Global

Small-to-Medium Site

A small-to-medium site typically has from 1 to 20 servers per environment. This type of site usually contains a small-to-medium volume of content (approximately 1 to 2 GB), with a low amount of content turnover. Figure 15.2 shows an example of a small-to-medium site.

Cc936693.f15csrk02(en-US,CS.10).gif 

Figure 15.2 Small-to-medium site 

In a small-to-medium site, the business manager adds new ad campaigns, discounts, and so on to the development environment. Developers develop new versions of applications, make enhancements, and debug production issues within the development environment. The system administrator supports the site and makes administrative changes to the development environment.

New content is deployed to the test/staging environment using Site Packager, Application Center, CRS, or OpenDeploy. Figure 15.2 shows a deployment done with Application Center. Database transfers are created and run using SQL Server DTS packages or DataDeploy. Content is deployed either from the development SQL Server or the Web server to a stand-alone Application Center cluster controller.

You use the Application Center Microsoft Management Console (MMC) to make the necessary changes to the application manifest and start the Application Center Application Deployment Wizard to deploy the application to the Application Center cluster controller. The Application Deployment Wizard helps you deploy content and configure one or more applications to selected Application Center clusters or members.

When new content has been sent to the test/staging environment, the test team can begin to test it. If changes are necessary, the entire content deployment process begins again.

You deploy content from the test/staging environment to the production environment using the Application Deployment Wizard. The Application Center stand-alone cluster controller deploys the application to each Application Center cluster controller in production, thus effectively distributing the new or updated content throughout the production environment.

Medium-to-Large Site

A medium-to-large site usually contains development, test/staging, ERP systems, and production environments, with 20 or more servers in the production environment and 10 to 20 servers in each of the other environments. This type of site generally contains a medium volume of content (more than 2 GB), with a medium amount of content turnover. When you deploy content to a medium-to-large site, you should consider deploying in stages, rather than trying to deploy all the content at once. You should also consider compressing content during replication. Figure 15.3 shows an example of a medium-to-large site.

Cc936693.f15csrk03(en-US,CS.10).gif 

Figure 15.3 Medium-to-large site

In a medium-to-large site, the business manager adds new ad campaigns, discounts, and so on, to the development environment. Developers develop new versions of applications, make enhancements, and debug production issues in the development environment. The system administrator supports the site and makes administrative changes to the development environment.

In Figure 15.3, Application Center is used to deploy updated content to a load-balanced Application Center cluster in the development environment. The system administrator can then build an environment in which business managers and site developers can add, change, or delete content. The system administrator can also change the application manifest and test application deployment inside the development environment before deploying the completed application to the test/staging environment.

You can deploy new content over a WAN link to the test/staging environment using CRS or OpenDeploy. You use SQL Server DTS packages or OpenDeploy to create and run database transfers.

You deploy content either from the development SQL Server or the Web server with the Application Center cluster controller to the Web server in the test/staging environment, acting as a stand-alone Application Center cluster controller. The system administrator then uses the Application Center MMC console to make the necessary changes to the application manifest and starts the Application Deployment Wizard to deploy the application to the Application Center cluster controller.

When new content has been sent to the test/staging environment, the test team can begin to test it. If changes are necessary, the entire content deployment process begins again.

You deploy new content using the Application Deployment Wizard. The Application Center stand-alone cluster controller deploys the application to each Application Center cluster controller in the production environment, thus effectively distributing the new or updated content throughout the production environment.

Global Site

A global site usually consists of several large, geographically separated sites connected by a dedicated WAN or an ISP/ASP-provided WAN. A global site might even be hosted by multiple ISPs/ASPs. This type of site contains a large volume of content, with a medium amount of content turnover. When you deploy content to a global site, you should consider deploying in stages, rather than trying to deploy all the content at once. You should also consider compressing content during replication, and make provisions for recovering from errors due to failures in the WAN link.

The development environment for a global site is usually centralized, and looks very much like the medium-to-large site development environment shown previously in Figure 15.3. However, it is not uncommon in a global site to have local development satellite locations devoted to localizing content, adapting content for a local market, or just participating in the general development effort.

You can typically consolidate content from satellite development sites by transferring it over dedicated WAN links to the primary development location using CRS or OpenDeploy. You can create and run database transfers using SQL Server DTS packages or DataDeploy. At the primary development location, you integrate the transferred content into the centralized development effort and redeploy it to each of the distributed test/staging environments.

Testing in each location is done in a similar fashion to the testing done in small-to-medium and medium-to-large sites. Figure 15.4 shows how a global site might be structured.

Cc936693.f15csrk04(en-US,CS.10).gif 

Figure 15.4 Global site 

You deploy new or updated content using the Application Center Application Deployment Wizard. The Application Center cluster controller in the test/staging environment deploys the application to each Application Center cluster controller in production, effectively distributing the new or updated content throughout the production environment.

Deployment Examples

Cc936693.spacer(en-US,CS.10).gifCc936693.spacer(en-US,CS.10).gif

This section contains deployment examples for the following types of content:

  • Campaigns, campaign items, expressions

  • COM+ applications

  • Databases

Campaigns, Campaign Items, and Expressions

This section describes a scenario that you might use to deploy new campaigns, campaign items, or expressions, using CRS over a WAN link to an Application Center cluster controller. You then use Application Center to deploy your content to the cluster and its members. Figure 15.5 shows how the new ad campaign is deployed in this scenario.

Cc936693.f15csrk05(en-US,CS.10).gif 

Figure 15.5 Deploying a new ad campaign 

When you design a new Commerce Server site, you must estimate the number of campaigns, campaign items, and expressions that might be created and archived over the life of the site. In most Commerce Server sites and under most circumstances, a dedicated SQL Server cluster will handle requests for these items. For this reason, you should create your site so that related campaign tables are stored in a separate database. It will then be a relatively simple task to move those tables and related sets of records through the entire development life cycle as a unit.

Important When you update campaigns, ads, and discounts, move only tables containing these records. Do not overwrite the Performance table.

In this scenario, business managers solicit a new advertising campaign, payment for which is based on the number of ad requests. The campaign is designed in conjunction with some static HTML content. The business managers, using Business Desk, then place the required ad campaign content into the development environment.

Content developers prepare the static content to which the ad campaign will link and add it to the development environment. The business managers and developers unit-test the new ad campaign within the development environment.

The system administrator then moves a copy of the database tables and the new static HTML content to the test/staging environment. Using CRS, the system administrator first creates a project to deploy the static HTML content to the Application Center cluster controller. Next, the database administrator creates a SQL Server DTS package to transfer the required database tables.

After running the DTS package, testers can test the campaign on the Application Center cluster controller, which has its own dedicated SQL Server server. The system administrator next uses Application Center to deploy the static HTML content to each member of the cluster. Finally, the system administrator uses a similar DTS package to deploy the campaign tables to the SQL Server cluster serving ad campaigns for other members of the Application Center cluster. For more information about DTS tasks, see "Running the Data Warehouse" in Commerce Server 2000 Help.

If the ad campaign does not successfully pass the tests, you repeat this campaign deployment process until it does. When the ad campaign has successfully passed all the tests in the test/staging environment, you use the same process to move the ad campaign from the test/staging environment to the production environment.

COM+ Applications

This scenario describes how to deploy a new COM+ application, using CRS over a WAN link to deploy any related static or dynamic content, and to install the COM+ application on the remote Application Center cluster controller. This scenario also explains how to deploy a COM+ application and related content to its members. Figure 15.6 shows how to deploy a COM+ application.

Cc936693.f15csrk06(en-US,CS.10).gif 

Figure 15.6 Deploying a COM+ application 

When you design a Commerce Server COM+ application, you must consider the related business logic components. You must install Commerce Server on the same server as the COM+ component. You can't reference Commerce Server components from COM+ components unless they are installed on the same server. COM+ components can reference both local Commerce Server components and remote COM+ components. However, you should only have a COM+ component access a remote COM+ component when it's absolutely necessary (for example, to access secure data), because remote access impacts performance.

The following steps explain how to move the COM+ object and the ASP pages to the test/staging environment and then to the production environment:

  1. Create a COM+ application with the Component Service snap-in and add the COM+ object.

  2. Export the resulting COM+ application to a Microsoft Windows Installer file.

  3. Create a batch file to install the COM+ application and the ASP pages, such as the following:

    net stop "World Wide Web Publishing Service"
    xcopy Templates\menu.bak c:\Inetpub\wwwroot\b2csite\template\ /E /R /Y
    xcopy Templates\menu.asp c:\Inetpub\wwwroot\b2csite\template\ /E /R /Y
    xcopy sitemap.asp c:\Inetpub\wwwroot\site\ /E /R /Y
    xcopy team.xml c:\Inetpub\wwwroot\site\ /E /R /Y
    xcopy images\*.png c:\Inetpub\wwwroot\site\images\ /E /R /Y
    msiexec -i htmlhelper.msi
    net start "World Wide Web Publishing Service"
    
  4. Using CRS, create a project to deploy the files, and then run a batch file (such as the batch file, msiexec -i htmlhelper.msi, in Step 3) to install the COM+ application.

    Running the CRS project copies the ASP pages and runs the batch file as a post-replication script. The Application Center cluster controller must not be serving active HTML/ASP requests from any other test team member when you run the CRS project. The pages can be tested on the Application Center cluster controller.

  5. Create an Application Center application image containing the following:

    • COM+ application

    • Virtual root

    • Files (ASP and other resource files, such as HTML, images, and so on)

  6. Deploy the Application Center application image (manually synchronized) to the members of the cluster.

If the pages don't pass the tests, repeat this COM+ application deployment process until the tests complete successfully. When the pages have been approved, you use the same process to move them from the test/staging environment to the production environment.

Databases

To ensure availability and scalability for large Commerce Server sites, you might want to replicate your Catalogs database. Use SQL Server to do this. For more information about how to use SQL Server to replicate Commerce Server databases, see SQL Server Books Online. Also see "Using SQL Server to Replicate Databases" in Commerce Server 2000 Help.

Use the Profiles Schema Mover utility to move profile schemas. For information about the Profiles Schema Mover utility, see Chapter 9, "Developer Notes."

Whether you use snapshot replication, transactional replication, or merge replication, the tasks described in the following table should be helpful.

Stage

Tasks

Configuring replication

Identify the publisher, distributor, and subscribers in your topology.
Use SQL Server Enterprise Manager, SQL-DMO, or Transact-SQL system stored procedures and scripts to configure the publisher, create a distribution database, and enable subscribers.

Publishing data and database objects

Create the publication.
Define the data and database object articles in the publication.
Apply any necessary filters to data that is to be published.

Subscribing to publications

Create push, pull, or anonymous subscriptions to indicate what publications should be propagated to individual subscribers and when.

Generating the initial snapshot

Identify where to save files.
Specify whether or not the files should be compressed.
Identify scripts that should be run before and after applying the initial snapshot.

Applying the initial snapshot

Apply the snapshot automatically by synchronizing the subscription, using the Distribution Agent or the Merge Agent. You can apply the snapshot from the default snapshot folder or from removable media that can be transported manually to the subscriber before the snapshot is applied.

Synchronizing data

Run the Snapshot Agent, Distribution Agent, or Merge Agent to synchronize data and propagate updates between publisher and subscribers.
For snapshot replication, a snapshot will be taken and propagated to subscribers.
For transactional replication, the Log Reader Agent will store updates in the Distribution database and the Distribution Agent will propagate updates to subscribers.
If you use subscriptions that can be updated with either snapshot replication or transactional replication, data will be propagated from the subscriber to the publisher and to the other subscribers.
For merge replication, data is synchronized during the merge process. Conflicts, if any, are detected and resolved at that point.

Cc936693.spacer(en-US,CS.10).gif