Chapter 6 - Synchronization and Deployment

This chapter focuses on key Microsoft Application Center 2000 (Application Center) activities—keeping cluster configuration settings and content synchronized and deploying content. Detailed information is provided about each of the features as they are used, including set up and configuration tips. You'll also get an inside look at the sequence of events and processing activities that occur when you use a particular feature.

On This Page

Synchronization Service Overview and Architecture
Synchronization Reliability
Synchronization Modes and Processing
Synchronizing Cluster Configuration Settings
Synchronizing Content and Applications
Deploying Applications
Special Cases
Configuring, Managing, and Monitoring Synchronization

Synchronization Service Overview and Architecture

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

The Application Center Synchronization Service provides the means for deploying content and applications and synchronizing a cluster—including content, applications, network configurations, and load balancing configuration. As you can see, synchronization is a core technology for maintaining consistent settings and content across Application Center clusters.

The Synchronization Service does not attempt to solve the problems of shrink-wrapped application installation or wide area deployment. However, it does not require any special hardware and implements the following guiding principles:

  • It works with existing publishing tools, such as Web Distributed Authoring and Versioning (WebDAV) and Microsoft FrontPage 2000. 

  • Synchronization is virtually transparent to the user, and multiple content types are replicated seamlessly across the cluster (for example, files, metabase settings, and system Data Source Names [DSNs]). 

  • At a minimum, synchronization performance is at the same level as the Site Server Content Deployment System (formerly called the Content Replication System) when handling large content updates. Typically it takes about 450 seconds to replicate 250 MB by using the Content Deployment System. 

The Application Center "shared nothing" design means that every cluster member can stand alone as a complete unit for serving content and providing access to applications. It also means that any member can assume the cluster controller's role if required to do so, provided that the member contains a complete set of the controller and cluster configuration settings.

As noted in Chapter 2, "Feature Overview," Application Center replicates:

  • Web content and Active Server Pages (ASP) applications 

  • COM+ applications 

  • Virtual sites (and their associated ISAPI filters) and content 

  • Global ISAPI filters 

  • File system directories and files 

  • Metabase configuration settings 

  • Exportable Cryptographic Application Programming Interface (CAPI) server certificates 

  • Registry keys 

  • System DSNs 

  • Windows Management Instrumentation (WMI) settings that Application Center uses 

You can divide all of the items in the preceding list into two broad categories: configuration settings and content (or applications, depending on the cluster). Before examining these two categories in more detail, let's take a look at the underlying architecture that supports the Synchronization Service.

Synchronization Service Architecture

Application Center, like the Content Deployment System, uses a single master replication model, which means that changes to a cluster member are not pushed out to the rest of the cluster; instead, all changes to members come from the cluster controller. Another implication of this model is what happens if changes are made to an individual member. If these changes include data that's contained in the controller's master inventory, they are overwritten the next time synchronization occurs. If, however, these changes are outside the scope of the inventory, the controller isn't aware of them and they're ignored, as illustrated in Figure 6.1.

Bb734911.f06uj01(en-us,TechNet.10).gif

Figure 6.1 How the single master replication model affects changes to member configuration or content 

Note Only files outside the scope of the inventory are ignored; all Internet Information Services 5.0 (IIS) configuration settings on members are overwritten by the controller's IIS configuration settings, which includes all the files that IIS references.

The architecture for the Synchronization Service consists of two parts: the replication engine and replication drivers. Generally speaking, the replication engine manages the synchronization process, while the drivers manage different content types. Figure 6.2 provides a high-level view of the Application Center Synchronization Service architecture.

The Replication Engine

As noted earlier, the replication engine drives content replication and cluster synchronization. It uses asynchronous communication to support its two-phase synchronization process—first transferring the data, and then writing it. Although synchronization is a two-phase process, the absence of commit and rollback capability means that this process is not truly transactional.

Note The replication engine encrypts DCOM and RPC traffic by using the same encryption mechanism (RPC Packet Privacy) that Microsoft Windows 2000 Server employs between domain controllers and servers. However, HTTP traffic, which only consists of files, is not encrypted. This means that metabase and registry entries are secure, but sensitive information, such as a password, stored in a file is not.

