Special Cases | Microsoft Application Center 2000 Resource Kit 2001

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.
NOTE
Application 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.
NOTE
Application 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:

Application Center Monitors: The status of specific replication events, and request forwarding initialization.
Application Center 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.

click to view at full size

Figure 6.6 The Health Monitor monitors that Application Center 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 CenterEvents."

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