Remote Diagnostics with Systems Management Server Version 2.0

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Updated : July 24, 2001

Published February, 1999

Abstract

The status system and remote tools provide administrators with the ability to easily isolate and troubleshoot Microsoft® Systems Management Server version 2.0 problems quickly. This paper outlines the process flow of the Systems Management Server 2.0 status system and details about remote tools to help administrators more clearly understand the Systems Management Server 2.0 system and how it can be used, tuned, and configured. Information on other troubleshooting tools included with Systems Management Server 2.0 such as Netmon and Healthmon will be covered in future white papers.

Introduction

Microsoft® Systems Management Server version 2.0 is a complicated mix of components and services that can be configured to provide organizations with a scalable, high-performing system that helps administrators manage their entire enterprise. However, this complication and control never comes without some price—specifically, for optimal function, administrators need to know how to troubleshoot the system. Systems Management Server 2.0 has been designed with a variety of tools to help the administrator isolate and resolve systems problems quickly.

The Systems Management Server 2.0 status system monitors and reports the overall state of a Systems Management Server site and hierarchy. Remote control allows the administrator to connect to user machines without leaving the comfort of their control room chairs.

This paper focuses on two specific system tools:

Systems Management Server Status System
Remote Tools

Understanding the Status System

The Systems Management Server version 2.0 status system monitors and reports the overall state of a Systems Management Server site and hierarchy. This functionality makes it a valuable tool you can use to assess the health of your Systems Management Server system. You can view continual site checkups that make you aware of the functional status of your site. Due to the speed of the status system, you can be notified of problems before they become critical and you can discover the source of problems that do occur.

Because the Systems Management Server status system has already been configured to provide you with the important data you need to troubleshoot your Systems Management Server sites, most of this paper explains in detail how the status system works. Then, the paper concludes with an explanation of how to maintain and tune the status system for your organization's specific needs, how to resolve common problems using the status system and, finally, how to integrate the status system with third-party management solutions.

Changes Since Systems Management Server 1.2

Like many areas of Systems Management Server 2.0, the status system has been significantly rewritten to meet the needs of our customers. The status system is now the common reporting mechanism for all Systems Management Server 2.0 components (client and server alike).

One of the common problems of Systems Management Server version 1.2 status was the lack of administrator control and access to status messages. To resolve this, the Systems Management Server 2.0 status system allows administrators full control over the flow of status messages through the system as well as how those status messages are processed. In addition to the status message configuration options, the status system user interface has been totally redeveloped.

Automated consolidation of status messages has been added to help administrators isolate problems in real time. These automated consolidation mechanisms, also called summarizers, examine incoming status messages as the site server receives them. The summarizers compare the messages with other Systems Management Server data and then update persistent tables that the administrator can view through the Systems Management Server Administrator console.

As administrators find problems, they can drill down on a summarizer to view the exact Systems Management Server feature, service, server, or component that is causing the problem. Once the problem has been located, administrators can continue examining deeper into the problem by viewing status messages or by simply launching remote tools and handling the problem via remote control or by using other mechanisms.

One problem that plagued users with Systems Management Server 1.2 was the lack of exposed functionality to edit, copy, and delete status messages within the user interface. In Systems Management Server 2.0, the Systems Management Server Status Message Viewer provides more viewing facilities and control over status messages than any other message viewer released by Microsoft to date. The Systems Management Server Status Message Viewer automatically filters on components requested by the administrator, allows for drag-and-drop customization of columns, and provides tool tips, complex filtering, and search facilities. The new viewer also has a variety of export mechanisms that help administrators isolate problems far faster than the viewer provided with Systems Management Server 1.2.

Lastly, the Systems Management Server 2.0 status system has been designed to give higher performance and be more scalable than the Systems Management Server 1.2 status system. Automated aging and deletion, summarization, replication, and filtering of status messages all make the Systems Management Server 2.0 status system functionality a vast improvement over Systems Management Server 1.2.

Understanding Status Messages

Systems Management Server 2.0 uses status messages to report information about the health of your site. Status messages can be generated from both client and server components and are different from the Microsoft Windows NT® operating system events. You can also configure Systems Management Server components to report only certain types of messages based on their severity and/or type. You can specify status filter rules that determine whether they are replicated to the parent site, written to the Systems Management Server site database, reported to the Windows NT Application Event Log, or if a custom application is executed with command-line parameters. You control where messages are written; be it to all four places or any combination of destinations you require.

A status message is similar to a Windows NT Event or a message written to a log file. Systems Management Server components generate status messages as they carry out their tasks. Both server and client components generate status messages. However, server components report many more status messages than client components for the following reasons:

Systems Management Server servers perform significantly more work than clients do.
If something malfunctions at a Systems Management Server client, it has little impact on the rest of the organization.
If a Systems Management Server server malfunctions, the impact on the organization can be quite extensive.

Similar to a Windows NT Event or a message written to a log file, a status message is a text message generated at a particular time by a particular component.

There are two broad categories of status messages:

Flow-of-Activity Messages

Components generate flow-of-activity messages to illustrate the tasks a component is carrying out. These messages:

Educate the administrator about the tasks the component performs.
Facilitate the debugging of complex problems.
Facilitate the auditing of Systems Management Server activity.
Contribute to reports and summaries showing the overall health or progress of a specific Systems Management Server feature.

Exceptional Messages

Components generate exceptional messages when they encounter a problem performing a task. These messages warn you about a problem that requires your attention.

Status Message Characteristics

Status messages have several characteristics that help you identify the types of activities occurring at your sites.

Message Severity

Every status message is stamped with a severity that indicates the gravity of the information presented in the message.

Error Messages

Error messages occur when there are problems that require immediate administrator attention. Typically, an error message means that a component cannot recover from or work around a problem. As a result, one or more Systems Management Server features may be nonfunctional until the administrator corrects the problem.

Warning Messages

Warning messages are generated when potential problems occur that may require administrator attention. Typically, the component is able to work around these problems.

Informational Messages

Informational messages are usually flow-of-activity messages that illustrate the activities of a component during normal, successful operation. Informational messages might also indicate problems if the problems are relatively unimportant. For example, if a component fails to connect to a computer using one account, but there are three other accounts it can try, the failure is reported as an informational message. If all of the accounts fail, the component might report a warning or an error message.

Message Type

In addition to message severity, status messages can be one of the three following types.

Milestone

When Systems Management Server components complete complex operations, milestone messages indicate successful or unsuccessful completion. If the operation is successful, the milestone message will be informational. If the operation is unsuccessful, the milestone message will be either a warning or an error message.

Detail

Detail status messages illustrate steps in complex operations. Often, they are meaningful only within the context of the sequence of status messages representing a complex operation.

Audit

Audit status messages provide an audit trail of actions that you take in the Systems Management Server Administrator console that result in objects being added, modified, or deleted. All audit messages are informational messages.

Message Date and Time

Knowing how date and time are displayed with status messages helps you to monitor and troubleshoot the system. Systems Management Server stamps every status message with the system date and time that the message is reported, down to millisecond resolution.

You can configure the Status Message Viewer to display time in either local time (the local time zone the Status Message Viewer is running in) or Greenwich Mean Time (GMT). You can use GMT to debug problems in a Systems Management Server hierarchy that has multiple sites in different time zones. It is easier to determine how events happen relative to one another when they are both reported in GMT.

Other Message Characteristics

There are other status message characteristics that help you identify the source of status messages within your Systems Management Server hierarchy.

Source

Server components, client components, or the Systems Management Server Provider can generate status messages.

Site Code

The site code that reports the status message is included with each message.

System Name

The system name is the name of the computer that reported the status message.

Component Name

The component name lists the name of the component that reported the message.

Optional Properties

Each status message can contain one or more optional properties. The current possible optional properties include Collection ID, Package ID, and Advertisement ID. For example, when the Available Programs Manager (a client component) reports a status message that it received an advertisement, the Available Programs Manager attaches an optional property to the status message that specifies the Advertisement ID.

Optional properties provide a consistent mechanism for different components to report status messages about particular Systems Management Server objects such as collections, packages, and advertisements. These properties also provide a means for you to run queries about specific objects.

Miscellaneous Characteristics

Each status message also includes the process and thread ID of the process and thread that reported the message. Some status messages contain additional information such as an error code reported by the operating system. In this case, Systems Management Server displays the exact error code reported by the operating system as well as the text for that error code, such as Access is denied (error code 5).

Status System Architecture

To help troubleshoot problems with the Systems Management Server status system, administrators must first understand how the system works. This allows them to not only understand how to configure the status system to best fit their needs, but it also allows them to come up with creative solutions that best work with the processes they currently have in place.

Within this section, how status messages are generated and flow up the hierarchy are explained in detail. Status message flow breaks down into four distinct categories:

Client Component Flow
Client Access Point Flow
Server Component Flow
Status Manager Flow

Client Component Flow

Client components with Systems Management Server 2.0 have been instrumented to report a wide variety of status messages. Status messages generated by client components are controlled via the "Status Reporting Properties." You configure how components report status messages by navigating to Component Configuration in the Systems Management Server Administrator console.

remotea

After you click Component Configuration, you can set client-reporting properties by selecting Status Reporting in the details pane and right clicking. Then click Properties.

Reporting properties tell client components what type and severity of messages should be reported to Status Manager and what status messages should be converted to Windows NT events.

The diagram above outlines the basic flow of status messages from the client machine to the client access point (CAP).

Client components process status messages they intend to generate based on the Client Reporting Properties that have been set up by the administrator. If the client component is supposed to convert the status message to a Windows NT event and if the client is a Windows NT-based system, then the client component generates a Windows NT event corresponding to the status message being processed.

If the client component is supposed to report that status message to the Status Manager on the site server, then it attempts to create a SVF (Status Message Varfile). This file is placed in one of three directories: %systemroot%, %Temp% or %tmp%. Once created, a request to Copy Queue is initiated so that the file can be copied from the client machine to the CAP. If the status system fails to instruct Copy Queue to move the file, it deletes the file and logs an error to the component's log file, and the status message is lost. If the status system succeeds in instructing Copy Queue to transfer the file, Copy Queue guarantees that the status message is eventually delivered to the CAP. Copy Queue also guarantees that the status message is delivered to the CAP in reported date order (oldest first).

Client Status MIF Flow

Many software programs produce a Status MIF file on success or failure of the installation of that software on a client. The Advertised Programs Manager collects the Status MIF, converts it to a status message, and processes it according to the Status Reporting configuration as specified in the previous section.

remote2

For example, when the Systems Management Server Installer installs packages on clients, it generates a Status.MIF on behalf of the software it installed. This file is placed in the directory determined by the %TEMP% variable or if no user is logged on or TEMP is unavailable, then in the %windir% directory. Other applications can create a MIF file via ISMIFxx.DLL, or they can use their own custom processes to create a MIF. Applications that create a MIF can call the file whatever they want as long as the extension remains *.MIF. If the application doesn't give the file a name and it uses the ISMIF32.DLL or ISMIF16.DLL, then the filename is the same as the application generating it (ex. Setup.MIF). This file contains various attributes about the package (like product, version, manufacturer, etc.) and status information about the package. An example of status information in the Status.MIF is displayed below:

START GROUP
 NAME = "InstallStatus"
 ID = 2
 CLASS = "MICROSOFT|JOBSTATUS|1.0"
 START ATTRIBUTE
 NAME = "Status"
 ID = 1
 ACCESS = READ-ONLY
 STORAGE = SPECIFIC
 TYPE = STRING(32)
 VALUE = "Failed"
 END ATTRIBUTE
 START ATTRIBUTE
 NAME = "Description"
 ID = 2
 ACCESS = READ-ONLY
 STORAGE = SPECIFIC
 TYPE = STRING(128)
 VALUE = "The file c:\temp\Readme.txt could not be opened."
 END ATTRIBUTE

In this example, the InstallStatus is failed because The file C:\temp\readme.txt could not be opened.

The Systems Management Server Installer in Systems Management Server 2.0 can report on more than four times the failure messages than it could in Systems Management Server 1.2.

Potential Problem Areas

There are a few potential problems that can occur when obtaining status messages from a client. If you are not receiving status messages from the client as you expect, then you might want to check some of these:

The status messages received at the site server from clients are determined strictly by the status reporting level configuration. If you have configured the status reporting levels incorrectly, it could either "flood" your system with client messages or prevent important status messages from arriving at the site server. Check the Client Status Reporting Level to ensure your site has been configured to deliver status messages at the granularity that you require.

If the Advertised Programs Manager (APM) has been stopped or if it is not operating correctly, then it is not able to use status MIF files to generate status messages (APM still generates a status message for its own operation.) This would not only prevent any status information from being generated by packages, but also prevent it from executing packages. Check to ensure that Advertised Program Manager is operating correctly.

If the client's disk is full, it could prevent either MIF files from being generated or *.SVF files from being created by Advertised Programs Manager. Check to ensure that disk space is as expected.

The Windows NT event log could fill up with status messages if the status reporting level has been configured to convert status messages to Windows NT events. Check to ensure that this is the setting that you desire and that the Windows NT event log has been configured for "Event Log Wrapping—overwrite events as needed." Alternately, you could also increase the size of your Windows NT event log if you want to maintain more Windows NT events.

If Copy Queue is not running, then *.SVF files may accumulate on the client machine. Ensure that Copy Queue is running properly so that *.SVF files get copied to the CAP.

Client Access Point Flow

Once the SVF file has been copied to the CAP, this file must be transferred to the Site Server for processing. All SVF files are stored on the Client Access Point in the Status Manager's Inbox (CAP_<Sitecode>\Statmsgs.box\*.SVF).

There are two ways this file can be transferred:

If the Client Access Point is a Windows NT-based system, then the Inbox Manager Assistant running on that system copies the file to the Status Manager's Inbox directory on the Site Server (SMS \Inboxes\Statmgr.box\statmsgs\*.SVF).

If the Client Access Point is not a Windows NT-based system (NDS or NetWare system), then the file is transferred in a different way. The Inbox Manager on the Site Server polls all non Windows NT-based systems within that site periodically looking for SVF files. If new ones are found, they are transferred to the Status Manager's Inbox on the Site Server.

Potential Problem Areas

There are a few potential problems that can occur when obtaining status messages from a client access point. If you are not receiving status messages from the clients as you expect, then you might want to check some of these:

If the client access point is not available, then status messages cannot be copied to it from the clients and Inbox services cannot transfer them to the site server. Ensure that the server that the client access point is on is online and that the configured CAP is available via the network.

If inbox services (Inbox Manager Assistant or Inbox Manager) are not operating properly or have been stopped, then *.SVF files can accumulate on the CAP.

If the disk space on the CAP fills up, then status messages from clients can accumulate on the client. The Copy Queue service continues to try and transfer these messages to the CAP until the problem is resolved.

If the network is down, all transfer services fail to copy status messages (*.SVF files) to or from the CAP. This can cause these files to accumulate on servers and clients until the problem is resolved.

Server Component Flow

Server components process status messages exactly like client components, except that messages are transferred between servers directly instead of via a client access point. Any server component that generates a status message uses the Server Component Status Reporting Properties settings to determine the type and severity of messages that should be processed and how. This is configured via the Status Reporting Properties dialog box under Component Configuration. The top section of the dialog box applies strictly to server component configuration while the bottom section applies only to client components.

Just like client components, if the status reporting rules indicate that the status message being processed should be converted to a Windows NT event, it will. However, if the status message is configured to be reported to Status Manager, then the processing is completely different.

There are two types of server components: Thread components and standard service components. Originally, when Systems Management Server 1.0 was being written, Windows NT 3.1 had a problem handling a large number of services. To resolve this, a number of services were implemented as "thread components" of Systems Management Server Executive. This has the advantage that the server components implemented as thread components could pass information quickly between themselves since they all shared the same process space. It also meant that these services had the disadvantage that if the Systems Management Server Executive was stopped as a service, so were all the other services.

Since Status Manager is also a thread component of Systems Management Server Executive, it is able to communicate more directly with other thread components. For this reason, any server component that is a thread component on the site server can simply append any status message generated to Status Manager's in-memory FIFO queue. If for some reason the in-memory FIFO queue becomes backed up, the in-memory FIFO queue spools new status messages as SVF files into a directory (\SMS \Inboxes\ statmgr.box\queue).

If the server component is on the site server and it is not a thread component of the SMS Executive, then it is required to create an SVF file in the Status Manager's Inbox directory. If for some reason, like a permission problem, the server component cannot write the status message to this directory, it logs an error in the component's log file and that status message is lost.

Additionally, if the server component is not on the site server, then that server component attempts to create an SVF file in the Status Manager's Inbox directory on the site server (over the network). If for any reason the server component is not able to create this file, it creates the SVF file in that machine's System32 directory (%systemroot%\ system32\ smsmsgs\<componentname>\*.SVF). Once created, the service continues its attempt to recopy the file to the Status Manager's Inbox on the site server until it succeeds. If for some reason, the server component cannot write to any directory, then it logs an error to the component's log file and the status message is lost.

Potential Problem Areas

There are a few potential problems that can occur when obtaining status messages from server components. If you are not receiving status messages from server components as you expect, then you might want to check some of these:

Obviously, any server component that is not running cannot generate status messages. If you are not receiving status messages from a server component as you expect, check to ensure that it is installed and running as expected.

Like client components, status messages from server components are controlled via the server status reporting levels. If these reporting levels are set incorrectly, it could increase or decrease the granularity of status messages you receive.

If the server's disk becomes full, it could prevent *.SVF files from being created by the server component. If the server component is trying to create *.SVF files over the network to the site server, it temporarily puts these files in a directory called %systemroot%\ system32\ smsmsgs\ <componentname>, where <componentname> is the same as the server component that is trying to create the *.SVF files. This same process occurs if the network is currently down. Note that if the server component is running on the site server and the site server's disk is full, not only will you lose status messages (since the *.SVF files cannot be created), but your site server will have other problems outside of status.

Status Manager Flow

When all client components and server components have generated their status messages, these messages will be in one of two places:

In the Status Manager's Inbox (SMS\Inboxes\Statmsgr.box\statmsgs\*.SVF)

In the Status Manager's in-memory queue

Status Manager picks up and processes these messages one at a time using Status Filter Rules that have been configured for the site. There are several pre-configured status filter rules, and administrators can also configure their own. To create and modify status filter rules, navigate to Status Filter Rules in the Systems Management Server Administrator console.

remoteb

Then, right click Status Filter Rules, select New, and click Status Filter Rule.

Status Filter Rules allow the administrator to control the following actions that can be performed on each status message as it is processed:

Write the Status Message to the Systems Management Server site database. If this option is set, the Status Manager writes the message to the Status Message table in the Systems Management Server site database. By default, status messages are only maintained for seven days. However, if administrators feel the message is higher or lower in priority than the default, then they can change the frequency to meet their needs. After this amount of time, the status message is purged from the status message time. This gives the administrators far more granular control over how long specific messages are maintained than in Systems Management Server 1.2.

Report the Status Message to the Windows NT event log. Status Manager first examines the Status Reporting Configuration for Server and Client components. If they are configured to write this message to the Windows NT event log, then it ignores this rule. However, if they are not configured to do such, then the Status Manager writes it to the Windows NT event log. This prevents the Status Manager from duplicating Status Messages within the Windows NT event log.

Replicate to the Parent Site. If configured to replicate the message to the parent site, Status Manager creates an SVF file in its outbox (SMS\Inboxes\Statmgr.box\outgoing\*.SVF) and initiates a call to Replication Manager to copy the status message to its parent's Status Manager Inbox.

Run a program. Status Manager can execute an administrator-defined batch file or executable and give it any number of the more than 50 command-line options available. For more information on command-line parameters, see Integrating the Status System with Third-Party Solutions later in this document.

Do not forward to Status Summarizers. Status summarizers receive a copy of the status messages that they require (based on Status Filter Rules in the Site Control File). If administrators do not want a specific message copied to the in-memory queue for a summarizer, then they can set this option in the Status Filter Rule to prevent it from being summarized.

Potential Problem Areas

There are a few potential problems that can occur when processing status messages at the site server. If you are not receiving status messages from Status Manager or if you feel Status Manager is not processing status messages as you have configured it, then you might want to check some of these:

If no *.SVF files are being copied to the Status Manager's Inbox, obviously it will have nothing to process. See the other explanations for flow to understand what can prevent these files from reaching the site server.

Obviously, if Status Manager has been paused or stopped, then no status messages are processed. Always ensure that Status Manager is running.

The Windows NT event log could fill up with status messages if there are rules configured to convert status messages to Windows NT events. Check to ensure that this is the setting that you desire and that the Windows NT event log has been configured for Event Log Wrapping. Alternately, you could also increase the size of your Windows NT event log if you wanted to maintain more Windows NT events.

No status messages can be written to the status message table if the database is full. (SQL Server™ 7.0 has a feature for auto-expanding databases and transactions logs.) When writing status messages to the database, the rule sets an age when each status message will be purged from the database. If you set this value too high, you could inadvertently fill up your database with status messages. It is recommended that you only keep advertisement status messages for over seven days and let all other status messages age out within seven days. Status summaries maintain the counts even if the status messages have been purged. Try to keep only the status messages that you would need in the event of a problem occurring.

Status Manager forwards messages to summarizers based on status filters set up in the site control file. If the administrator changes these filters, status summarizers do not receive the status messages they are counting on for normal operation. If you have modified the site control file directly and find that the summarizers are not counting messages correctly, this could be the cause of it. It is strongly suggested that you do not modify the summarizer's filter rules within the site control file.

Although the status system allows you to run an executable when status messages arrive, it is not recommended that you select an executable that takes a huge amount of time to complete. The status system ensures the completion of each activity and then processes status messages sequentially as fast as it can.

When running a program, all status message processing is suspended until that program completes and returns control to the status system. Selecting slow programs slows down the status system processing. Avoid setting up filter rules that execute a program for every status message that is received. Some administrators may attempt to do this to pipe status messages into their company's defined processes. This can be done, but it must be understood that it can dramatically slow down status message processing.

Interpreting the Status System

The Systems Management Server status system monitors and reports the overall health of Systems Management Server sites and site hierarchies. An important feature of the Systems Management Server status system is the ability it gives you to view a snapshot of the status of the site systems, components, packages, and advertisements in your site. You can view these snapshots at different levels of detail through status summarizers.

Status summarizers produce status summaries from status messages and other data in the Systems Management Server site database. Status summaries are not reports, because they are not based on scheduled queries to the site database. Instead, they are produced in real time as the summarizers receive status messages from the other Systems Management Server components.

Systems Management Server includes four status summaries:

Component Status
Site System Status
Package Status
Advertisement Status

Each of the summaries is produced by a unique summarizer thread component, with the exception of Package Status, which is produced by Distribution Manager.

Status Summarizer Concepts

Six important concepts relate to status summarizers and the summaries they produce. These concepts include:

Counts versus states
Display intervals
Status indicators
Thresholds
Launching the Status Message Viewer and other tools
Replication of status summaries up the site hierarchy

Counts and States

Each piece of data in a status summary is classified as either a count or a state. A count is a tally of events that occur over a specific period of time; for example, the number of Error status messages reported by SMS Executive since the beginning of the week. A state is the last known condition of something; for example, the number of free bytes available for the site database.

Each of the status summaries contains some state data. Only two of the status summaries, Component Status and Advertisement Status, contain count data.

Display Intervals

Status summaries containing count data tally events over a specific period of time called a display interval. Each status summary contains several different display intervals; you can view count data using different display intervals to gauge when events occurred. For example, the Component Status summary counts the number of Error, Warning, and Informational status messages reported by the server components at your site. To view the counts for different time periods, select Component Status, right click, select Display Interval, and then choose the period of time you would like to view. After you select a display interval, the details pane displays data based on the display interval you select.

Note: Display intervals are not available for Site System Status and Package Status Summaries, because both of these summaries are based entirely on states.