The engine's primary responsibilities include handling administration requests coming from the user interface, coordinating replications among the various drivers, and performing general synchronization tasks. These tasks encompass:

  • Cross-server communication—The engine handles communications between the controller and any member that's a synchronization target. 

  • Security—The engine uses the ACC_ computername account for cross-server communication. 

    Bb734911.f06uj02(en-us,TechNet.10).gif

    Figure 6.2 The ApplicationCenter Synchronization Service architecture 

  • Batching—Changed items are batched during automatic synchronization at the replication source for either a certain period of time (10 seconds) or until the buffer size is exceeded. Because the buffer size is 250 items and the maximum number of buffers is 200, you can theoretically batch up to 50,000 changes. 

  • Transport—The engine uses DCOM (or RPC if it's operating in stager mode) to transfer batched updates 

  • Eventing, logging, and notifications—The engine sends events, as appropriate, in response to specific conditions. (Note: the various drivers also do this.) 

The relationship between the replication engine and the various drivers is shown in Figure 6.3, which also shows how data is transferred between the source and target servers.

Bb734911.f06uj03(en-us,TechNet.10).gif

Figure 6.3 Replication engine and driver architecture 

Data Types and Transfer Methods

During the synchronization process, two types of data may be sent—either an XML content description list or binary data. There are three types of information that can be expressed as an XML list:

  • An IHave content list, which describes all the content present on the source. 

  • An Action list, which is a request for updated content that a target sends to the source. 

  • An Update list, which contains all the content that was updated, or a link to the content if it was transferred through the built-in HTTP engine. 

For the sake of future synchronization processing examples, let's refer to the preceding lists as IHave, Action, and Update, respectively.

As shown in Figure 6.3, the two protocols for transferring data from the source server to a target server are HTTP and DCOM. RPC is used as an alternative transport to DCOM in staging scenarios. RPC is used because it supports the use of port specification, which is required for deployments through a firewall.

Note The default port specification is port 4243 for HTTP file transfers and port 4244 for RPC data transfers.

Replication By Using the DCOM and RPC Protocols

When DCOM replication takes place, the driver passes to the engine a well-formed XML object. This object contains the change description for a single resource, such as a path statement for a file or directory.

In cases where replication takes place through a firewall, which is a typical staging scenario, the DCOM data is converted to RPC format and passed through the specified RPC port on the firewall. The replication engine transports the XML object (UTF-8 encoded) to the destination server. The receiving server ensures that the entire batch is received, reconstitutes the RPC data as DCOM, and then instructs the driver to apply the changes by writing the new data to the target.

Replication By Using the HTTP Protocol

This method sends the data in binary format by using FastFile transmit, an HTTP API, which is capable of moving large amounts of data quickly. Communication between the source and target servers takes place on a single port and uses HTTP. If used through a firewall, this port has to be enabled as well. (Only the file system driver uses this protocol to copy data.)

Note Although synchronization is accomplished by using HTTP FastFile, configuring bandwidth throttling on the Web server has no affect on synchronization because the replication engine does not use IIS or the front-end adapter.

The Replication Drivers

Each driver shown in Figure 6.3 is responsible for replicating its own particular type of content. Of course, there are several additional activities that each driver handles. Depending on the driver, these activities can encompass:

  • Monitoring the driver data store. 

  • Reading the driver-specific data. 

  • Writing data to an XML object or to a driver-specific file transfer API. 

  • Comparing the content list on the source and target. 

  • Locking and/or unlocking a resource for writing. 

  • Handling the transfer and committing it to permanent storage for a given resource. 

  • Handling security at the resource level. 

Resource replication order 

The replication engine calls the appropriate driver based on the order that resources are specified in the metabase (LM\WebReplication\DriverOrder), and should not be changed.

The default order for resource replication is:

  • FS—file system 

  • MB—metabase 

  • IIS—IIS sites and bindings 

  • NET—network and Network Load Balancing (NLB) configuration 

  • REG—registry 

  • DSN—DATA SOURCE NAMES 

  • CAPI—CryptoAPI 

  • WMI—Windows Management Instrumentation 

  • COM+—COM+ applications 

Assuming that a synchronization or deployment needs to replicate all of the preceding resources, each driver will be called sequentially, up to, and including the NET settings resource group. After the NET settings are applied, the balance of the changes (for example, DSNs and WMI settings) is un-ordered because they are applied concurrently.

Note When an administrator creates a virtual directory that points to an existing path, this approach serves to guarantee that files referenced by virtual directories are applied to each member before the virtual directory settings are written to the IIS metabase.

Let's examine the Application Center replication drivers in more detail, starting with the File System driver.

File System Driver

The File System driver uses standard Microsoft Win32 APIs for read/write functions and picks up change notify from ReadDirChangesW, which works with FAT- and NTFS-formatted disks. The driver uses a file's last modified date, size, and attributes to create a signature. The File System driver does content comparisons of the content tree of the controller and individual members to identify content that needs to be replicated.

The driver informs the replication engine of changes as they occur, and when a file is synchronized, the entire file is copied to the target. The File System driver monitors the following areas by default:

  • All virtual directories identified in the IIS metabase. 

  • All custom errors defined by the metabase. 

  • All ISAPI and IIS filters identified in the IIS metabase. 

  • User-specified directories in an application. 

The File System driver assumes that the target has the same disk/directory configuration as the controller and does not attempt to translate drive letters or paths. Therefore, it is necessary to configure all members so that they have identical directory and file structures. The driver detects UNC paths and disk volumes that are using the exchange file system and does not replicate them.

File System Issues

FAT-based file systems do not support ACLs. If you synchronize or deploy from a server that uses a FAT file system to a server that uses NTFS, the files copied to the target will inherit the access control lists (ACLs) from the parent target where they're written on the target. In the case of file synchronization from an NTFS source to a FAT target, the synchronization or deployment will be aborted and rolled back and an appropriate error event generated.

Note By default, the global replication definition is set to replicate ACLs. You can turn off this feature in the cluster_name Properties dialog box, and then enable/disable ACL replication in a deployment in the New Deployment Wizard.

If possible, you should make sure that your file systems are homogenous across the cluster. The key issue with mixed file systems is that the granularity of LastModified time, which is 2 seconds on FAT, and 1 second on NTFS. So, if NTFS is the source and LastModified time is an odd number, the file is always replicated, whether or not it has been updated.

The File System driver bypasses most file locking issues by renaming the old version of the file and moving the new version from a temporary location to its final destination. If this operation fails, the driver attempts to repeat this operation several times before stopping that particular write operation and moving on to the next file in its update list.

Metabase Driver

The Metabase driver uses the metabase BaseObject to perform read/write functions and utilizes the existing IIS notification code for change notify. The driver uses all the property identifiers and values in a metabase node to create a signature.

The Metabase driver is granular to the node level; that is, when there's notification of a property change, the driver sends all the properties for that node. For example, if you make a change to the ServerComment for site 1, every property in /W3SVC/1/Root will be replicated (this is not recursive).

During a full-synchronization replication, the driver walks the entire metabase and compares its values to those of a member. Any required settings and attributes are copied to the target.

Note Unless you are using a non-NLB cluster, IUSR and IWAM account information is replicated, as well as the IP addresses associated with the controller's virtual sites.

Registry Driver

The Registry driver supports read/write functions and obtains change notify by using standard Win32 APIs. This driver doesn't use a signature because of the small size of the data to be transferred, and the default configuration of Application Center does not replicate any registry keys. However, you can identify and add registry keys to an application. The Applications view supports navigation through the entire registry down to the key level. Although the browser doesn't display the key's values, this registry path is sufficient for identifying keys and their values for replication purposes.

Note Two things should be noted about this driver. First, it isn't intended to serve as a registry backup solution (for example, it doesn't handle secured keys). Second, the driver doesn't compare key values; it just sends the entire key content.

CAPI Driver

The CAPI driver, via the CAPI2 APIs, uses IIS to interrogate the metabase looking for CAPI certificates and a certification trust list (CTL) that is referenced by IIS virtual sites. Then, it will access the CAPI store to extract the relevant information. After receiving this information, the CAPI driver runs these identifiers through a hashing algorithm to generate a signature. See the Signatures sidebar on the following page. When certificates change, the new information is encrypted with the signature, and then it is replicated to members.

Note By default, IIS server certificates are exportable. However, if you disable this capability, they can't be synchronized to other members. The CAPI driver generates an event for each certificate it can't replicate.

WMI Driver

The WMI driver performs read/write operations via standard WMI functions (for example, put, get, and delete member of instance) and a custom event consumer provider. It also provides change notify. The driver uses the complete text of an object's instance to derive a signature.

The driver is responsible for comparing, and then moving, the Health Monitor and Application Center namespaces. During a full synchronization, the WMI driver compares controller and member signatures; if they don't match, the driver transfers the newer class/instance text to the target server. After the text is copied, the driver stores the class/instance information in WMI.

COM+ Driver

The COM+ driver uses the COM+ administrative APIs for read/write functions and uses object properties to create a signature. The driver is also used for replicating selected COM+ Global Catalog settings. Because the Global Catalog doesn't support change notification, these settings are replicated only when a full synchronization takes place or when a COM+ application is replicated. The driver compares COM+ applications on the source and target servers and synchronizes objects that have changed.

