Now that we’ve examined the different tools
for handling status messages, let’s look at the status message process
flow. Nearly every SMS 2003 service and component generates status
messages. Not only does the site server itself generate messages, as
one would expect, but the components and services running on site
systems (management points, client access points, and so on) and agents
running on SMS clients also generate status messages. The status
message system in SMS 2003 has the capacity to generate a multitude of
messages; however, as we’ve seen, status summarizers and filters keep
these messages to a manageable level by default. Nevertheless, status
message reporting can add to your existing network traffic bandwidth
issues.
Reporting Status on Site Servers and Site Systems
Status
messages generated on the site server are processed within the site
server itself and then updated to the SMS database. If the SMS database
resides on the same server, no additional network traffic is generated.
However, status messages that SMS services and components generate on
site systems are copied to the site server so that they can be updated
to the SMS database. Figure 1 depicts the process flow for status messages generated on the site server and site systems.
Several options are available to the SMS
administrator when configuring status message reporting. Remember that
one option enables the SMS administrator to specify whether to convert
the status message to a Windows event. When an SMS service or thread
generates a status message, that service or thread checks its
properties to see whether this option has been set. If it has, the
status message is first converted to a Windows event and written to the
Windows Application Event Log. If no other reporting options have been
configured, the process stops here. If other reporting options have
been configured, the status message must be handed off to the Status
Manager component on the site server. If the server on which the status
message was generated is the site server, the status message is placed
either in Status Manager’s In Memory Queue if a thread component
generated the message or in Status Manager’s inbox
(SMS\Inboxes\Statmgr.box\Statmsgs) as an .SVF file if a service
component generated the message.
If the
server on which the status message was generated is a site system, the
status message is copied to Status Manager’s inbox on the site server.
If for some reason the component is unable to copy the status message
to the site server, it stores the status message(s) in the
%Systemroot%\System32\Smsmsgs subdirectory on the site system and
retries until it can successfully copy the status message to the Status
Manager’s inbox on the site server.
Reporting Status from Clients
As
we’ve seen, SMS components and agents residing on SMS clients also
generate status messages, and these messages too must be reported back
to the site server for updating to the SMS database. Figure 2
illustrates the flow of status messages from the SMS Legacy Client to
the site server. Status messages generated on the SMS Advanced Client
are propagated to the site’s management point and from there moved to
the site server.
Status
information is collected not only from SMS client components and
agents, but also as the result of application installations in the form
of status MIF files. For example, both the package program created
through the SMS Administrator Console and the packages compiled through
the SMS Installer have the ability to generate status MIF files upon
the execution of the program or package.
When
a status message is generated on the SMS client by an SMS client
component, its properties are checked by that component to determine
whether the message needs to be converted to a Windows event. If so,
and if the SMS client is also a Windows NT client or higher, the status
message is written to the Windows Application Event Log. Next, the
status message and status MIF files are written to an .SVF file and
stored in the %Systemroot% or in the Temp or TMP directory. The client
component then initiates a request for the Copy Queue component on the
client to move the .SVF file to the Status Manager’s inbox on the
client access point (CAP) (CAP_sitecode\Statmsgs.box).
Copy Queue is an SMS client component that writes data to CAPs and
management points reliably. When Copy Queue has trouble writing its
error messages to the CAP, it will write to the CPQMgr32.log file in
the %Systemroot%\MS\SMS\Logs file on the client in question. After the
file is written to the management point or the CAP, the Inbox Manager
Assistant thread wakes up and moves the .SVF file to Status Manager’s
inbox on the site server.
Tip
Each
client component generates a log file in the %Systemroot%\MS\SMS\Logs
directory on the client computer by default. Check these log files to
determine whether the .SVF file was created during troubleshooting of
status message generation. In addition, in the log file of the
component that should have generated the status message, look for a
line that begins with “STATMSG” on or around the time that the status
message should have been generated. If it doesn’t exist, or if the next
line begins with the text “CserverStatusReporter,” the component might
have had trouble generating and reporting the status message. |
Reporting Status to the SMS Database
Once
the status message is written to its in-memory queue or to its inbox,
Status Manager wakes up and reads the status message or .SVF file. It
evaluates the message against the status filter rules established by
SMS during setup or modified by the SMS administrator. As we’ve
discussed, a status message can be handled in one of five ways, as
shown in Figure 3.
The
status message could be written to the SMS database or discarded. If
the Status Manager has not already done so, the status message could be
converted to
a Windows event and written to the Windows event log. The status
message could be handed to a status summarizer to be condensed for
viewing through the SMS Administrator Console. If a parent site exists,
the message could be sent to the parent site for inclusion in its SMS
database or viewing through its SMS Administrator Console. The SMS
administrator could also configure a program to be executed upon
receipt of a status message. This program might be a system pop-up
notification on the SMS administrator’s desktop, the execution of a
batch file, or a notification using paging software.
As
you can see, the status messaging system in SMS 2003 is quite robust
and is capable of inundating you with information about your site
server, site systems, and clients. Fortunately, you can control which
status messages are reported and how these messages are handled, and
you can tailor their generation to fit your specific reporting needs.
