| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### Configuration

Configuration is defined as the setting up of all the parameters, data, queues, files, and other configuration data needed to run the applications at runtime using the middleware. It can include setting the parameters needed for load balancing, deciding how many threads to include in the thread pool, deciding how many and how big the queues will be and how overflow will be handled, and setting global timeout and retry parameters. It will also include the setup of the Directory information and security data (e.g., users, passwords, ACLs, and so on).

Setting up the Directory-As we saw in the last chapter, there are two ways in which entries are created in the Registry. The first way is used when the server is loaded as an executable and executing process. In this case, the server registers itself, and its components using commands the programmer must add to his program. The second way is for the administrator to provide a setup program that registers the server, which in turn registers its components. In this latter case, work is required by the administrator.

The administrator must also maintain the Registry once it is set up. If the component dies or is removed, the administrator has to physically remove the entry from the Registry.

Configuring transaction data-Transaction Server Explorer can be used to configure and administer components, packages, servers, clients, transactions, and security. The administrator can manage transactions from the interface as well as change display parameters, reset the log, and start and stop the DTC.

MSMQ-MSMQ Enterprise Explorer is used to administer MSMQ. It provides a tree view of the logical configuration of the enterprise and by using the tool the administrator can view and modify properties of the enterprise, sites, computers, queues, and connected networks. Sites, CNs, and PECs are all displayed from the root of the enterprise, and each site contains a view of the available servers, routing servers, and computers, each of which can have one or more queues. MSMQ Explorer also displays all replicated site information.

Setting up the security data-We have already seen how the Security information is created using primarily the User Manager. The table of users, passwords, and public keys is stored with the Registry on each host, and as such must be set up on every machine by the administrator using this utility. Each table holds host-specific information—the users allowed to access that host. This is likely to change in the future with the introduction of the Active Directory, a service I described in the last chapter, as the Active Directory is to hold security data and will be a central store for information, replicated around the network.

### Event/Problem Monitoring, Capture, and Diagnosis

Event or problem monitoring is the monitoring of the application, machines, network, and system software in order to capture “events” things that have happened in the system whether these are errors/faults or simply things needing a warning message or information message. The term event is intended to cover all sorts of events—security events, application events, operating system events, middleware events, DBMS events, and so on.

Monitoring the events is the start of the process. The actual aim of the process is to monitor and then capture the events so that the administrator can analyze the information and act on the analysis. By using the information he or she may adapt the configuration, change the installation, change the application design, and so on. In fact, his or her job may simply involve informing other administrators of the problem for them to resolve—the DBMS administrator, for example.

Monitor and capture

The Windows Event log is an important part of the administrator’s toolkit and is used by all the other tools. Windows NT Event logs are kept for each machine. In other words, there is no centralized event log for the entire system, although SNMP can be used to provide this.

We saw in an earlier chapter on security that the Event log is used to record security breaches and violations, but it is also used to record other sorts of event. Each NT workstation or server in fact has three event logs:

  • a system log
  • a security log
  • an application log

The system log is used to record configuration problems, state of services, startup, shutdown, and use of peripherals.

Security events cover successful accesses and failures—cases where access was denied. Security permissions can be set from the appropriate Explorer tool. The audit policy has to be set for each server to specify which actions to audit (objects, users) and which types (success, failure, both).

The application log is used to record application events, which can be for information, warnings, and error messages.

The messages sent to the log all have the type of message, the date, time, source, user, eventid, and computer. Although problems are logged, serious problems are also written to the console.

Diagnosis

Events can be viewed from each Explorer tool or from the Windows NT Event Viewer. Event logs can also be viewed using SNMP links to SMS tools—Netview, etc.

Whereas each Explorer tool displays events only related to that particular tool—MSMQ Explorer, for example, displays events only of type MSMQ—the Event Viewer covers all events but supports sorting, filtering, and searching of events.

Problem resolution

Problem resolution tools are there to help in resolving problems once they have either been identified by the administrator by analysis of the event information, or once they have been identified by the event monitor itself. Thus, for example, the administrator may realize from analysis of the event log that a transaction is caught in a deadly embrace and needs to be terminated manually. In this case, specific functions may be available to help him or her perform this problem resolution task.

Alternatively, the event monitor could, for example, identify that a server process has failed and, using the data, trigger a middleware process to restart the server process automatically.

In the first example, administrator intervention is needed, and the administrator uses the problem resolution tools after he or she has identified a problem exists. In the latter case, the process is entirely automatic, no administrator intervention is needed—all problem resolution is handled automatically.

As we saw, DCOM performs little in the way of automatic problem resolution. There is no automatic fault handling, and those tools there are to support problem resolution are currently somewhat specialized and administrator controlled. The administrator can resolve transactions from the Transaction Server interface, for example, as well as reset the log and start and stop the DTC.

In the future, more facilities are expected in this area. The Zero Administration Initiative, for example, is due to support remote problem diagnosis and resolution.

Previous | Table of Contents | Next