Of the various types of information that is replicated across a cluster, there are some elements that require special handing:
Each of these is described in the following sections.
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.
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:
NOTE
Application Center uses the ExportApplication and InstallApplication methods of the ICOMAdminCatalog interface to export and install COM+ applications.
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.
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:
The basic processing sequence for implementing any ISAPI filter changes follows the steps used for installing a new global filter:
As noted previously, if you make changes to filters at the virtual site level, IIS will not be reset.
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.
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:
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.
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:
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.
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.
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.
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."