Each display interval has a start time and an end time that specifies the time over which the counts are made. The start time is the time or date you select as the display interval. The end time is always now, the current time. For example, if the current date and time is Wednesday at 2:32 PM, and you select Since 8:00:00 AM as the display interval in Component Status, the summary displays counts made from Wednesday at 8:00 AM to Wednesday at 2:32 PM. Or, if you select "Since Monday" as the display interval, the summary displays counts made from Monday at 12:00 AM to Wednesday at 2:32 PM.

Both the start time and end time for a display interval are in the time zone of the site server for the site. For example, suppose the site server for your NYC site is on Eastern Standard Time and the site server for your site CHI is on Central Standard Time. If you select Since 12:00:00 AM as the display interval in Component Status, the counts displayed for site NYC will be Since 12:00 AM Eastern Standard Time and the counts displayed for site CHI will be Since 12:00 AM Central Standard Time.

Display intervals that have earlier start times always show counts that are greater than or equal to the counts shown for display intervals that have more recent start times. Continuing the example above, if the current date is Wednesday, the Since 8:00:00 AM display interval always shows lesser or equal numbers of Errors, Warnings, and Informational status messages than the Since Monday display interval. But, if the current day of the week is Monday, the counts are the same.

You can select different display intervals to determine when events occurred in the past. Continuing the example above, if the current time is 2:32 PM, to determine the number of Error status messages reported by the SMS Executive between 8:00 AM and 12:00 PM on the same day, subtract the number of Errors displayed when the "Since 8:00:00 AM" display interval is selected from the number displayed when "Since 12:00:00 PM" is selected.

Status Indicators

Systems Management Server uses three indicators to report the health of server components in the Component Status summary and of site systems in the Site System Status summary. Note that only Site Status (Component Status and Site System Status) uses status indicators. The three states currently supported are:

remote6

Thresholds

A threshold is a limit you set to control when a Warning or Critical status indicator is displayed instead of an OK status indicator. For Component Status, you can specify how many Error, Warning, or Informational messages a component must report before its status indicator is changed to Warning or Critical. For Site System Status, you can specify how low the amount of free storage space can drop before a storage object on a site system is flagged with a Warning or Critical status indicator.

You can view the thresholds configured for components and storage objects by selecting any item in the details pane within Component Status or Site System Status, right clicking, and then selecting Properties.

remotec

Replication of Status Summaries Up the Site Hierarchy

To distribute processing load down the site hierarchy, each summarizer produces a status summary of only its own site. Periodically, each summarizer replicates summaries for both its own site and its child sites up the site hierarchy to its peer at the parent site. On receiving these summaries, the parent site summarizer integrates them into its collection of summaries. Administrators at the parent site can view the summaries for the parent site and all of the sites below it in the hierarchy.

Status summaries replicate up the site hierarchy independent of the actual status messages the summaries are based on. You can configure Systems Management Server to replicate only the status summaries, only the status messages, both, or neither. You can also configure the messages to replicate at different priorities. The configuration you use may have a strong influence on how effectively you can monitor a hierarchy of child sites from a parent site.

Monitoring and Troubleshooting with System Status

The Systems Management Server status system can assist you in both monitoring and troubleshooting your Systems Management Server sites. You can monitor the status of your Systems Management Server hierarchy using System Status in the Systems Management Server Administrator console.

remoted

System Status contains the four status summaries and a collection of general-purpose queries for launching the Status Message Viewer.

This section describes how you can use the status system for monitoring and troubleshooting network problems with Systems Management Server.

Warning: Do not attempt to configure the status system until you have used it for a period of time and you are confident that you fully understand the ramifications of changing the various default settings.

In the following sections, it is assumed that you have navigated to System Status in the Systems Management Server Administrator console and that you can select the particular status summary under discussion. The section below details how you use each of the four status summaries to monitor and troubleshoot your Systems Management Server site and hierarchy.

Site Status

The Site Status item in the Systems Management Server Administrator console tree contains the Component Status and Site System Status summaries for the current site and all of the sites below it in the hierarchy. The Site Status console tree item has three levels: the all-sites level, the per-site level, and the status summary level. The all-sites level contains a rolled-up view of the per-site level, which contains a rolled-up view of the status summary level. The status summary level is composed of the Component Status summary and the Site System Status summary.

remotee

The easiest way to understand the Site Status console tree is to start at the status summary level and work up to the all-sites level at the top.

Component Status

The Component Status summary is a high-level view of the health of Systems Management Server server components at a given site. The details pane includes one row for every server component running at the site. The table below describes the data reported for each component. The table specifies which data are counts and which data are states.

Component Status Details Pane Columns

Column name	Data Type	Description
Status	State	Health of the component: OK, Warning, or Critical.
Site System	State	Name of the site system the component is installed on. (Some components may run on more than one site system.)
Component	State	Name of the component.
State	State	State of the component: Installing, Started (running), Paused, Stopped, or Deinstalling.
Error	Count	Number of Error status messages reported by the component during the display interval.
Warning	Count	Number of Warning status messages reported by the component during the display interval.
Informational	Count	Number of Informational status messages reported by the component during the display interval.
Type	State	Specifies whether the component runs according to a schedule or autostarts (runs continuously).
Next Scheduled	State	Time and date when the component is next scheduled to start, if the component runs according to a schedule.
Last Started	State	Last time and date when each component started.
Last Message	State	Last time and date a status message was received from the component.

Note: To refresh this data, right click on Component Status in the console tree and select Refresh.

The Errors, Warnings, and Info columns tally the numbers of Error, Warning, and Informational status messages reported by each component during the display interval. You can change the display interval by right clicking Component Status, selecting Display Interval, and then selecting the interval you desire.

The display interval for Component Status for one site does not change when you change the display interval for another site. You must specify each site's display interval individually.

You can launch the Status Message Viewer by right clicking a component and selecting Show Messages. The messages you view will be the ones reported by that particular component during the display interval. You can also launch other tools by right clicking and selecting one of the other options.

The status indicator in the Status column represents the health of each component. The status indicator is set based on whether the component has reported enough Error, Warning, or Informational status messages to exceed Warning or Critical thresholds. You can view the thresholds for a component by right clicking a component in the details pane and selecting Properties.

The Status Threshold Properties dialog box specifies Warning and Critical thresholds for Error, Warning, and Informational status messages and the Threshold period. The Threshold period specifies the period of time for which the thresholds are evaluated. For example, if the Threshold period is Since 12:00:00 AM and the Informational messages threshold is set to 100 for Warning and 200 for Critical, then the component's status indicator is set to Warning whenever the component has reported between 100 and 199 Informational status messages since 12:00:00 AM on any given day. The component's status indicator is set to Critical whenever the component reports 200 or more Informational status messages.

Warning: Do not confuse the Threshold period with the display interval. Selecting a different display interval does not change the Threshold period. Because the status indicators for the components are driven from the Threshold period, changing the display interval does not change the component's status indicators either.

You can configure thresholds by navigating to Status Summarizers, selecting Component Status Summarizer, and right clicking Properties.

remotef

You can set the Threshold period on the General tab and the threshold values on the Threshold tab.

Site System Status

The Site System Status summary is a high-level view of the health of all of the site systems at a given site. The details pane includes one row for every storage object (disk drive, database, and so on) used by Systems Management Server for every site system for the site. Table 20.4 describes the data reported for storage objects. As the table indicates, all of the summary data for Site System Status are states.

Site System Status Details Pane Columns

Column name	Data type	Description
Status	State	Health of the storage object: OK, Warning, or Critical.
Site System	State	Name of the site system containing the storage object.
Role	State	Systems Management Server site system role performed by the site system: client access point, distribution point, SQL Server, software metering server, component server, or site server.
Storage Object	State	Path to the storage object if the storage object is a directory that contains files or the name of the database or transaction log if the storage object is a database or transaction log.
Total	State	Maximum amount of storage space (measured in bytes) the storage object can contain.
Free	State	Amount of free (unused) storage space (measured in bytes) for the storage object.
% Free	State	Percentage of free storage space available on the storage object.
Down Since	State	Displays the date and time when the storage object was first found to be down (inaccessible). The storage object is considered down if the site server failed to connect to the storage object due to network problems, security problems, and so on.

To refresh this data, in the Systems Management Server Administrator console tree, right click Site System Status and select Refresh.

You can launch the Status Message Viewer by right clicking a site system and selecting Show Messages. The messages you view are the ones reported by all of the components running on the site system you select. Be careful with this option; if there are many components running on the site system, there might be a large number of messages. You can also launch other tools by right clicking and selecting one of the other options.

The status indicator in the Status column represents the health of each storage object. The status indicator is set based on whether or not free storage space on the storage object was below the Warning or Critical threshold the last time the Site System Status Summarizer polled the storage object. You can view the thresholds set for a storage object by right clicking a storage object in the details pane and selecting Properties. For example, if the Warning threshold is 1024 KB and the Critical threshold is 512 KB, the storage object's status indicator is set to Warning when the free storage space ranges from 513 to 1024 KB. It is set to Critical when the free storage space is 512 KB or less.

You can configure the thresholds by navigating to Status Summarizers in the Systems Management Server Administrator console, selecting Site System Status Summarizer, and right clicking Properties.

remoteg

If the Site System Status Summarizer cannot connect to the storage object to determine the Total and Free storage space, a storage object's status indicator is set to Critical. Network problems, security problems, and so on can cause the Site System Status Summarizer to fail to connect. When the status indicator is set to Critical due to network connection problems, the "Down since" column contains the time and date the connection problems first occurred. This time and date appears in the time zone for the site you are viewing. For example, if you are viewing Site System Status for your NYC site (which is on Eastern Standard Time), the column shows times and dates in Eastern Standard Time.

The Per-Site Level of Site Status

The per-site level of Site Status contains a rolled-up status of the Component Status and Site System Status for a given site. The details pane includes one row for each category of site status: Component Status and Site System Status. The table below describes the data reported in the details pane. All of the summary data at this level are states, as indicated by Table 20.5.

Per-Site Level of Site Status Details Pane Columns

Column name	Data type	Description
Status	State	Overall health of the category of site status for the site: OK, Warning, or Critical.
Category	State	Category of site status: Component Status or Site System Status.
Summary Date	State	Last date that the category of site status for the site was updated.

To refresh this data, right click the site you are viewing in the console tree and select Refresh.

The status indicator for each of the categories is a roll-up of the status indicators in the status summaries for that category of site status. For example, the status indicator for Component Status is set to OK as long as the status indicators for all of the components at that site are set to OK. The status indicator for Component Status is set to Warning if one or more status indicators of the components are set to Warning and if none of the status indicators for the components are set to Critical. The status indicator for Component Status is set to Critical if one or more status indicators for the components are set to Critical.

In the Systems Management Server Administrator console tree, the Component Status and Site System Status folders are overlaid with the status indicator for each category. Also in the console tree, the icon representing the site you are viewing is overlaid with the status indicator from whichever category is more critical. For example, if the status indicator for Component Status is set to Warning and the status indicator for Site System Status is set to Critical, the icon representing the site is set to Critical.

The summary date changes whenever any of the data changes for the category of site status. This happens, for example, whenever the Site System Status Summarizer executes a polling cycle to determine the total and free storage space on all the storage objects at a site. The date also changes whenever the Component Status Summarizer receives a status message from a component, and the count of Error, Warning, or Informational status messages is updated for that component. This time and date appears in the time zone for the site you are viewing. For example, if you are viewing the NYC site (which is on Eastern Standard Time), the column shows dates and times in Eastern Standard Time.

Note: The summary date is particularly important when you are monitoring a child site's status from the parent site. The summary date for a child site is always slightly old due to the delays in replicating the summary data up the site hierarchy. The summary date for a grandchild site is even older. You can adjust the priority at which status summaries are replicated up the hierarchy. If you find an extremely old summary date for a status summary of a child site, the parent site has not received a status summary from that site in a while, and there could be problems in the replication process.

The All-Sites Level of Site Status

The all-sites level of Site Status contains a rolled-up status of the Component Status and Site System Status of the current site and all of the sites below it in the hierarchy. The details pane includes one row per site. The table below describes the data reported in the details pane. The table specifies which data are counts and which data are states.

All-Sites Level of Site Status Details Pane Columns

