Status Message Process Flow

[Previous] [Next]

Now that we've examined the different tools for handling status messages, let's look at the status message process flow. Nearly every SMS 2.0 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 (logon points, client access points, and so on) and agents running on SMS clients also generate status messages. The status message system in SMS 2.0 has the capacity to generate a multitude of messages; however, 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 are generated by SMS services and components on site systems are copied to the site server so that they can be updated to the SMS database. Figure 5-38 illustrates the process flow for status messages generated on the site server and site systems.

As mentioned in the section "Configuring Status Reporting Properties" earlier in this chapter, 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 NT event. When a status message is generated by an SMS service or thread, its properties are checked by that service or thread to see whether this option has been set. If it has, the status message is first converted to a Windows NT event and written to the Windows NT 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 the message was generated by a thread component or in Status Manager's inbox (SMS\Inboxes\Statmgr.box\Statmsgs) as an .SVF file if the message was generated by a service component. 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 in the WINNT\System32\Smsmsgs subdirectory on the site system and retries until it can successfully copy the status message to Status Manager's inbox on the site server.

Figure 5-38. Status message process flow for status messages generated on the site server and site system.

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 5-39 illustrates the flow of status messages from the client 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 MIFs. For example, both the package program created through the SMS Administrator Console and the packages compiled through SMS Installer have the ability to generate status .MIF files upon the execution of the program or package.

Figure 5-39. Status message process flow from the client to the site server.

When a status message is generated on the SMS client by an SMS client component, the message's properties are checked by that component to determine whether the message needs to be converted to a Windows NT event. If so and if the SMS client is also a Windows NT client, the status message is written to the Windows NT Event Log. Next the status message and status .MIF files are written to an .SVF file and stored in the system root (Windows or WINNT, for example) or in the Temp or TMP directory. The client component then initiates a request for the Copy Queue on the client to move the .SVF file to Status Manager's inbox on the CAP (CAP_sitecode\Statmsgs.box). Copy Queue is an SMS client component that writes data to CAPs and logon points reliably. When Copy Queue has trouble writing its error messages to the CAP, it will write them to the CQMgr32.log file instead.

At this point, if the CAP is a Windows NT server, the Inbox Manager Assistant thread wakes up and moves the .SVF file to Status Manager's inbox on the site server. If the CAP is not a Windows NT server—that is, it is a NetWare server or an NDS server—the Inbox Manager thread on the site server will copy the .SVF file from that server to Status Manager's inbox on the site server at its next polling cycle. Inbox Manager, by default, polls these CAPs once every 15 minutes.

TIP

---

Each client component generates a log file in the 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. Additionally, in the log file of the component that should have generated the status message, look for a line that begins with "STATMSG" from around the time the status message should have been generated. If that line doesn't exist, or if the next line begins with the text "CServerStatusReporter," the component may have had trouble generating and reporting the status message. Refer to Chapter 23 of the Microsoft Systems Management Server 2.0 Resource Guide (part of the Microsoft BackOffice 4.5 Resource Kit, available through Microsoft Press) for a complete discussion of the status message reporting process and troubleshooting tips.

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 and those modified by the SMS administrator. Remember, a status message can be handled in one of five ways, as shown in Figure 5-40.

The status message could be written to the SMS database, converted to a Windows NT event and written to the Windows NT Event Log, or 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 Windows NT workstation desktop, the execution of a batch file, or a notification using paging software.

As you can see, the status messaging system in SMS 2.0 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.

Figure 5-40. Using status filter rules to handle a status message.