Note Only the New Deployment Wizard uses the COM+ driver, so you can synchronize COM+ applications only by using the New Deployment Wizard.

For more a more in-depth look at COM+ replication, see "Special Cases " later in this chapter. 

Signatures 

Application Center uses signatures to compare files or values.

A file signature is created by taking a set of numeric values, such as file size and attributes, and running these values through the MD5 hashing algorithm to compute a value, which is the signature. Every time a file changes, a new signature gets created. By comparing the new signature to the old, you can assume that the file was changed in some fashion.

In most cases, Application Center uses the last write, file size, and file attributes (except for archived files) to create any required signatures.

Synchronization Reliability

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

There are several scenarios that can cause a synchronization failure. For example, the network disconnection of a single server or having a single target server fail and be unreachable can cause a partial failure but would not cause the synchronization to quit. A complete failure is only likely to happen if there is a cluster-wide network or TCP/IP failure.

Note If the cluster controller fails when synchronization is occurring, the synchronization will fail and the content will not be applied. After you bring the controller back online (or designate a new controller) we recommend that you initiate a full synchronization to ensure that the entire cluster is in synchronization.

Transport Recovery

Application Center uses the existing TCP/IP and DCOM mechanisms for transport recovery if there is a mid-point transfer failure. The only driver responsible for recovery is the File System driver because it implements its own transport.

Apply Time Recovery

Apply time recovery is the responsibility of the individual drivers because it occurs when a driver is writing its data stream. If the target is locked, the driver is responsible for retrying the write. Each content driver determines the retry count and interval for its own data. If the apply can't be done within its retry parameters, the driver skips that set of changes and generates an event notification that's sent to the replication engine.

Each synchronization will have an end state—that is, a degree of success—which generates different events and performs subsequent actions depending on the end state. (See Table 6.1.) A "success" end state occurs when all content is replicated and applied to all the targets correctly. Because changes to content are typically set to automatic synchronization mode, full synchronization will be applied only where necessary.

Table 6.1 Replication Results 

Result

Corrective action

Events generated

Success—All changes are replicated and applied to all servers.

None

Successful replication.

Partial Success—One or more, but not all, servers fail to receive or have changes applied.

Resynchronize the failed items to the targets.

Failure events for specific target(s).

Complete Failure—Every server fails to receive or have changes applied.

Repeat the synchronization.

Failure events for every target.

Note Because the Application Center Synchronization Service runs in a separate process from IIS, even a synchronization failure that requires a restart won't affect the cluster's ability to serve content.

Synchronization Modes and Processing

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

As noted earlier in this chapter, the Synchronization Service, running as LocalSystem, uses the replication engine and its drivers to keep cluster members in sync with the cluster controller. This service operates in one of two basic modes: automatic and on-demand. Each mode determines the timing and scope—members and content—of cluster synchronization.

Automatic Synchronization

By default, the system is configured for automatic updates. Applications will synchronize changes—configuration or content—as they are made, and will do a full synchronization of the entire cluster on an established time interval.

Change-Based Synchronization

When you make changes to the cluster controller, such as changing a member's drain time (a configuration change) or modifying part of an application (a content change), automatic synchronization is started. The changes to the controller are then replicated across the cluster. Change-based synchronization is enabled by the automatic session.

The Automatic Session