Column name	Data type	Description
Status	State	Overall health of this site: OK, Warning, or Critical.
Site	State	Site code and site name for this site.
Version	State	Version of Systems Management Server installed on this site, including the Service Pack if one is installed.
State	State	State of this site.
Error	Count	Total number of Error status messages reported by all server components at this site during the display interval.
Warning	Count	Total number of Warning status messages reported by all server components at this site during the display interval.
Informational	Count	Total number of Informational status messages reported by all server components at this site during the display interval.
SMS DB % Free	State	Percentage of free storage space available for the site database.
Trans. Log % Free	State	Percentage of free storage space available for the site database's transaction log.

To refresh this data, right click the site you are viewing in the console tree and select Refresh.

Note: The Site Hierarchy console tree represents the site as a hierarchy of console nodes, but the Site Status console tree item in the Systems Management Server Administrator represents the site hierarchy as a list of console nodes. The Site Status console tree provides no information as to where a site is in the hierarchy; you should obtain that information from the Site Hierarchy console tree.

The status indicator for each of the sites is the rolled-up status indicator produced at the per-site level for each of the sites. In the console tree, the Site Status folder is overlaid with the status indicator from whichever site is the most critical. For example, the Site Status folder is overlaid with an OK status indicator as long as the status indicators are set to OK for all of the sites in the hierarchy. The Site Status folder is overlaid with a Warning status indicator if one or more status indicators for the sites are set to Warning and none of the status indicators for the sites are set to Critical. The Site Status folder is overlaid with a Critical status indicator if one or more status indicators for the sites are set to Critical.

You can determine the health of your site hierarchy at a glance by examining the status indicator applied to the Site Status folder in the Systems Management Server Administrator console tree. If the Site Status folder indicator is OK, all of the components and storage objects in your site hierarchy are OK. If the Site Status folder indicator is not OK, you can browse through the console tree to determine which components and storage objects are not OK. The Errors, Warnings, and Info columns are the sums produced from the Component Status summaries for all of the sites. Just as in Component Status, you can view these counts for different display intervals. For more information, see "Component Status" earlier in this chapter.

You can launch the Status Message Viewer by right clicking a site and selecting Show Messages. The messages you view are the ones reported during the display interval by all of the server components running at the site you selected. Be careful with this option. Depending on the display interval you select, there may be a large number of messages.

The SMS DB % Free and Trans. Log % Free columns are obtained from Site System Status for each site.

Package Status

Package Status provides a summary report of the health of packages and distribution points in your site. In many organizations, administrators distribute multiple packages concurrently to multiple destinations. Package Status allows you to monitor when packages arrive at distribution points. A package must arrive at a distribution point before a client can access, install, or run an advertisement. All dates in Package Status are displayed in the time zone of the machine running the Administrator console.

Package status provides three levels of status information details:

Summary status for all packages in all sites.
Details for a specific package in all sites.
Details for a specific package in a single site.

Summary status for all packages in all sites

When you select Package Status, Systems Management Server displays a summary of the status for each package. This summary includes the status of all distribution points the package has been assigned to in all sites. All values displayed include the current site and any child sites (if applicable). The table below displays the information displayed in the details pane when you select Package Status in the Systems Management Server Administrator console.

remoteh

Package Status Details for All Sites

Column name	Description
Name	Shows the name you assigned the package when you created it in the Systems Management Server Administrator console.
Source Version	Identifies the current version of the package source files, as defined by the originating site. If you are viewing package status at a child site, the version displayed is the one currently in use at the child site. When you specify a new package source directory in the Package Properties dialog box or use the Update Distribution Points option from the Package, Task menu for a specific package, Systems Management Server increments the version number. This assists you in determining whether a distribution point has the latest version of the package source.
Version Date	Identifies the date and time when the version in the Source Version column was created.
Targeted	Displays the total number of distribution points (including child sites) that are specified to have a copy of the package. A distribution point remains targeted until it is specified for removal.
Installed	Shows the total number of distribution points to which the current source version of the package has been previously copied. A distribution point is considered installed until an update, refresh, or removal operation is specified.
Retrying	Displays the total number of distribution points for this package that have had at least one failure during an installation or removal operation, but that have not yet exceeded the number of retries allowed and are currently in an Installation Retrying or Removal Retrying state.
Failed	Displays the total number of distribution points for this package that have exceeded the number of retries allowed during an installation or removal operation and that are currently in a Installation Failed or Retry Failed state.
Source Site	Shows the site where the package originated.
Size	Displays the size of the package source directory.
Compressed Size	Displays the size of the compressed version (if any) of the package source directory. The compressed size is not calculated unless creation of a compressed copy is specified in the Package properties or unless the package is targeted to a distribution point in a child site.
Package ID	Shows the internally assigned identifier for the package. The first three digits are the site code of the originating site.

Details for a Specific Package in All Sites

You can view summary information relative to the sites where each specific package has been sent. The summary that displays when you select <package name> includes information about the package with totals for all sites in your Systems Management Server hierarchy.

remotei

In the table below, the information Systems Management Server displays in the details pane when you select a specific package.

Details for a Specific Package in All Sites

Column name	Description
Site	Displays the site code and site name for each site that has at least one distribution point specified to have a copy of the package.
Source Version	Identifies the version of the package source currently in use at individual Systems Management Server sites. When you specify a new package source directory in the Package Properties dialog box or use the Update Distribution Points option from the Package, Task menu for a specific package, Systems Management Server increments the version number. This assists you in determining whether a distribution point has the latest version of the package source.
Targeted	Shows the total number of distribution points in the sites that are targeted for this package.
Installed	Shows the total number of distribution points in the sites that have successfully installed the current source version of the package.
Retrying	Displays the total number of distribution points in the sites that have had at least one failure during an installation or removal operation, but that have not yet exceeded the number of retries allowed and are currently in an Installation Retrying or Removal Retrying state.
Failed	Displays the total number of distribution points in the sites that have exceeded the number of retries allowed during an installation or removal operation and that are currently in an Installation Failed or Retry failed state.
Summary Date	Displays the most recent date and time when a change in package status for the sites was reported.

Details for a Specific Package in a Single Site

After you view package and distribution point information relative to all sites in your hierarchy, you might want to view the package status for a package in a particular site. You can view package details for a single site by selecting <site code - site name> under a package in the Systems Management Server Administrator console.

remotej

The table below displays the information Systems Management Server displays in the details pane when you select <site code - site name> for a specific package.

Details for a Specific Package in a Single Site

Column name	Description
Distribution Point	Displays the computer name for each distribution point in the selected site specified to have a copy of the package.
Source Version	Identifies the version of the package source currently installed on the distribution point. This column is blank before the package is installed on the distribution point.
State	Indicates which, if any, operation the Distribution Manager component in the selected site has pending or currently underway for the distribution point or if the distribution point is in an idle and ready state. Possible distribution point states are: Installed Installation pending Installation retrying Installation failed Removal pending Removal retrying Removal failed
Last Copied	Displays the date and time when the current package source version for the selected site was last successfully copied to the distribution point.
Type	Shows the site system of the distribution point (Windows NT Server, NetWare Bindery volume, or NetWare NDS volume).
Path	Displays the path that the Distribution Manager component selected to store this package on the distribution point. Note that the syntax used in the details pane is appropriate for the type of operating system in use (Windows NT, NetWare Bindery, or NetWare NDS).
Summary Date	Shows the most recent date and time that any site has indicated a change in status for the selected distribution point in the selected site.

If you launch the Status Message Viewer by right clicking on item in any of the Package Status details panes and selecting Show Messages, the messages you view are the ones relevant to the package you selected.

Advertisement Status

Advertisement Status provides a summary report of the total number of clients that have received and run an advertisement. The table below displays the information Systems Management Server displays in the details pane when you select Advertisement Status in the Systems Management Server Administrator console.

Advertisement Properties Summary

Column name	Description
Name	Displays the name the administrator gave the advertisement when it was created.
Package	Displays the name of the package specified in the advertisement.
Program	Displays the name of the program specified in the advertisement.
Target Collection	Shows the target collection specified in the advertisement.
Available After	Shows the date (in local time) when the advertisement will be made available to clients.
Expires After	Shows the date (in local time) when the advertisement expires and is no longer available to clients.
Advertisement ID	Displays the unique ID that Systems Management Server assigns to each package.

When you select a specific advertisement, Systems Management Server displays summary information by site for the advertisement as shown in the table below.

Advertisement Status Summary

Column Name	Description
Site Type	Displays whether the site receiving the advertisement is a primary or a secondary site.
Site	Displays the site code and site name for the site receiving the advertisement.
Received	Displays the total number of users, client computers, or both in the site reporting successful receipt of the advertisement.
Failures	Displays the total number of users, client computers, or both in the site that experienced an error processing the advertisement or its associated package or that attempted to run the advertised program but failed prior to the program being executed.
Programs Started	Displays the total number of users/and or client machines in the site that were able to successfully start running the advertised program.
Program Errors	Displays the total number of users, client computers, or both that reported errors while running the advertised program. A program is considered in error when it produces either a non-zero exit code or an Install status MIF file with a Failure status attribute.
Program Success	Displays the total number of users, client computers, or both reporting that the advertisement ran successfully. A program is considered successful when it produces either an exit code of zero or an Install status MIF file with a Success status attribute.

If you launch the Status Message Viewer by right clicking an item in any of the Advertisement Status details panes and selecting Show Messages, you can view the status messages relevant to the particular advertisement.

Maintaining and Tuning the Systems Management Server Status System

You configure the Systems Management Server Status System from several locations within the Systems Management Server Administrator console. There are four important configuration areas. The order in which you configure these items is not important.

Status component configuration
Status filter rules
Status summarizers
Deleting status objects

Status Reporting Configuration

You configure how components report status messages by navigating to Component Configuration in the Systems Management Server Administrator console.

remotek

After you click Component Configuration, select Status Reporting in the details pane, right click and then select Properties.

The Status Reporting Properties dialog box enables you to configure which status messages are reported to the Status Manager from server and client components within your site. You can also configure which status messages are logged to the Windows NT event log from this dialog box. For both reporting and logging, you can select the following:

All milestones and all detail messages
All milestones
Error and warning milestone messages
Error milestone messages
Report detail messages on failure

Report detail messages on failure

After a successful operation, components report milestone messages. Then, when a failure occurs, the component also reports the detail messages. Most of the time, you will be interested in only seeing detail messages when you need to debug problems.

Status Filter Rules

Systems Management Server status messages are continually generated by Systems Management Server components. Therefore, it is possible for your Systems Management Server hierarchy to become flooded with status messages. By creating and configuring status filter rules, you can specify how status messages will be processed at the site you are configuring. When the Systems Management Server status system processes a status message, there are five possible types of processing that can occur. Each type of processing results in the message either being discarded or reported to one or more of the following locations.

Systems Management Server site database
Windows NT event log
Parent site
Status summarizers
Passed to an external user-specified program

The following sections explain how to use status filter rules, starting with a description of how to tune status message configuration by using status filter rules. Then, specific information for configuring status filter rules is presented, followed by several examples that can assist you in determining strategies for configuring status filter rules in your sites.

Tuning Status Message Configuration with Status Filter Rules

You can tune and customize how Systems Management Server processes status messages by configuring filter rules. For example, you can configure the system to:

Discard status messages from a component that is flooding the system with the same status message over and over again.

Replicate error status messages to the parent site at High Replication priority and replicate other status messages at Low Replication priority.

Not replicate status messages from the Systems Management Server Client to the parent site while other status messages are being replicated.

Alert you via the net send command when a particular component reports an Error status message.

Keep status messages associated with particular advertisement in the Systems Management Server site database for 30 days and only keep other status messages for 7 days.

Having proper filter rules can make a big difference in how your site performs. After you become familiar with the status system, you might want to tune the system to improve site performance. The following sections give explanations and examples that will help you determine how to configure status filter rules for your site.

When to Use Status Filter Rules

As you begin to observe the number and types of messages being reported through your site hierarchy, you will begin to have questions about how to write filter rules that give you the messages you need. Some questions you might ask are:

Which status messages will I never need to view?

The Status Message Viewer displays the messages that are in the Systems Management Server site database. After you determine which messages you do not want to save and view, you can configure the status filter rules to not write these messages to the Systems Management Server site database and not replicate them to a parent site. This saves database space, processing cycles on the site server, and network bandwidth used in intersite replication.

Which status messages do I need to store in the Systems Management Server site database for a long time?

You can configure the status filter rules to keep certain messages for a long period of time, but to keep other status messages for only a short period of time. For example, from Advertisement Status, you can determine which Systems Management Server clients received a particular advertisement by launching the Status Message Viewer to view the status messages generated when the clients receive the advertisement. If you want to keep a record of those clients for 60 days, you can configure the status filter rules to keep those messages in the Systems Management Server site database for 60 days.

Do I want to view status messages at a parent site that were generated at a child site?

If the answer is no, consider configuring the status filter rules at the child sites to not replicate status messages to the parent site. This will lower the amount of processing done at both the child sites and the parent site and decrease the amount of network bandwidth used in intersite replication. You can prevent the status messages from being replicated and still allow the status summaries to be replicated. This would give you a summary view of information at the parent site. Then, when you detect a problem, you can connect to the child site to view the actual status messages.

Which status messages reported from secondary sites do I need to view?

Because secondary sites do not have site databases or Systems Management Server Administrator consoles, you have to configure status filter rules at secondary sites to replicate messages to the parent primary site if you want to view them. The Status Manager was designed to process several million status messages per day at a primary site that runs on a high-performance computer. Nonetheless, a primary site that has many child sites might get overloaded by all the status messages coming from those child sites. This problem is especially important in child secondary sites, because their messages can be viewed only at the parent primary site.

Configuring Status Filter Rules

You configure status filter rules on a site-per-site basis. To tune status message processing optimally for your site hierarchy, you can specify different filter rules for different sites. The Status Manager is the server component that processes each status message, one at a time, using the status filter rules. Each of these rules contains a list of criteria and a list of actions. When a status message matches the list of criteria, the Status Manager performs the actions specified by that rule. Status messages are processed against each rule, one rule at a time, in the order that the rules are displayed in the Status Filter Rules details pane in the Systems Management Server Administrator console.

The order of the status filter rules displayed in the Systems Management Server Administrator console is significant, because the first rule is always executed first. Then, the Status Manager proceeds down the list and processes each rule in the order it is displayed. If a status message matches a higher-priority rule, the Status Manager performs the actions specified, even if a lower-priority rule does not specify those actions.

For example, if a matching higher-priority rule specifies that the status message should be written to the Systems Management Server site database, the Status Manager writes the message to the site database, regardless of what the lower-priority rules specify. If a matching, lower-priority rule specifies an action that is not specified by a matching higher-priority rule, the Status Manager performs that action. In this way, higher-priority rules override lower-priority rules.

A possible status filter rule action is Do not process lower-priority rules. If a status message matches a rule specifying that action, the lower-priority rules are not processed for that status message. If a status message matches two rules that both specify an action, that action is only executed once. For example, if Rule A and Rule B both specify the Replicate to parent site action, only one copy of status messages matching those rules is replicated.

You can change the priority of a rule by selecting a rule and then right clicking Increment Priority or Decrement Priority. To create and modify status filter rules, navigate to Status Filter Rules in the Systems Management Server Administrator console.

remotel

Then, right click Status Filter Rules, select New, and click Status Filter Rule.

Some choices on the Status Filter Rule Properties dialog box have drop-down boxes. When you click the drop-down box arrow, Systems Management Server queries the site database to determine the possible values. This operation could take some time. If you know exactly which value you want, you can just type it into the box without clicking the arrow. For example, if you know you want the rule to match status messages from the SMS Executive component, type SMS _EXECUTIVE into the Component box. Make sure you type in the correct value. If you misspell a component name or other value, you are not prompted to correct it. The table below explains the various items you can enter on the General tab to filter status messages.

Status Filter Rules General Tab

Item	Explanation
Name	The name you assign the status filter rule. This name appears in the results pane. The name must be unique; two rules cannot have the same name.
Source	The source that reports the status message. For example, Systems Management Server Server (server components), Systems Management Server Client (client components), or Systems Management Server Provider (Systems Management Server Administrator console and any other tools that exercise WBEM to change the Systems Management Server configuration).
Site Code	The site code of the site that reports the status messages.
System	The name of the computer that reports the status message. The system could be a site system or a Systems Management Server client computer.
Component	The name of the component that reports the status message. The component could be a Systems Management Server server component (service or thread), Systems Management Server client component, or a client of the Systems Management Server Provider such as "Systems Management Server Administrator console."
Message Type	The type of message (Milestone, Detail, or Audit).
Severity	The severity of the message (Informational, Warning, or Error).
Message ID	The numeric ID of the status message. You can find the numeric ID of specific status messages through the Status Message Viewer or the Event column of the Windows NT Event Viewer.
Property Name	The optional property present in some status messages, but not in others. For example, most status messages from the Distribution Manager component have a Package ID that identifies the package the message applies to. Alternatively, all Audit status messages have a User Name property that identifies the user who performed the action specified in the messages. To specify a property name, you must first specify a source.
Property Value	The value of the optional property specified by Property Name. For example, if you enter Package ID for Property Name, the Property Value might be NYC00001. If you select the box for Property Name, but do not select the box for Property Value, then the rule will match all status messages that have the optional property associated with them, regardless of the value.

To complete a new status filter rule, you also need to set items on the Actions tab.

Status Filter Rules Actions Tab

Item	Explanation
Write to the Systems Management Server site database	Specifies that status messages matching this rule should be written to the Systems Management Server site database. You must also specify how long the message should be kept in the database by adjusting the Keep message for X days value. The Delete Status Messages task under Database Maintenance in the Systems Management Server Administrator console uses the number of days listed in the status filter rules to determine which messages to delete and when.
Report to the Windows NT event log	Specifies that the status messages matching this rule should be written to the Windows NT event log on the site server. When you select this option, Systems Management Server writes Milestone, Detail, and Audit messages to the Application Event Log.
Replicate to the parent site	Specifies that the status messages matching this rule should be replicated to the parent site, if there is a parent site. You should also specify the priority at which messages should be replicated with the Replication priority value.
Run a program	Specifies that each time a status message matches this rule, the Status Manager should execute the program and command-line arguments specified in the Program edit box.
Do not forward to status summarizers.	Specifies that each time a status message matches this rule, the Status Manager should not forward a copy of this status message to any status summarizer components. You can use this option to throw away messages that are flooding the system. For example, if a server component reports a particular Error status message every 10 seconds that is not relevant for your site, that error will be tallied by the Component Status Summarizer. A long series of these errors in a short time causes the Critical Threshold to be exceeded, and the component is then flagged as Critical (red) in the Component Status summary display. You can set up a filter rule to prevent a particular Error status message from being forwarded to the Component Status Summarizer, which prevents the threshold from being exceeded and the component being marked as Critical.
Do not process lower-priority status filter rules	Specifies that each time a status message matches this rule, the Status Manager should not process any lower-priority rules for that status message. This is a useful way to create rules to delete particular kinds of status messages. For example, if you are not interested in status messages from SMS _ INBOX_MANAGER, you could create a rule that matches all status messages from SMS _INBOX_MANAGER that has no actions checked except Do not forward to status summarizers and Do not process lower-priority status filter rules. Place this rule at the top of the list. The Do not process lower-priority status filter rules action prevents the lower-priority rules from being processed.

Sample Status Filter Rules

Earlier in this chapter, you were introduced to five example status filter rules. This section provides instructions for creating some of these filter rules. Some of these examples might be directly applicable to a problem you face, but others might be less useful to you. By reading each of them, you will gain a better understanding of how to use status filter rules for your organization.

If you decide to use some of these example rules at one of your sites, make sure you examine the existing rules to see the status messages they match, the actions they perform, and their priority relative to your new rules. If your new rules are lower priority than existing ones, the existing rules will be processed before your new rules, and might interfere with what you're trying to accomplish with the new rules. Remember, however, that you can change the priority order.

To configure status filter rules, navigate to Status Filter Rules in the Systems Management Server Administrator console.

remotem

Right click Status Filter Rules, select New, and click Status Filter Rule. Each of the examples below assumes that you know how to access the Status Filter Rule Properties dialog box.

To discard status messages from a component that is flooding the system with the same status message over and over again:
1. Create a new status filter rule.
2. Click on the General tab.
3. In the Name box, enter Throw away status message X from component Y on system <computer name>," where X is the Message ID of the message you want to discard and Y is the name of the component that is generating it.
4. Click Site system. Type the name of the computer the component is running on.
5. Click Component and enter the name of the component, Y.
6. Click Message ID and enter in the Message ID of the status message, X.
7. Verify that no other items are checked.
8. Select the Actions tab.
9. Click Do not forward to status summarizers.
10. Click Do not process lower-priority status filter rules.
11. Verify that no other items are checked and then click OK.
12. In the Status Filter Rules results pane, select the new rule and right click. Select Increment Priority until the new rule is the first one in the list.

This step ensures that the Status Manager processes each status message against this filter rule first. Because the rule specifies Do not process lower-priority status filter rules, none of the other rules have the opportunity to write the message to the Systems Management Server site database, replicate it to the parent site, and so on.

To alert you via the net send command when a particular component reports an Error status message:
1. Create a new status filter rule.
2. Click on the General tab.
3. In the Name box, enter "Alert me when the Inbox Manager component reports any Error status messages."
4. Click Component and select Inbox Manager from the drop-down box.
5. Click Severity and select Error.
6. Verify that no other items are selected.
7. Select the Actions tab.
8. Click Run a program and in the Program box, type the following:
9. C:\Winnt\System32\Net.exe send %sitesvr Component %msgcomp running on computer %msgsys reported the following error: %msgdesc
10. Replace C:\winnt\system32 with the appropriate path to the system32 directory on your site server.
11. Verify that no other items are selected.
12. Click OK.
13. In the Status Filter Rules results pane, select the new rule and right click Increment Priority until the new rule is the first one in the list. This makes sure that the Status Manager processes this rule first, which prevents any of the existing rules from interfering with it. This rule causes any Error status messages processed by the Status Manager that come from the Inbox Manager to pop up as messages on the site server console.

The criteria you specified in the General tab do not include a site code or a system name. Therefore, you will be alerted when the Status Manager processes a status message from the Inbox Manager running on any computer at any site, including child sites. To restrict the alerting to components from a specific computer or site, check the System or Site Code boxes in the General tab as appropriate.

Configuring Status Summarizers

Status Summarizer configuration enables you to determine the specific configuration of each status summarizer. You configure status summarizers by navigating to Status Summarizer in the Systems Management Server Administrator console.

remoten

After you click Status Summarizer, you can select Site Systems Status Summarizer, Component Status Summarizer, or Advertisement Status Summarizer from the details pane.

You can disable any of the summarizers that might not be relevant at any particular time. For example, if you do not intend to send advertisements for an extended period of time, you might want to disable the Advertisement Status Summarizer. However, most of the time, you will want to leave your summarizers enabled, because they provide valuable data.

Another feature includes both replicating a summary to the parent site and determining the replication priority. These are powerful features that can help administrators at parent sites that monitor status at child sites. For component status and site system status, you can also configure the thresholds Systems Management Server uses to determine when to report a warning or an error icon in the Systems Management Server Administrator console.

Deleting Status Messages

Status messages that are written to the Status Message Table (Systems Management Server Database) can be deleted in one of four ways:

Within the Systems Management Server Status Message Viewer, you can select the status messages you want to delete and press [delete]. This is a slow way to delete them as the Systems Management Server Status Message Viewer deletes them one at a time.

You can accomplish the same thing as (1) from Status Message Queries under System Status. Instead of selecting "Show Messages," you can select "Delete Messages." This option deletes status messages that are returned by the query that you created. You can verify what will be deleted by selecting Show Messages to see the complete list of status messages in the Systems Management Server Status Message Viewer.

When setting up status filter rules, you can define a status filter rule for specific status messages and set the action for those as "Write to Systems Management Server Database" and "Keep messages for X days." Using the time frame of your choice for the "X". By default, status messages are maintained for seven days. However, if you have messages you want to keep longer or delete earlier, you can set up a status filter rule accordingly. This option does not work until you have enabled status message deletion under Tasks in the Systems Management Server Admin console.