When automatic synchronization is first started, a session is created on the cluster controller (for the purpose of illustration, we'll call it the AutoSession). The AutoSession only exists on the controller and its sole purpose is communicating with the replication drivers in order to receive notifications of configuration or content changes. This activity is made possible by the replication engine, which listens for notifications from the replication drivers indicating that a change has occurred in their name space. (You may recall, from "The Replication Drivers" section earlier in this chapter, that each driver is responsible for tracking changes to its namespace[s].)

The AutoSession is a long running session, and it creates all the necessary short-lived synchronization sessions that are required to apply changes to the cluster. When the AutoSession receives a change notification, it creates a new, short-lived session. This new session, which exists on the controller and the members, behaves like any other replication session.

Note Unlike the process described in "Processing Activities During a Full Synchronization" later in this chapter, there is no exchange and comparison of IHave lists, only an Update list is sent to the targets.

The short-lived session only exists for the length of time it takes to complete the synchronization. After the changes are applied to the members, the session is removed.

If there is a failure of either the controller or member, the session is canceled (by either the controller or member). There is no formal retry mechanism for these sessions, except for the hourly automatic sessions that perform a full synchronization.

Warning The settings for interval- and change-based automatic synchronization is combined. As Figure 6.7 indicates, disabling automatic updates also disables hourly full synchronization.

Interval-based Synchronization

During the setup process, Application Center is configured to automatically perform a "periodic full synchronization" of the cluster every 60 minutes (the default interval). A full synchronization of the cluster means that all the configuration settings and all the applications are synchronized to each member.

On-Demand Synchronization

Typically, on-demand synchronization is done when you create a new application or deploy an application. This is a partial synchronization, which is to say that only a selected portion of the controller's content is synchronized, rather than a full synchronization of the cluster. However, you can force a full synchronization of the entire cluster at any time. Table 6.2 summarizes both the automatic and on-demand synchronization options that are available to you.

Table 6.2 Synchronizations Summary 

Synchroniza-tion type

Invoked by

Resources

Target

System applications replicated?

Requires target in synchroni-zation loop?

Automatic: change-based

Enable in cluster_name

Any changed files associated with an application or any changed system settings.

All members in loop.

Y

Y

Automatic: interval-based

Enable and configure in cluster_name Properties.

All applications and system settings.

All members in loop.

Y

Y

On-demand: member

Right-click member_name, and then click Synchronize.

All applications and system settings.

Specified member.

Y

N

On-demand: application

In the Applications view, select the application, and then click Synchronize.

Selected application.

All members in loop.

N

Y

On-demand: cluster

Right-click cluster_name, and then click Synchronize Cluster.

All applications and system settings.

All members in loop.

Y

Y

Note You can alter the default configuration settings at the cluster, controller, and individual member levels through their Properties dialog box. For more information, see "Configuring, Managing, and Monitoring Synchronization" later in this chapter.

Processing Activities During a Full Synchronization

The following processing activities typically take place when the entire cluster is synchronized.

The first thing that takes place is a call from the replication engine to all the drivers, instructing them to walk through their individual namespace (for example, application files and directories, metabase settings, and user-specified DSNs) on the controller and compare this information with each cluster member. The information that's different is then copied to the member and applied.

Note In order to optimize the synchronization process, each driver maintains a token that indicates the time when the driver was last synchronized. When a full synchronization occurs, the token is checked to see if it's already in synchronization or not. If it is, the need for lengthy and resource-consuming content comparisons is eliminated.

There is, of course, more inter-server communication going on than indicated in the preceding summary. Figure 6.4 illustrates the communications and data transfer activities that occur between a controller and member during a full synchronization.

Bb734911.f06uj04(en-us,TechNet.10).gif

Figure 6.4 Controller and member communications during full synchronization 

Before stepping through the major communications and data transfer activities, let's examine the lists that provide the foundation for replication: IHave, Action, and Update.

  • IHave—lists all the current configuration settings and content with their signature that's stored on the cluster controller. 

  • Action—specifies the data that the member needs to be in synchronization with the controller. 

  • Update—contains all the resources that the member requested in its Action list. 

Now let's walk through the main processing activities during a full synchronization. First, authentication occurs between the controller and the member. The user name and credentials for the ACC_ computername account are used in intra-cluster replication, or administrative credentials (user name and password specified in the New Deployment Wizard) are used for inter-cluster deployment. In an inter-cluster deployment, the account must have administrative rights on the target. After inter-server communication is validated, a session is started for all the source drivers, and the replication engine instructs the target replication engine to do the same.

After the target replication engine gets a session running for its drivers, the controller sends its IHave list to the member. The member compares this list to its own IHave list and generates an Action list, which is sent to the controller. This Action list contains all the items that the member needs to be perfectly synchronized with the controller. How does it deal with deletes? The cluster member will note that the IHave list did not contain something that it has, and will delete those items during the apply phase.

The cluster controller does three things in response to the Action list. First, it processes the Action list and creates an update list that is sent to the member. This update list contains the actual items that have been requested in the Action list. For all the drivers except the File System driver, the items are actually included in the Update list.

The following sample illustrates the XML code that you'd expect to see in an IHave list:

<SCOPE TYPE="IHAVE" LAST="0" RESTYPE="FS" ROOT="c:\inetpub" ETAGTYPE="STRONG" 
ITEMSIZE="8810" ENUM="FULL" ITEMCOUNT="2" DIFFUSION="MULTICAST"> 
<NODE SUBPATH="wwwroot" ENUM="FULL"> 
<ITEM NAME="default.asp" ETAG="67ED898" SIZE="345"></ITEM> 
<ITEM NAME="myimg.jpg" ETAG="5656365" SIZE="8465"></ITEM> 
<NODE SUBPATH="Images"/> 
<NODE SUBPATH="Apps"/> 
</NODE> 
</SCOPE> 
<SCOPE TYPE="IHAVE" LAST="0" RESTYPE="FS" ROOT="c:\inetpub\wwwroot" ETAGTYPE="STRONG" 
ITEMSIZE="4" ITEMCOUNT="1"> 
<NODE SUBPATH="Images" ENUM="FULL"> 
<ITEM NAME="image2.jpg" ETAG="463ED898" SIZE="4"></ITEM> 
</NODE> 
</SCOPE> 

During this phase, the replication drivers on the controller copy the updates to a temporary storage location on the member. Then, after all the content has been transferred, the controller signals the target that it's ready to commit the session. When the transfer is finished, the member signals the controller that this phase is complete and it's ready to commit the changes.

Finally, the session is committed and the files and other resources are copied from their temporary location to the appropriate locations on the member. After the member notifies the controller that the commit was successful, the session is ended.

Most cluster synchronization, whether it's interval-based—which is just an instance of a full synchronization—or user-initiated (for example, the manual synchronization of an application), follows the same basic process as the one just described.

Note Some drivers skip one or more parts of this process. For instance, updates to the registry content on the controller generate the UpdateList directly, without going through the IHave/Action phases.

Synchronizing Cluster Configuration Settings

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

During synchronization, Application Center replicates controller and cluster configuration settings to all of the cluster members.

Note During synchronization, a member that is in offline state (for load balancing) is still synchronized to the controller unless you explicitly disable synchronization on that member.

Even if synchronization is disabled on a member, there are certain settings that are still copied from the controller to each member on an ongoing basis. This is done to ensure that every member has up-to-date information about the cluster infrastructure and topology. Some examples of this configuration information are: IP address binding, network adapter information, and server computer names.

See Also: Appendix G, "Managing IIS IP Bindings." 

Replicating Network Settings

The controller replicates several network settings across the cluster, including the following:

  • The load-balanced IP address on the front-end network adapter in a multi-adapter configuration 

  • IP subnet 

  • Default gateway and gateway cost metric 

  • DNS server search order 

  • DNS domain 

  • Primary and Secondary WINS server 

  • WINS node type 

Replicating NLB Settings

In a cluster that has NLB enabled, the controller replicates the following information:

  • The cluster name. 

  • The cluster IP address. 

  • The message exchange period (in milliseconds) between cluster nodes. 

  • The number of messages that can be missed from a node before initiating convergence. 

  • The User Datagram Protocol (UDP) that should be used to receive remote control commands. 

  • A switch that specifies whether or not remote control and enumeration are enabled for the controller. 

  • The start and end port numbers for disabled port rules. 

  • The start port number, end port number, protocol, and affinity for load-balanced port rules. 

Synchronizing Content and Applications

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

When dealing with server content and applications, it's important to realize that Application Center treats everything it serves to clients as an application. An application is simply a collection of all the software resources for a Web site, virtual directory, or COM+ application (for example, Web sites, static Web pages, ASP pages, and components). In the context of Application Center, the Default Web Site created by IIS is an "application" that has specific resources associated with it. An application, then, can also be regarded as a resource manifest or inventory.

This model allows administrators to think of their sites in terms of logical groups of resources, and it can be used to optimize deployment and synchronization tasks.

In the Application Center cluster environment, there are default and user-defined applications; each type of application consists of a collection of resources that are required for an application. Let's start by examining the default applications that Application Center identifies after you create a cluster.

The Default Applications

In addition to the standard Default and Administration Web sites used by IIS, Application Center adds its own administrative site—the Application Center 2000 Administrative Site. This IIS node contains Application Center–specific Web content that is required for the Web-based Administrative client as well as displaying information in the details pane of the Microsoft Management Console (MMC) user interface.

If you look at the Applications view (right-click the Applications node in the console tree), you'll see that a fourth application, AllSites, is listed. Take note of the fact that this application lists the previous three Web sites as its resources, which means that it contains all the metabase information stored in the LM/W3SVC path. This approach ensures that all the applications (and their resources) on the controller are consistently synchronized across the cluster. By providing a single reference point for all the Web site information on the controller, AllSites can be used as a tool to synchronize the entire metabase, either manually or automatically.

Note If you publish a site to the controller, but don't explicitly identify it and its resources as an Application Center "application," the site and it's resources are automatically associated with the AllSites application because the target, Default Web Site, is an AllSites resource.

User-Defined Applications

Application Center lets you define your own applications, which provides a greater degree of granularity than the default applications. It also enables you to accommodate special situations that aren't addressed by conventional Web publishing. Creating a new application is a two-step process that involves naming the new application, and then identifying the resources that are associated with it.

After you name the new application, it appears in the upper part of the Applications view. The application naming convention enforces these rules:

  • Names must be from 1 through 127 characters. 

  • Leading and trailing white spaces are trimmed from the name. 

  • Invalid characters are: ", ', <, and > 

Tip Because a globally unique identifier (GUID) is created for each application, you can use the same friendly name for more than one application. However, this is not recommended because it is likely to create some confusion when managing your applications.

The next step is to use the drop-down list in the lower part of the Applications view and add the resources that you want to have associated with the application.

The following options are available for identifying resource types.

  • All Resources 

  • COM+ Applications 

  • Data Sources 

  • File System Paths 

  • Registry Keys 

  • Web Sites and Virtual Directories 

All Resources

The All Resources category lists all the resource types that are associated with an application when it's highlighted in the upper part of the Applications view.

COM+ Applications

This list displays the COM+ application names that are currently available. By default, Application Center, COM+ (for example, COM+ Utilities), IIS (for example, IIS Out-Of-Process Pooled Applications), and System resources are provided. Resource names followed by Remote Server Names (RSN) are COM+ proxies. In order to change the RSN, you have to run the COM+ administrative tool.

Warning You should never replicate any of the default COM+ applications, for two reasons. First, it isn't necessary; and second, it can result in unpredictable server configurations following synchronization.

Data Sources

This category provides a flat list of system DSNs. These DSNs are stored in the \HKEY_LOCAL_MACHINE \SOFTWARE \ODBC \Odbc.ini\ODBC Data Sources key. DSNs are used to connect applications to databases. That is why they are very important to replicate with the rest of your Web application. However, the preferred way to reference remote databases is via "Connection strings." These connection strings, which are imbedded directly into an ASP page or an application, eliminate the need for DSNs. The DSN driver is supplied to ensure backward compatibility with earlier applications.

Note Only system DSNs can be added to an application, but you can add a file DSN as a file.

Each entry in the Odbc.ini subkey assigns a logical DSN to a set of attributes that includes:

  • The name of the ODBC database server. 

  • The name of the database on the server. 

  • Whether multiple databases are supported. 

  • The type of server (for example, Microsoft SQL Server). 

  • A description of network and connection parameters. 

  • Additional information, such as character set conversions. 

File System Paths

An authenticated user can browse the entire file namespace and select the appropriate paths for the application. Each item that's selected will appear as the full path after it's added to the application resource list.

Registry Keys

The resource enumerator provides the ability to browse down through any of the registry key paths, such as HKEY_LOCAL_MACHINE \SOFTWARE \MICROSOFT APPLICATIONCENTER SERVER, but users are restricted from enumerating the entire hive.

Web Sites and Virtual Directories

This resource list consists of IIS Web sites and virtual directories. Only Web sites and virtual directories are displayed because Web directories and files can be browsed and added via the File System resource enumerator.

Editing Applications

Once you've created an application, you can rename it, edit each resource category, add more resources, or delete the application.

Note Removing a resource only deletes it from the application resource inventory that you're editing; it does not delete the original resource from the disk.

The ability to create and manage your own application definition is especially useful when you want to identify specific resources that change frequently and are common to several Web sites. You can eliminate the need to replicate entire sites by creating a single custom application that contains these resources. This technique also reduces errors, because you are updating resources in one place rather than trying to manually propagate changes in several locations.

Table 6.3 summarizes the alert notifications associated with application resource list editing.

Table 6.3 Alerts for Application Resource Editing 

Title

User notification

COM+ Application Created

A new COM+ application was created with the name: name. The value for name is the COM component.

Resources Not Found

No resources of the specified type could be found to add to the application.

Resource Addition Error

The resource was not added because an error occurred while trying to add the resource.

Application Does Not Exist

The resource was not added because the current application no longer exists.

COM+ Proxy Error

The resource was not added because an error occurred while trying to add the COM+ proxy resource.

Invalid Resource

The resource name is not valid. Verify the resource name, and then try again.

A by-product of the application creation process is the replication definition, which the Application Center synchronization feature uses to replicate content.

The Replication Definition

After you define an application, Application Center transparently creates a replication definition. Application Center accesses replication definitions—which include, among other things, the application name and GUID—to determine exactly what content to replicate from the controller to members. In addition to the definitions that are created when you publish to the controller's Web site or explicitly create an application, there are special replication definitions for two Application Center applications. For illustration purposes, let's refer to these two applications as "SystemApp" and "DefaultRep."

The first application, SystemApp, defines which resources are always synchronized to the cluster, even if a target is out of the synchronization loop. It includes metabase information, such as a pointer to the current controller and a list of members, and has a corresponding replication definition, which we'll call the System Replication Definition.

The second application, DefaultRep, is synchronized only to members that are in the synchronization loop. It contains information such as cluster configuration information, a list of default monitors, and information about network adapter drivers. DefaultRep also has its own replication definition.

Figure 6.5 provides an overview of the interaction among the Application Center applications, a user-defined application, and their replication definitions when an automatic synchronization occurs on a cluster. The resource lists for the user-defined application (Application 1) and the hidden DefaultRep application (Application 2) are merged into a single replication definition. This definition is a union of all the application resource lists on the system, and it's updated every time an application is added or deleted. When the replication engine creates the replication session, it merges the System and Application replication definitions. This design is economical in terms of resources, because it will send all of the data to the targets while only consuming one session between the controller and members.

Note If a member isn't in the synchronization loop, it still receives all of the content description, but it filters out all items except those that are contained in System Replication Definition.

Bb734911.f06uj05(en-us,TechNet.10).gif

Figure 6.5 Using replication definitions to create an automatic replication session 

Note If an application resource is detected as missing (for example, a file was deleted) during synchronization, a 5047 event is fired.

Once an application exists on a server—regardless of how it was created—you can use the New Deployment Wizard to deploy an application (or applications) to one or more cluster members.

Deploying Applications

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

The New Deployment Wizard is a tool that enables you to easily deploy applications from a source server to a specified target. This wizard, like the others you've seen so far, provides a step-by-step method for deploying new content, either within a cluster or to another cluster. The New Deployment Wizard is designed to address the concerns of system administrators who want to maintain a secure, yet usable, buffer between their testing and production environments. (Chapter 8, "Creating Clusters and Deploying Applications," presents a detailed staging and deployment scenario that uses the New Deployment Wizard.)

In terms of processing, content deployment is virtually identical to synchronizing content across a cluster. The New Deployment Wizard uses the synchronization service's replication engine and drivers to move applications from one member to another. The notable difference is that you have to provide administrative-level credentials on the target to launch a deployment.

Let's step through the New Deployment Wizard dialog and examine its processing in detail.

Welcome to the New Deployment Wizard

The first page of the wizard tells you what the wizard does and provides the following warnings:

  • Content and configuration data on the target is overwritten if it's contained in the resource inventory for this deployment. 

  • If the target is a controller, any data that's copied over will be synchronized across that controller's cluster. 

Deployment Target Options

This lets you assign a label to the deployment and specify the target destination. By default, the deployment is labeled with the current time and date stamp; however, you can enter a custom label to make tracking easier. Two target options are offered:

  • A target within the current cluster. 

  • One or more targets on an external cluster. 

Your selection determines whether additional credentials are required—a destination target outside the cluster requires credentials with administrative privileges. If you're deploying within the current cluster, this isn't necessary because you must be connected to, or logged on to, the source as an administrator to deploy content.

Target Authentication

On this page, you must provide credentials for the target. Because you can only provide one set of credentials, they have to be valid for all of the targets that you identify in the next wizard page.

Targets or Controllers

You can build the target list one server at a time, by entering the server name or by browsing the network, and then clicking the Add button. Each time you add a server the wizard contacts the target and verifies that the credentials you previously provided are suitable. If not, the wizard rejects the server as a deployment target.

Note If your deployment target is a cluster member, you will see the Target servers within the cluster page. It is functionally identical to the Target Servers or Controllers page, except that available targets are displayed on screen.

Deployment Content

This wizard provides this page to allow you to specify which applications to deploy. The first option is to deploy the entire server image, which consists of all the content and configuration settings on the source. This choice provides a simple method for creating a backup copy of the controller, if it happens to be the deployment source.

The second option is deploying one or more of the applications that are listed. The wizard builds this list from the master inventory. At a minimum, the list consists of the Administration Web site, AllSites, the Application Center 2000 Administrative site, and the Default Web Site. If any user-defined applications exist on the source, they are displayed as well.

Deployment Options

This page of the wizard offers the following deployment choices:

  • Replicate File and Directory Permissions—You can either leave existing file and directory permissions intact on the target or copy over the file and directory permissions that are in place on the source. 

  • Deploy COM+ Applications—If you're deploying a COM+ application, this flag is necessary because some services on the target will be reset. If this is the case, it may be necessary to restart the target. If you've identified a COM+ application as your source, you have to plan your deployment and the consequences. 

    Note COM+ application deployment is a multi-step process. First, the application is deployed to the target cluster controller. Second, the new application on the target cluster controller is synchronized to the cluster members. The subject of COM+ application deployment is addressed in detail in Chapter 8, "Creating Clusters and Deploying Applications." 

  • Deploy Global ISAPI Filers—This situation is similar to deploying COM+ applications, except that only IIS will be reset, which can potentially affect the entire cluster if the target is the controller. 

    Warning If you're deploying either a COM+ application or global ISAPI filters, some planning is essential, and you need to be fully aware of the potential consequences of such a deployment. 

For a more in-depth look at COM+ and ISAPI filter replication, see "Special Cases" later in this chapter.

Completing the New Deployment Wizard

The final page lets you initiate a deployment by clicking the Finish button. This page provides a pause that gives you a chance to scroll back through the wizard and double-check your selections—just in case you missed something or failed to take into account what will happen.

After you click the Finish button, the deployment is launched and all of the pertinent information is passed to the Application Center Synchronization Service, which does the actual configuration and content copying from the source server to the target server.

Deploying content over a Wide Area Network (WAN) 

A frequent question is whether or not Application Center can deploy content over a WAN—it can—however, we do not recommend using Application Center for WAN deployments.

This position is based on the design criteria that were used for the initial release of the product. During the product design stage, the product team determined that the highest priority was the efficient replication of content and configuration settings within a demilitarized zone (also known as a DMZ perimeter network), which typically involves moving content from a stager to a cluster over a LAN. Accordingly, the Application Center Replication Service, which is the core technology for deployment, is designed to move large amounts of data quickly and securely over a network that is both stable and capable of consistent throughput. In other words, LAN-based replication is predictable.

WAN-based replication on the other hand, involves moving data over a diverse range of WAN links whose stability and throughput capabilities are unpredictable. In the real world, these links can range anywhere from a 56-KB modem connection to an OC-12 line. In this world, a replication system needs to provide transfer restart capability to handle dropped connections and allow the sender to prioritize WAN traffic, and implement bandwidth throttling to accommodate throughput issues. The Site Server Content Deployment System (SSCD) provides many of these capabilities; however, you should be aware that SSCD is designed to handle files and has limited support for configuration replication. (It will replicate a subset of the IIS metabase.)

For the present time at least, we recommend using the Content Deployment System, which is included on the Application Center product CD, as a viable alternative for deploying files over a WAN.

Future releases of Application Center will include the features that are currently found in SSCD.

Special Cases

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

Of the various types of information that is replicated across a cluster, there are some elements that require special handing:

  • User accounts 

  • COM+ components 

  • Global ISAPI filters 

  • Health Monitor configuration items 

Each of these is described in the following sections.

Deploying User Accounts

Although Application Center creates its own account (ACC_ computername) for cluster administration purposes, which is replicated, other user account replication is limited to the IIS default anonymous user account (IUSR_). This restriction is imposed to allow users to install and work with Application Center clusters without requiring a separate domain server for each cluster.

The IUSR_ account that's replicated is the name found at the W3svc node and a replication service does not search down this tree for additional IUSR_ accounts. For scenarios that employ multiple anonymous user accounts, a dedicated domain server is the recommended best practice.

Warning If the IUSR_ account is a Windows domain account, it isn't replicated.

In order to synchronize account information between the metabase and the Security Account Manager (SAM), the user has to change account information, that is to say, the password, by using the SAM.

Deploying COM+ Components

The greatest challenge to deploying components on a cluster is the fact that today's technology locks the DLLs that house objects, making it impossible to rename or update the DLL. Typically, you have to stop all services related to the DLL, copy over the new files, register the new DLL, restart the services and, all too frequently, restart the server.

The COM+ application driver eases the burden of component deployment by stopping the processes associated with the in-use DLL, installing the Windows Installer packages (.msi) file for the application, and restarting the appropriate processes. It's not a perfect solution, but it simplifies component deployment in a cluster by doing most of the work for you.

Note Because there isn't any native support for COM in Application Center, you will have to convert your COM-based applications to COM+ applications.

Before you can deploy COM+ objects (or applications), you have to identify them as an application resource by using the Applications node. At the same time, you have to identify the resources that are associated with the component itself, such as files and registry keys. Although Application Center will allow you to create this application on the controller, it's not recommended; a far less risky approach is creating the application on a stager, and then deploying it to the controller. (For detailed information about COM+ application deployment, see Chapter 8, "Creating Clusters and Deploying Applications.")

Note Unlike Web-based applications, COM+ applications aren't automatically synchronized across the cluster. As you may recall, component replication is an on-demand service because it may require restarting a server.

The COM+ application driver uses information about the COM+ application (by using the Microsoft Installer APIs) to provide a form of versioning for these applications. Because these APIs can enumerate and query a particular application, it's possible to gather Global and Application properties. A hashing algorithm creates a signature from these properties, and the COM+ driver uses this signature to compare versions of an application on the source and target servers.

When you initiate a COM+ application replication, the following sequence of actions takes place:

  • The target compares its application signature to the signature contained in the controller's replication definition, and if they're different it requests the application in its Action list. The COM+ application driver generates an .msi file for the application and uses the File driver to send it to the member. 

    NoteApplication Center uses the ExportApplication and InstallApplication methods of the ICOMAdminCatalog interface to export and install COM+ applications. 

  • Before executing the .msi file and installing the application, user connections are drained and the server is set offline. The main reason for draining connections is to ensure that the DLL is unlocked when it comes time to commit the replication. 

  • The COM+ driver stops the W3svc Service and other services that are listed in the metabase. To obtain a list of all the services that are shut down, from the command line, type: mdutil enum /webreplication

  • The driver changes the command-line property to prevent activation from DCOM calls or Component Load Balancing (CLB). 

  • The driver stops any COM+ applications that are associated with the application that's being installed. 

  • The driver makes a call to a COM+ API with the appropriate install level. (It always installs users and roles.) 

  • The driver executes the .msi file and installs the application. 

  • The COM+ driver restarts the services on the target, including application-related services, IISAdmin, and all Web-related services. 

NoteApplication Center does not search for externally dependent DLLs or executables associated with the COM+ application. These files must be associated with the virtual site, added to an application, or already installed on the target. The COM+ driver is only granular to the application level; all the application components are replicated.

Deploying Global ISAPI Filters

Although global ISAPI filters are replicated with the File driver, special handling is required because the servers require an IIS reset when changes are made to a global ISAPI filter.

Note When a new filter is installed at the virtual site level, IIS doesn't need to be reset.

Like components, global ISAPI filters are replicated by using the New Deployment Wizard. Because global ISAPI filter handling can cause a server reset on the target, the global ISAPI filter deployment option is turned off by default.

Detecting an ISAPI filter change at all levels and taking the correct action on the target server involves parsing the metabase driver's IHave list from the source server and looking for the following cases:

  • A change is made to the global filter load order. In this case no IIS reset is called. 

  • The ISAPI filter file is updated. If a global filter's FilterPath is updated, the file driver detects the change. It will trigger an IIS reset if the change is related to a global filter; if the change is at the virtual site level, no reset is called. 

  • A new ISAPI filter is added. The metabase driver looks for the addition of a filters entry in the W3svc metabase. If a new entry is found, the driver requests an IIS reset; if the change is at the virtual site level, no reset is called. 

  • An ISAPI filter is deleted. The metabase driver looks for the deletion of a filters entry in the W3svc metabase. If a new entry is found, the driver requests an IIS reset; if the change is at the virtual site level, no reset is called. 

The basic processing sequence for implementing any ISAPI filter changes follows the steps used for installing a new global filter:

  • Copy the file and metabase setting to the target. 

  • Before the session is committed, stop IIS (call the equivalent of the IISReset command-line utility to do a reset IIS/stop). 

  • Apply the metabase setting. 

  • Restart IIS (call the equivalent of the IISReset command-line utility to do a reset IIS/start). 

As noted previously, if you make changes to filters at the virtual site level, IIS will not be reset.

WMI/Health Monitor Replication Driver

Most of the Microsoft Health Monitor data resides in the Health Monitor namespace, but data is also stored in the Application Center and Windows 2000 namespaces. Because Health Monitor uses WMI extensively to store the Application Center monitoring policies and other configuration data, this driver is used to handle WMI data.

The nature of WMI data 

WMI is a non-transactional store that can be viewed as an object-oriented database management system (OODBMS). There are objects organized in classes, which in turn reside in namespaces. Classes are part of a hierarchy and they have qualifiers, properties, and methods. They can also have instances that are uniquely identified by a key.

WMI provides an "intrinsic event" notification for changes to classes and instances that the WMI/Health Monitor driver uses to perform full or automatic synchronization.

During setup, Application Center installs the class definitions—contained in .mof files—for events and providers, and then compiles them. Setup also installs and configures the base classes for the monitoring application, Health Monitor.

Driver Architecture and Replication

The WMI/Health Monitor replication driver has its own namespace and supports change notify by using the WMI event consumer provider, which registers the following class events:

  • When a class is created. 

  • When a class is deleted. 

  • When a class is modified. 

  • When a class instance is created. 

  • When an instance is deleted. 

  • When an instance is modified. 

The driver uses temporary consumers for changes in the three different namespaces where the instances/classes to be replicated are stored. Any change notify event triggers an automatic replication.

During a full synchronization, the driver parses the Health Monitor namespace and applies the signature it derives from instance names and property values. After comparing signatures, any newer instance text is copied to the target. The same processing takes place in the Application Center namespace, where instances of Event Filters and classes derived from the configuration base are stored.

Note All the required .mof files are copied to a temporary directory on the target. Then, the WMI/Health Monitor driver compiles these files, puts the new instances in WMI, and commits the session.

Synchronizing Monitor Information

The Health Monitor namespace contains information such as configuration rules, actions, and event filters. There is a System class with a single instance for every computer. Everything else in the hierarchy descends from the System instance. The Health Monitor namespace hierarchy consists of three major nodes: Actions, Non-Synchronized Monitors, and Synchronized Monitors. The latter are Application Center–defined monitors that are used for cluster and member monitoring. These monitors are replicated to all members every time the cluster is synchronized. For more information about monitoring and eventing, please see Chapter 9, "Working with Monitors and Events."

Because some of the configuration settings are specific to individual servers on the cluster, this driver recognizes the difference between cluster-wide and local monitors, and synchronizes only the members to the global monitors (the Synchronized Monitors shown in Figure 6.6). This collection of monitors includes:

  • ApplicationCenter Monitors: The status of specific replication events, and request forwarding initialization. 

  • ApplicationCenter Log Monitors: The size of the Application Center Event and Performance Logging database. 

  • Online/Offline Monitors: The status of the Web server (online or offline). 

  • Processor: Processor utilization. 

  • Web Site Monitors: Result of a request for the default Web page from the local_host

Bb734911.f06uj06(en-us,TechNet.10).gif

Figure 6.6 The Health Monitor monitors that ApplicationCenter synchronizes across the cluster 

Note The Email, Take Server Offline, and Bring Server Online actions are replicated only if they are associated with, a synchronized monitor—also known as a synchronized data group or data collector.

Synchronizing Performance Counter Information

Performance data is provided by a set of performance counters that you add, delete, or modify through the user interface when viewing either a cluster or member performance display. The Application Center namespace stores configuration data for a Performance log consumer and an Event log consumer.

The WMI replication driver replicates all the performance counter classes so that this logging will occur over the entire cluster. Although the driver has to replicate all the classes derived from the Application Center performance configuration base (which records the performance counters to watch), the base itself is a Perfmon provider class whose instances are dynamically created and updated at run time. As a result, instances don't have to be replicated. There is also a counter class that is used for controlling what is actually displayed on the performance display. The driver has to replicate all instances of this class.

Synchronizing Event Information

Eventing is enabled through filters that are bound to event consumers in all three namespaces. The instances that require replication, along with the filter and binding information, are stored in the three different namespaces that the driver is concerned about: Application Center, Health Monitor, and Windows 2000 Events (root\Cimv2).

During synchronization there are more than 90 events fired that provide and record information, warning, or error messages. One example of how you can use this event information is the synchronized monitor (Application Center Monitors) that's installed by default. Select * From MicrosoftAC_Replication_Session_General_Event flags a critical condition and sends out an email notification if the EventID is 5038. This Error event is fired if there is failure during a synchronization session.

Obtaining Replication Event Information

You can use the MicrosoftAC_Replication_Event class and its children to access the extensive data that Application Center collects during synchronization and deployment. The schema for the MicrosoftAC_Replication_Event class is documented in Chapter 9, "Working with Monitors and Events," and detailed event information is documented in Appendix D, "Application Center Events."

See also: Chapter 9, "Working with Monitors and Events," and Chapter 11, "Working with the Command-Line Tool and Scripts." 

Configuring, Managing, and Monitoring Synchronization

Bb734911.spacer(en-us,TechNet.10).gif Bb734911.spacer(en-us,TechNet.10).gif

Application Center enables you to configure synchronization on the cluster-wide and individual member levels. As shown in Figure 6.7, the clustername Properties dialog box for the cluster lets you specify:

  • Whether or not automatic updates are enabled, as well as the time interval between full synchronizations. 

  • Whether or not file and folder permissions are replicated. 

Bb734911.f06uj07(en-us,TechNet.10).gif

Figure 6.7 The RKStager Properties dialog box for configuring synchronization on a cluster 

At the individual member level, you can use the membername Properties dialog box to take the member out of the synchronization loop by disabling synchronization for the member.

Synchronization Exclusions

The synchronization exclusions feature provides increased flexibility by allowing you to synchronize part of a file tree by creating an exclusion list. This list is granular down to the individual file and file extension level.

This feature addresses two common scenarios:

  • First, it isn't necessary to synchronize certain types of files across a cluster. This is particularly true for files which are created dynamically, for example *.log files, and server-specific configuration files such as *.ini files. 

  • Second, there are cases, particularly on a stager, where you don't want to replicate a test site. Through the exclusion list, you can ensure that a vsite's directories/subdirectories are not copied to a cluster, nor across a cluster. However, the vsite's metabase information will be replicated. 

You can create a synchronization exclusions list using by the Synchronization Properties dialog box (Figure 6.8), which is opened by right-clicking the Synchronizations node in the Application Center console tree.

Note You have to create the exclusion list on the target rather than the source system. All files are transferred during synchronization, and exclusions are applied during the apply phase by the target. In cases where an exclusion list exists on both the source and target, the exclusions configured for the target are implemented.

This feature gives you the ability to exclude settings and content from replication on the basis of:

  • File name and path (C:\Samplefolder\Somefile.ext). 

  • File name extension (C:\Samplefolder\*.ini). 

  • Directory (C:\Samplefolder\Sampledirectory\). 

You can add as many items to the exclusions list as you want, provided that you use the preceding parameters for your exclusions.

Note Exclusion by directory also includes specified subdirectories.

Bb734911.f06uj08(en-us,TechNet.10).gif

Figure 6.8 The Synchronization Properties dialog box for configuring synchronization exclusions 

Note Implemented via a File System driver attribute, the exclusion list can be created at the individual member level.

The exclusions list is a very useful tool; however, it should be used cautiously on any cluster because the list overrides all the default replication settings. There is the potential to completely disable all replication for critical settings and content on a cluster.

Monitoring Synchronization

In addition to displaying real-time synchronization status information on the cluster and controller nodes' details pane (See sidebar). Application Center also provides a Synchronizations node in the console tree where you can view detailed synchronization and deployment information (Figure 6.9).

Replication phases during synchronization 

During synchronization several status messages are displayed in the Synchronizations view that indicate which phase the synchronization is in. These phases and the major activities (Figure 6.4) for each are as follows:

  • Initializing—The source server is starting a replication job. 

  • Scanning—The IHave lists are created on both the source and target(s), the lists are compared, and the target generates an Action list. 

  • Transferring—The Update list is sent to the target, and the required files are copied to a temporary directory on the target. The target notifies the source that it's ready to commit the session. 

  • Applying—The replicated files and configuration settings are written to the target. 

Bb734911.f06uj09(en-us,TechNet.10).gif

Figure 6.9 The Synchronizations node and its details view 

The upper part of the Synchronizations view displays summary information for a synchronization or deployment that's finished. (During synchronization, status indicators show the current stage of the synchronization: reading, transferring, or applying files. The following summary is provided:

  • Start date 

  • Start time 

  • Name (of the deployment; synchronizations default to the cluster name) 

  • Status (success, partial success, or failure) 

  • Errors (number of) 

  • Elapsed time (for the entire synchronization) 

The lower part of the Synchronizations view provides detailed information for a specific synchronization by using a General tab and an Events tab. The General tab displays:

  • The target name. 

  • The synchronization status. 

  • The number of errors. 

  • The number of files (and their total size) that were transferred. 

  • The number of files (and their total size) that were applied. 

The Events tab, illustrated in Figure 6.10, enables you to access event information that's generated for the synchronization. You can view All, Errors Only, Errors and Warnings, or a specific event by providing an event identifier as a filter.

Bb734911.f06uj10(en-us,TechNet.10).gif

Figure 6.10 Detailed error and warning event information for synchronization 

Application Center's Synchronization and Deployment feature set provides a robust tool for quickly deploying complex business applications throughout your organization; these services also ensure that servers in both Web and COM+ application clusters remain synchronized with each other. Additionally, any activity related to synchronization and deployment is easy to monitor and audit.

Bb734911.spacer(en-us,TechNet.10).gif