You enable status message deletion by navigating to Tasks in the Systems Management Server Administrator console.

remoteo

Select Delete Aged Status Messages, right click, and then click Properties. The Delete Aged Status Messages Properties dialog box appears. You can both enable and schedule the deletion process.

Warning: The Systems Management Server status system generates a large number of status messages. Do not change this setting until you take the time to assess the capacity of your database. Then, before you change this option, measure the number of status messages being reported to your site server based on your site characteristics and status configuration.

Resetting the Status Summarizers

Status summaries for Component Status and Advertisement Status maintain their data within the Systems Management Server site database separately from status messages. This has the possibility that summaries could indicate a count of status messages in the database that have previously been deleted or aged out of the database. These persistent summaries allow administrators to see an accurate count of status messages and the state of components, sites, and resources regardless of the contents of the Systems Management Server site database.

Administrators can reset these status counts via the "Reset Summary Counts" option in the Systems Management Server Administrator's console under Component Status or Advertisement Status in the released product of Systems Management Server 2.0.

Status System Performance

The status system is a powerful tool for debugging the Systems Management Server system at your site. However, it is only as powerful as you have it configured. It is possible to configure your site to discard every status message generated and/or not write any status messages to the Systems Management Server site database. The Systems Management Server 2.0 status system has been vastly improved over the Systems Management Server 1.2 status system, and it can process over eight million status messages per day (depending on your configuration and hardware). Administrators have full control over how status messages are stored, forwarded, and processed. However, with all of this control, there are a few guidelines that should be watched while configuring your site.

Take care in launching the Systems Management Server Status Message Viewer.

Although the Systems Management Server Status Message Viewer has been designed to handle a vast number of status messages, the administrator must take care in launching it. It is possible to launch the Systems Management Server Status Message Viewer and ask it to return every status message in the entire database. This could be hundreds or millions of status messages.

The Systems Management Server Status Message Viewer makes a query to the Systems Management Server site database and stores these results in a temporary, memory-mapped file on the local hard disk. This local file allows the viewer to process filtering and searching more rapidly than continually making queries to the Systems Management Server site database. However, it also means that in large queries, it not only can take some time to return the query, but it could also take up more hard-disk space that your local system has open. If you plan to load large queries on a regular basis, it is suggested you set the option for a record limit to avoid filling your local disk drive.

Take care in configuring the client reporting levels.

In a large Systems Management Server Site, the number of clients can be quite large and increasing the amount of status messages received by even one increases the total number received at the site server by an order of magnitude proportional to the number of clients at your site. In a small site, requesting one additional status message from clients could increase the total received at the site server by less than 100. On the other hand, in a large hierarchy with more than 100,000 clients, you could be requesting more than 100,000 new status messages to be returned to the central site.

Until you understand the implications of increasing the status message load on your site, it is recommended that you leave the client component status reporting levels at their default configurations. Increasing these could dramatically increase your network traffic from the clients to the client access points, the amount of incoming status messages copied to the site, and number of status messages replicated up your hierarchy.

Understand the status system before attempting to modify the default status system configuration.

Modifying the status filter rules can have dramatic implications on how status messages are processed, forwarded to parent sites, or discarded. As an administrator, it is highly recommended that you understand the status system flow and the ramifications of changes before you make changes to the status filter rules.

Be careful in setting the startup schedule for the Site System Status.

Under Summarizer Configuration, the administrator can change the default schedule for Site System Status. The default setting for Site System Status is to update resource information (hard disk, SQL and Transaction log space) every three hours. Reducing this startup schedule could increase your site's network traffic, especially if you were to set a schedule to update every five minutes or so. Smaller sites could be unaffected by such a schedule change, while much larger systems could be severely impacted. Site System Status uses a session to connect to the target machines using underlying protocols installed.

Avoid excessive overuse of creating Status Filter Rules that execute command-line applications.

Although the status system can interface with other monitoring and alerting systems by executing command-line applications, doing this should be kept to a minimum. As previously mentioned, executing these files causes processing of status messages to come to be suspended while command-line applications are executed. This can decrease the performance of Status Manager's processing of status messages if overly exercised. In general, executing a command-line application for all error conditions may be tolerable with a site with a moderate status message flow. If you notice that the Status Manager is creating a backlog of *.SVF files in its inbox directory, then you will definitely want to take some tuning measures. Changing filters, component status reporting levels, or how status messages are processed can dramatically affect the overall status system.

Integrating the Status System with Third-Party Solutions

Many third-party solutions that can monitor or manage Windows NT systems either use Windows NT events as their mechanism or SNMP (simple network management protocol) traps to display state information. Since the status system contains much richer information for reporting the health of Systems Management Server components, some information may be lost in the translation to these formats. Some potential problems to take note of:

Windows NT events typically place the service name within the Source Field. Systems Management Server component names are listed within the category name for Systems Management Server Windows NT events. This is because the source for SMS Status Messages are contained with the sources "SMS Server" or "SMS Client" DLLs (dynamic-link libraries).

Systems Management Server status messages are far richer in reporting information and display the flow of activities within the system as milestone and detail messages. Additionally, Systems Management Server status messages may contain optional properties such as "Package ID". Windows NT events or SNMP traps provide no provisions for flow of activity or optional properties within their events.

The Systems Management Server status system has provisions for supporting management platforms that do use Windows NT events or SNMP traps. For any given status message received by the site server, a status filter rule can be created to instruct Status Manager to run an executable or batch file with command-line parameters. Status Manager supports more than 90 command-line parameters that can pass to any command-line application.

For example:

C:\Winnt\System32\Net.exe send %sitesvr Component %msgcomp running on computer %msgsys reported the following error: %msgdesc

Creative Uses of the Status System

Although the status system was designed to specifically monitor Systems Management Server servers and components, it is an easy task to add additional non-Systems Management Server servers for monitoring by the status system. If your organization has servers they want to monitor the disk space on, they can use the Systems Management Server Admin console to add those servers as distribution points for Systems Management Server. By adding these as distribution points, Site System Status begins to monitor the resources on those servers.

Using Remote Tools

This section of this white paper concentrates on a few aspects of the Systems Management Server Remote Tools feature. The basic subset of the Remote Tools themselves (for example, remote control, file transfer, and so on) is fairly well-understood and not much changed from Systems Management Server 1.2. The configuration of the component, however, is dramatically different. Hence, a large amount of this section is given over to a description of how the configuration works.

Aspects of security of remote control and how to maximize the performance are also discussed in detail, since these are often of paramount importance in any Systems Management Server deployment. Some troubleshooting tips are also included.

Changes Since Systems Management Server 1.2

Although the basic functionality of the Remote Tools may not have changed dramatically, a number of areas are sufficiently different to merit a mention of their own.

Site-wide and Local Configuration

The configuration parameters for the Remote Tools Client Agent can be set in the Admin UI for all clients in a whole site. They can subsequently be adjusted individually on each client if desired. Or the clients can be denied the ability to change the settings established by the site administrator, thus establishing a "lock-down" mode on the clients.

How the configuration works is explained in more detail later.

TCP/IP Protocol Support

As well as providing native IP support (for example, not NetBIOS over IP) for Remote Tools sessions, the Remote Tools use TCP based sessions. Use of TCP dramatically improves the reliability of a remote control session, particularly over busy networks or over connections of limited reliability. Routers typically forward TCP packets with a higher priority that UDP (which is the protocol previously used), and the underlying protocol provides guaranteed end-to-end connectivity, and fewer lost connections.

System Tray Indicator

In the past, the remote control agent announced its presence on the client by way of a small window in one corner of the screen containing the remote control icon. This window could not be hidden or minimized and caused a certain amount of irritation. On Microsoft Windows® 95 or Windows 98 and Windows NT version 4.0 and version 5.0 clients, it is now possible to show an icon in the System Tray instead. This has the same characteristics of the icon window in that it changes symbol when a remote control session is in progress and allows the status window to be launched from it, but it is far less obtrusive. It is still possible to display the old icon window if desired.

Performance and Stability Improvements

Use of TCP improves the reliability of remote control sessions as already discussed. Many bug fixes and code rewrites have also improved the overall quality of the feature. Performance has been improved by large changes, such as compression and wallpaper suppression, as well as more hidden improvements in the algorithms used in the client and admin code. Performance and how to improve it is discussed in more detail later.

Configuration

Remote Tools in Systems Management Server 2.0 provides a far wider level of configuration control than was available in version 1.x. Systems Management Server 1.2 had a fixed set of default configuration options, which were implemented on clients when they were installed, and which could subsequently be changed only by sending a "job" to change the .ini file settings. In Systems Management Server 2.0, the default configuration settings for the Remote Tools Client Agent are configured through the Admin UI on a site-wide basis. That is, any changes made through the Admin UI are implemented on all clients within that site.

Once these site-wide settings have been set on clients within a site, a Control Panel applet is available on the client, which allows the configuration settings to be customized on the individual client. A user can choose to accept the configuration settings applied to the site or can change them.

An administrator can also choose to "lock down" the client configuration settings, and not allow users to change them from the site-wide defaults. This forces the same configuration to be implemented on all clients within the site.

Configuration of the client remote control parameters is now held in the Registry rather than in a .ini file.

Configuration Mungers

The flexibility in how the Remote Tools configuration settings can be set are implemented with the help of two configuration programs that run on the clients. These applications are known colloquially as mungers, because they take the settings from a number of registry locations, for example, the location where site-wide settings are held, or the location where the control panel applet stores its settings, and munge them together into a single set of configuration options.

The Hardware Munger (rchwcfg.exe) controls the properties shown on the Advanced tab of the Remote Tools Client Agent Property sheet in the Admin UI. These are the compression algorithm used (Windows NT only), the protocol used, and whether the Windows NT video acceleration should be used (Windows NT only). The hardware munger runs only at the time when the Remote Tools client agent is installed. This means that if any properties are changed in the Advanced tab after clients are installed, those clients do not receive the new configuration settings. For any updated settings to be implemented on a client, it is necessary to rerun the hardware munger with the command-line option install. Thus, the command

rchwcfg.exe install

should be run. This must be run in the local Administrator context to be able to modify the registry. It can be sent as a command-line only Advertisement from the MMC console, in which case it can be set to run in the Administrative context.

One of the properties configured by the Hardware Munger is the protocol that the remote control agent uses. The ability to configure it in this way removes much of the need to specify binding orders, as was required in Systems Management Server 1.x. And there is no need for various tools to configure the binding order on the client.

The Security Munger (rcclicfg.exe) control all the other configuration options. The security munger runs whenever a new set of configuration settings is "pushed" to the client from a site of which it is a member. It also runs whenever the Remote Control applet is run in the control panel and changes are made on the client.

The Registry

To understand the operation of the mungers, it is necessary to understand the Registry keys that are involved in the munging process.

The configuration parameters set in the Remote Tools Client Agent Property sheet are propagated to the client by the client infrastructure, and stored under the Registry key

HKLM\Software\Microsoft\SMS \Client\Sites\

System\

<site code>\

Client Components\

Remote Control

This area is read-only as far as the client is concerned. If the client is a member of more than one site, then there will be multiple Client Components keys under each of the sites of which the client is a member.

One of the jobs of the mungers is to reconcile multiple site membership. This is done according to a set of rules, which normally opts for the most restrictive setting, from a security point of view. For example, if a client is a member of two sites, and one site requires that permission is sought from the client to carry out a Remote Tools operation while the other does not, the munger will opt to use the more restrictive option, that is to require that permission is sought. Each configuration option is reconciled in a similar manner, and the results are placed in the key

HKLM\Software\Microsoft\SMS \Client\

Client Components\

Remote Control\

Combined Sites

Consider this Registry key to be the "staging area" for the site-wide configuration. One of the settings munged in this way is the flag indicating whether to "lock down" the client, the REG_DWORD value is Allow Client Change.

Some of the client configuration for remote control can be set on the client using a Control Panel applet. This allows the visible and audible signal settings as well as the remote control level and Permission Required settings to be changed on the client. The control panel applet uses values in the Registry key

HKLM\Software\Microsoft\SMS \Client\

Client Components\

Remote Control\

User Settings

to store its settings. This can be considered as the "staging area" for the user settings. The applet also looks at the Allow Client Change value shown above. If it is set to zero, then the client is locked down and the applet does not allow any changes to be made. It also displays the site-wide settings.

Once the munger has reconciled the Combined Sites settings, it uses the Allow Client Change value and the Use Local Settings value in the User Settings key (which is controlled by the "Use Administrator Settings" checkbox in the control panel applet) to determine which group of settings to supply to the remote control agent. It does this according to this table:

Allow Client Change = 0	Allow Client Change = 1
Use Local Settings = 0	Combined Sites
Use Local Settings = 1	Combined Sites

The relevant settings are copied from either the Combined Sites or the User Settings staging areas into

HKLM\Software\Microsoft\SMS \Client\

Client Components\

Remote Control\

which is the location read by the remote control agent (WUSER32.EXE). Or looked at another way, it can be considered to be the "working set," as opposed to the "staging areas" previously discussed.

This description shows the operation of the security munger. Not all of the settings are available to the control panel applet, for example, the Permitted Viewers on Windows NT-based clients. The Permitted Viewers written to the working set are always copied from the sites staging area.

When it is run, the hardware munger only deals with the Sites key and writes directly to the Remote Control key. It does not need to use the staging areas.

Disabling the Security Munger

The current implementation of the Remote Tools Client Agent properties allows the same settings to be forcefully applied across a whole site or for all clients in the site to be able to change to default settings. The UI does not allow a subset of users within a site to have more control over the local remote control settings than others do. This is due to the architecture of Systems Management Server, in that client agent properties are implemented on a site-wide basis, and not, say, collection-based.

There are examples where this "all or nothing" approach is not sufficiently flexible. For example, within a single site, you may have a mixture of clients and servers running Windows NT Server and Windows NT Workstation. The Windows NT Servers could be in a locked closet (i.e., no users present). In which case, Remote Control must be allowed immediately with no need to ask for permission. On the other hand, the Windows NT-based workstations are users' machines, containing sensitive data. In which case, it is absolutely necessary to ask for permission before starting a remote control session. As it stands, the only way to implement this is to allow all clients in the site the ability to change their settings. At which point, all of the Windows NT-based servers must be visited to switch off the Permission Required flag. This is not ideal and also allows the users more control over the remote control settings than may be desired.

To overcome this difficulty, a mechanism is implemented that allows the security munger to be disabled individually on clients. In the key

HKLM\Software\Microsoft\SMS \Client\Client Components\Remote Control\

create the REG_SZ value UpdateEnabled and set it to "No." Then, when the munger is invoked, it exits without performing any updates, and that fact is logged to the log file RCCLICFG.INI. This also means that any changes made using the control panel applet are not used. Indeed, this has to be used with great care, because any client with this registry value set no longer participates in any site-wide changes to the Remote Tools Client Agent properties.

In the example presented, the site-wide settings can be set to lock-down clients, and require that permission to remote control clients is sought, then apply the UpdateEnabled value to the Windows NT-based servers, and then change the Permission Required value in the Remote Control key.

Users will not normally be able to implement this registry value themselves on their own clients (in an attempt to circumvent the site-wide policy) as that part of the registry will normally be locked to low rights users.

Security

Of all the operations that Systems Management Server allows you to do on a client, remote control is possibly the most "dangerous" in terms of security. Once an administrator is remote controlling a client, he has as many rights and access to that machine as if he were sitting at it. Added to this, there is also the possibility of carrying out a remote control session without the user at the client being aware of it. Thus, it is important to understand the different security options available and also to understand the legal implications of using some of them in certain jurisdictions.

Visible and Audible Indicators

It is possible to configure a remote control from a state where there is never any visible or audible indication that a remote control session is under way. It has been made this flexible due to customer demands ranging from one end of this spectrum to the other. When configuring the options available in the Remote Tools Client Agent properties, due notice must also be taken of company policy and local laws about what level of unannounced and unacknowledged intrusion is permitted.

Permission Required

Security from unauthorized and unannounced remote control can be controlled by setting the configuration parameter, which requires the user on the client explicitly to grant permission before any of the remote tools are started. Individual tools can also be enabled and disabled, allowing, for example, remote chat and file execute, but not remote control.

Collection-based

It is possible to grant different users access to the remote tools for clients in different Collections. This would allow an administrator to allow most Helpdesk operators to remote control most users' PCs. But by placing certain clients in a specific collection, for example, the HR department, that collection could have a more restricted set of users who are allowed to remote control those clients.

These security rights are set up using the Security Rights node in the MMC. By default, all collections are open to be remote controlled, but these can be changed to restrict the use of this feature more closely.

Windows NT User Authentication

Any attempt to run any remote tools on a Windows NT-based client has to undergo a further level of security. This is implemented at the client. A list of Permitted Viewers is held in the client Registry. When a Remote Tools session is requested from the Admin UI, the user information is sent to the client and compared with the entries in the Permitted Viewers list. If there is a match, then the remote tool is able to run (subject to being granted permission by the client user if Permission Required is set). If there is no match, then a dialog box is presented on the Admin UI, asking for user, domain, and password information. A valid name and password that matches a user in the client's Permitted Viewers list must be supplied in order to proceed.

The Permitted Viewers list is set up through the Remote Control Client Agent Property sheet. The list can include user groups and also fully qualified domain and user/group combinations, e.g., DOMAINNAME\username.

Logging

To provide an audit trail, remote control sessions are logged for the Admin UI and for Windows NT-based clients. On the client, the start and end of the use of each tool is logged in the Windows NT event log, with the user name and machine name of the viewer. It is not possible to mark the endpoint for all of the tools, such as reboot or file execute, but the start is always logged.

On the Admin UI, use is made of the Systems Management Server status system. An Informational status message is sent whenever any of the remote tools are started. Again, the name and machine name of the viewer are logged as well as the name of the machine against which the Remote Tool is being run.

Performance

This section is going to concentrate on performance issues pertaining to remote control of Windows NT-based clients. Remote control of clients running Windows NT uses a raster-based, or screen-scraping, mechanism, rather than GDI hooking used on Windows® 3.x and Windows 95 or Windows 98-based clients. The reasons for this are historical and based mainly on the security that was imposed by Windows NT.

Raster-based remote control is less efficient than using GDI calls and uses greater network bandwidth and more client resources. However, there are a number of techniques that can be used to minimize both and make the performance of Windows NT remote control far more in line with what would be expected. Just as, SQL Server must be tuned for optimum performance, so too does remote control.

Compression

There are two compression algorithms available to use on a Windows NT remote control client: LOW, which used the Run Length Encoding (RLE) algorithm, and HIGH, which uses the Lempel-Ziv (LZ) algorithm.

While it may appear that using the best compression always yields the best performance, this is not necessarily the case. The different algorithms are better at different jobs. RLE compression, by its very nature, is very good at compressing images with large amounts of white space or long runs of the same color. So normal text processing or spreadsheet work would probably compress best using RLE. LZ, on the other hand, is good at compressing repeated patterns, so would perform better if a "busy" wallpaper or bitmap is in use. So depending on the applications most often in use on the client, the compression algorithm should be chosen to best match it.

LZ compression is also a much greater burden on the client. So any gains you achieve by better compression may be offset by poorer client performance.

It is, therefore, recommended that LZ compression is used only where network bandwidth is the overriding factor.

Video Accelerators

Using Windows NT video acceleration is discussed in more detail in the next section. The accelerated video drivers work by sending only delta information of screen updates rather than sending the whole screen image every time it changes. The delta is created by forming the smallest rectangle, which encloses all of the changes to the screen, and sending just that rectangle. This means that if something changes at the bottom right and top left of the screen at the same time, then most, if not all of the screen image must be resent. In light of this, it is best not to run applications such as Task Manager (which constantly updates the CPU usage in the System Tray) during remote control sessions.

Color Depth

Remote Control sends only 256 color images across the network. If the client is running with 256 colors, then the agent has very little work to do in sending updates. If, however, the client has 16- or 24-bit color depth, then for every screen update, the remote control agent must reduce every pixel of the screen image from 16 or 24 bits to 8 bits. This can be a significant burden on the client. The difference in performance, depending on how many colors the client is using, is quite dramatic. For remote control of headless servers, for example, the servers should use only 256 colors.

Memory

Especially when using the video accelerators, the remote control agent can be memory hungry. The agent must compare whole screen images to calculate what portion is updated to send just the delta information. Therefore, the more memory that can be made available on the client, the better the performance is. And if the client is page faulting all the time because of other applications' memory use, the remote control performance suffers, too.

Background Wallpaper

If a background wallpaper is in use on a client, then the remote control agent has to update it as windows are moved around on the desktop. Removing background wallpaper, especially complex multi-color ones, reduces the load on the agent. It is possible to disable the client wallpaper during remote control sessions via a switch available through the menus on the Remote Control Client Viewer Window. If this option is set, the wallpaper is removed for the duration of the remote control session and reinstated at the end of the session.

Troubleshooting Remote Tools

Failure to Install

There can be occasions when it appears that the remote tools agent fails to install on clients. Breakdowns can occur in a number of places.

Remote Tools Agent Is Not Enabled.

The remote tools client agent is installed only if it is enabled via the Admin UI. The General tab of the Remote Tools Client Agent property sheet contains a check box that enables the Remote Tools Client Agent. If this is changed (switched on or off) after a client is installed (i.e., the base Systems Management Server client components are installed), then it can take up to 23 hours for this change to be implemented. Restarting the client or stopping and starting the Systems Management Server Client Service (on Windows NT-based clients) accelerates the process.

Remote Control Client Installation Failed

The installation program to install the Remote Tools agent may have run, but, for some reason, failed to complete. The installation log file can be viewed to determine why. The log file is %WINDOWS%\MS\SMS \Logs\remctrl.log. One possible reason for failure to install is if another remote control agent is already installed on the client. In particular, the Systems Management Server Remote Tools agent does not run in parallel with remote control agents from Intel's LANDesk and Novell's Z.e.N Works. On installation, if one of these other agents is detected, then the Systems Management Server agent is not installed.

Configuration Updates Are Not Implemented on the Client

The flexibility in the configuration possibilities provided by the remote tools feature can also lead to the apparent failure to update the client with configuration changes made by an administrator. If changes made in the configuration do not appear to get implemented on the client, these checks should be made:

Have you waited long enough? During normal operation of Systems Management Server, updates to client agent configuration are passed to the client only every 23 hours. Restarting the client or stopping and starting the Systems Management Server Client Service can accelerate this process.

Is the client choosing to use local settings? If the Admin has not chosen to "lock down" the clients, then a user at the client is free to choose their own configuration settings. Check the Use Local Settings value in the User Settings staging area of the client's registry (if troubleshooting remotely). If it is 1, then the client is in local mode, and site-wide changes do not take effect.

Has the Munger been disabled? Check the UpdateEnabled value in the HKLM\Software\Microsoft\SMS \Client\Client Components\Remote Control\ key on the client Registry. If it is present and set to "No", then the Munger will not run, and no updates take place.

Has the Munger run? Look under the Sites area of the client Registry (as described above) and at the Combined Sites staging area. Have they been updated according to the Munger description above? And have these settings been replicated to the working set? If not, check the log file in %WINDOWS%\MS\SMS \Logs\Remctrl.log. It will log when it is run and even say if the Munger is disabled. You can run the Munger manually on the client simply by running the RCCLICFG.EXE program, though you must be a local administrator to be able to write to the Registry.

Failure to Connect

Even when the Remote Tools Client Agent has been installed, invoking Remote Tools from the Admin UI may fail to connect to the client.

Is the Agent Running

The Remote Tools agent must be running on the client to establish a session. If the agent is configured to be showing a visible signal always (whether the System Tray icon or the High Security Window), then the presence of the icon verifies that the agent is running. Otherwise on Windows NT, use the Service Manager from the Control Panel to determine if the Systems Management Server Remote Control Service is installed and running.

On clients running Windows 95 or Windows 98 operating systems, the agent is not run as a Service. To determine if it is running, open the Remote Control applet in the Control Panel. The first tab has a Status pushbutton, which, when clicked, should open the Remote Tools Agent's Status Window. If the Window opens, then the agent is running.

On Windows 3.x clients, the agent always appears as a running task.

The agent can be run manually on all platforms. On Windows NT, if the agent is not running (the Service is disabled or stopped), the agent can be started by running WUSER32 /nosvc. This runs the agent in a non-service context, so it is running as the current logged-on user, and terminates when the user logs out. On Windows 9x clients, simply running WUSER32 starts the agent. In both cases, it can be stopped by running WUSER32 /x. Note that using this method to attempt to disable the agent on Windows 95 or Windows 98 is only temporary, as the Systems Management Server Client Service detects that the agent is not running and attempts to restart it.

Is the Protocol Correct

Most failure to connect problems can be attributed to protocol problems. To determine which protocol the agent is listening on, double-click the remote control icon or invoke the Status window from the control panel as described above. The Status window displays the protocol that is being used. If you have changed the protocol in the Admin UI after the agent has been installed on the client, the client will not have picked up the change unless you have run rchwcfg.exe install as described earlier.

When you run Remote Tools from the MMC, the Remote Tools Window appears and a list box is shown that gives information on the attempts the application is making to connect to the client. This can reveal useful information, especially when connections fail.

On running the Remote Tools application, the Systems Management Server database is searched for the client you are attempting to connect to. All address information for that client is used to attempt a connection. This information is the Discovery information, which is collected when the client is first discovered or subsequently updated through Heartbeat Discovery or other methods. It can be viewed by looking at the Properties of the resource in the MMC.

The Remote Tools application sends out requests on all of the addresses for all of the protocols it knows about. The agent normally listens on one address on a specific protocol. When the agent receives a connection request it recognizes (correct address and protocol), it responds. When the Remote Tools application receives this response, it immediately stops all of the other parallel connection attempts and uses the address and protocol of the responding attempt. After this initial negotiation, there is no logical connection maintained for the duration of the Remote Tools session, a connection is established for each Remote Tool that is run. It will always be on the protocol and address that made the first connection.

Another possible failure to connect is that the client and Admin machine may not share a common protocol. The protocols supported by each end of the connection should be checked.

Video Accelerators

One of the most important factors in getting the best performance from remote control of Windows NT-based machines is the use of the accelerated video driver (IDISNTKM.DLL in NT4.0 and 5.0, IDIS_NT.DLL in NT 3.51). Windows NT remote control is raster-based. Without the accelerated video driver, every update of the screen requires the whole screen image to be sent, which is obviously going to be slow. The accelerated video driver compares the screen images and sends only the differences to the viewing machine. So except when the whole screen is constantly changing, performance will be increased and network usage decreased.

In the Advanced tab of the Remote Tools Client Agent property sheet in the Admin UI, you can set whether the accelerated video drivers should be installed on clients. You can also specify which video drivers it will be installed for. While there are currently no known issues with any particular video driver or card, it may be the case that some "bad" card type of driver is encountered that interferes with the remote control accelerated video driver. Since this runs in Kernel mode (on Windows NT 4.0), problems can manifest with a blue-screen that is to be avoided at all costs. It is, therefore, recommended that the video acceleration is tested with each of the video drivers in use before the remote control feature is rolled out.

The video accelerator is installed by the Hardware Munger when the remote control agent is installed on the client. This process is described here, which should allow the manual installation or deinstallation of the driver, should it be so required.

Firstly, it must be determined where the video drivers are located. The Registry key HKLM\HARDWARE\DEVICEMAP\Video is read and the values for \Device\VideoX are read. For example, the results could be:

\Device\Video0: \REGISTRY\Machine\System\ControlSet001\Services\chips\Device0

\Device\Video1:\REGISTRY\Machine\System\ControlSet001\Services\VgaSave\Device0

The device containing VgaSave is never touched by this process, as it could be your only way back into the system (using VGA Save mode on bootup) if the process fails badly.

Thus, using the contents of the \Device\Video0 value, we next look at the registry key it is pointing to, i.e., HKLM\System\ControlSet001\Services\chips\Device0. In this key is a value called InstalledDisplayDrivers, which is a REG_MULTI_SZ containing the video driver list. This is the value that is operated on in the next steps.

When the Systems Management Server administrator elects to have the video accelerator installed with the Remote Control client on all the Windows NT clients using his site, a chain of events is set into motion. These events are:

The Remote Control client installation executable copies the appropriate dll to the client's %WINDIR%\system32 directory (idis_nt.dll for Windows NT 3.51 clients, idisntkm.dll for NT 4.0 and 5.0 clients).
The Remote Control client installation executable calls rchwcfg.exe and has it set up the video driver list on the client so that the accelerator will be loaded. For this example, we'll look at a Windows NT 4.0 system having a plain vanilla SVGA card (and no proprietary driver for it); the video driver list initially looks something like this:

vga vga256 vga64k

After RCHwCfg.exe has run, this video driver list will have been changed to:

idisntkm vga idisntkm vga256 idisntkm vga64k

The designation for the Windows NT 4.0 video accelerator (idisntkm) appears BEFORE the name of each video driver in the list compatible with and capable of supporting video acceleration.
Once the Remote Control client installation has finished, the WUSER32 service is autostarted. However, since the video driver can't be changed on-the-fly, the WUSER32 service doesn't have the use of the video accelerator at this time. The client must be rebooted for the video accelerator to load.
On the first reboot after installation, the VGA driver is used and attempts to load the video accelerator. It probably does not support the video accelerator, so the accelerator isn't loaded. To prevent further attempts at loading the accelerator with this driver, it is removed from the driver list. At the end of this step, the video driver list is

vga idisntkm vga256 idisntkm vga64k
On the second reboot after installation, the video driver vga256 is to be used and is supposed to support video acceleration, so the attempt is made to load the video accelerator. The load may be successful, or it may not. If the accelerator loaded successfully, the video driver list after this step is

vga idisntkm vga256 idisntkm vga64k

In this event, the video accelerator is loaded (with the vga256 driver) on all successive reboots of the client.

If the accelerator didn't load successfully, the video driver list after this step is

vga vga256 idisntkm vga64k
If the video accelerator didn't load on the second reboot, then the vga64k video driver is used on the third reboot. The video driver may or may not load successfully. If the load is successful, then the video driver list after this step is

vga vga256 idisntkm vga64k

In this event, the video accelerator is loaded (with the vga64k driver) on all successive reboots of the client.

If the load is not successful, the video driver list after this step is

vga vga256 vga64k

In this event, the video accelerator is never loaded on the client.

IN THE EVENT that the video card in the client has a proprietary video driver (such as an S3), then the video driver list may look like this

vga vga256 s3 vga64k

Since the S3 is on the list of Video Drivers that can support video acceleration, during Remote Control client installation, the video driver list is changed to

idisntkm vga idisntkm vga256 idisntkm s3 idisntkm vga64k

During the reboot sequences, if the S3 driver can load the video accelerator successfully, then it is selected as the driver to be used during all successive reboots.

HOWEVER, if the video card in the client has a proprietary video driver that is NOT on Intel's list of video drivers that can support video accelerator (call this driver NGD), then the client's video driver list is changed by Remote Control installation to

idisntkm vga idisntkm vga256 NGD idisntkm vga64k

In this case, the video accelerator is loaded only if the vga256 or vga64k driver is selected for use once all the required reboots are completed.

Remember The process of Windows NT trying out the next video driver in the list on successive reboots stops once a driver successfully loads the accelerator. Windows NT does not move on and attempt to use any driver in the video driver list after vga256 if vga256 successfully loads the accelerator. Thus, even if the proprietary driver could support the accelerator, if the name of the driver is positioned in the list AFTER the name of a generic driver that successfully loads the accelerator, then the proprietary driver won't be used.

Appendix A: Status System Command-Line Arguments

The Systems Management Server status system provides a feature you can use to execute programs when status messages are processed. You can use this feature to execute customized programs that send electronic mail (e-mail) or alert paging systems when critical errors occur or milestones are reached. For example, you might want to receive a beeper notification when a package has been successfully distributed to distribution points. Or, you might want to receive an e-mail message when the Systems Management Server Executive service produces an error message.

Warning: The Status Manager's processing will be blocked until the specified program exits; therefore, it is important to only specify programs that exit very soon after they are started.

You can access the Run a program status filter rule feature by navigating to Status Filter Rules in the Systems Management Server Administrator console.

remotep

Right-click Status Filter Rules, select New, click Status Filter Rule, and then select the Actions tab. When you type a program name, the Status Manager executes the specified program and command-line arguments. You can also specify escape sequences that the Status Manager resolves to different characteristics of the status message before executing the program. In this way, you can pass the characteristics of the status message as command-line arguments to the program. For example, if you type the following expression, Systems Management Server sends an alert message to the user logged on to the Systems Management Server Administrator console.

net send %sitesvr The Systems Management Server component %msgcomp reported a status message.

Every time SMS _EXECUTIVE reports a status message that matches this rule, an alert message that says: "The Systems Management Server component SMS _EXECUTIVE reported a status message" is sent.

Each of the escape sequences begins with the % character and is followed by zero or more alphanumeric characters (A-Z, a-z, 0-9). The escape sequences are case-sensitive. The escape sequence %% is converted to a single % character. Escape sequences do not need to be followed by a space for Systems Management Server to recognize them.

For example, the command line:

pageme.exe "%comp's dead!"

would result in Systems Management Server executing the command line:

pageme.exe "SMS _EXECUTIVE's dead!"

The following table enumerates all of the possible escape sequences.

Command-Line Escape Sequences for Status

Escape sequence
Status Message Properties
%msgsc
%msgsys
%msgsrc
%msgcomp
%msgpid
%msgtid
%msgtype
%msgsev
%msgid
%msgdesc
%msgis01
%msgis02
%msgis03
%msgis04
%msgis05
%msgis06
%msgis07
%msgis08
%msgis09
%msgis10
%msglta
%msgltA
%msgltb
%msgltB
%msgltd
%msgltH
%msgltI
%msgltj
%msgltm
%msgltM
Status Message Properties
%msgltp
%msgltS
%msgltU
%msgltw
%msgltW
%msglty
%msgltY
%msgltZ
%msggmta
%msggmtA
%msggmtb
%msggmtB
%msggmtd
%msggmtH
%msggmtI
%msggmtj
%msggmtm
%msggmtM
%msggmtp
%msggmtS
%msggmtU
%msggmtw
%msggmtW
%msggmty
%msggmtY
Current Site Properties
%sc
%parentsc
%sitesvr
%sqlsvr
Miscellaneous
%%
%lta
%ltA
%ltb
%ltB
%ltd
%ltH
%ltI
%ltj
%ltm
%ltM
%ltp
%ltS
%ltU
%ltw
%ltW
%lty
%ltY
%ltZ
%gmta
%gmtA
%gmtb
%gmtB
%gmtd
%gmtH
%gmtI
%gmtj
Miscellaneous
%gmtm
%gmtM
%gmtp
%gmtS
%gmtU
%gmtw
%gmtW
%gmty
%gmtY

For More Information

For the latest information on Systems Management Server, check out our World Wide Web site at https://www.microsoft.com/smsmgmt/.

Remote Diagnostics with Systems Management Server Version 2.0

On This Page

Introduction

Understanding the Status System

Changes Since Systems Management Server 1.2

Understanding Status Messages

Status Message Characteristics

Status System Architecture

Client Component Flow

Client Status MIF Flow

Client Access Point Flow

Server Component Flow

Status Manager Flow

Interpreting the Status System

Status Summarizer Concepts

Monitoring and Troubleshooting with System Status

Maintaining and Tuning the Systems Management Server Status System

Status Reporting Configuration

Status Filter Rules

Tuning Status Message Configuration with Status Filter Rules

When to Use Status Filter Rules

Configuring Status Filter Rules

Configuring Status Summarizers

Deleting Status Messages

Resetting the Status Summarizers

Status System Performance

Integrating the Status System with Third-Party Solutions

Creative Uses of the Status System

Using Remote Tools

Changes Since Systems Management Server 1.2

Configuration

Security

Performance

Troubleshooting Remote Tools

Video Accelerators

Appendix A: Status System Command-Line Arguments

For More Information

Additional resources